ZERG Development
You are developing ZERG, a system for parallel Claude Code execution. Your role is to improve, harden, and extend it.
Architecture
ZERG combines GSD methodology (spec-driven, fresh agents per task), Claude Code's native Tasks (persistent coordination), and devcontainers (isolated parallel execution).
Key components:
.zerg/orchestrator.py: Python script managing worker fleet.claude/commands/: Slash command definitions (init, plan, design, rush, worker, status).devcontainer/: Container configuration for workersARCHITECTURE.md: Design decisions and rationale
Design Decisions (Intentional)
Understand these before proposing changes:
- Git worktrees: Each worker gets own branch. Prevents conflicts without locking.
- Levels: Tasks execute in waves. All workers complete level N before any start N+1.
- Exclusive file ownership: No two tasks modify same file. Enforced at design time.
- Spec as memory: Workers share spec files, not conversation context. Stateless, restartable.
- Native Tasks: Status in Claude Code's Tasks via shared Docker volume.
- Random ports: Workers pick from 49152-65535. Orchestrator tracks assignments.
Current Gaps
- No production testing
- Basic error recovery
- No monitoring dashboard
- No integration tests
- No cost tracking
- No remote execution
Development Standards
Testing Changes
- Manual test in a real project
- Consider edge cases: zero tasks, one worker, ten workers, failures
- Update docs if behavior changed
- Preserve backwards compatibility
Improvement Areas
Orchestrator: Error handling, health checks, merge conflict resolution, metrics
Commands: Prompt tuning, edge case handling, better examples
Devcontainer: Layer caching, MCP config, GPU support
Docs: Troubleshooting, contribution guide
Output Style
Flowing prose, not bullets. Concise updates on what changed and why. After changes, summarize and indicate what to test.
1---2name: zerg-development3description: You are developing ZERG, a system for parallel Claude Code execution. Your role is to improve, harden, and extend it.4---5# ZERG Development67You are developing ZERG, a system for parallel Claude Code execution. Your role is to improve, harden, and extend it.89## Architecture1011ZERG combines GSD methodology (spec-driven, fresh agents per task), Claude Code's native Tasks (persistent coordination), and devcontainers (isolated parallel execution).1213Key components:14- `.zerg/orchestrator.py`: Python script managing worker fleet15- `.claude/commands/`: Slash command definitions (init, plan, design, rush, worker, status)16- `.devcontainer/`: Container configuration for workers17- `ARCHITECTURE.md`: Design decisions and rationale1819## Design Decisions (Intentional)2021Understand these before proposing changes:2223- **Git worktrees**: Each worker gets own branch. Prevents conflicts without locking.24- **Levels**: Tasks execute in waves. All workers complete level N before any start N+1.25- **Exclusive file ownership**: No two tasks modify same file. Enforced at design time.26- **Spec as memory**: Workers share spec files, not conversation context. Stateless, restartable.27- **Native Tasks**: Status in Claude Code's Tasks via shared Docker volume.28- **Random ports**: Workers pick from 49152-65535. Orchestrator tracks assignments.2930## Current Gaps3132- No production testing33- Basic error recovery34- No monitoring dashboard35- No integration tests36- No cost tracking37- No remote execution3839## Development Standards4041<investigate_before_changing>42Read existing code thoroughly. Understand why decisions were made. Check ARCHITECTURE.md for rationale. Match existing patterns.43</investigate_before_changing>4445<avoid_overengineering>46Make only requested changes. No speculative features or abstractions. Simpler is better. Remove complexity when possible.47</avoid_overengineering>4849<use_parallel_tool_calls>50Execute independent tool calls simultaneously. Read multiple files in parallel. Sequence only when outputs feed inputs.51</use_parallel_tool_calls>5253<default_to_action>54Implement changes directly. Fix bugs, don't describe fixes. Use tools to discover context rather than asking.55</default_to_action>5657## Testing Changes58591. Manual test in a real project602. Consider edge cases: zero tasks, one worker, ten workers, failures613. Update docs if behavior changed624. Preserve backwards compatibility6364## Improvement Areas6566**Orchestrator**: Error handling, health checks, merge conflict resolution, metrics67**Commands**: Prompt tuning, edge case handling, better examples68**Devcontainer**: Layer caching, MCP config, GPU support69**Docs**: Troubleshooting, contribution guide7071## Output Style7273Flowing prose, not bullets. Concise updates on what changed and why. After changes, summarize and indicate what to test.
tools-only