sdd

Reviews technical plans against the codebase for feasibility, correctness, and completeness. Use after /plan to get a second opinion before approving the plan.

Reviews functional specifications for completeness, ambiguity, and missing edge cases. Use after /spec to get a second opinion before approving the spec.

Implements tasks using strict Test-Driven Development (Red-Green-Refactor). Works through the task list one at a time, each producing a verified, tested change. Use when user says "implement", "start coding", "begin implementation", "TDD this", "build it", or after running /tasks. Do NOT use for exploratory coding or prototyping without a task list. Requires a task list in context and an active feature branch.

Automates batch file migrations from one pattern to another. Language and framework agnostic. Use when user says "migrate files", "batch migration", "convert all files from X to Y", "replace pattern across files", "mass refactor", or "migrate codebase". Do NOT use for single-file changes or non-migration refactors.

Creates a technical plan from a functional spec. Defines HOW to build it: architecture decisions, data models, testing strategy, constraints. Reads the actual codebase for context. Use when user says "plan this", "technical plan", "how to build", "architect", "design the solution", or after running /spec. Do NOT use without a spec — run /spec first.

Validates completed batch migrations for consistency and correctness. Checks for residual old patterns, runs tests, verifies build, and generates a quality report. Use when user says "review migration", "validate migration", "check migration status", "verify batch changes", or after running /migrate. Do NOT use if no migration has been performed.

Reviews code changes before shipping. Checks for bugs, security issues, performance problems, test coverage gaps, and adherence to project conventions. Use when user says "review code", "review changes", "check my code", "code review", "review before PR", or between /implement and /ship. Do NOT use for spec review (use spec-reviewer agent) or plan review (use plan-reviewer agent).

Orchestrates the complete Spec Driven Development pipeline: spec -> plan -> tasks -> implement -> review -> ship. Use when user says "new feature", "full development cycle", "run", "build this end to end", "start feature", or provides a user story / PRD to implement from scratch. Do NOT use for quick fixes or single-file changes — use individual phase skills instead.

Commits, pushes, and opens a pull request for completed work. Uses Conventional Commits format and gh CLI for PR creation. Use when user says "ship", "create PR", "open pull request", "push", "ship it", "commit and PR", or after running /implement. Do NOT use without running /review first or with failing tests. All tests must be passing before shipping.

Writes a functional specification for a feature, bug fix, or change. Describes WHAT to build, not HOW. Uses Given/When/Then acceptance criteria. Technology-agnostic. Use when user says "write spec", "specify feature", "define requirements", "what should this do", or pastes a user story / PRD / feature request. Do NOT include implementation details — use /plan for that.

Synchronizes CLAUDE.md and .claude/ configurations across similar projects. Detects project type, compares against templates, and propagates updates. Use when user says "sync configs", "update CLAUDE.md across projects", "standardize configs", or "check config consistency". Do NOT use for initial project setup from scratch.

Breaks a spec and plan into small, ordered, self-contained tasks. Each task is completable in a single agent session with tests. Creates a GitHub issue and feature branch. Use when user says "break into tasks", "create tasks", "task breakdown", "decompose", "create issue", or after running /plan. Do NOT use without a spec and plan in context. Requires gh CLI authenticated and a Git repository.

Debugs issues using competing hypotheses in parallel via agent teams. Multiple teammates investigate different theories simultaneously and challenge each other's findings to converge on the root cause. Use when user says "team debug", "parallel debug", "investigate with team", "competing hypotheses", "debug in parallel", or when the root cause is unclear and multiple theories are plausible. Do NOT use for obvious bugs with clear stack traces — debug directly instead. Do NOT use when agent teams are not enabled.

Implements multiple tasks in parallel using agent teams. Each teammate owns a set of independent tasks and follows TDD (Red-Green-Refactor). Uses shared task list for coordination. Use when user says "team implement", "parallel implement", "implement in parallel", "implement with team", or when there are 3+ independent tasks that touch different files. Do NOT use for sequential tasks with dependencies — use /implement instead. Do NOT use when agent teams are not enabled.

Orchestrates a parallel multi-perspective code review using agent teams. Spawns specialized reviewers (security, performance, tests, conventions) that work simultaneously and challenge each other's findings. Use when user says "team review", "parallel review", "deep review", "multi-perspective review", "thorough code review", or when reviewing large or critical changes. Do NOT use for quick reviews of small changes — use /review instead. Do NOT use when agent teams are not enabled.

Closes the SDD loop after a PR merges by consolidating review findings, post-review commits, and user-stated lessons into the repo-scoped wiki. Locates the preliminary wiki page by PR number, gathers post-merge context via gh CLI, then delegates to /sdd:wiki-ingest --final with cross-references back to the preliminary. Use when user says "close loop", "wiki close-loop", "post-merge ingest", "archive lessons", or after merging a PR that has a preliminary wiki entry. Do NOT use before the PR is merged — the lessons are not yet final. Do NOT use for spec/plan/tasks ingestion (that is /ship Step 9).

Ingests SDD artifacts (spec, plan, tasks summary, review findings, lessons) into the repo-scoped `.wiki/` knowledge base. Two modes: `--preliminary` (post-ship, pre-merge) writes spec/plan/tasks-summary pages; `--final` (post-merge) writes review-findings and lessons pages cross-linked to the preliminary. Use when user says "ingest wiki", "save to wiki", "archive to wiki", "write to .wiki", or when /ship/close-loop delegate here. Do NOT use for wiki consultation (that is handled inline by /spec, /plan, and /wiki:close-loop via scripts/wiki-query.sh). Do NOT write wiki pages without explicit user confirmation.

1 hook across 1 event