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.

Carry the source material through. Every link, doc, or reference the user brought into the conversation (a vendor guide, API docs, an issue, a thread) is cited in the spec where it applies. Material that was pasted rather than linked has no other home, so save it verbatim beside the spec (.scratch/<slug>/research/<name>.md) and link that file. The spec is the only artifact the build sessions inherit: a fact left out of both is gone.

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 GLOSSARY.md, or the older CONTEXT.md, if one exists: domain-modeling maintains it) and respect any ADRs in the area being touched (including migration and data-backfill rules in CLAUDE.md / AGENTS.md). When the conversation relies on a simplifying data or usage claim ("no active subscriptions", "dead table", "zero rows") to drop schema or skip an expand–contract step, verify it against the codebase (rg for live callers, admin resources, and seeders) and a read-only count on the configured database before encoding it in the spec.

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.