htmlify
Use HTML when the answer needs shape, scanning, comparison, annotation, print/PDF sharing, or browser-native interaction. Produce a single .html file by default.
Operating Rules
- Gather evidence first. Read the repo, docs, git state, PR/CI/deploy state, logs, screenshots, or supplied source material needed for the artifact. Mark uncertain claims as
needs verification.
- Pick the smallest artifact mode that fits the request:
operator-brief: what happened, what is next, blockers, risks, attention.build-plan: problem, target shape, phases, owners, validation, rollback.implementation-map: modules, files, data flow, hot path, edit sequence.pr-review-packet: motivation, before/after, diff tour, reviewer checklist.release-brief: PRs, checks, deploy state, proof, rollback.incident-report: impact, timeline, root cause, mitigations, follow-ups.decision-brief: options, tradeoffs, recommendation, decision needed.status-report: shipped, slipped, carryover, blockers, next period.explainer: concept, request path, examples, glossary, FAQs.prototype or editor: clickable flow, tuning panel, triage board, or exportable UI.
- Make the artifact visual before verbose. Prefer cards, lanes, timelines, matrices, charts, diagrams, annotated diffs, tabs, accordions, and compact tables over long paragraphs.
- Keep it self-contained. Inline CSS and JS; no external fonts, CDNs, assets, analytics, or build step unless the user explicitly asks.
- Make it operator useful. The first viewport should reveal the subject, current status, and where attention should go.
- Keep copy tight. Labels, numbers, and short evidence-backed statements beat generic prose.
- Include print CSS for artifacts intended to share, archive, or export as PDF.
- Add keyboard navigation for deck-style artifacts. For full presentation decks with speaker notes and run-of-show, use the companion
deckify skill instead.
- Make mobile acceptable, but optimize dense operational artifacts for desktop review.
- When an image, screenshot, figure, or thumbnail references a link, article, documentation page, post, paper, dashboard, or source page, attach the source in the visible caption/ref near the image. Prefer a caption anchor such as
Source: <a href="...">Exact source title</a> or weave the linked title into the caption. Do not leave source URLs only in hidden metadata.
- Validate before final response: doctype, standalone
<html>/<body>, no missing local assets, expected sections, source-linked captions for referenced images, and no obvious layout overlap.
Visual Direction
Default to the Hardcopy design system — the document language of engineering plates and datasheets: warm paper field, ink hairlines, serif display headings, mono-uppercase metadata, one international-orange accent, carbon code wells, stamps for status, crop marks, and a plate-style title block. Load references/hardcopy.md for the token block, the seven devices, and print rules before styling any artifact.
When the project supplies DESIGN.md, brand tokens, or an established design system, those are authoritative over Hardcopy.
Validate the Artifact
Before the final response, run the bundled validator on the written file:
npx -y @zakelfassi/htmlify htmlify-answer --validate path/to/artifact.html --profile rich
Use --profile app for artifacts that legitimately carry inline interactivity (editors, prototypes, boards). From a repo or plugin checkout, use node <checkout>/bin/htmlify-answer.js (in Claude Code plugin context: node "${CLAUDE_PLUGIN_ROOT}/bin/htmlify-answer.js"). Fix every reported error before responding; report any remaining warnings in the final response. If the validator cannot run in the environment, perform rule 11 manually and say so.
HTML Shape
Use semantic structure:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1" />
<title>Exact Artifact Title</title>
<style>
/* Inline, responsive, print-aware CSS. */
</style>
</head>
<body>
<main>
<section aria-labelledby="title">
<p class="eyebrow">Mode / repo / date</p>
<h1 id="title">Exact subject</h1>
</section>
</main>
</body>
</html>
Use restrained, purposeful UI. Avoid generic purple gradients, decorative blobs, nested cards, huge marketing heroes for operational work, and filler copy that restates headings.
Recommended Sections
For most operator/build artifacts:
- Title: exact subject, date, repo/branch/environment.
- Scoreboard: green/yellow/red status cards.
- What changed: timeline or shipped cards.
- System shape: flow, module map, ownership lanes, or annotated diff.
- On deck: next actions with owner/context/gate.
- Risks and blockers: severity, evidence, mitigation, decision needed.
- Better next time: process, architecture, or product improvements.
- Alpha: non-obvious learning worth preserving.
- Validation: tests, deploy proof, manual checks, gaps.
- Closeout: next focus and stop/continue/kill recommendation.
Rich Artifact Patterns
Load references/htmlify-principles.md when the artifact needs deeper mode selection, design guidance, or examples inspired by the HTML effectiveness catalogue.
Load references/agent-integrations.md when the user asks how to install htmlify into Codex, Claude Code, Cursor, Windsurf, Aider, Pi/OMP, or other coding agents, or asks for hook-based automatic long-answer export.
Use these modules when useful:
- Scoreboard cards for state, counts, proof, blockers.
- Timeline for discovery, fix, validation, deploy, follow-up.
- Swimlanes for frontend/backend/infra/test/docs ownership.
- Dependency graph for modules, services, and hot paths.
- Risk matrix for issue, evidence, severity, owner, mitigation.
- File tour for path, change, why it matters, validation.
- Decision panel for options, tradeoffs, recommendation.
- Review annotation layer for comments, evidence, and follow-up prompts.
- Lightweight editor when the user needs to manipulate ordering, flags, prompts, or triage state and export the result.
Final Response
Report the HTML file path, artifact mode, evidence sources checked, and validation performed (including the validator command and result). State any verification not run.
If using the bundled Pi/OMP runtime, see the repository README for /htmlify commands and install paths.
1---2name: htmlify3description: Create self-contained HTML artifacts from agent or repo context, including operator briefs, build plans, implementation maps, PR/release packets, incident timelines, decision briefs, reports, explainers, diagrams, prototypes, and lightweight editors. Use when the user asks to turn dense text, code evidence, plans, reviews, or status into browser-ready HTML instead of a markdown wall.4license: Apache-2.05---67# htmlify89Use HTML when the answer needs shape, scanning, comparison, annotation, print/PDF sharing, or browser-native interaction. Produce a single `.html` file by default.1011## Operating Rules12131. Gather evidence first. Read the repo, docs, git state, PR/CI/deploy state, logs, screenshots, or supplied source material needed for the artifact. Mark uncertain claims as `needs verification`.142. Pick the smallest artifact mode that fits the request:15 - `operator-brief`: what happened, what is next, blockers, risks, attention.16 - `build-plan`: problem, target shape, phases, owners, validation, rollback.17 - `implementation-map`: modules, files, data flow, hot path, edit sequence.18 - `pr-review-packet`: motivation, before/after, diff tour, reviewer checklist.19 - `release-brief`: PRs, checks, deploy state, proof, rollback.20 - `incident-report`: impact, timeline, root cause, mitigations, follow-ups.21 - `decision-brief`: options, tradeoffs, recommendation, decision needed.22 - `status-report`: shipped, slipped, carryover, blockers, next period.23 - `explainer`: concept, request path, examples, glossary, FAQs.24 - `prototype` or `editor`: clickable flow, tuning panel, triage board, or exportable UI.253. Make the artifact visual before verbose. Prefer cards, lanes, timelines, matrices, charts, diagrams, annotated diffs, tabs, accordions, and compact tables over long paragraphs.264. Keep it self-contained. Inline CSS and JS; no external fonts, CDNs, assets, analytics, or build step unless the user explicitly asks.275. Make it operator useful. The first viewport should reveal the subject, current status, and where attention should go.286. Keep copy tight. Labels, numbers, and short evidence-backed statements beat generic prose.297. Include print CSS for artifacts intended to share, archive, or export as PDF.308. Add keyboard navigation for deck-style artifacts. For full presentation decks with speaker notes and run-of-show, use the companion `deckify` skill instead.319. Make mobile acceptable, but optimize dense operational artifacts for desktop review.3210. When an image, screenshot, figure, or thumbnail references a link, article, documentation page, post, paper, dashboard, or source page, attach the source in the visible caption/ref near the image. Prefer a caption anchor such as `Source: <a href="...">Exact source title</a>` or weave the linked title into the caption. Do not leave source URLs only in hidden metadata.3311. Validate before final response: doctype, standalone `<html>`/`<body>`, no missing local assets, expected sections, source-linked captions for referenced images, and no obvious layout overlap.3435## Visual Direction3637Default to the **Hardcopy** design system — the document language of engineering plates and datasheets: warm paper field, ink hairlines, serif display headings, mono-uppercase metadata, one international-orange accent, carbon code wells, stamps for status, crop marks, and a plate-style title block. Load [references/hardcopy.md](references/hardcopy.md) for the token block, the seven devices, and print rules before styling any artifact.3839When the project supplies `DESIGN.md`, brand tokens, or an established design system, those are authoritative over Hardcopy.4041## Validate the Artifact4243Before the final response, run the bundled validator on the written file:4445```bash46npx -y @zakelfassi/htmlify htmlify-answer --validate path/to/artifact.html --profile rich47```4849Use `--profile app` for artifacts that legitimately carry inline interactivity (editors, prototypes, boards). From a repo or plugin checkout, use `node <checkout>/bin/htmlify-answer.js` (in Claude Code plugin context: `node "${CLAUDE_PLUGIN_ROOT}/bin/htmlify-answer.js"`). Fix every reported error before responding; report any remaining warnings in the final response. If the validator cannot run in the environment, perform rule 11 manually and say so.5051## HTML Shape5253Use semantic structure:5455```html56<!DOCTYPE html>57<html lang="en">58<head>59 <meta charset="utf-8" />60 <meta name="viewport" content="width=device-width, initial-scale=1" />61 <title>Exact Artifact Title</title>62 <style>63 /* Inline, responsive, print-aware CSS. */64 </style>65</head>66<body>67 <main>68 <section aria-labelledby="title">69 <p class="eyebrow">Mode / repo / date</p>70 <h1 id="title">Exact subject</h1>71 </section>72 </main>73</body>74</html>75```7677Use restrained, purposeful UI. Avoid generic purple gradients, decorative blobs, nested cards, huge marketing heroes for operational work, and filler copy that restates headings.7879## Recommended Sections8081For most operator/build artifacts:82831. Title: exact subject, date, repo/branch/environment.842. Scoreboard: green/yellow/red status cards.853. What changed: timeline or shipped cards.864. System shape: flow, module map, ownership lanes, or annotated diff.875. On deck: next actions with owner/context/gate.886. Risks and blockers: severity, evidence, mitigation, decision needed.897. Better next time: process, architecture, or product improvements.908. Alpha: non-obvious learning worth preserving.919. Validation: tests, deploy proof, manual checks, gaps.9210. Closeout: next focus and stop/continue/kill recommendation.9394## Rich Artifact Patterns9596Load [references/htmlify-principles.md](references/htmlify-principles.md) when the artifact needs deeper mode selection, design guidance, or examples inspired by the HTML effectiveness catalogue.9798Load [references/agent-integrations.md](references/agent-integrations.md) when the user asks how to install htmlify into Codex, Claude Code, Cursor, Windsurf, Aider, Pi/OMP, or other coding agents, or asks for hook-based automatic long-answer export.99100Use these modules when useful:101102- Scoreboard cards for state, counts, proof, blockers.103- Timeline for discovery, fix, validation, deploy, follow-up.104- Swimlanes for frontend/backend/infra/test/docs ownership.105- Dependency graph for modules, services, and hot paths.106- Risk matrix for issue, evidence, severity, owner, mitigation.107- File tour for path, change, why it matters, validation.108- Decision panel for options, tradeoffs, recommendation.109- Review annotation layer for comments, evidence, and follow-up prompts.110- Lightweight editor when the user needs to manipulate ordering, flags, prompts, or triage state and export the result.111112## Final Response113114Report the HTML file path, artifact mode, evidence sources checked, and validation performed (including the validator command and result). State any verification not run.115116If using the bundled Pi/OMP runtime, see the repository README for `/htmlify` commands and install paths.
zakelfassi