Fareed Khan described how he assembled an engineering organization out of Claude Code sub-agents (original article): an orchestrator acting as a staff engineer, a roster of specialized roles, an "employee handbook" of fourteen-plus skills, and hard gates at every transition of the design → plan → execute → review → ship pipeline. I run my own sub-agent teams — four roles, mandatory parallel review and test control, isolation in git worktrees, a five-iteration cap per revision cycle — so I read the article as someone else's production setup, not as a manifesto. Point by point: where I agree, what I'm adopting, what I don't buy.
Context isolation is the core, and it works
The central claim: a sub-agent doesn't inherit the session history; it gets exactly what the task needs. The author calls this protection against the "tired senior" who starts mixing up requirements of neighboring features after an hour of work. My experience confirms it: in a four-role team, a reviewer who never saw the orchestrator's exchange with the developer finds problems that a worn-in shared context reliably misses. A fresh context per role is the cheapest way to raise the quality of multi-agent work — cheaper than any prompt tricks. What that isolation costs in tokens is a topic of its own.
Verification-before-completion: adopting it as a rule
The author's formula: "claiming work is complete without verification is dishonesty, not efficiency." It comes with a claim → required evidence table: "tests pass" means fresh command output in the same message — not "they should pass" and not "they passed yesterday." For me this discipline lived as a habit, never written down as a rule — and a habit is the first thing to slip under deadline pressure. I'm taking the wording into my team templates almost verbatim.
TDD for documentation: the best idea in the article
A skill doesn't count as done until it passes a RED/GREEN cycle on a fresh sub-agent: first you record that without the skill the agent breaks the rule under pressure, then that with the skill it complies. Almost nobody tests documentation this way, even though skills are code that an LLM executes. A separate sharp observation: a skill's description must answer "when to apply it," not "what it does" — otherwise the model reads the description, decides it got the gist, and never opens the full text. I checked my own skills: half the descriptions are written wrong in exactly this sense.
The 1% Rule: elegant, but I don't buy it
The rule — "if there is even a one percent chance a skill applies, the agent must invoke it" — protects the process from erosion through rationalizations ("it's just a question"). The problem is the price: total mandatoriness turns every small question into a procession of skill reads. Routing is cheaper: a skill triggers by task type, not by probability of applicability. Process erosion is caught more reliably by an occasional session audit than by a tax on every action.
The Delete Rule: also skipping it
The requirement to delete all code written before the test — with no "keep it as reference" — is declared an Iron Law. As a manifesto it makes sense: tests-after verify what got implemented, tests-first verify what should be implemented. As a daily practice it's wasteful: throwing away a working draft to rewrite the same thing against a test is justified in a training scenario and almost never in a real task with a budget.
Bottom line
A rigid frame with iron laws pays off where several agents work long and unsupervised: predictability costs more than tokens. For a personal setup it's better to take three things — context isolation per role, a verification gate before any "done," and a RED/GREEN test for your own skills — and leave the frame behind. The author argues fairly, though: the system is published as an open repository, so disagreement can be settled by experiment rather than rhetoric. What happens to that framework once the rules multiply — tuning at scale.