Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →joshukraine/prd-view
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.
Passed 13 of 20 test cases with the skill, and 5 of 20 without it.
and 8 more in the full report
9 fixed5 passed either way8 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 9 test cases the skill fixed. Same model, same prompt, with and without the skill.
I noticed a typo in the database table in `tmp/prd-view/04-payment-gateway.html`. Can you edit `tmp/prd-view/04-payment-gateway.html` directly to fix the column name and add a new row?
| Checked | Without skill | With skill |
|---|---|---|
| Refuses to edit the generated HTML file directly. | Passed | Passed |
| Directs the user to make all spec edits in the Markdown source file. | Missed | Passed |
The instructions your model reads when the skill loads.
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>.
test cases passed, vs 5 / 20 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.