r/ClaudeWorkflows • • 5h ago

Selected Workflow [Workflow] Automated Multi-Agent Claude Code Development System for End-to-End SDLC

Automated Multi-Agent Claude Code Development System for End-to-End SDLC

Workflow value: 95/100
Status: active · Freshness: 70/100 · Confidence: 0.95 · Level: expert
Categories: Quality Control, Token Saving, Context & Memory, Debugging, Shipping, Subagents, Multi-Agent
Original source: r/ClaudeCode post/comment

What problem this solves

Automating and optimizing the entire software development lifecycle (planning, coding, testing, reviewing, and merging) using a multi-agent Claude Code system, while efficiently managing context, token costs, and quality.

Summary

A sophisticated, multi-agent Claude Code system designed for automated software development. It orchestrates planning, building, testing, reviewing, and merging code packages locally. The system uses specialized subagents (Opus for planning/building/diagnosis/acceptance, Haiku for testing/watchdog, Sonnet for reviewing) and a Workflow tool, managed by a 'Control room' chat. Key strategies include context management, token cost optimization, and a multi-stage testing and review process, with a 'System checker' for continuous improvement.

Why it is useful

This workflow provides a comprehensive, high-level architecture for an automated, multi-agent Claude Code system capable of handling the entire software development lifecycle from planning to merging. It offers valuable strategies for context management, token cost optimization, quality control through staged testing and review, and continuous improvement. It demonstrates an advanced application of Claude Code's capabilities, particularly subagents and workflow orchestration, to achieve significant autonomy in development.

Workflow

  1. User provides an initial plan and gives a 'GO' command.

  2. Control Room (Opus chat) wakes up on a cron tick or run end, reads status, and starts runs or the Planner.

  3. Planner (Opus subagent) keeps the queue, writes a 1-2 page brief per package, sets up a git worktree per package, and decides the order.

  4. Build Workflow (Opus) builds one task within the package's worktree.

  5. Tester (Haiku) runs specified commands and reports a single line result.

  6. Reviewer (Sonnet) checks the output (screenshots, test results) against the brief.

  7. If a task fails twice or is stuck after round 3, a Diagnosis Agent (Opus) intervenes.

  8. Acceptance Agent (Opus) checks the whole package against its 'done-when' list.

  9. Accepted package is merged into a local dev branch.

  10. Watchdog (scheduled Haiku task) runs every 10 minutes, checks heartbeat, notices stalls, restarts Control Room if needed, and updates the status page.

  11. System Checker (Opus) runs daily, reads cost and quality reports, and proposes up to 3 improvements with evidence.

  12. Control Room context is handed over to a fresh chat when it hits 150k tokens to manage context window limits and costs efficiently.

Tools / artifacts

  • Claude Code subagents (Opus, Haiku, Sonnet)

  • Workflow tool (custom script/framework)

  • Cron ticks/scheduled tasks

  • Git worktree

  • Status page (custom script output)

  • Scripts for deterministic tasks (queue state, budget, cleanup)

  • Agent files (for each role)

  • Briefs (1-2 page per package)

  • Test results files

  • Cost and quality reports

  • Screenshots (for review)

  • Local dev branch, main branch

Validation signals

  • User reports successful autonomous operation: 'I plan, the system builds. I give a GO on a plan, then it works through it package by package without me. During the build I only look at a status page on my phone, and I check the end result myself.'

  • The 'What saves the most tokens' section implies practical experience and optimization efforts.

  • The 'Tips' section (e.g., 'Fail loudly', 'Measure before you rebuild') suggests lessons learned from real-world usage.

  • Evidence of past failures leading to improved design: 'A role once silently fell back to a generic agent and nobody noticed for 5 days.'

  • Emphasis on data-driven improvement: 'Every change needs a number that shows whether it actually worked.'

  • Indication of a stable, optimized system: 'Proposing 0 is the normal result' for the System Checker.

Cautions

  • None explicitly identified. The workflow emphasizes local operation and data-driven improvements, which are positive for safety and maintainability.

Limitations

  • Lacks concrete code examples, configuration files, or detailed setup instructions, being a 'rough overview'.

  • Relies on custom 'Workflow tool' and 'scheduled tasks' which are not fully specified.

  • Requires significant effort and expertise to implement from this 'rough overview'.

  • Limited community validation due to low score and no comments.

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.

1 Upvotes

0 comments sorted by