Claude Code · interactive HTML deliverables
Turn your work into documents you can read, act on, and review.
Three commands that take the scattered inputs of your work and produce one self-contained, interactive HTML file. report synthesizes sources to read; decide gathers pending choices to act on; branch-review turns a diff into a filterable review.
Install
One command to add it, one to install
The repo is a plugin marketplace. rich-html is standalone — no dependencies, no spec or tracker coupling.
# 1 · register the marketplace (once) /plugin marketplace add moacyrricardo/skills # 2 · install /plugin install rich-html@moacyr-skills # 3 · activate in the current session /reload-plugins
Once installed the commands are namespaced — /rich-html:report, /rich-html:decide, /rich-html:branch-review.
Three tools, one system
One to read, one to act on, one to review
Each produces a document about your work — not the product itself (that's what the prototype plugin's mockup is for). They share a format contract, so the three feel like one system.
read
report
Synthesizes heterogeneous sources into a readable document — conclusion first, evidence one expand away. Read-only.
act
decide
Gathers pending decisions into an interactive surface where each expands to its real context — then emits one prompt to execute your choices.
review
branch-review
Turns a branch or PR diff into a filterable review — the full diff sliced by facet and regrouped by change-type, named by intent. Read-only.
The shape
Scattered inputs in, one file out
Each tool runs the same shape — collect what's spread across your work, structure it, emit a single self-contained file — toward a different end.
The shared format · html-doc
Four rules that make one file work everywhere
All three commands build on the html-doc skill, which encodes the non-obvious constraints so the outputs feel like one system.
data: URIs — renders as a local file, an email attachment, or a Claude Artifact under a strict CSP.mockup.<details>. Dense, but never a wall.dataviz), a screenshot, or a layout sketch. Never the artifact alone.How they work
Inside each tool
report · sources → a readable document
Frame first
It settles the audience and the angle — the one question the report is for — before gathering, so the result isn't an undifferentiated data dump.
Gather & cross-check
Pulls from whatever's present — repo & git, PRs, the issue tracker, docs & specs, logs — and cross-checks them. When two sources disagree, that discrepancy is itself a finding, surfaced rather than smoothed over.
/rich-html:report the state of the payments migration, for the teamConclusion first
Leads with the answer; sections follow; every claim that rests on a source carries its proof one expand away, attributed so it's checkable. It never changes what it reports on.
decide · decisions → a surface + one prompt
Collect the pending choices
Sweeps for genuine forks: a concern's ## Options, unresolved PR-review forks, "needs decision" issues, autopilot escalations, TODO(decide:) markers. Not tasks — decisions.
Model each with real context
A one-line question, 2–4 concrete options (with a recommended one where the evidence supports it), and expandable context wired to the actual source — the point of the surface.
/rich-html:decide everything waiting on me across the open concerns and PRsEmit one prompt
You choose per decision (or "accept all recommended"), and a Copy prompt button assembles a single, self-standing prompt — one line per decision with its choice and source — to hand straight back to an agent. It never degrades into chat Q&A.
branch-review · a diff → a filterable review
Resolve the diff
From a PR number/URL, a base...head range, a branch name, or bare — the current branch vs. its merge-base. The exact base and totals are pinned in the header, so you know precisely what's under review. Read-only.
Two filter axes
Every change is tagged by facet (code / tests / docs / spec) and clustered by change-type — why each cluster exists, named by its intent (jul2026-sync-replay, not a bare service). The full diff slices both ways, and a summary — files, ± lines, a dataviz chart — recomputes as you filter.
Reasoning over hunks
Each cluster leads with one paragraph on why it exists; the real diff is one expand below it. The change-type rule was hardened by an adversarial redteam — the original seed-vs-emergent taxonomy became name-by-intent, with generic-layer naming as the checkable smell.
Which one
Reading, deciding, reviewing
report. Facing a pile of unmade choices you want to clear in one pass → decide. Wanting to understand what a branch or PR changed, and why → branch-review. If report hits a decision that needs making it points at decide; if decide finds reportable state rather than a fork, it points back at report; and if a change hides an unmade decision, branch-review points at decide too.
Changelog
What's changed
Notable additions to the shared format, each backed by the evidence behind the call.
branch-review output redesigned into a review tool (plugin 0.3.1)
The generated file now resembles a real diff-review UI — a collapsible file navigator, a "why these change-types" overview, and two combinable intersecting filters (change type × file type) over change-type clusters of inline unified diffs — while staying a theme-aware document. The command's §5 now specifies this shape. Annotating a change-type and emitting a decide-style prompt was explored but deliberately left out — that write-path belongs to decide; branch-review stays read-only.
branch-review — a third command (plugin 0.3.0)
Turns a branch or PR diff into a filterable HTML review: the full diff sliced by facet (code / tests / docs / spec) and regrouped by change-type, each cluster named by its intent rather than a generic layer. The change-type rule was hardened by an adversarial redteam across three real PRs — the original seed-vs-emergent taxonomy was undecidable when a change fit both, so it became name-by-intent with generic-layer naming as the checkable smell. The worked example below is this plugin's own PR #20, reviewed by the command itself.
Visual evidence — a fourth html-doc rule
Evidence can now be carried in the form that reads fastest — a code snippet, an inline-SVG flow diagram, a chart (via dataviz), an existing screenshot, or a schematic layout sketch — always added under the prose claim, never replacing it. The trial below renders four scenarios (code / layout / chart / flow) twice from identical content: prose-only vs. prose + a supporting artifact, with a Baseline / Side-by-side / Improved toggle and a scoring rubric.