| name | to-spec |
| description | Turn settled requirements, an approved plan, a prototype result, or an issue into a durable implementation-independent specification with testable acceptance criteria and explicit scope. Use when the user asks for a specification, PRD, requirements document, or stable multi-session artifact. Do not use while material product decisions remain unresolved or for simple one-step work. |
Write Specification
Preserve what must be built and why without freezing volatile implementation details. Synthesize settled decisions; do not reopen them or invent missing requirements.
Read references/evidence.md when assessing requirement quality, traceability, or acceptance criteria. Keep one owner for the specification; if delegation is explicitly authorized, use delegate-work only to collect independent repository or external evidence, then reconcile it before writing.
Respect the Specification Contract
- Work read-only except for the requested specification artifact.
- Return the specification in the response by default.
- Save it to a file only when the user requests a file, provides a path, or an established repository workflow requires one.
- Do not publish to GitHub, Linear, or another external tracker without explicit authorization and an exact target.
- Do not repeat a planning interview when the active context is already decision-complete.
Gather the Settled Context
Read:
- the user request and accepted clarifications;
- the active plan and prototype or research findings;
- relevant repository behavior, tests, domain vocabulary, and architecture decisions;
- existing issue or specification material and comments;
- compatibility, security, data, migration, and operational constraints.
Verify important claims against the repository when possible. Preserve the user's language unless the project has a more precise established term.
If a material product, architecture, or compatibility decision remains open, return to the skill before finalizing the specification.
