# Smith Mode > > - **Type:** Skill - **Install:** `agentstack add skill-gunesbizim-agent-smith-smith-mode` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [gunesbizim](https://agentstack.voostack.com/s/gunesbizim) - **Installs:** 0 - **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [gunesbizim](https://github.com/gunesbizim) - **Source:** https://github.com/gunesbizim/agent-smith/tree/main/templates/skills/smith-mode ## Install ```sh agentstack add skill-gunesbizim-agent-smith-smith-mode ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # Smith Mode > Vendored from [mrtooher/fable-mode](https://github.com/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](https://github.com/gunesbizim) - **Source:** [gunesbizim/agent-smith](https://github.com/gunesbizim/agent-smith) - **License:** MIT Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-gunesbizim-agent-smith-smith-mode - Seller: https://agentstack.voostack.com/s/gunesbizim - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.