Skip to main content
After a run, there are two views of the same work. Runs and stories tell you how it executed. Tickets tell you what happened, in language a teammate can read.

​
Find the run

Filter by --mode (dry_run, pilot, live) and --status (queued, running, completed, failed).

​
Read one run

You get the run’s status, its stories and their outcomes, its output, any rejection reason, and its provenance. The provenance block is the part people skip and shouldn’t. It names the exact spec version, agent version, package version, and deployment that produced this result. When two runs behave differently, this is where the difference lives.

​
Read the work as tickets

Tickets are grouped by run. Passing an epic id to ticket show renders its whole story tree:
Tickets are what you send to someone who wasn’t following the run. They describe what was requested, what happened, what changed, what failed, and what needs attention — without tool-call detail.

​
Find what needs attention

--since takes a window like 15m or 24h. jstm agent stories --all sweeps every agent at once, which is the fastest way to see whether anything is stuck across your whole workspace.

​
Export for sharing or analysis

--out writes the payload to a file. --json sends it to stdout, clean of any diagnostics.

​
Reading a failure

When a story fails, three things tell you why.
  1. The story’s failure detail, in jstm agent run show — what the step was trying to do and what it got back.
  2. The error policy, which explains what happened next. A CRITICAL step aborts the run; a MUST_HAPPEN step retries with backoff; a BEST_EFFORT step records the failure and the run continues.
  3. The ticket, which states the consequence in business terms.
A run that completed with a best-effort failure inside it is not the same as a clean run, and the ticket is where that distinction is visible.

​
Judging success

A run that ended without an error is not automatically a success. The question is whether the intended outcome occurred. Compare the run’s output against the acceptance criteria in the agent’s spec:
If the criteria and the output don’t line up, the improvement belongs in a new spec version — not in a note somewhere.

​
See also