smart

name	smart
description	Run a task through a budget-aware multi-model pipeline from a Fable/Opus main chat that never switches model: plan and interview, orchestrate Sonnet 4.5 implementer subagents, then self-review. Use when the user wants planning, implementation, and review handled by different models.
user-invocable	true
disable-model-invocation	false

Smart — multi-model workflow

Run a task through three phases from a single main chat on the smart model (Fable, or Opus). The point is to keep expensive tokens on the judgment work — planning, verifying, reviewing — and delegate implementation and research to subagents that each carry their own pinned, cheaper model — without the token blow-up of agent teams.

Why subagents, not teams

This is a hub-and-spoke workflow: an orchestrator hands out self-contained work and workers report back. That is exactly what subagents are for — each runs in its own context window and only a summary returns to the main context, so both cost and main-context bloat stay low.

Agent teams exist for the opposite case: teammates that talk to each other. They spin up a full Claude instance per teammate (token cost scales linearly) and add coordination overhead we don't need here. So we do not set CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS. When the orchestrator wants a second opinion, it spawns a one-off reviewer subagent instead of forming a team.

Models: one main chat, subagents carry their own

Run the whole session from the main chat on one model — Fable (or Opus if Fable is unavailable) — and never switch /model. Two phases must live in the main chat because a subagent can't do them: the interview (only the main chat talks to you) and the final self-review (wants the full session). Both want the smart model anyway, so it's already there.

Everything delegated carries its own model and effort from its subagent definition, so the sub-context switches model for you:

Phase / role	Runs in	Model	Effort
Plan & interview	main chat	Fable (→ Opus)	xhigh
Implement	impl-worker subagents	Sonnet 4.5	medium
Research	researcher subagents	Haiku	low
Review	main chat + reviewer (opt)	Fable (→ Opus)	xhigh

Set the main chat to Fable (or Opus) at xhigh effort once, at the start. The impl-worker pins the full ID claude-sonnet-4-5, because the bare sonnet alias resolves to Sonnet 5 — the pricier model we don't want here.

Shared brain: MEMORY.md

Subagents are stateless cold starts and this flow spans three phases, so keep a single working doc as the shared state. Put it in the scratchpad (or a gitignored path) — do not commit it.

It holds:

• Plan — the agreed approach and scope.
• Decisions — settled questions and their answers.
• Open questions — anything still blocking, for you to resolve.
• Task specs — one section per delegated unit of work (see Phase 2).
• Review findings — what Phase 3 surfaced and what was fixed.

The orchestrator points each subagent at the relevant section instead of re-explaining context in the spawn prompt. This keeps spawn prompts small and the main context lean.

Testability (non-negotiable)

Every change the pipeline produces must be written to be testable — clear seams, injectable dependencies, pure logic separated from side effects, no hidden global state a test can't reach. Design this in during planning; it is not a later concern.

If a piece genuinely can't be made reasonably testable, it does not get waved through silently: the worker flags it to the orchestrator, and the orchestrator gets the user's explicit OK with AskUserQuestion before accepting it, recording the decision in MEMORY.md.

Phase 1 — Plan & interview (Fable, xhigh effort)

1. Set /model to Fable (or Opus) and /effort to xhigh — and leave it there; you won't switch again this session.
2. Run the plan-interview skill: work back and forth with the user, leading with open questions and an outline before writing the plan.
3. Choose the least-code approach — this is the planner's job, not the worker's. First read the code the change will touch and trace the real flow; be lazy about the solution, never about reading. Then, for each piece of work, walk the laziness ladder (defined in the self-review skill) and pick the lowest workable rung: does it need to exist at all, and can existing code, the standard library, a native feature, or an already-installed dependency do it before anything new is written? Record the chosen approach in the plan so it flows into the task specs — the Sonnet 4.5 workers implement the rung you picked rather than exercising this judgment themselves. Never trim safety (validation, security, error handling, accessibility).
4. Write the agreed plan, settled decisions, and any open questions into MEMORY.md.
5. Do not start implementing in this phase.

Phase 2 — Implement (orchestrate from the main chat)

Stay in the main chat (Fable/Opus) — no model switch. You are the orchestrator: you verify and coordinate, you do not write the implementation yourself.

1. Decompose. Break the plan into self-contained tasks — a function, a file, a test suite — each producing a clear deliverable. Write one task spec per task into MEMORY.md (files to touch, expected behaviour, constraints, done criteria). Include the minimal approach chosen in planning — which existing code, stdlib, native feature, or dependency to use — so the worker builds that, not its own idea of the solution.
2. Delegate. Spawn an impl-worker (Sonnet 4.5) subagent per task. Keep the spawn prompt short: point it at its MEMORY.md section and the relevant files. Independent tasks can run in parallel; give each worker a disjoint set of files to avoid conflicts.
3. Research cheaply. For any web lookup, docs check, or library research, spawn a researcher (Haiku) subagent rather than doing it in the main context — only its summary returns.
4. Verify every return. Read each worker's diff against its spec and against the self-review criteria and its laziness ladder (placement, simplicity, DRY, YAGNI, idiom, robustness, and whether the worker over-built past the rung you picked). If it falls short, send precise feedback and re-delegate. Answer worker questions.
5. Escalate, don't guess. For ambiguous product decisions, ask the user with AskUserQuestion and record the answer in MEMORY.md. When a worker flags something as hard to test, follow Testability above — get the user's OK before accepting it. For a second opinion on a risky diff, spawn a reviewer (Fable) subagent.

Phase 3 — Self-review (Fable, xhigh effort)

1. Still in the main chat (Fable/Opus) — no model switch needed.
2. Run the self-review skill across the whole change — read every changed file in full, not just diffs.
3. Fix issues found, or delegate fixes back to an impl-worker if mechanical.
4. Record findings and fixes in MEMORY.md, then summarize for the user.

$ARGUMENTS