spec-plan-ship

Granular implementation plan with ordered tasks and typed architectural anchors. Acts as Software Architect to define HOW, WHERE, and in what ORDER. Reads spec from docs/specs/ or accepts inline description. Produces tasks of 2-5 min each with exact file paths, typed signatures (interfaces, function contracts), specific instructions, verification steps, and test requirements. References existing patterns in the codebase. Includes adversarial review via subagent before presenting. Use after /feature-spec or directly for small-medium changes.

Feature specification before coding. Captures WHAT, WHY, and key design decisions. Produces specs with problem statement, requirements, acceptance criteria, design decisions, schema/API/UI changes, risks, and deploy checklist. Detail scales to complexity — simple features get short specs, complex features get comprehensive specs that capture the full decision context. Use when: "new feature", "I want to add", "let's build", "feature spec", or before any non-trivial implementation. Saves spec to docs/specs/ for review and approval before planning.

Test-Driven Development enforcement. Use when implementing tasks from a feature plan, fixing bugs, or adding new functionality. Follows the classic RED-GREEN-REFACTOR cycle: write a failing test first, implement the minimum code to pass it, then refactor. Integrates with /feature-plan tasks that have Tests: Yes. Use with: "tdd", "write tests first", "test driven", or before implementing any task marked for testing.

Designs operational functional tests for Medium+ features before production. Use after /test-plan when a feature changes a real business capability, workflow, automation, user journey, pipeline, agent behavior, admin/operator handoff, cron, webhook, or multi-step system flow. Focuses on whether the product works in realistic operation, not only whether functions, endpoints, or UI components pass tests.

Full test plan for Medium+ complexity features. Reads the approved plan (which already has a Test Matrix section), and expands it into a comprehensive standalone test suite — detailed cases, fixtures, factories, E2E flows, parallelization groups, and adversarial review. Use for features with cross-layer interactions (DB + API + UI), multiple consumers, shared state, or greenfield projects. NOT needed for Low complexity features where the plan's embedded Test Matrix is sufficient. Use after /feature-plan and before implementation.