AI Agent & Automation Workflows

Use when the user wants to fix, address, clear, or resolve open Dependabot security/vulnerability alerts for a repository, end to end. Fetches open alerts via the gh CLI, fixes them per ecosystem (pnpm/npm overrides + lockfile regen, cargo update, pip/go/bundler), verifies with audit and frozen-lockfile installs, then branches → commits → pushes → opens a PR, and squash-merges once CI is green — escalating only when a fix carries breaking-change risk or can't be resolved. Trigger on "/dependabot-sweep", "address the dependabot alerts", "fix the security vulnerabilities", "clear the dependabot alerts", "handle the dependency vulnerabilities", "sweep dependabot".

Use when user invokes /docgen to generate or update documentation. Also triggers on "generate docs", "update the README", "write the changelog". Accepts a doc type (readme, api, architecture, changelog) and optional scope. Always outputs to conversation first and asks before writing to disk. Do NOT use for explaining code behavior — use /explain instead.

Use when user invokes /harness-compile or wants to compile a harness.yaml into native config files for Claude Code, Cursor, and GitHub Copilot. Generates CLAUDE.md, AGENT.md, .mcp.json, .cursor/rules/, .vscode/mcp.json, and related files from a single harness.yaml source. Supports --target, --dry-run, and --clean flags.

Harness Kit documentation — installation, plugin catalog, creating plugins, cross-harness setup, architecture, and FAQ. Use when working with or configuring harness-kit plugins, understanding the plugin/skill system, installing slash commands, setting up AI coding tool configuration, answering questions about the plugin marketplace, writing SKILL.md files, using harness.yaml, or integrating with Copilot, Cursor, or Codex. Do NOT use for general Claude Code questions unrelated to harness-kit.

Use when user invokes /harness-export or wants to save their current harness-kit plugin setup to a shareable harness.yaml file. Detects installed skills, collects source info, and writes the config in Harness Protocol v1 format. Do NOT use for importing or restoring a harness — use /harness-import instead.

Use when user invokes /harness-import or wants to install plugins from a shared harness.yaml config file. Reads the config, presents each plugin interactively, and generates the Claude Code install commands for the ones the user selects. Handles both Harness Protocol v1 format (version: "1") and the legacy format (version: 1).

Use when user invokes /harness-sync or wants to sync AI tool configurations across Claude Code, Cursor, and GitHub Copilot. Inventories installed skills, instruction blocks, and MCP configs on all detected platforms, reports divergence, and lets the user push or pull changes. Push path reuses harness-compile logic. Pull path updates harness.yaml and recompiles. Never overwrites without explicit confirmation.

Use when user invokes /harness-validate or wants to check whether a harness.yaml file is valid according to the Harness Protocol v1 JSON Schema. Reports validation errors with field paths and helpful fix suggestions.

macOS desktop notifications and iTerm2 badge management for Claude Code lifecycle events. Not a slash command — this plugin provides hook scripts. See README for wiring instructions.

Use when user invokes /lineage with a column name (optionally qualified with table/schema). Also triggers on "trace this column", "where does X come from", "what reads from Y table". Traces column-level data lineage through SQL, Kafka, Spark, JDBC, and ORM codebases. Produces a structured lineage path with confidence ratings and an SVG or ASCII diagram. Do NOT use for general code explanation — use /explain instead.

Use when you want to sweep all open pull requests across all repos, triage their status, run code reviews on unreviewed PRs, merge what's ready, fix quick blockers, and produce a full status report. Trigger when the user says "check my PRs", "close out open PRs", "what's the status of my PRs", "sweep my PRs", "PR sweep", "pull request sweep", or wants a cross-repo PR status report. Future: pairs with the loop skill for ongoing automated PR management.

Use when you've planned a non-trivial change and are about to implement it, finished a complex or multi-file piece of work, just wrote tests, or are stuck on repeated failures — and any time the user says "rubber duck this", "rubber ducky", "get a second opinion", "sanity-check my plan", "poke holes in this", "what am I missing", "critique my approach", "review this before I build it", or "/rubber-ducky". Spawns independent read-only critics on DIFFERENT Claude models than the one driving the session to catch blind spots, design flaws, and substantive bugs while course corrections are still cheap. Skip it only for small, obvious, well-understood changes. Do NOT use for reviewing a finished diff or PR — use /review for that; rubber-ducky pressure-tests your own in-progress thinking before and during implementation.