Build
You know what you want shipped. These workflows turn a request into validated, reviewed code and won’t hand you slop on the way out. They enforce a build-check-review loop instead.| You say | Smithers runs |
|---|---|
| ”Add rate limiting to the API and don’t stop until it builds, validates, and a reviewer signs off.” | implement: implement, validate, review, loop on failures. |
| ”Replace the auth cookie format. Research the existing code first, make a plan, then implement it test-first.” | research-plan-implement: research, plan, then the same validation loop. |
| ”Migrate the dashboard to the new gateway APIs. Show me the milestone plan before you start, then work through it.” | mission: milestone plan, your approval, then focused workers per milestone. |
| ”Take the tickets in my backlog and implement each one on its own branch, then merge the ones that pass.” | kanban: one worktree branch per ticket, merge the ones that validate and pass review. |
Plan
Shape the work before any code is written. These produce plans, tickets, and sharper requirements. Nothing touches the repo.| You say | Smithers runs |
|---|---|
| ”Give me an ordered plan for adding account-level billing limits. Don’t touch the code.” | plan: a structured, ordered implementation plan, no repo changes. |
| ”I want to build the billing admin section. Break that into separate implementable tickets with acceptance criteria.” | tickets-create: decompose the request into tickets with titles, descriptions, and acceptance criteria. |
| ”I want to improve onboarding but I haven’t thought it through. Interrogate me until the requirements are clear.” | grill-me: an interview loop that asks you questions until the request is clear enough to act on. |
| ”How should we add audit logs? Inspect the repo and gather context first.” | research: a tool-capable agent inspects the code and external docs for prior art and file references. |
Quality
Make existing work stronger. Review it, fix bugs at the root, raise coverage, and audit the whole repo for gaps.| You say | Smithers runs |
|---|---|
| ”Review the changes I just made and tell me if they’re production-ready, with specific issues.” | review: configured reviewers return approval status and structured issues by severity. |
| ”Fix the intermittent gateway reconnect failure: reproduce it, fix it, and verify the fix.” | debug: reproduce, fix, then run the full validation loop. |
| ”Add regression coverage for webhook signature failures and make sure the tests actually pass.” | improve-test-coverage: find high-impact test gaps and validate the new tests. |
| ”Take an inventory of every feature in this repo, then audit each group for missing tests and error handling.” | feature-enum → audit: build a code-backed feature map, then review each group in parallel for gaps. |
Run while you’re away
Smithers runs are durable. They survive crashes, restarts, and flaky tools, and the runtime always knows what’s done and what’s next. So you can start something long-running, close the lid, and come back to progress. Keep going until you stop it. Say:“Keep working on reducing our flaky tests and don’t stop until I tell you to.”Your agent runs
ralph, an unbounded loop that re-runs the smart agent on your prompt over and over. When there’s enough progress, tell your agent to stop it and it runs bunx smithers-orchestrator cancel RUN_ID for you.
“Every morning, scan the repo for stale TODOs and broken doc examples and open fixes.”Your agent registers a cron schedule (
bunx smithers-orchestrator cron add) that kicks off a workflow on its own, a repo janitor that runs without you in the loop. Ask your agent what’s scheduled and it runs bunx smithers-orchestrator cron list.
Gate on your approval. Say:
“Draft the release blog post, but don’t publish until I approve it.”The workflow pauses at an approval gate and durably suspends. It waits for your decision: say “approve it” and your agent runs
bunx smithers-orchestrator approve, and the run resumes exactly where it left off. The work happens while you’re away; the irreversible step waits for you. The same gate is what mission uses to hold its milestone plan until you sign off.
Make your own workflows discoverable
Smithers treats having your agent author new workflows as a first-class path. Once you’ve built task-specific and project-specific workflows, say:“Write skill docs for all the Smithers workflows in this repo so any agent can find and run them.”Your agent runs
workflow-skill. It reads every local workflow’s metadata and source, then writes concise agent-facing skill docs under .smithers/skills/. After that, any coding agent on the project can discover and operate your workflows without reading the source first.
Read next
Talk to your agent
How to phrase outcomes so your agent picks the right workflow.
Watch and steer
See a run live, approve gates, and redirect work in flight.
All workflows
The full catalog, with inputs and behavior for every built-in workflow.