to-spec

Files (3)

• SKILL.md
• delivery-surfaces.md · references/
• spec-template.md · references/

SKILL.md (first lines)

# To Spec

Produce a technical delivery contract, not an implementation transcript.

1. Use the current conversation or supplied PRD as the product source. Do not repeat requirement discovery unless one unresolved decision would invalidate the design.
2. Inspect the repository, its `AGENTS.md` or equivalent instructions, existing implementation seams, build configuration, and relevant tests before designing.
3. Resolve durable coding-spec roots in this order:
   - an explicit project convention or configured path;
   - `.agents/spec`;
   - `.trellis/spec`;
   - `docs/spec`.
4. Read only the relevant durable specs. If an existing project uses `.trellis/spec`, keep it canonical; do not create `.agents/spec` beside it. For a new project with no established root, `.agents/spec` is the neutral default.
5. Use [references/spec-template.md](references/spec-template.md) selectively and consult [references/delivery-surfaces.md](references/delivery-surfaces.md) only for surfaces present in the change.
6. Ground decisions in repository evidence. State assumptions and open questions instead of inventing facts.
7. Specify observable behavior, boundaries, contracts, data flow, errors, compatibility, migration, and proportionate verification. Avoid line-by-line implementation instructions.

Write beside the source PRD when possible. Otherwise use `.scratch/<feature>/spec.md`. Working PRDs and delivery specs stay under `.scratch`; durable coding conventions stay in the resolved spec root. Never migrate or duplicate a Trellis spec tree silently.

Do not implement. Report the path and the main design decisions. Suggest `slice-spec` only when the work is too large for one coherent delivery session, crosses several independently risky seams, or needs staged rollout.

From JobsHwang/skills, MIT.

More from JobsHwang/skills