Render a session — or any subject — as explorable HTML.

A composed document, not a transcript dump

Open the file in any browser and you get a synthesized document — a summary and type tags for the session, architecture and flow diagrams rendered as inline SVG, decision records (what was chosen, what was rejected, why), a file-touch list with real path:line references, and a timeline and metrics where the session has them.

For richer surfaces there are two interactive components: an interactive explorer — a selector that drives a live diagram region and a detail pane from one shared data model, useful for multi-component architectures where you want to navigate relationships rather than read a static diagram — and a data-driven step timeline — phases of parallel and sequential steps with source pills and micro-cycles, useful when the session covers a pipeline, workflow, or multi-phase build.

Components adapt to the session — the catalog is a floor, not a ceiling. When content fits no off-the-shelf component, a bespoke one is composed from the same design-system primitives so it still looks native, and empty sections are omitted rather than stubbed. After writing the file, create surfaces a short coverage summary — what made it into the document and what was intentionally omitted — so you can spot anything left out before you close the session.

Two inputs, one visual layer

Everything walkthrough renders comes from one of two input modes. A session drives create and update; a subject drives document. The two lanes converge on the same shared renderer and emit one portable HTML file. Click a lane for detail.

The visual layer is reused verbatim across all three skills — one house style, two themes, an open component system, everything inlined. Only the model and the gathering differ: document swaps in its own subject model where create uses the session model. That shared layer is why a session recap and a plugin docs page are recognizably the same artifact.

The model-before-markup pipeline

create runs a fixed five-stage pipeline: the full structured model is built before a single HTML tag is written, and two quality gates bracket the render. This page was produced by /walkthrough:document running this same flow over the plugin's README and manifest. Click any step for detail.

create runs this flow over a session: gather reads cited source files so path:line refs are real, synthesize builds the session model, select maps it to components, assemble inlines the scaffold, and write emits the file. Rendering never starts from the raw transcript — the full model is built first. document runs the same flow over a subject instead; update adds two stages in front — reconstruct the prior model from the rendered HTML and merge in explicitly-named files — before re-entering it.

Rich detail surfaces

Click a node, card, or cross-link and its detail opens. Light detail opens in a structured glance pane; richer content — a hosted diagram, code — opens in a centered sheet that can itself open further detail, nested. Click a surface for detail.

The pane is the lightweight right-edge glance; the sheet is a centered surface roomy enough to host a full diagram or code block. A surface can itself open another — so a node opens a sheet, and a cross-link inside that sheet opens the next detail — letting you navigate relationships in a multi-component architecture rather than read one static diagram. Empty fields are omitted rather than stubbed, so each surface shows only what it actually has.

Three skills, one shared renderer

The three user-facing skills are /walkthrough:<name>, all default frontmatter — user- and intent-invocable. Typing the slash form works; so does asking in plain language. Alongside them sits one internal building block — render (user-invocable: false), consumed by the lens plugin. No agents, no hooks, no scripts.

Self-contained, tokens only

Two invariants make every walkthrough recognizably the same artifact and portable anywhere. They are non-negotiable.

The result renders with no network beyond that one font fetch — copy the file anywhere, email it, drop it in a wiki, and it works without the plugin, without a server, and without a connection. Walkthroughs are written to .claude/walkthrough/<YYYY-MM-DD-HHMM>-<slug>.html. When a walkthrough on the same subject already exists, create asks whether to update it in place, write a new versioned file, or overwrite — rather than silently adding a -2/-3 suffix. On the first run in a repo, it offers to add the directory to .gitignore (a session artifact can contain code and prose you exchanged) and remembers your choice in settings.md.

Works in Claude Cowork

walkthrough is a pure-skill plugin — no hooks, no shell scripts, no agents — so it installs and runs in Claude Cowork exactly as it does in Claude Code. Its one portable HTML file is a natural Cowork deliverable: run it and you get an explorable page you can email, drop in a wiki, or open offline.

Create, then refresh in place

/walkthrough:create architecture decisions scopes a session recap to the decisions you made; /walkthrough:update later folds in a new spec and overwrites the same file.

> /walkthrough:create architecture decisions

gather      read cited source files (path:line refs are real)
synthesize  session model — sections, nodes, edges, decisions, files
select      map model → components (omit empty, never stub)
assemble    inline scaffold + tokens + JS + SVG + detail data
write       .claude/walkthrough/2026-06-04-1430-architecture.html

→ one self-contained HTML file. Open it in any browser.

# ── later, after the spec lands ──

> /walkthrough:update specs/v2-pipeline.md

Which document to refresh?
  • 2026-06-04-1430-architecture.html   (only match)
  → yes

reconstruct  rebuild prior model from rendered HTML (const DET)
merge        revise superseded content, fold in v2-pipeline.md
write        overwrite the SAME file — no new file, no backup

→ same path, now its up-to-date self.

What it is — and isn't

A walkthrough is a snapshot, not a live view. Knowing the boundary keeps expectations honest.