| name | spec-orchestrator |
| description | Skill routing and workflow orchestration. Routes to correct spec skill based on task type. Establishes discipline and manages transitions between workflow phases. Use when starting any conversation or task to determine which spec skill applies.
|
| user-invocable | false |
If you think there is even a 1% chance a skill might apply to what you are doing, you ABSOLUTELY
MUST invoke the skill.
IF A SKILL APPLIES TO YOUR TASK, YOU DO NOT HAVE A CHOICE. YOU MUST USE IT.
This is not negotiable. This is not optional. You cannot rationalize your way out of this.
Spec Workflow
You have skills. You MUST use them. Not "should." Not "when convenient." MUST.
Invoke relevant skills BEFORE any response or action. Even a 1% chance a skill might apply
means you invoke it. If an invoked skill turns out to be wrong for the situation, you don't
need to follow it. But you must check.
The One Rule
Never write code until the human has reviewed and approved a written plan.
Every project goes through this process. A todo list, a single-function utility, a config
change — all of them. "Simple" projects are where unexamined assumptions cause the most
wasted work. The spec can be short, the plan can be brief, but you MUST present them
and get approval.
Artifacts
Every feature produces two artifacts in docs/specs/YYYY-MM-DD-<feature>/:
design.md ← spec-brainstorm (requirements + research + architecture)
plan.json ← spec-plan (tasks, dependencies)
Skill Routing
spec-brainstorm → Discovery + design + architecture → design.md
spec-plan → Implementation plan + tasks → plan.json
spec-implement → Execute tasks, track progress, report
spec-finish → Post-implementation validation
code-subagents → Parallel dispatch, two-stage review
"Create a spec for X" / Build / Add Feature
spec-brainstorm → spec-plan → spec-implement → spec-finish
Fix Complex Bug / Refactor
spec-brainstorm (research-heavy) → spec-plan (targeted) → spec-implement
Quick Fix / Trivial Change
If genuinely trivial (typo, single-line config, variable rename) — skip the pipeline.
But be honest. If there's any doubt, plan it.
Hard Transitions
| After completing... | The ONLY next step is... |
|---|
| spec-brainstorm | spec-plan |
| spec-plan | spec-implement |
| spec-implement | spec-finish |
Do NOT jump from requirements to code. Do NOT jump from research to implementation.
Iteration Patterns
The workflow is not purely linear. Expect backflows:
Research → Research (discovery loop)
- Brainstorm reveals new requirements → loop back to discovery phase
- Human adds new scope mid-brainstorm → continue discovery
Plan → Research (design flaw)
- Planning reveals design assumptions are wrong → back to brainstorm
- Tasks can't be decomposed without more context → back to brainstorm
Implement → Plan (missing tasks)
- Implementation reveals missing tasks → update plan.json
- Blocked on dependency not in plan → back to plan
Implement → Research (fundamental issue)
- Implementation reveals design is fundamentally wrong → back to brainstorm
- "This can't work as designed" → back to brainstorm
Finish → Implement (bugs found)
- Validation finds bugs → back to implement
- Tests failing → back to implement
When to escalate
If you loop 2+ times on the same issue, stop and ask the human:
"We've looped on [issue] twice. Should we reconsider the approach?"
Red Flags — You Are Rationalizing
| What you're thinking | Why it's wrong |
|---|
| "This is too simple for a plan" | Simple tasks have the most unexamined assumptions |
| "I already know how to do this" | Knowing how ≠ having the human's approval for how |
| "The human seems impatient" | Wasting time on wrong code is worse than planning |
| "I'll just do a quick prototype" | Prototypes become production. Plan it. |
| "I need to explore the code first" | That's the brainstorm phase. Write it in design.md. |
| "Let me just fix this one thing" | One thing becomes three. Plan it. |
| "I can plan in my head" | Plans in your head can't be reviewed or annotated |
| "This is just a refactor" | Refactors touch more code than features. Plan it. |
| "I'll write the plan after" | Post-hoc plans are fiction. Plan before. |
| "I need more context first" | Skills tell you HOW to gather context. Check first. |
| "The skill is overkill" | Simple things become complex. Use it. |
| "I know what that skill says" | Skills evolve. Read current version. Invoke it. |
| "This feels productive" | Undisciplined action wastes time. Skills prevent this. |
Skill Types
Process skills (spec-brainstorm, spec-plan, spec-implement, spec-finish): Follow exactly.
Don't adapt away discipline.
Knowledge skills (oracle-grill-me, oracle-domain-modelling): Adapt principles to
context. These inform decisions within the workflow.
Discipline skills (oracle-debug): Strict methodology that must be followed
exactly — no adaptation that bypasses root-cause investigation.
Process skills come first. Knowledge skills get invoked by process skills when needed.
User Instructions
"Add X" or "Fix Y" doesn't mean skip workflows. Instructions say WHAT, not HOW.
The skills define HOW.
