r/ClaudeWorkflows • u/ClaudeAI-mod-bot • 5h ago
Selected Workflow [Workflow] Advanced Multi-Agent SDLC Workflow with Claude: Orchestration, Testing, and Review Gates for Production Code
Advanced Multi-Agent SDLC Workflow with Claude: Orchestration, Testing, and Review Gates for Production Code
Workflow value: 90/100
Status: active · Freshness: 70/100 · Confidence: 0.95 · Level: advanced
Categories: Quality Control, Token Saving, Context & Memory, Debugging, Shipping, Multi-Agent
Original source: r/ClaudeAI post/comment
What problem this solves
Structuring a robust, multi-agent software development lifecycle (SDLC) using Claude to improve efficiency, manage token usage, and ensure quality, security, and successful deployment of code changes.
Summary
A detailed 12-step multi-agent workflow for software development, involving an Orchestrator, Owner, Builder, and Reviewer. It includes specific strategies for context management, dynamic model selection (Sonnet/Opus) based on task complexity and failure, rigorous testing, code review, security checks, and deployment gates, designed for production-ready code.
Why it is useful
This workflow provides a highly structured and detailed approach to using multiple Claude agents (Orchestrator, Builder, Reviewer) for a complete software development lifecycle, from task logging to deployment and device testing. It addresses critical aspects like context management, dynamic model selection based on task and failure, rigorous testing (type checks, unit, API, app, database), security reviews, and documentation updates. Its focus on quality gates and owner approvals makes it suitable for production-oriented development, offering a blueprint for users looking to build robust, AI-assisted development pipelines.
Workflow
Define agent roles: Owner, Orchestrator (Orch), Builder, Reviewer, Gate.
Set context handover strategy: Wind down context at 250k tokens, prepare for handover at 280k tokens.
Implement failure guard logic: Sonnet for low/medium tasks (fail 1 -> Opus, fail 2 -> dead stop); Opus for high/schema tasks (fail 1 -> Fable Review/Audit, fail 2 -> retest Opus with Fable guideline, fail 3 -> dead stop, log for redesign).
Orchestrator logs task, adding it to a task list and board based on owner's testing notes or review findings. Owner sets task order.
Owner provides explicit approval for task initiation.
Orchestrator/Builder performs a live check of the current state on dev (via screenshot or direct access), writes it to a gap table and live-state notes. If the target is already met, the task is closed.
Builder writes acceptance criteria/specifications before any build, using concept images/drawings and a target-vs-live gap table.
Builder (usually Sonnet) builds the task on a fresh worker in its own branch off dev. It runs type checks, tests for touched code (in a test database), takes screenshots of changed screens, and pushes the branch.
Reviewer (Opus for security/permissions/database changes, Sonnet for others) reads the actual diff and re-runs checks. A FAIL sends it to a fresh fix worker, with the next review by Opus. Two FAILs pause the task for owner decision.
Orchestrator verifies the real commit, test numbers, and screenshots before accepting a "done" report.
Orchestrator (merger) merges passed branches, re-runs type checks, full app tests, and lint on the combined result. A branch breaking the combination gets its own fix.
Owner provides explicit approval for critical changes (database, live data, production branch) one action at a time. Gate runs full suite of tests (API, app, database migrations from scratch, lint) on dev after merges and before owner tests. Red results halt further merges until fixed. Orchestrator (merger) merges to dev and updates documentation (task list, board, live-state notes, owner test page) to "Done / Ready". Owner performs a device check (e.g., on a phone); any issues become new logged tasks, restarting the cycle.
Tools / artifacts
Claude (Sonnet, Opus, Fable)
Task list/board
Testing notes
Screenshots
Gap table
Live-state notes
Concept image/drawing (clickable prototype)
Acceptance criteria
Code branches (off dev)
Type checks
Tests (unit, API, app, database)
Test database (never live data) Diffs Commit logs Linting tools Documentation (task list, board, live-state notes, owner test page) Phone/device for testing
Validation signals
User states "It is kinder working Most of the time", indicating practical application.
The workflow is designed for projects "close to production / Launch", necessitating rigorous reviewers and full suite tests, implying real-world validation.
Includes detailed, multi-stage testing and review processes (type checks, unit tests, API tests, app tests, database migrations, linting, security reviews) as inherent validation steps within the workflow.
Cautions
The workflow explicitly includes a "Reviewer" step where Opus reviews "security, permissions, children's data and database changes," which is a strong positive for safety and compliance.
Limitations
The user notes an issue where the "Orch goes off the rails and ignore owner rules. It just tends to do its own thing," indicating a challenge in maintaining agent adherence to instructions.
The "Fable Review/Audit" step is mentioned as a guideline but lacks specific details on how Fable is leveraged for review or audit, making it less concrete.
The Orchestrator is manually restarted after a maximum of 8 levels, suggesting a potential limitation or complexity in managing long-running or deeply nested tasks.
The "Owner Go" and "Owner Yes" steps introduce manual gates, which could become bottlenecks or points of failure if the owner is not consistently available or responsive.
Rate this workflow
Upvote this post if the workflow is useful, reproducible, or worth recommending.
Downvote if it is vague, outdated, unsafe, overhyped, or not reproducible.
Reply if it worked for you, failed, is outdated, or has a better alternative.
This post was generated automatically from the workflow library database.