by johnkf5-ops
Give Claude its own dev team: one supervisor, four specialists, and bulletproof plans/builds without losing context.
# Add to your Claude Code skills
git clone https://github.com/johnkf5-ops/the-dev-squadGive Claude a dev team in one workspace: one supervisor, four specialists, and a shared build doctrine that produces bulletproof plans before coding starts.
The point is not just that it runs on your Claude subscription. The point is that you stop copy-pasting between sessions, keep context in one place, and let one Claude session act like a supervisor with a real dev team behind it while you can still jump in and talk to any specialist directly.
I was spending hours doing the same ritual over and over: open one Claude session to shape the idea, another to write the plan, another to review it, another to code it, another to test it. Every handoff meant more copy-paste, more context loss, and more chances for the build to drift.
The Dev Squad is the answer to that problem. Instead of juggling separate chats by hand, you give Claude its own dev team in one place. The supervisor is still just a Claude session, like any other session you would open yourself, except now it knows it has a planner, a plan reviewer, a coder, and a tester it can use on your behalf. You can still intervene directly with any of them whenever you want, but you no longer have to manually orchestrate the whole thing.
The real win is not “multi-agent” by itself. The real win is that the build plan becomes the contract for the whole team. The planner writes a plan with complete, copy-pasteable code. The plan reviewer tears it apart until there are no gaps. Only then does the coder touch the implementation. The tester checks the result against the approved plan instead of guessing what “done” means.
The key insight is still the same: the plan is the code contract. The planner does not write a vague spec sheet. The planner writes a plan that is complete enough for the coder to build without asking a single question. That is what makes the builds reliable — by the time coding starts, the biggest decisions should already be made and verified.
That is why the team shares a doctrine: build-plan-template.md, checklist.md, and the locked plan.md. The supervisor can run the team for you, but the quality bar stays the same. Research first. Verify from source. Write complete code in the plan. Do one self-review. Let the plan reviewer challenge it. Only then move to coding and testing.
This project exists because I wanted that whole process in one interface, with one shared context, and a supervisor who can run it for me when I do not want to babysit five different sessions.
If you already vibe code solo with Claude, you are already doing the job of a whole team yourself. The Dev Squad is the “why limit yourself?” version of that workflow. Same Claude. Same chat feel. But now there is a planner, reviewer, coder, and tester coordinated around the same build doctrine so you can get the output quality of a real dev team without losing context every time you switch tasks.
The Dev Squad is Claude with its own dev team:
build-plan-template.md, checklist.md, and the approved plan.mdToday, the current product shape is already visible:
Internally the app still labels the team as S, A, B, C, and D. In the product, think of them as the Supervisor, Planner, Plan Reviewer, Coder, and Tester.
The longer-term implementation plan for pushing even more authority into the supervisor lives in SUPERVISOR-BUILD-PLAN.md. The concrete v0.4 containment plan lives in SANDBOX-RUNNER-PLAN.md. The next UX + headless-mode plan lives in UI-AND-HEADLESS-PLAN.md.
| Team Member | What It Does | Internal ID |
|-------------|--------------|-------------|
| Supervisor | Your default Claude session. Oversees the team, captures the concept, starts work, pauses after review, continues approved plans, and helps when runs stall or get weird. | S |
| Planner | Chats with you about the concept, researches everything, and writes a build plan with complete code for every file. | A |
| Plan Reviewer | Reads the planner's work and tears it apart. Asks hard questions. Loops with the planner until there are zero gaps. | B |
| Coder | Follows the approved plan exactly. Writes every file, installs deps, and builds the project. No improvising. | C |
| Tester | Reviews the code against the approved plan, runs it, catches bugs, and loops with the coder until everything passes. | D |
Each team member is a separate Claude Code session running Claude Opus 4.6. They communicate through structured JSON signals routed by an orchestrator. Restrictions are enforced by a PreToolUse hook, but the real product idea is not “a hook-driven pipeline.” It is a supervisor-led dev team that all follows the same build doctrine: the build plan template, the checklist, and the locked plan. See SECURITY.md for the threat model and known limitations.
1. Open the viewer
2. Tell the supervisor what you want to build
3. Ask the supervisor to start planning or start the build
4. Let the supervisor manage the team, or jump into any specialist panel yourself
5. Your project is in ~/Builds/
The supervisor is the recommended front door now. The old buttons and direct specialist chats are still there, but the product is increasingly shaped around “talk to the supervisor, let the supervisor use the team.”
Phase 0: Concept — You talk to the supervisor or the planner. The recommended flow is to tell the supervisor what you want, let the supervisor capture the concept, and then tell the supervisor when to start the team. Strict mode can still ask for Bash approvals later.
Phase 1: Planning — The planner reads the build plan template and checklist, researches the concept (web searches, docs, source code), writes plan.md with complete, copy-pasteable code for every file, then does one self-review pass before handing it to the plan reviewer. No placeholders.
Phase 1b: Plan Review — The plan reviewer reads the plan and sends structured questions back to the planner. They loop until the reviewer is fully satisfied and approves. The plan is locked. No agent can modify it.
Phase 2: Coding — The coder reads the locked plan and builds exactly what it says. Every file, every dependency, every line of code.
Phase 3: Code Review + Testing — The tester reads the plan and the code. Checks every item. If anything doesn't match or fails, the tester sends issues back to the coder. They loop until the tester approves and all tests pass.
Phase 4: Deploy — The finished project is ready.
The plan-review loop between the planner and the plan reviewer catches design gaps before a single line of code is written. The test loop between the coder and the tester catches implementation bugs before anything ships. Each loop has no round limit — they keep going until it's right.
A pixel art office where 5 agents sit at desks. You watch them work in real-time:
Host, Isolated Alpha, or Host FallbackFull Build / Plan Only, START, STOP AFTER REVIEW, CONTINUE BUILD, RESUME STALLED RUN, STOP, Reset, View Plan. These now act as fallback controls; you can also ask the supervisor to do the same things in chat.When idle, agents wander the office, visit the hookah lounge, and play ping pong.
A simpler Supervisor-first workspace for the same team model:
No comments yet. Be the first to share your thoughts!