| name | to-spec |
| description | Produce a specification document at docs/specifications/ — problem, solution, user stories, acceptance criteria, testing seams, and scope for a feature. The engineering source-of-truth a plan later implements. Use when the user wants a spec or says /to-spec, or when another skill needs the spec phase before planning. |
| allowed-tools | Bash(git config:*), Bash(date:*), Glob, Grep, Read, Write |
To Spec
A spec is the engineering source-of-truth: what to build and the
definition of done. It is stable — it outlives plan revisions — because it
carries no file paths and no code snippets. Those go stale, so they belong
to the plan, where they can be kept current. Spec
is the stable what; the plan is the volatile how.
Normally invoked by architect after research; also
runs standalone.
Input
Determine what to specify, in priority order:
- Invoked from
architect with a build goal and research context → use those.
- A spec worked out in the current conversation → capture that; do not start
over.
- Otherwise → ask the user what to build; if the request is vague, elicit
intent first via
clarify.
Detect the primary language from the repo so acceptance criteria target the
right test runner; fold the detection into whatever you ask next rather than
blocking on it. Non-code work → language is .
