Prd View

4. Render into the template

The structure lives in template.html (this skill's directory); the look + click-to-copy live in ../_shared/house-style.html. Produce the view by:

1. Read template.html and use it as the exact structure. Its head comment documents every token and component snippet.
2. Inline the shared house style — copy the <style> block from ../_shared/house-style.html in place of the <!-- HOUSE STYLE: … --> marker, and its <script> block in place of the <!-- HOUSE SCRIPT: … --> marker. Copy the actual <style>…</style> and <script>…</script> elements (they begin at column 0): the file opens with a documentation comment that mentions <style>/<script> by name — do not capture that comment text or its closing -->, or you will nest the real CSS inside a broken element and lose all styling. Output must be one self-contained file — no external assets, no build step, works from file://.
3. Fill the tokens. Build {{TOC}} (one <li> per section), {{METRICS}}, and {{SECTIONS}} (one details.section card per source ## section, each with a <span class="badge">§N</span>). Open the high-signal early sections (context, architecture, model) by default; collapse deep-reference tails (exhaustive field lists, future considerations) so the page stays scannable.
4. Apply the conversions as you fill each section:
   • Data-model tables → keep the table, but mark types with .pill and required/optional with .req / .opt. Group or summarize a very long field list if it reads as a wall, but never drop fields silently — note any grouping.
   • Lifecycle / architecture / sequence → inline <svg> inside <figure class="diagram">. The diagram must match the spec exactly (same states, same transitions, same components).
   • RFC keywords → <span class="kw">SHOULD</span>.
   • Pasteable values (endpoints, commands, seed values) → <button class="copy" data-copy="VALUE">VALUE</button>.
   • Cross-refs → keep the → See file.md §N pointer (a <code>§N</code> tag is fine) so the reader can reach the canonical detail.
5. Strip every instructional comment — the template's head how-to block and all snippet comments guide filling only and must not appear in the output. Keep the template's interactive shell verbatim, though: its supplemental <style>/<script> and the back-to-top, expand/collapse-all, and click-to-copy source-path controls are real content, not instructional.

5. Save and open

Write to a stable, gitignored path inside the project that owns the PRD (reuse the same filename per source file, so re-runs just need a browser refresh):

tmp/prd-view/<source-file-basename>.html

Then open it so the reader doesn't have to — it is a single self-contained file, so this is instant and needs no server:

open tmp/prd-view/<source-file-basename>.html

open uses the default browser; pin one if the Clipboard API needs it: open -a "Google Chrome" <file>.

6. Report and invite the vetting loop

Tell the reader the path and that it was opened, then explicitly invite the loop:

View:   tmp/prd-view/11-individual-book-requests.html  (opened in your browser)
Source: docs/prd/11-individual-book-requests.md  (authoritative)

Close by inviting correction: if anything in the view looks wrong, thin, or surprising, we fix the Markdown and regenerate. That round-trip is the feature.

Important

• Local-only. This view is for the author, like /debrief. No publishing, no hosting, no PR comments.
• Ephemeral. Output lives in gitignored tmp/ and is regenerated on demand — never commit it, never treat it as a source.
• One file in, one view out. No whole-docs/prd/ bundle, no cross-file navigation — that is deferred.
• Faithful, not creative. When in doubt about a diagram or a count, prefer the simplest correct rendering or omit it. Surfacing a gap beats inventing a detail.