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. Domain terms already used in the codebase — search for prominent nouns/verbs in module names, types, and route names.
   3. Terms surfaced in the conversation context.

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.

5. Write the PRD following PRD-TEMPLATE.md, to two destinations:

   • Disk: get the target path from bash scripts/next-prd-index.sh <slug> (prints the zero-padded next-index path, creates docs/prds/ if missing), then write the filled template there. This is what heist and maestro consume.
   • Tracker: bash scripts/publish-prd.sh <prd-file> "<title>" — opens a GitHub issue with the needs-triage label, auto-falling back (drop the label, or skip the tracker entirely) and warning to stderr when the label is missing, gh is unconfigured/unauthed, or the repo isn't on GitHub.