菜单
Render a PRD Markdown file as a rich, self-contained HTML reading view (Dashboard style) and open it in the browser. The Markdown stays authoritative; the HTML is a derived, ephemeral presentation.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | prd-view |
| description | Render a PRD Markdown file as a rich, self-contained HTML reading view (Dashboard style) and open it in the browser. The Markdown stays authoritative; the HTML is a derived, ephemeral presentation. |
| argument-hint | [docs/prd/NN-feature.md] |
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.
$ARGUMENTS: the path to one PRD Markdown file (e.g. docs/prd/11-individual-book-requests.md).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).Read the target file in full. Identify the project name from the repo's CLAUDE.md, docs/prd/README.md, or repo name — it becomes the sidebar breadcrumb (e.g. "ComixDistro PRD"). Note the file's number and title for {{DOC_TITLE}} (e.g. "11 · Individual Book Requests").
Map the file before rendering. Identify:
## sections (each becomes one collapsible card).<pre>).→ See file.md §N) — keep them as explicit pointers back to the canonical Markdown.The at-a-glance strip is what gives confidence of completeness. Pick the 4–6 most salient counts for this specific file — there is no fixed vocabulary. Good candidates, depending on the file:
SHOULD/MUST requirements · API endpoints · user roles/personas · channels/pools · phases · external integrations.Count honestly from the source. If a terse file has no meaningful counts, fall back to structural ones (sections, cross-refs) or omit the strip entirely rather than padding it with filler. Each card is <div class="metric"><div class="v">N</div><div class="k">label</div></div>.
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:
template.html and use it as the exact structure. Its head comment documents every token and component snippet.<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://.{{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..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.<svg> inside <figure class="diagram">. The diagram must match the spec exactly (same states, same transitions, same components).<span class="kw">SHOULD</span>.<button class="copy" data-copy="VALUE">VALUE</button>.→ See file.md §N pointer (a <code>§N</code> tag is fine) so the reader can reach the canonical detail.<style>/<script> and the back-to-top, expand/collapse-all, and click-to-copy source-path controls are real content, not instructional.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>.
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.
/debrief. No publishing, no hosting, no PR comments.tmp/ and is regenerated on demand — never commit it, never treat it as a source.docs/prd/ bundle, no cross-file navigation — that is deferred.Create a pull request with auto-generated description, issue linking, ROADMAP updates, and PR-metadata validation.
Merge a pull request with status checks, squash merge, and branch cleanup. Handles worktree contexts.
Fan out a batch of autopilot-queued issues to parallel background worktree subagents — each runs /autopilot — with an Opus gating review on every Sonnet-built PR.
Detailed technical walkthrough covering architecture, test coverage, product tour, and key design decisions.
Pre-PR advisory check for deviations from the project spec. Read-only analysis.
Generate a hands-on QA testing guide as a self-contained HTML page — for Rails apps or static (Hugo) sites. --publish uploads the HTML to the project's configured QA host.