Menu
Write a structured specification before code: objectives, structure, code style, testing strategy, boundaries. Use when starting a new project or feature.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Build a personalized learning roadmap with milestones and practice checkpoints
Structured document review for structure, clarity, and technical accuracy. Use for "review this doc", feedback, critique, or /doc-review.
Render a documentation-style Cursor Canvas that organizes architecture notes, API references, walkthroughs, and how-tos into a navigable layout with sections, tables of contents, and cross-references. Use when the user asks for a docs canvas, documentation overview, architecture walkthrough, API reference page, or wants to render structured documentation as an interactive canvas.
Conductor/subagent routing for tasks across multiple harnesses. Assesses task complexity and intent, then dispatches to the appropriate subagent model via a harness-specific adapter. Supports Anthropic (Claude), Cursor, OpenCode, Codex (OpenAI), and Pi adapters. Use via /dynamic-task command or direct invocation from other skills.
Agent evaluation framework. Measure agent performance, identify weaknesses, and track improvement over time. Use when assessing agent quality, comparing approaches, or validating changes.
Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when the user wants to stress-test a plan, get grilled on their design, or mentions "grill me".
| name | spec-driven-development |
| description | Write a structured specification before code: objectives, structure, code style, testing strategy, boundaries. Use when starting a new project or feature. |
| metadata | {"category":"user-invoked"} |
| disable-model-invocation | true |
Default output: return only the result, blockers, and required evidence. Omit preambles, process narration, repeated context, confidence scores, and follow-up offers. Use at most five bullets unless a required artifact or schema needs more.
Write a comprehensive specification before writing any implementation code. The spec covers objectives, interface contracts, project structure, code style, testing strategy, and behavioral boundaries. This is the canonical Define-phase skill.
specs/{feature}/spec.md| Rationalization | Reality |
|---|---|
| "I can just start coding" | Without a spec, you will discover requirements mid-implementation, causing rework. |
| "The spec will be outdated immediately" | Specs capture intent. Implementation details change; intent should not. |
| "This is too small for a spec" | If it touches more than one file or more than one concern, it deserves at least a brief spec. |
specs/{feature}/spec.md| Excuse | Counter |
|---|---|
| "I'll write the spec as I code" | Coding without a spec leads to rework. A 5-minute spec prevents a 5-hour rewrite. |
| "This is too simple for a spec" | Simple features become complex. A spec keeps scope clear and prevents scope creep. |
| "The requirements are clear in my head" | Mental requirements change during implementation. Written specs catch ambiguities early. |
| "I'll document it after implementation" | Post-implementation specs describe what was built, not what should be built. Spec first. |
| "The spec will be outdated immediately" | Specs capture intent. Implementation details change; intent should not. |