prd-view

# PRD View Render one canonical PRD Markdown file as a rich **HTML reading view** — a sticky-sidebar "Dashboard" the human scans, jumps around, and collapses to fight overwhelm. The point is engagement: long monochrome specs go under-read, and an unread spec is not authoritative in practice. This view is **derived and ephemeral**. The Markdown file is the single source of truth. The HTML is a presentation generated on demand, written to a gitignored `tmp/` and never committed — so it cannot drift and there is never a second source of truth. It is also a **vetting instrument**: when the rendered view surfaces something wrong or surprising, the fix goes into the *Markdown*, and you regenerate — never patch the HTML. The cardinal rule follows from that: **present, do not embellish.** Every claim in the output must be traceable to the source file. Add no requirements, decisions, or structure the spec does not state. Diagrams encode only facts the spec gives. If the source is ambiguous or self-contradictory, *surface that* (a `callout.flag`) rather than silently resolving it — surfacing it is the vetting loop working. ## Input - `$ARGUMENTS`: the path to one PRD Markdown file (e.g. `docs/prd/11-individual-book-requests.md`). - If no path is given, list the `docs/prd/*.md` files and ask which one to render. Render exactly one file per run (a whole-`docs/prd/` bundle is out of scope). ## Your task ### 1. Read and orient Read the target file in full. Identify the **project na...