You do not need an army of models. You need a system: one mind to frame the work, several hands to execute it, and a clean boundary between every task.
+
01strong model for ambiguity
03bounded workers in parallel
∞iterations with evidence
Read this as a route map, not a prompt recipe.
+
RULE ZEROStrong model for ambiguity. Light model for bounded work.
THINKMAKE
+
A small fleetcoordination before parallelism
ORCHESTRATOR
Decides what needs to happen.
Opus / reasoning
→
The orchestrator preserves intent, writes small contracts, and gathers results that can be verified. It does not need to type every line.
+
Why the boundary mattersone vague task / three predictable failures
01Context soup
Every worker reads everything. Nobody knows which facts are load-bearing.
02Branch collision
Two agents touch the same checkout. The fastest path becomes conflict resolution.
03Confident drift
The diff is polished, but no one checks whether it solved the original problem.
+
The subagent loop
Click a phase. See the handoff.
Delegation means moving one bounded task into a smaller context—not giving away responsibility.
+
What crosses contextsbrief → diff → evidence
Package
Contains
Why it matters
Brief
goal, files, boundaries
stops the worker inventing the problem
Worktree
branch and isolated checkout
parallel edits do not collide
Checks
tests, build, criteria
turns “looks good” into evidence
Diff
small, reviewable change
integration and discard stay cheap
+
Git worktrees
One branch per hand.
A worktree is another directory linked to the same repository. Each agent gets its own checkout and index; history remains shared.
Select a node to inspect its checkout, owner, and next action.
repository topology 4 checkouts
+
Model routing
Do not pay for reasoning where you need rhythm.
Choose a job to see why the model profile changes.
WorkProfilePrompt shape
+
Model gearboxcapability tier × thinking effort
Two separate knobs
Choose the engine. Then choose the gear.
A stronger model changes the capability ceiling. Higher reasoning effort gives that model more room to work. Start with the lightest combination that passes your real checks, then move one knob at a time.
REASONING / THINKING
ROUTING RULEUse strong models for ambiguity and judgment. Use lighter models for bounded execution. Raise effort only when evaluation shows a gain.
+
Skills
Write the right way once.
A skill is a reusable procedure. It can carry instructions, references, scripts, and assets. It is not magical memory, and it does not replace acceptance criteria.
Do not package everything you know. Capture the non-obvious choices that repeatedly improve an outcome, then prove the skill changes behavior.
AFTER REAL USE
observe failure→sharpen one rule→retest behavior→keep it narrow
+
Common skillschoose behavior before model
The field kit
Different jobs. Different instincts.
A skill changes how an agent approaches work. Some shape communication. Others enforce research, debugging, review, or completion discipline. Select one to inspect its operating rule and verified source.
ONE PRACTICAL LOADOUT
PLAN unlazy →BUILD ponytail-lite →DEBUG diagnosing-bugs →REPORT caveman
INSTALL PACKAsk your coding agent to verify, install, and validate the skills.
+
Hands-on10 minutes / one missing feature
Tiny Tasks lab
Same task. Better operating system.
Start with a deliberately incomplete static task board. Run one prompt as written, reset, then run the skill-enabled version. Compare diff size, verification evidence, and unnecessary complexity.
You do not need an army of models. You need a system: one mind to frame the work, several hands to execute it, and a clean boundary between every task.
-
01strong model for ambiguity
03bounded workers in parallel
∞iterations with evidence
Read this as a route map, not a prompt recipe.
-
RULE ZEROStrong model for ambiguity. Light model for bounded work.
THINKMAKE
-
A small fleetcoordination before parallelism
ORCHESTRATOR
Decides what needs to happen.
Opus / reasoning
→
The orchestrator preserves intent, writes small contracts, and gathers results that can be verified. It does not need to type every line.
-
Why the boundary mattersone vague task / three predictable failures
01Context soup
Every worker reads everything. Nobody knows which facts are load-bearing.
02Branch collision
Two agents touch the same checkout. The fastest path becomes conflict resolution.
03Confident drift
The diff is polished, but no one checks whether it solved the original problem.
-
The subagent loop
Click a phase. See the handoff.
Delegation means moving one bounded task into a smaller context—not giving away responsibility.
-
What crosses contextsbrief → diff → evidence
Package
Contains
Why it matters
Brief
goal, files, boundaries
stops the worker inventing the problem
Worktree
branch and isolated checkout
parallel edits do not collide
Checks
tests, build, criteria
turns “looks good” into evidence
Diff
small, reviewable change
integration and discard stay cheap
-
Git worktrees
One branch per hand.
A worktree is another directory linked to the same repository. Each agent gets its own checkout and index; history remains shared.
Select a node to inspect its checkout, owner, and next action.
repository topology 4 checkouts
-
Model routing
Do not pay for reasoning where you need rhythm.
Choose a job to see why the model profile changes.
WorkProfilePrompt shape
-
Model gearboxcapability tier × thinking effort
Two separate knobs
Choose the engine. Then choose the gear.
A stronger model changes the capability ceiling. Higher reasoning effort gives that model more room to work. Start with the lightest combination that passes your real checks, then move one knob at a time.
REASONING / THINKING
ROUTING RULEUse strong models for ambiguity and judgment. Use lighter models for bounded execution. Raise effort only when evaluation shows a gain.
-
Skills
Write the right way once.
A skill is a reusable procedure. It can carry instructions, references, scripts, and assets. It is not magical memory, and it does not replace acceptance criteria.
Do not package everything you know. Capture the non-obvious choices that repeatedly improve an outcome, then prove the skill changes behavior.
AFTER REAL USE
observe failure→sharpen one rule→retest behavior→keep it narrow
-
Common skillschoose behavior before model
The field kit
Different jobs. Different instincts.
A skill changes how an agent approaches work. Some shape communication. Others enforce research, debugging, review, or completion discipline. Select one to inspect its operating rule and verified source.
ONE PRACTICAL LOADOUT
PLAN unlazy →BUILD ponytail-lite →DEBUG diagnosing-bugs →REPORT caveman
INSTALL PACKAsk your coding agent to verify, install, and validate the skills.
-
Hands-on10 minutes / one missing feature
Tiny Tasks lab
Same task. Better operating system.
Start with a deliberately incomplete static task board. Run one prompt as written, reset, then run the skill-enabled version. Compare diff size, verification evidence, and unnecessary complexity.