To Spec

Take the current conversation context and codebase understanding and produce a spec (a PRD). Do not interview the user — the interview already happened (usually a grilling session); this skill synthesizes it.

If a load-bearing decision is genuinely unresolved — one the spec cannot be written without — don't guess and don't launch a full interview. Ask just that decision (via AskUserQuestion where available, otherwise a plain question in chat — recommended option first, trade-offs per option), or suggest a grill-me round if several are open.

Written once per effort, revised in place after. One spec covering everything the effort builds, written in a single session. If it came from a wayfinder map, that first write closes the map and does not run on it again. Later, if downstream work exposes a wrong or missing decision, re-run to edit this spec in place — never write a second spec beside it, and never reopen or re-close the map.

Pipeline position: grill-with-docs/wayfinder (decide) → to-spec (write the spec) → to-tickets (break it into tickets) → implement (build one ticket per session).

Process

1. Explore the repo

Understand the current state of the codebase if you haven't already. Use the project's domain vocabulary throughout the spec (read CONTEXT.md if one exists — domain-modeling maintains it) and respect any ADRs in the area being touched.

Invoked with a wayfinder map, read the map and every closed decision ticket's ## Resolution first — those resolutions are the authoritative decisions the spec must encode. Don't synthesize from conversation memory alone; a fresh session may not hold what earlier ticket sessions decided.

Finish exploring only when you can name the domain terms and ADRs that constrain the spec, the closest existing implementation and tests to imitate (or confirm none exist), and the tracker destination step 3 will use.