How to Build a Software Factory with 7 Claude Agents
This is the full guide from the video. You are going to split your AI coding into 7 specialized agents, a Researcher, a Story Writer, a Project Manager, a Backend Engineer, a Frontend Engineer, a Test Verifier, and a Validator, so that one line from you runs a full feature through research, planning, building, testing, and review, with you approving at exactly 3 checkpoints.
The reason this works: when one AI session plays analyst, architect, both engineers, tester, and reviewer at the same time, wrong assumptions in the plan become wrong code everywhere, and by the time you notice, the mistake has spread. Give every job its own agent with a clean context window and strict rules, and mistakes get caught at the plan, not after 10 files changed.
Don't want to figure this out alone? I walk members through every step inside the community. Join the Skool → skool.com/raycfu
What You Need
Claude Code installed, from code.claude.com, running Claude Fable. A real project repo. That is it. Everything else in this guide gets created inside the repo.
Step 1: Write the Rulebook First (CLAUDE.md)
Before any agents, your project needs a memory file, because every Claude Code session starts knowing nothing about your project. Create a file called CLAUDE.md in the root of your repo. Keep it between 100 and 300 lines. Here is a starter shape, edit everything in brackets to your stack:
# CLAUDE.md
## Stack
[Next.js App Router, Node.js, Prisma, BullMQ, Resend]
## Commands
dev: [npm run dev]
test: [npm test]
migrate: [npx prisma migrate dev]
## Architecture rules
- Business logic lives in services. API routes stay thin.
- [Your folder conventions]
## Do not
- Do not add cron jobs. Use [BullMQ].
- Do not log raw payment payloads.
- Do not commit directly to main.
## Deeper docs
- docs/architecture.md
- docs/billing.md
The maintenance habit that makes this compound: every time the AI makes a mistake that surprises you, ask whether a rule in CLAUDE.md would have prevented it. If yes, add the rule. Within a few weeks this file becomes a record of every wrong assumption, and your sessions get noticeably better.
Step 2: Create the Folder Structure
Open Claude Code in your repo and paste:
Create this folder structure for my agent factory:
.claude/agents/
.claude/skills/feature-factory/
.claude/hooks/
Just create the folders, nothing else yet.
Step 3: Create the 7 Agents
In Claude Code, run the /agents command, choose to create a new agent, and paste each description below, one agent at a time. Claude writes the agent file, you review it and save. Do all 7.
Agent 1, the Researcher:
Create an agent called researcher. Its only job is to inspect the codebase and explain how things work before anything is built. Given a feature idea, it maps the relevant files and their roles, documents existing patterns to follow, finds similar features already built, flags risks like timezone handling, multi-tenant isolation, and retry logic, and lists which tests will need updating. It is strictly read-only: tools are Read, Grep, and Glob only. It never edits files, never runs anything that modifies state, and never fills a gap with an assumption, it asks instead.
Agent 2, the Story Writer:
Create an agent called story-writer. It receives my rough feature description plus the researcher's findings, and produces: one user story in the form "As a [role], I want [behavior], so that [outcome]", acceptance criteria that a test can verify directly covering the happy path, failure paths, and business rules, a list of edge cases, an explicit out-of-scope list, and open questions it genuinely cannot answer. It never invents business rules, never writes code or technical design, and stops to ask when something is unclear. Tools: Read only.
Agent 3, the Project Manager:
Create an agent called project-manager. It receives the approved user story, the researcher's findings, and CLAUDE.md, and produces the technical brief every builder follows: data model changes with fields, types, and migrations, the process flow, API changes with endpoint and request and response shapes, frontend changes with components, pages, and hooks, the tests required for success, failure, and edge cases, risks and open questions, and a list of every file that will change. It never edits files, never invents new infrastructure without calling it out explicitly, and never skips tenant isolation or timezone concerns. Tools: Read, Grep, and Glob only.
Agent 4, the Backend Engineer:
Create an agent called backend-engineer. It receives the approved technical brief, the researcher's findings, and CLAUDE.md, and implements only the backend half: API routes, services and business logic, database access and migrations, background jobs, and unit tests for everything it writes. It is scoped to backend folders only and may never touch React components, pages, or client-side hooks. It never adds dependencies without instruction, never modifies files outside the agreed scope, and never finishes without running typecheck, lint, and the test suite. When done it returns a summary: every file added or edited, every existing helper reused, and any CLAUDE.md rule that would have helped. Tools: Read, Edit, Write, Bash, restricted to backend directories.
Agent 5, the Frontend Engineer:
Create an agent called frontend-engineer. It receives the approved technical brief, the researcher's findings, and the backend-engineer's summary, which is the API contract. It implements only the UI half: React components and pages, client-side hooks and state, loading and error states, and component tests for everything it writes. It consumes the API exactly as the backend produced it and never invents endpoints or response shapes, if the API shape is wrong for the UI it reports the mismatch as feedback instead of patching around it. It is scoped to frontend folders only and never touches services, API routes, workers, or migrations. It never finishes without running typecheck, lint, and the test suite. Tools: Read, Edit, Write, Bash, restricted to frontend directories.
Agent 6, the Test Verifier:
Create an agent called test-verifier. Its only job is proving the feature does what the user story said. It receives the approved story with all acceptance criteria, the approved brief, and both builder summaries, and writes one acceptance test file covering every acceptance criterion, testing the feature from the outside the way a real user experiences it, not unit tests. It reports which criteria pass, which fail, and which cannot be covered cleanly. It never modifies backend or frontend code, never invents workarounds for untestable criteria, and never marks a criterion covered when it is not. When a test fails, it reports exactly which criterion failed and sends it back to the right builder, it does not patch anything itself. Tools: Read, Edit, Write on test files only, plus Bash.
Agent 7, the Validator:
Create an agent called validator. It compares the finished implementation against the approved story and brief, and reports gaps. Every run it checks: acceptance criteria not implemented, failure paths with no test coverage, security issues including missing auth checks, tenant isolation gaps, secrets in logs, and raw errors exposed to clients, files changed outside the agreed scope, patterns inconsistent with CLAUDE.md or the existing code, duplicate logic that should reuse existing helpers, and any timezone or multi-tenant concern from the brief that was quietly skipped. It groups findings by severity, critical, important, and minor, with a file path and line number for every finding. It never fixes anything, and if nothing is wrong it says so plainly instead of inventing issues to look thorough. Tools: Read, Grep, and Glob only.
Step 4: Wire the Chain with One Orchestrator Skill
Now connect the agents into one assembly line. In Claude Code, paste:
Create a skill called feature-factory in .claude/skills/feature-factory/. When I describe a feature, run this chain: 1) researcher maps the code, 2) story-writer produces the user story, then PAUSE for my approval, 3) project-manager produces the technical brief, then PAUSE for my approval, 4) backend-engineer builds and reports its summary, 5) frontend-engineer builds against that summary, 6) test-verifier writes and runs acceptance tests, 7) validator reports gaps by severity. If the verifier or validator finds a problem, route it back to the correct builder, then re-run verification. Finish by presenting everything for my final review before any PR. Read the 7 agent files in .claude/agents/ and wire the handoffs so each agent receives exactly the inputs described in its file.
Claude writes the skill, reading your agent files and building the handoffs. Review it and save.
Step 5: Add the 5-Minute Disaster Prevention Hook
One more paste in Claude Code:
Create a pre-commit hook in .claude/hooks/ that blocks any commit containing .env, .key, .pem, or secrets.json files, with a clear error message telling me what was blocked and why.
Five minutes, and the factory can never leak a credential into git. Do not skip it.
Step 6: Run Your First Feature Through the Chain
Pick something small and real. Type one line:
Build invoice reminders for invoices unpaid for more than 7 days. Use the feature-factory skill.
Here is what happens. The Researcher maps your invoice, payment, and email code. The Story Writer hands you a user story with acceptance criteria, and you pause and read it, this is checkpoint one. The Project Manager turns the approved story into the technical brief, and you pause again, this is checkpoint two, and the moment to catch things like "store IDs in memory" before 10 files change. The Backend Engineer builds the service, route, job, and unit tests. The Frontend Engineer reads the backend summary and builds the UI against that exact API. The Test Verifier writes acceptance tests for every criterion and reports what passed. The Validator sweeps everything and reports gaps with file paths and line numbers, and anything it catches routes back to the right builder automatically. Then checkpoint three: you review and open the PR.
Three human decisions. Everything between them runs on its own.
Expect the first run to stumble somewhere, that is normal and useful. Every stumble becomes a new rule in CLAUDE.md or a sharper line in an agent file. After 3 or 4 features, the factory knows your codebase and you stop supervising and start deciding what to build next.
The Rule That Saves Your Sessions: Kill Drift Early
Most sessions do not fail loudly, they drift. A wrong assumption enters the chat and everything gets built on top of it. So use this rule forever: a small mistake gets corrected inline, but a wrong architectural assumption means you throw the conversation away and start fresh with the right assumption baked into the first prompt. If you just say "no, subscriptions belong to companies, not users", the AI patches, and now both versions haunt your codebase. A clean session with the right mental model beats a patched session every single time.
The Quick Reference
Researcher maps the code, read-only. Story Writer turns the idea into a story with acceptance criteria, read-only. Project Manager turns the story into the technical brief, read-only. Backend Engineer builds the backend half, backend folders only. Frontend Engineer builds the UI against the backend's contract, frontend folders only. Test Verifier proves the story is satisfied with acceptance tests, test files only. Validator reports what everyone missed, read-only, fixes nothing.
Three checkpoints: approve the story, approve the brief, approve the PR.
One line in. A finished, tested, validated feature out.
Don't want to figure this out alone? I walk members through every step inside the community. Join the Skool → skool.com/raycfu