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.
SkillScore86Maintained
Automatic
◆AI Engineer pack
Last verified 8/21/2026
What it changes
Passed 18 of 21 test cases with the skill, and 4 of 21 without it.
Without skill18%
With skill86%
Checks it passed that the model alone missed
Identifies targetRunId as the required input parameter key
Directs sourcing the objective from ctx.input in the run state
Recommends bunx smthrs scores run-8819z to retrieve task scores
and 12 more in the full report
15 fixed4 passed either way3 still failing0 broke
Pass-rate lift
+68 pp
Tokens
+8%
Agent turns
0%
Response time
-46%
Model gemini-3.6-flashMeasured 8/21/2026v119 of 22 cases passed with skill · 21 comparable
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 15 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 15
Prompt
I want to automatically generate a summary slideshow deck for completed Smithers run `run-5512p` using the standard packaged workflow instead of manually extracting data. I plan to pass `runId` as the JSON payload property in `bunx smthrs workflow run report-slideshow`. Is this parameter correct, and what is the exact command?
What was checked, without and with the skill
Checked
Without skill
With skill
Identifies targetRunId as the required input parameter key
Missed
Passed
Specifies the command bunx smthrs workflow run report-slideshow
Passed
Passed
case-04 · gemini-3.6-flash · 8/21/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md77 linessingle file
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".