bunx smithers-orchestrator starters.
Implement → review loop
Iterate until a reviewer signs off, with a hard cap.Parallel multi-agent review
Two models catch different bugs. Cost = the slower model’s latency.continueOnFail keeps one model’s timeout from blocking the other.
Approval gate with branching
Decision data drives the next branch.onDeny: "fail" aborts, "continue" proceeds without the gated branch, "skip" skips the gated tasks.
Retry policy & timeouts
Optional, non-blocking step
Conditional branch on output
ctx.outputMaybe for control flow.
Dynamic ticket discovery
Discover work, run each ticket, re-render to catch the next batch. Scales to large projects.t.id, not array index) so resume matches.
Coherent task with tools
One context boundary per logical operation, not per step. Splitting too finely loses cross-step reasoning.Per-agent least-privilege tools
Side-effect tools with idempotency
External mutations must mark themselves and use the runtime idempotency key.Caching for iterative authoring
Schemas in their own file
MDX prompt with auto-injected schema
props.schema is the JSON-schema description of the Task’s outputSchema, auto-injected. Keeps the prompt and the validator in sync.
Custom hooks over ctx
VCS revert & per-attempt snapshots
Smithers records a jj change ID (or git SHA) per attempt. Revert any attempt to its exact workspace state:Time travel: fork, replay, diff
--run to start immediately); replay also makes a child run but immediately resumes it. --restore-vcs checks out the original revision so re-execution sees the same source.
Scoring tasks
ratio.
Eval suites for regressions
status, output (exact match), and outputContains (partial match). Reports land in .smithers/evals/<suite>.json; the command exits non-zero on failures.
Continue-as-new for very long runs
A run with too much accumulated state hands off to a fresh run with carried state.Hot reload while authoring
Fork agent session context
Every agent task produces a reusable session snapshot.fork starts a new task from a copy of another task’s final context — without mutating the source.
fork adds the source as a dependency (the forked task waits for it), copies its conversation into a fresh session, then submits the new prompt. Both branches above start from the same investigation and never affect each other. Chain it for follow-ups (plan → implement → verify); inside a <Loop> it forks the latest completed snapshot for that id. See <Task> fork.
Read next
- How It Works — the model these recipes plug into.
- Components — full prop surface.
- CLI — every command.