write-prd

Write a PRD that captures the feature implemented in the current session, in the house style of docs/prd/. That folder is an OKF (Open Knowledge Format) knowledge bundle — see docs/prd/README.md — so every PRD is a markdown concept document with YAML frontmatter, and the relative links between PRDs draw the edges of the bundle's knowledge graph.

The audience is a future developer or AI agent reading the file cold — months later, after the code has drifted. The point is not to restate what the diff shows; it is to capture the why and the non-obvious decisions that the code alone can't explain. The frontmatter description doubles as the PRD's one line in docs/prd/index.md — it is what an AI agent reads to decide whether to open the file at all, so make it carry the feature's essence.

Workflow

1. Anchor on the existing style. Read at least one existing PRD in docs/prd/ (e.g. 10_print_file_as_pdf.md or 03_jd_url_extraction.md) before writing. Match its tone, density, and section order. Do not invent new sections.

2. Mine the session for content. The conversation history is your source material — pull from:

   • The user's original requirement (becomes the Why).
   • Approach choices made during planning, especially ones where you considered alternatives and picked one. These are the Decisions worth remembering.
   • The actual files touched (use git diff / git status if needed to be precise) — these populate Files of interest.
   • User corrections and "no, do it this way" moments — these are usually the most valuable decisions to record.
   • Verification steps you ran (curl, browser checks, tests) — these become How to verify end-to-end.

3. Propose a filename and version, then confirm. Filename is NN_snake_case.md — NN is the zero-padded next number in sequence (ls docs/prd/ for the current highest; e.g. 28_feature_name.md). Version is v1 for a new feature, v2 etc. if extending one — check whether a related PRD already exists. Briefly tell the user the proposed path and version in one line, then write it. Don't block on a long confirmation cycle; the user can rename if needed.

4. Write the PRD using the template below. Save to docs/prd/NN_<name>.md.

5. Update the bundle indexes. Add the PRD's line to docs/prd/index.md under # PRD — title-alphabetical order, format * [Title](NN_name.md) - <description from frontmatter> — then regenerate docs/prd/viz.html (commands live in docs/prd/README.md → "Adding or updating a PRD"; expect the reported concept count to go up by one).

6. Show the user the path and a one-line summary of what was written. Don't dump the PRD back into chat — they can open the file.