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-squadGuides for using ai agents skills like the-dev-squad.
Give 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.
No comments yet. Be the first to share your thoughts!
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 labels the team as S, A, B, C, D, and E. In the product, think of them as the Supervisor, Planner, Plan Reviewer, Coder, Tester, and Security Auditor (optional).
For the architecture, security model, and current honest stance on what we ship vs. what we deliberately don't, see ARCHITECTURE.md, SECURITY.md, and SECURITY-ROADMAP.md.
╔═══════════════════════════════════════════════════════════════╗
║ SQUAD ROSTER v0.4.3 ║
╠═══════════════════════════════════════════════════════════════╣
║ ● S │ SUPERVISOR │ ONLINE ║
║ ● A │ PLANNER │ ONLINE ║
║ ● B │ PLAN REVIEWER │ ONLINE ║
║ ● C │ CODER │ ONLINE ║
║ ● D │ CODE REVIEWER/TESTER │ ONLINE ║
║ ○ E │ SECURITY AUDITOR │ OPTIONAL (toggle at start) ║
╚═══════════════════════════════════════════════════════════════╝
| 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 |
| Security Auditor (optional) | Read-only OWASP-class audit after testing succeeds. Ranks findings by severity. You choose what to fix, dismiss, or ignore — and when to deploy. Only runs if the Security Audit toggle is on at build start. | E |
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