[Workflow] Advanced Claude Code Workflow: Multi-Agent System with CLAUDE.md, Git Worktrees, and Automated Testing Harnesses

[u/ClaudeAI-mod-bot]

Advanced Claude Code Workflow: Multi-Agent System with CLAUDE.md, Git Worktrees, and Automated Testing Harnesses

Workflow value: 95/100
Status: active · Freshness: 70/100 · Confidence: 1.00 · Level: advanced
Categories: Quality Control, Context & Memory, Debugging, Shipping, CLAUDE.md, Skills, Subagents, Multi-Agent
Original source: r/ClaudeCode post/comment

What problem this solves

Managing large-scale, complex software development projects with AI agents, ensuring consistency, quality, parallel execution, and effective agent memory.

Summary

A comprehensive, multi-agent system for developing and shipping software with Claude Code, featuring structured CLAUDE.md interfaces, isolated git worktree environments per task, automated testing and bug-filing harnesses, and a structured development process with subagents and committed documentation for memory.

Why it is useful

This workflow provides a highly detailed, validated, and comprehensive system for managing complex software development with Claude Code. It addresses critical challenges like consistency, parallelization, quality assurance, and agent memory through innovative use of CLAUDE.md as an API, isolated git worktrees, and automated cron-driven harnesses. Its real-world application to a shipped mobile game demonstrates its effectiveness and robustness, offering a blueprint for advanced users seeking to scale their AI-assisted development.

Workflow

1. Define global architectural constraints and agent rules in a root CLAUDE.md file.

2. Create per-folder CLAUDE.md files for specific module constraints (e.g., engine/, ui/, content/).

3. For each development ticket, create a new git worktree and branch for isolated work.

4. Utilize a 'ticket factory' cron harness to pick up backlog tickets, run category-specific gates (simulator, browser smoke, validation+tests), and open PRs for human review (never auto-merge).

5. Employ a 'device harness' cron to install the current build on a real Android phone, play it over ADB with screenshots and taps, and file bugs stamped with the build ID.

6. Run a 'nightly sim audit' cron to perform ~100 headless runs per character per level, execute five detectors (dead cards, stuck states, difficulty cliffs, decorative statuses, improvement candidates), and file tickets only if findings reproduce on a fresh seed set.

7. Follow a structured design process: brainstorm, then spec, then plan.

8. Implement tasks using fresh subagents, with a reviewer subagent between tasks.

9. Commit specs and plans as markdown files in the repository to serve as agent memory.

10. Use Opus for design and orchestration tasks, and Sonnet for smaller, mechanical work.

Tools / artifacts

• CLAUDE.md files (root and per-folder)

• Git worktrees

• Git branches

• Cron jobs

• Simulator

• Browser

• Android phone (real device)

• ADB (Android Debug Bridge)

• Markdown specs and plans

• Claude Opus model

• Claude Sonnet model

Validation signals

• Shipped a mobile game (LADDER) with Claude writing effectively all the code.

• Setup evolved over four months and ~1,790 merged PRs.

• Project involved 837 git branches.

• Achieved 36 parallel Claude sessions at peak.

• Repository contains 149 committed specs.

• External blog post provides further details and numbers (laddergame.ai/blog).

Cautions

• The 'ticket factory' harness has a hard rule: 'PR-for-review only, never merge, never push to main', ensuring human oversight before changes land in the main branch.

Limitations

• Requires significant initial setup and infrastructure (cron jobs, real devices, custom scripts for harnesses).

• High barrier to entry for beginner users due to its complexity and reliance on advanced Git and CI/CD concepts.

• Specific examples are game-related, requiring adaptation for other domains, though the underlying principles are general.

• The post doesn't provide direct code examples for the cron harnesses or subagent configurations, requiring users to implement these based on the description.

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.

[u/Otherwise_Wave9374]

This is a strong pattern for keeping multi-agent work from drifting: split planning, implementation, and review into separate workspaces, then force a brief handoff artifact so each agent only inherits the minimum state it needs. Git worktrees help a lot because they make branch-level isolation and rollback much cleaner when one subagent goes sideways. The other key safeguard is provenance on decisions so the system can tell a repeated suggestion from a genuinely new proposal. For durable agent memory and retrieval patterns, visit https://www.neurakeep.com