---
title: "What You Can Do"
icon: "list-check"
description: "Say the outcome you want. Your agent picks a proven Smithers workflow and runs it for you."
---

Say the outcome you want. Your agent picks a proven recipe and runs it.

You don't write workflows or run the CLI by hand. You talk to your coding agent, and it reaches for one of the built-in Smithers workflows (durable recipes that render → execute → persist) and drives it through to a validated, reviewed result. Any agent, any model, any machine.

This page is the catalog. Each row is an outcome you want, the exact words you say to your agent, and what Smithers does under the hood.

## Build

You know what you want shipped. These workflows turn a request into validated, reviewed code, enforcing a build-check-review loop instead of handing you a first draft.

| You say | Smithers runs |
| --- | --- |
| "Add rate limiting to the API and don't stop until it builds, validates, and the review signs off." | [`implement`](/workflows/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`](/workflows/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`](/workflows/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`](/workflows/kanban): one worktree branch per ticket, merge the ones that validate and pass review. |

<Frame caption="implement runs a build → validate → review loop and feeds failures back in, so you get reviewed code instead of a first draft.">
  <img src="/images/workflow-ui/implement.png" alt="Smithers workflow UI showing the implement workflow with implementation, validation, and reviewer nodes wired into a loop" />
</Frame>

<Frame caption="research-plan-implement gathers context and plans before touching code, the pipeline for work in unfamiliar territory.">
  <img src="/images/workflow-ui/research-plan-implement.png" alt="Smithers workflow UI showing research, plan, and validation-loop stages chained in sequence" />
</Frame>

<Frame caption="mission breaks long-horizon work into approved milestones with parallel workers, so a multi-day migration runs as scoped, reviewable chunks.">
  <img src="/images/workflow-ui/mission.png" alt="Smithers workflow UI showing a mission plan with milestones, parallel feature workers, integration, and validation" />
</Frame>

<Frame caption="kanban implements each ticket in its own worktree branch and merges only the ones that pass: isolated parallelism on one board.">
  <img src="/images/workflow-ui/kanban.png" alt="Smithers workflow UI showing kanban fanning tickets out into separate worktree branches before a merge step" />
</Frame>

## 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`](/workflows/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`](/workflows/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`](/workflows/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`](/workflows/research): a tool-capable agent inspects the code and external docs for prior art and file references. |

<Frame caption="plan returns ordered steps without changing the repo, the input you feed into implement, mission, or tickets-create.">
  <img src="/images/workflow-ui/plan.png" alt="Smithers workflow UI showing a single plan task that emits an ordered step list" />
</Frame>

<Frame caption="tickets-create splits one broad request into discrete tickets with acceptance criteria; drop them in .smithers/tickets/ and hand them to kanban.">
  <img src="/images/workflow-ui/tickets-create.png" alt="Smithers workflow UI showing a request decomposed into multiple structured tickets" />
</Frame>

<Frame caption="grill-me interrogates you before any planning, so the plan is built on real requirements instead of a vague one-liner.">
  <img src="/images/workflow-ui/grill-me.png" alt="Smithers workflow UI showing grill-me running an iterative question-and-answer interview loop" />
</Frame>

<Frame caption="research gathers repo and external context up front, so the plan that follows cites real files and prior art.">
  <img src="/images/workflow-ui/research.png" alt="Smithers workflow UI showing a research agent inspecting the repository and external sources" />
</Frame>

## 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`](/workflows/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`](/workflows/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`](/workflows/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`](/workflows/feature-enum) → [`audit`](/workflows/audit): build a code-backed feature map, then review each group in parallel for gaps. |

<Frame caption="review returns approval status plus issues tagged by severity, so 'is this production-ready' gets a structured answer.">
  <img src="/images/workflow-ui/review.png" alt="Smithers workflow UI showing reviewer agents producing approval status and structured issues" />
</Frame>

<Frame caption="debug reproduces the bug before fixing it and runs every validation iteration, with no early exit until the fix is verified.">
  <img src="/images/workflow-ui/debug.png" alt="Smithers workflow UI showing debug reproducing, fixing, and validating a bug across fixed iterations" />
</Frame>

<Frame caption="improve-test-coverage fills high-impact gaps and validates that the new tests actually pass.">
  <img src="/images/workflow-ui/improve-test-coverage.png" alt="Smithers workflow UI showing improve-test-coverage adding and validating tests" />
</Frame>

<Frame caption="feature-enum produces a code-backed feature inventory that audit then reviews group by group in parallel: a whole-repo gap report.">
  <img src="/images/workflow-ui/feature-enum.png" alt="Smithers workflow UI showing feature-enum producing grouped feature names from a repo scan" />
</Frame>

<Frame caption="audit consumes the feature map and reviews each group for missing tests, docs, and error handling across the whole inventory.">
  <img src="/images/workflow-ui/audit.png" alt="Smithers workflow UI showing audit fanning out across feature groups and merging a report" />
</Frame>

## 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`](/workflows/ralph), an unbounded loop that re-runs the smart agent on your prompt. When you've had enough progress, tell your agent to stop it and it runs `bunx smithers-orchestrator cancel RUN_ID`.

<Frame caption="ralph loops the same prompt indefinitely, so a long-grind task keeps making progress while you're away.">
  <img src="/images/workflow-ui/ralph.png" alt="Smithers workflow UI showing ralph running a single agent task in an unbounded loop" />
</Frame>

**Run on a schedule.** Say:

> "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 the workflow on its own. Ask 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 durably suspends at an approval gate. Say "approve it," 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. This is the same gate `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`](/workflows/workflow-skill): it reads every local workflow's metadata and source, then writes concise agent-facing skill docs under `.smithers/skills/`. That directory is Smithers-owned generated output; common coding harnesses such as Claude Code and Codex do not auto-scan it without per-harness wiring. After generation, follow the printed next steps to bridge the generated docs into the harness-discoverable skill location, typically `.agents/skills`.

<Frame caption="workflow-skill turns your local workflows into agent-facing skill docs, so the next agent on the repo can drive them by name without reading the source.">
  <img src="/images/workflow-ui/workflow-skill.png" alt="Smithers workflow UI showing workflow-skill reading local workflows and emitting skill documentation" />
</Frame>

## Read next

<CardGroup cols={3}>
  <Card title="Talk to your agent" icon="comments" href="/guide/talk-to-your-agent">
    **How-to:** phrase the outcomes above so your agent picks the right workflow.
  </Card>
  <Card title="Watch and steer" icon="eye" href="/guide/watch-and-steer">
    **How-to:** see a run live, approve gates, and redirect work in flight.
  </Card>
  <Card title="All workflows" icon="list" href="/workflows/overview">
    **Reference:** the deeper catalog, with inputs and behavior for every built-in workflow.
  </Card>
</CardGroup>
