to-prd

This skill takes the current conversation context and codebase understanding and produces a PRD. Do NOT interview the user — just synthesize what you already know. If context is too thin to synthesize, halt and tell the user to run /grill-me first; don't fabricate scope.

Process

1. Read the codebase. Explore the repo to understand current state if you haven't already. Use the project's domain glossary throughout the PRD.

2. Scan docs/adr/ for accepted ADRs touching the area. List relevant ones in a Sources line and respect their locked decisions. If the PRD's scope would violate an ADR, surface the conflict to the user before writing.

3. Pick the Glossary source (in priority order):

   1. Glossary block emitted by a prior /grill-me session in the conversation.
   2. docs/intent/NNNN-<slug>.md — the same block, written to disk by grill-me. Check here whenever the conversation doesn't carry one: the interview may have happened in an earlier session, or its output may have been compacted away. Match by slug, or take the most recently modified file when the feature is obvious. Cite it in Sources.
   3. Domain terms already used in the codebase — search for prominent nouns/verbs in module names, types, and route names.
   4. Terms surfaced in the conversation context.

   Sources 1–2 are the same artifact and carry the edge-case decisions too — fold those into the PRD rather than re-deriving them, so blueprint inherits a ledger instead of starting one.

4. Sketch the major modules to build or modify. Actively look for opportunities to extract deep modules — ones that encapsulate substantial functionality behind a simple, testable, slow-to-change interface (Ousterhout). Do not interview; synthesize from context. If module shape is unclear, halt and route back to /grill-me.