architecture-review
Reviews a technical proposal before implementation. Use for designs, RFCs, ADRs, architecture proposals, and issues that define how a system change should…
Generates a polished, static HTML reading view from an existing Markdown PRD or technical design. Use when a user asks to render, present, visualize, or make a PRD or design document easier for humans to read in a browser.
$ npx -y skills add owainlewis/blueprint --skill html-doc --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/html-docContext preview
The summary Claude sees to decide when to auto-load this skill.
Generates a polished, static HTML reading view from an existing Markdown PRD or technical design. Use when a user asks to render, present, visualize, or make a PRD or design document easier for humans to read in a browser.
name: html-doc description: Generates a polished, static HTML reading view from an existing Markdown PRD or technical design. Use when a user asks to render, present, visualize, or make a PRD or design document easier for humans to read in a browser.
Turn one complete Markdown PRD or technical design into one verified static HTML page. Keep Markdown canonical. Change presentation, not meaning.
Generation requires Python 3.11 or newer, Pandoc 3 or newer, Node.js 22.12 or newer, and npm. The skill directory contains a locked Mermaid dependency tree.
Before the first Mermaid render, run:
npm ci --prefix <skill-directory>
Use `scripts/html_doc.py` from this skill directory for all generation and lifecycle operations.
Read the complete source. Confirm it is no larger than 2 MiB. Determine the document kind from the request or the exact basename rule.
Treat content problems separately from presentation problems. If the Markdown contradicts itself, omits a required decision, or contains an invalid diagram, report that source problem. Do not silently repair its meaning.
For a file source:
python3 <skill-directory>/scripts/html_doc.py render <source.md> --kind <prd-or-design> --out <output.html>
`--kind` may be omitted only for exact `prd.md` and `design.md` basenames. `--out` may be omitted to create a sibling HTML file.
For exact inline Markdown, pipe it through standard input and provide both kind and output:
python3 <skill-directory>/scripts/html_doc.py render --inline --kind <prd-or-design> --out <output.html>
The command returns JSON containing `candidate`, `output`, and `token`. It does not replace the final output. Keep those exact values for verification and finalization.
If an output lock already exists, do not delete it automatically. It may represent another pending render. Report its path. Use `discard --force-stale` only when the state is known to be abandoned.
Open the candidate as a local file. Do not treat source inspection as browser proof.
Check all of these:
Compare the canonical content inside `main` with the Markdown abstract syntax tree. Navigation, source metadata, and derived accessibility text are not canonical content. Each top-level source block must map to one ordered `data-source-block` node with its SHA-256 identity and nested content intact. A Mermaid block maps to one figure whose exact source appears once in its disclosure.
If a presentation defect comes from the shared renderer or styles, fix that source and regenerate. If it is a content defect, leave the source and candidate unchanged and report it.
Only after every check passes, atomically install the candidate:
python3 <skill-directory>/scripts/html_doc.py finalize --out <output.html> --token <token>
If any check fails, remove only this pending candidate:
python3 <skill-directory>/scripts/html_doc.py discard --out <output.html> --token <token>
Finalization performs one same-directory atomic replacement. It never deletes the previous output first. A failed render, check, or replacement must leave the previous verified output byte-for-byte unchanged.
The final page must:
Stop when the verified candidate is finalized. Report the output path, source hash, and browser checks performed.
Design. Plan. Build. Validate. Blueprint gives coding agents ten focused skills. They cover understanding existing code, deciding what to build, and delivering reviewed pull requests.
Reviews a technical proposal before implementation. Use for designs, RFCs, ADRs, architecture proposals, and issues that define how a system change should…
Creates or updates root ARCHITECTURE.md from verified implementation. Use when a repository needs current architecture documentation or a structural change…
Coordinates a large batch of GitHub issues through separate Codex worker threads, tested pull requests, review loops, and gated merges. Use when the user asks…
Writes a proposed design covering requirements, user experience, technical choices, and proof. Use when important product or technical choices must be settled…
Makes existing code easier to understand without changing behavior. Use to simplify structure, remove duplication or dead code, improve names, or remove…
Turns an approved design or decided brief into ordered tasks for separate agent runs. Use for implementation tasks, tracker tickets, or useful milestones. Do…