The six agents

The scout. Reads the repo and returns the small set of files and line ranges that matter for the goal — never writes. When the knowledge-base bridge is connected, prospector queries the code graph via the tome trio (tome_search / tome_describe / tome_call — injected into its session from the parent bridge) and falls back to grep/ast_grep when it isn't.

Runs when: When the goal touches code the parent model has not already loaded into context — i.e. the case where reading the whole repo would burn the budget before planning starts.

Tools read · grep · find · ls · ast_grep · lsp_query · comment_check · task (3) · web (2) · cached (2) · tome trio (3)

Example reads repo → returns ["src/calc.js:12-48", "src/format.js:5-22", "package.json:scripts.test"]

Hand off → passes findings

Turns prospector's findings into a numbered, executable plan and writes it to `.smithy/plan.md`. Read-only — draftsman never edits your code, only the ledger. Forces itself into the loop for any open-ended goal or 3+-file change so the build has a blueprint to follow.

Runs when: Always for open-ended goals and 3+-file changes. Skipped only when the goal is trivial enough that a one-line fix doesn't need a plan ceremony.

Tools read · grep · find · ls · ast_grep · lsp_query · task (3) · web (2) · cached (2) · tome trio (3)

Example findings + goal → 5-step .smithy/plan.md with checkboxes, file paths, and a short rationale per step

Hand off → hands plan

A fresh-instance critic (no shared context with draftsman — eliminates self-review bias). Re-reads the relevant code and the plan, then issues a verdict in `## Adversarial Reviews`: `approve` / `request changes` / `block`. A `block` sends you back to planning instead of wasting a build.

Runs when: Auto-runs on any non-trivial plan (the kind that warrants a second pair of eyes). You can also ask for a re-review in plain prose — the model re-runs the inspector on request.

Tools read · grep · find · ls · ast_grep · lsp_query · task (3) · web (2) · cached (2) · tome trio (3)

Example fresh-context read of .smithy/plan.md + repo → "VERDICT: approve" (or request changes / block with concrete follow-ups)

Hand off → APPROVE → build

The only writer. Under `/smithy`, smith auto-runs in its own git worktree so concurrent builds never race on the same files; on success the branch merges back, on conflict an interactive chooser (judge-auto-fix, manual, or abort). Emits `[DONE:n]` markers so the orchestrator can track progress against the plan. Once done, judge verifies (not draftsman — see Option A in the docs).

Runs when: Once inspector has approved the plan. Skipped for trivial goals where planning is overkill — smith handles the one-line fix directly.

Tools read · grep · find · ls · ast_grep · lsp_query · comment_check · edit · write · bash · apply_patch · todos (2) · hashline (2) · task (3) · web (2) · typecheck · tome trio (3)

Example reads approved plan → applies edits → emits [DONE:1] … [DONE:5] → commits on branch

Hand off → hands work → verify

Runs your test suite and type-checker against the current tree — for the post-`/smithy` judge, smith's branch has already merged so the parent tree IS the verified code. Emits a verdict in `## Verification`: `APPROVE` / `REQUEST CHANGES` / `REJECT`. Each run appends to the ledger, so the history of audit accumulates. Ask for a re-check in plain prose any time.

Runs when: Automatically after smith finishes a multi-step plan. You can also ask for a re-verification in plain prose at any time.

Tools read · grep · find · ls · ast_grep · lsp_query · comment_check · bash · hashline_read · todo_read · task (3) · web (2) · cached (2) · typecheck · test_finder · tome trio (3)

Example runs npm test + tsc --noEmit → emits "VERDICT: APPROVE" (or REQUEST CHANGES with concrete follow-ups)