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.

Why This Exists

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.

What This Is

The Dev Squad is Claude with its own dev team:

• the Supervisor is your default front door
• the Planner writes the build plan
• the Plan Reviewer pushes on the plan until there are no gaps
• the Coder builds the approved plan
• the Tester checks the result against the plan and sends fixes back when needed
• the Security Auditor is optional — toggle it on at build start and a final OWASP-class read-only audit runs after testing, with severity-ranked findings you choose what to do with before deploy
• the whole team follows the same doctrine: build-plan-template.md, checklist.md, and the approved plan.md
• you can talk to the supervisor by default or jump directly into any specialist chat whenever you want

Today, the current product shape is already visible:

• the supervisor can capture the concept, start the team, pause after review, continue an approved plan, resume stalled planning/review turns, and stop the run
• the specialists keep their own context in the same workspace instead of forcing you to copy/paste between sessions
• there are now two interfaces for the same team:
  • the Office View for the full visual dashboard
  • the Squad View for a calmer Supervisor-first workspace without the office UI

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.

The Team

╔═══════════════════════════════════════════════════════════════╗
║  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) ║
╚═══════════════════════════════════════════════════════════════╝

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.

How It Works

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