// Create a comprehensive specification from a brief description. Runs requirements gathering, solution design, and decomposition — routing decomposition to one of three tiers based on a complexity classifier: Direct (no plan), Incremental (linear phase plan), or Factory (parallel units with holdout scenarios).
Lightweight implementation orchestrator for low-complexity work — fixes, refactors, doc changes, or single-AC features that do not warrant a phase plan or factory decomposition.
Linear phase-loop orchestrator for single-feature implementation plans. Use for medium-complexity work where transparent human-in-the-loop phase review is preferred over factory automation.
Implementation entry point. Use to execute a completed specification. Auto-detects the decomposition tier (Direct, Incremental, or Factory) from spec artifacts and dispatches to the matching execution sub-skill.
Decompose a single-feature specification into a linear, phase-by-phase implementation plan. Use this for medium-complexity work — single feature, one or two components — where transparent human-in-the-loop phase review is preferred over factory automation.
Scaffold, status-check, and manage specification directories. Use when creating a new spec, reading spec status, transitioning between phases, or logging decisions on a spec in .start/specs/.
Factory loop orchestrator for multi-feature or multi-component implementation manifests. Use for high-complexity work with parallel-eligible workstreams and holdout-scenario evaluation.
| name | specify |
| description | Create a comprehensive specification from a brief description. Runs requirements gathering, solution design, and decomposition — routing decomposition to one of three tiers based on a complexity classifier: Direct (no plan), Incremental (linear phase plan), or Factory (parallel units with holdout scenarios). |
Act as an expert requirements gatherer that creates specification documents for one-shot implementation.
Description: $ARGUMENTS
SpecStatus { requirements: Complete | Incomplete | Skipped solution: Complete | Incomplete | Skipped decomposition: { tier: Direct | Incremental | Factory | None status: Complete | Incomplete | Skipped } readiness: HIGH | MEDIUM | LOW }
State { target = $ARGUMENTS spec: string // resolved spec directory path (from specify-meta) perspectives = [] mode: Standard | Agent Team classification: Direct | Incremental | Factory // from reference/classifier.md status: SpecStatus }
Always:
.start/ and docs/ directories.Never:
Use the specify-meta skill to create or read the spec directory.
match (spec status) { new => Ask the user to choose: Start with Requirements (recommended) — define requirements first Start with Solution — skip to technical design Start with Decomposition — skip to tier classification (requires existing requirements + solution) existing => Analyze document status (check for [NEEDS CLARIFICATION] markers). Suggest continuation point based on incomplete documents. }
Ask the user to choose: Standard (default) — parallel fire-and-forget research agents Agent Team — persistent researcher teammates with peer collaboration
Recommend Agent Team when: 3+ document phases planned, complex domain, multiple integrations, or conflicting perspectives likely (e.g., security vs performance).
Read reference/perspectives.md for applicable perspectives.
match (mode) { Standard => launch parallel subagents per applicable perspectives Agent Team => create team, spawn one researcher per perspective, assign tasks }
Synthesize findings per the synthesis protocol in reference/perspectives.md. Research feeds into all subsequent document phases.
Use the specify-requirements skill.
Focus: WHAT needs to be built and WHY it matters. Scope: business requirements only — defer technical details to Solution.
Ask the user to choose between Continue to Solution (recommended) and Finalize Requirements.
Use the specify-solution skill.
Focus: HOW the solution will be built. Scope: design decisions and interfaces — defer code to implementation.
If a CONSTITUTION.md exists at the project root, use the validate skill in constitution mode to verify the architecture aligns with the rules.
Ask the user to choose between Continue to Decomposition (recommended) and Finalize Solution.
Read reference/classifier.md and apply the complexity heuristic to requirements.md and solution.md.
Surface the classification with rationale — show the signals that drove it (feature count, AC count, component count, change type, parallel markers).
Ask the user to choose the decomposition tier (under header "Decompose"):
Highlight the classifier's recommendation. The user may override freely.
Log the decomposition tier choice in the spec README decisions table per reference/classifier.md decision-logging guidance.
match (user choice) { Direct => skip to step 7 (no decomposition artifact written; implement-direct will read requirements.md and solution.md directly). Incremental => Use the specify-incremental skill. Focus: Decompose the single-feature solution into linear phases with embedded TDD tasks. Factory => Use the specify-factory skill. Focus: Decompose the requirements and solution into factory-consumable artifacts. }
Ask the user to choose between Finalize specification (recommended) and Revisit Decomposition.
Use the specify-meta skill to review and assess readiness.
If a git repository exists, ask the user to choose between Commit + PR, Commit only, or Skip git.
Read reference/output-format.md and present completion summary accordingly.