Smith Mode

Smith Mode

> Vendored from mrtooher/fable-mode and bundled with agent-smith.

This skill encodes execution discipline for complex work: decompose before acting, delegate where the runtime allows, verify with checks that can fail, self-critique before delivery.

A note on what this is. The skill shapes the procedure a model follows. It does not change the model's underlying capability. Coherence across long tasks and genuine self-correction live in the weights, not in a prompt. On a model that already does these well, the skill reinforces good habits. On a weaker model, it imposes structure the model would otherwise skip, but it cannot lift the model's reasoning ceiling. Treat this as a checklist, not a capability transplant.

When NOT to use this

If a task has one obvious correct approach and fits in a single pass, do it directly and skip this loop. Staging a trivial task wastes effort and buries the answer under ceremony. This loop earns its cost only when a one-shot attempt would plausibly miss something.

Core Loop

The loop is constant across domains. Only the verification artifact in step 3 changes by domain (see Domain-specific patterns).

1. Stage map (before touching anything) Write out the full stage plan before starting. Number the stages. Include a brief expected output for each. This is how you avoid discovering at stage 7 that you made a wrong assumption at stage 2. Update the map when what you learn invalidates what you planned. The map is a living document, not a contract.

Each stage should produce one verifiable artifact. If a stage produces nothing checkable, merge it with the next.

Example format:

Stage 1: [Name] → [Expected output]
Stage 2: [Name] → [Expected output]
...

Hierarchical planning tiers (large features / migrations only): for work that spans many files or sessions, expand the flat stage map into three explicit tiers — plan top-down, execute bottom-up:

• Strategic — the goal and the few high-level moves; what success looks like end-to-end.
• Tactical — a per-move stage map (the numbered stage list above), one per strategic move.
• Atomic — the executable steps inside a stage: the exact files, commands, and the failable

verification (step 3) for that step.

When to tier: only when the scale warrants it — a multi-file feature, a migration, or a multi-session effort. For a small task a single flat stage map is correct; do not manufacture three tiers for trivial work. Tiering is a tool for managing scale, not a ceremony.

2. Delegate independent work (if the runtime supports it) First check whether subagent/Agent tooling exists in the current runtime. If it does not (for example, a plain chat surface with no Agent tool), run the stages sequentially and proceed to step 3.

If subagent tooling is available and stage N and stage M don't depend on each other, spawn them concurrently. Each subagent should be briefed with: its specific task, what it should produce, where to save outputs, and any relevant context from prior stages.

Good delegation: "research X while I do Y", "process these 3 files", "verify this independently". Bad delegation: splitting a single coherent thought just to use subagents.

3. Verify with a check that can fail Each stage must define a pass condition that an external artifact satisfies. Acceptable checks:

• a test that runs and passes
• a file or output that provably exists in the expected shape
• a source actually fetched and read, not assumed
• an output diffed against the stated spec

"I reviewed it and it looks right" is not a check. A model that would skip verification will also pass its own introspection. If a stage genuinely has no failable check, say so explicitly and mark its output as unverified so the gap is visible downstream.

The cost of catching an error at stage 3 is trivial; at stage 8 it is catastrophic.

If a fix at stage N invalidates a prior stage's output, re-run that stage's check before continuing. The loop goes forward and backward.

4. Self-critique before delivery Before presenting final output, read it as a skeptical reviewer would. Name at least one weakness or limitation. Either fix it or flag it to the user. Step 3 is the check that can fail. Step 4 is the judgment call about what remains weak after the check passes.

---

Domain-specific patterns

Each domain below is an instance of step 3: it names the failable check that fits the work.

Software engineering

• Read the entire relevant codebase section before writing a line
• Write tests before (or alongside) implementation, not after
• For large changes: plan the diff, then execute it
• Failable check: tests run; error paths exercised, not just the happy path

Research / knowledge work

• Gather sources before synthesizing. Do not write as you search
• For each claim that matters: what's the evidence? what would falsify it?
• Distinguish confirmed facts from inferences; flag the latter explicitly
• Failable check: every load-bearing claim traces to a source actually read

Data analysis

• Understand the data shape before writing any analysis
• State your hypothesis before computing, not after seeing the numbers
• Check for obvious data quality issues (nulls, duplicates, outliers) first
• Failable check: data quality assertions run against the actual data and pass

Long-running / multi-session tasks

• Maintain a work log: decisions made, why, what was tried and failed
• At the start of any continuation, re-read the work log before doing anything
• Define done criteria upfront so you know when to stop
• Failable check: done criteria are written and testable, not vibes

---

What this skill doesn't do

It doesn't make the underlying model smarter. Complex reasoning, novel synthesis, and domain expertise still depend on the model. This skill shapes how a model works through a problem: the approach, the discipline, the verification habits. It does not change raw capability.

When a task is genuinely beyond the model's capability, flag it rather than producing plausible-sounding wrong output.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: gunesbizim
• Source: gunesbizim/agent-smith
• License: MIT

Install and usage instructions live in the source repository linked above.