Turn a run's persisted state into a self-contained HTML slideshow report — objective, decisions, graph, gates, evals, artifacts, failures, and the recommended next run. Use when a long or important run needs a legible, shareable summary instead of scrolling raw logs.
Scanned 9/2/2026
Install to Claude Code
npx -y skills add smithersai/smithers --skill report-maker --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Report Maker?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/smithersai-report-maker)More formats (shields.io, HTML) on the badges page.
---
name: report-maker
description: Turn a run's persisted state into a self-contained HTML slideshow report — objective, decisions, graph, gates, evals, artifacts, failures, and the recommended next run. Use when a long or important run needs a legible, shareable summary instead of scrolling raw logs.
---
# Report Maker
This skill is about **the reporting layer**: turning what a run actually did into
something a human can read in two minutes and forward. The output is a single
self-contained HTML slideshow: no server, no build, one file to open or attach.
The hard rule: build it from **structured run state, not your prose memory of
the run.** Read the persisted frames, outputs, scores, and events back out of
Smithers and render *those*; anything you can't pull from run state doesn't
belong on a slide. This matters because an agent's recollection drifts and omits
exactly the failures that matter. Persisted state doesn't.
## When to reach for it
- A run took minutes-to-days, or is decision-heavy and important enough that
someone besides you needs to know what was decided, what gated, what was
tested, and what's still open: review it, sign off, or hand it off.
- A run finished (or failed) and you're about to summarize it in chat. Render the
slideshow instead and link it; chat scrollback is not a report.
Skip it for a single-task run nothing downstream depends on: `smithers inspect`
suffices.
## What goes on the slides
One coherent deck, in order:
- **Title / objective**: the run's name and the goal it was given (`ctx.input`).
- **Decisions**: choices made and why; assumptions vs. open questions.
- **Workflow graph**: the executed shape (`smithers tree <run>`, `smithers graph`).
- **Tools / skills / sources**: what the agents used and read.
- **Backpressure gates**: approvals, signals, eval gates: which passed, paused, and who cleared them.
- **Tests / evals & results**: `smithers scores <run>` and any `smithers eval` report; pass/fail per case, not "looks good".
- **Artifacts**: diffs (`smithers diff <run> <node>`), files written, outputs (`smithers output`).
- **Failures / retries**: `NodeFailed` events, retry counts, what finally worked.
- **Remaining issues**: unverified, deferred, or still red.
- **Recommended next run**: the concrete follow-up command, not "keep iterating".
## Pull the state, then render
Source every slide from the CLI rather than memory:
```bash
bunx smthrs inspect <run-id> --json # full run state (runState field): nodes, outputs, approvals
bunx smthrs events <run-id> --json # ordered event history (failures, retries, gates)
bunx smthrs scores <run-id> # scorer results per task
bunx smthrs tree <run-id> # executed graph shape
bunx smthrs diff <run-id> <node-id> # a node's DiffBundle for the artifacts slide
```
## The automated path: the `report-slideshow` workflow
You don't have to hand-build the deck: the archived **`report-slideshow`**
workflow under `examples/init-pack/` can be copied with its dependency closure.
Once installed, it reads a run's persisted state and emits the slideshow for you:
```bash
bunx smthrs workflow run report-slideshow --input '{"targetRunId":"<run-id>"}'
```
Reach for it to bootstrap the report, then hand-tighten the decisions and
next-run slides. It runs its own deterministic `gather` step then an
agent-backed `render` step; `targetRunId` is the input name because `runId` is
reserved for the report workflow's own run. For ongoing monitoring, use
`smithers monitor` instead: it opens a live all-runs web UI, not a slideshow.
## Progress is events, not "working on it"
The same principle governs status while a run is *in flight*: report **specific
events** ("node `review` paused on approval", "case `lists-breaking-changes`
went red", "retry 2/3 on `fix` succeeded"), never a content-free "still working
on it". If you can't name the event, query it (`smithers events <run> --watch`,
`smithers ps`, `smithers why <run>`) first. The slideshow is that same event
stream, made legible and shareable at the end.
See `skills/smithers/SKILL.md` for the run/observe surface and
`docs/llms-core.txt` (`smithers inspect`, `events`, `scores`, `timeline`) for the
exact JSON shapes each slide reads from.
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!