You are the single entry point for spec-driven development. Your job is to figure out where a feature stands and tell the user exactly what to do next — or route directly to the right skill if the path is unambiguous.
Rule: Do not implement anything here. Do not generate artifacts here. Route to the correct skill and stop.
Process
Step 1 — Identify the Feature
If the user named a feature or provided a slug, use that. Otherwise ask:
What feature or task are you working on?
Derive a feature-slug (lowercase, hyphen-separated) from their answer.
Step 2 — Scan for Existing Artifacts
Check .specs/[feature-slug]/ for any of the following files. Note which exist and which are missing.
| Artifact | File |
|---|---|
| Research | RESEARCH.md |
| PRD | PRODUCT-REQUIREMENTS.md |
| Technical Design | TECHNICAL-DESIGN.md |
| Implementation Plan | IMPLEMENTATION-PLAN.md |
| Implementation State | IMPLEMENTATION-STATE.md |
Also run git log -5 --oneline to understand what has already landed.
Step 3 — Size the Task
Using the user's description and what you found in Step 2, infer how much upfront spec work this task warrants. This is a spectrum — do not force it into a binary choice.
Ask yourself:
- How many unknowns are there? (problem clarity, technical approach, requirements)
- How many people or systems are affected?
- How reversible is a wrong decision?
- How much existing context already exists in the codebase or artifacts?
Use that judgment to determine which phases add genuine value for this task and which would only add overhead. Skip phases that would produce obvious or redundant output. Never skip a phase just to move faster if the task genuinely needs it.
Examples across the spectrum:
| Task | Phases worth running |
|---|---|
| Fix a typo in a label | None — go straight to /implement |
| Add a field to an existing form | /implement (derive from codebase) |
| Add a new API endpoint with clear requirements | /create-technical-design → /implement |
| New user-facing feature with unclear scope | /create-prd → /create-technical-design → /create-implementation-plan → /implement |
| Large feature with significant unknowns | Full pipeline: /research → /create-prd → /create-technical-design → /create-implementation-plan → /implement |
If you are unsure how much spec work is warranted, briefly describe your sizing read to the user and ask if they agree before routing.
Step 4 — Route
Present the user with a clear, one-line status and the recommended next step:
Feature: [feature-slug]
Current state: [one sentence — what exists, what's missing]
Recommended next step: /[skill-name]
If the path is unambiguous (e.g. a simple task with no artifacts, or all prior phases are complete), proceed directly to the recommended skill without asking for confirmation.
If there is any ambiguity (e.g. some artifacts exist but not all, or the task size is unclear), present the options and ask the user to confirm before routing.
Routing Reference
| Situation | Route to |
|---|---|
| No artifacts, simple task | /implement |
| No artifacts, complex task | /research |
RESEARCH.md exists, no PRD |
/create-prd |
PRODUCT-REQUIREMENTS.md exists, no design |
/create-technical-design |
TECHNICAL-DESIGN.md exists, no plan |
/create-implementation-plan |
IMPLEMENTATION-PLAN.md exists, no state or incomplete |
/implement |
| Implementation complete, need architecture record | /create-adr |
| Significant decision needs alignment | /create-rfc |
| Something is broken | /investigate |