/orchestrate Command
Orchestrate Command
⚡ EXECUTION INSTRUCTIONS FOR CLAUDE
When this command is invoked, YOU (Claude) must execute these steps immediately: This is NOT documentation - these are COMMANDS to execute right now. Use TodoWrite to track progress through multi-phase workflows.
🚨 EXECUTION WORKFLOW
Phase 1: Execute Documented Workflow
Action Steps:
- Review the reference documentation below and execute the detailed steps sequentially.
📋 REFERENCE DOCUMENTATION
Orchestrate Command
Purpose: Multi-agent orchestration system for complex development tasks
Action: Coordinate multiple specialized agents to work on complex development tasks with proper task distribution and result integration
Usage: /orchestrate [task_description] [OPTIONS]
Options:
| Option | Description | Default |
|--------|-------------|---------|
| --agent-cli <cli> | Agent CLI to use (claude, codex, gemini, cursor). Supports comma-separated chain for fallback (e.g., 'gemini,claude') | gemini |
| --context <path> | Path to markdown file to inject into agent prompt as context | - |
| --branch <name> | Force checkout of specific branch (prevents new branch creation) | - |
| --pr <number> | Existing PR number to update (prevents new PR creation) | - |
| --mcp-agent <name> | Pre-fill agent name for MCP Mail registration | - |
| --bead <id> | Pre-fill bead ID for tracking | - |
| --validate <cmd> | Semantic validation command to run after agent completes | - |
| --no-new-pr | Hard block on PR creation (agents must use existing PR) | false |
| --no-new-branch | Hard block on branch creation (agents must use existing branch) | false |
CRITICAL RULE: When /orchestrate is used, NEVER execute the task yourself. ALWAYS delegate to the orchestration agents. The orchestration system will handle all task execution through specialized agents.
🚨 ORCHESTRATION DIRECT EXECUTION PREVENTION: ⚠️ MANDATORY HARD STOP PROTOCOL
ABSOLUTE RULE: When /orchestrate or /orch is used, you MUST:
- ❌ NEVER use Edit, Write, Bash, or any execution tools yourself
- ❌ NEVER use Task tool to create agents
- ❌ NEVER start implementing the task directly
- ✅ ONLY use the tmux-based orchestration system
- ✅ ALWAYS respond: "Delegating to tmux orchestration system..."
- ✅ USE:
python3 .claude/commands/orchestrate.py "task description"
🚨 ABSOLUTE BRANCH ISOLATION PROTOCOL: ⚠️ MANDATORY - NEVER LEAVE CURRENT BRANCH
- ❌ FORBIDDEN:
git checkout,git switch, or any branch switching commands - ❌ FORBIDDEN: Working on other branches, PRs, or repositories
- ✅ MANDATORY: Stay on current branch for ALL work - delegate everything else to agents
- ✅ DELEGATION RULE: Any work requiring different branch →
/orchor orchestration agents - 🔍 Evidence: Branch switching violations cause context confusion and work contamination
- MENTAL MODEL: "Current branch = My workspace, Other branches = Agent territory"
VIOLATION EXAMPLES (NEVER DO THESE):
- ❌ Using Task tool to create agents (Task tool ≠ orchestration system)
- ❌ Writing code to solve the problem yourself
- ❌ Running commands to implement features yourself
- ❌ Editing files to fix bugs yourself
- ❌ BRANCH VIOLATIONS:
git checkout other-branch,git switch main - ❌ BRANCH VIOLATIONS: Working on different PRs or repositories directly
CORRECT BEHAVIOR:
-
✅ Run orchestration command:
python3 .claude/commands/orchestrate.py "Fix bug X" -
✅ Monitor agent progress:
tmux attach -t agent-name -
✅ Check results:
/orch status -
✅ BRANCH ISOLATION: Stay on current branch, delegate other branch work to agents
-
✅ BRANCH ISOLATION:
/orch "Work on PR #123"instead ofgit checkout pr-branch -
Hard Stop Pattern:
/orchestrateor/orchprefix detected → immediate tmux agent delegation -
User Urgency Safeguard: "just decide", "just start", "you choose" are guidance for TMUX AGENTS, NOT permission for direct execution
-
Mental Model:
/orch= "create tmux agents to do this", NEVER "I should implement this directly" -
Zero Exception Rule: Orchestration commands ALWAYS trigger tmux agent creation regardless of user urgency
-
Behavioral Firewall: Automatic "Delegating to tmux orchestration system..." response followed by tmux agent creation
-
Pattern Recognition: Operational command classification → mandatory tmux protocol enforcement
-
🔍 Evidence: Session violation prevented by this protocol (see CLAUDE.md)
-
CRITICAL: Task tool ≠ orchestration system. Orchestration = tmux agents only.
🚨 CRITICAL BRANCH PROTECTION RULE: When monitoring orchestration agents:
- ❌ NEVER switch branches without explicit user permission
- ❌ NEVER leave the current branch to investigate agent work
- ✅ ALWAYS stay on your current branch while agents work in their isolated workspaces
- ✅ Request explicit approval before any branch switch: "May I switch to branch X? Please approve with 'approve [number]'"
- 🔒 Branch Context: Your branch = your workspace. Agent branches = their workspaces. Never mix them!
- ⚠️ Violation Impact: Switching branches disrupts user's work context and can cause lost changes
Implementation:
- Python Script:
python3 .claude/commands/orchestrate.py [task_description] - Shell Wrapper:
./claude_command_scripts/orchestrate.sh(if available) - Tmux Agents: Creates real tmux sessions with Claude Code CLI agents
- NOT Task Tool: Task tool is for different purposes, orchestration uses tmux system
- System Check: ALWAYS checks system status first before executing tasks
Features:
- Real tmux sessions: Creates separate terminal sessions for each agent
- Claude Code CLI integration: Full access to all slash commands in each session
- Task delegation: Smart routing based on task content (UI→frontend, API→backend, etc.)
- Progress monitoring: Real-time status via
/orchestrate What's the status? - Agent collaboration: Direct connection to agent sessions for collaboration
- Natural language: Understands commands like "Build user authentication urgently"
- Priority handling: Recognizes urgent, ASAP, critical keywords
- Agent reuse optimization: Idle agents reused before creating new ones (50-80% efficiency gains)
- Individual agent per task: Each task gets dedicated agent with complete isolation
- Resource efficiency: Strategic reuse while maintaining task isolation
System Requirements:
- Redis server running (for coordination)
- Orchestration system started:
./orchestration/start_system.sh start - Or started via:
./claude_start.sh(auto-starts orchestration when not running git hooks)
Automatic Behavior:
/orchcommands automatically check if the orchestration system is running- If not running, attempts to start it before executing the task
- Shows clear status messages about system state
- Memory Integration: Automatically queries Memory MCP for:
- Past mistakes and learnings related to the task
- Previous similar orchestration patterns
- Known issues and their solutions
- This helps agents avoid repeating past errors
- Note: If Memory MCP is unavailable, tasks proceed without memory context (non-blocking)
Agent Types:
- Frontend Agent: UI, React components, styling (
frontend-agent) - Backend Agent: APIs, database, server logic (
backend-agent) - Testing Agent: Tests, QA, validation (
testing-agent) - Opus Master: Coordination and oversight (
opus-master) - Task Agents: Dynamic agents with reuse optimization (
task-agent-*)
Examples:
# Basic usage (defaults to gemini CLI)
/orchestrate implement user authentication with tests and documentation
/orchestrate refactor database layer with migration scripts
/orchestrate add new feature with full test coverage and UI updates
/orchestrate optimize performance across frontend and backend
# Specify agent CLI
/orchestrate --agent-cli claude "Fix security vulnerability in auth module"
/orchestrate --agent-cli codex "Generate test suite for API endpoints"
# CLI chain with fallback (tries gemini first, falls back to claude)
/orchestrate --agent-cli gemini,claude "Implement complex feature X"
# Update existing PR on specific branch
/orchestrate --branch feature-x --pr 123 "Add more tests and fix review comments"
# With context file injection
/orchestrate --context ./design-doc.md "Implement according to the design spec"
# With validation command
/orchestrate --validate "./run_tests.sh" "Fix the failing tests"
# Hard blocks (prevent new PR/branch creation)
/orchestrate --no-new-pr --branch main "Update documentation only"
/orchestrate --no-new-branch --branch feature-y "Continue work on feature-y"
# Combined options
/orchestrate --agent-cli gemini --context ./spec.md --pr 456 --validate "pytest" "Implement feature from spec"
# Status and monitoring
/orchestrate What's the status?
/orchestrate connect to sonnet 1
/orchestrate monitor agents
/orchestrate help me with connections
Natural Language Commands:
- Task Delegation: "Build X", "Create Y", "Implement Z urgently"
- System Monitoring: "What's the status?", "monitor agents", "How's the progress?"
- Agent Connection: "connect to sonnet 1", "collaborate with sonnet-2"
- Help: "help me with connections", "show me connection options"
Quick Commands:
- Start system:
./orchestration/start_system.sh start - Check status:
/orchestrate What's the status? - Connect to frontend:
tmux attach -t frontend-agent - Connect to backend:
tmux attach -t backend-agent - Connect to testing:
tmux attach -t testing-agent - Monitor all:
tmux list-sessions | grep -E '(frontend|backend|testing|opus)'
Important Notes
- Working Directory: The orchestration system creates agent workspaces as subdirectories. Always ensure you're in the main project directory when running orchestration commands, not inside an agent workspace
- Monitoring: Use
tmux attach -t [agent-name]to watch agent progress - Results: Check
/tmp/orchestration_results/for agent completion status - Cleanup: Run
orchestration/cleanup_agents.shto remove completed agent worktrees - Branch Context: Agents inherit from your current branch, so their changes build on your work
🚨 AGENT TASK PATIENCE
Agent tasks require TIME - wait for completion before ANY declaration:
- ⚠️ Orchestrate agents work autonomously and may take 5-10+ minutes
- ❌ NEVER declare success OR failure without checking completion status
- ❌ NEVER make declarations based on quick checks (10s, 30s, 60s too soon)
- ✅ ALWAYS check tmux output for "Task completed" message
- ✅ ALWAYS verify PR creation in agent output before declaring results
- 🔍 Evidence: Agent task-agent-5819 succeeded with PR #851 after 270 seconds
- 📋 Proper verification: tmux output → "Task completed" → PR URL → verify PR exists
- ⚠️ Status warnings like "agent may still be working" mean WAIT, don't declare
🔄 PR UPDATE MODE vs CREATE MODE
CRITICAL: Agents must detect whether to UPDATE existing PRs or CREATE new ones:
🔍 PR Update Pattern Detection
The orchestration system recognizes these patterns as PR UPDATE requests:
- Explicit PR references: "fix PR #123", "update pull request #456", "adjust PR #789"
- Contextual PR references: "adjust the PR", "fix the pull request", "update that PR"
- Action words with PR: "modify", "fix", "adjust", "update", "enhance", "improve" + "PR/pull request"
- Continuation phrases: "continue with PR", "add to the PR", "the PR needs", "PR should also"
🆕 PR Create Patterns (Default)
These patterns trigger NEW PR creation:
- No PR mentioned: "implement feature X", "fix bug Y", "create Z"
- Explicit new work: "create new PR for", "start fresh PR", "new pull request"
- Independent tasks: Tasks that don't reference existing work
📢 User Feedback
Orchestration will clearly indicate the detected mode:
🔍 Detected PR context: #950 - Agent will UPDATE existing PR
Branch: feature-xyz
Status: OPEN
OR
🆕 No PR context detected - Agent will create NEW PR
New branch will be created from main
⚠️ Edge Cases
- Merged/Closed PRs: Agent will warn and ask for confirmation
- Multiple PR mentions: Agent will ask which PR to update
- Ambiguous "the PR": System will show recent PRs and ask for selection
- Branch conflicts: Agent will attempt rebase/merge with clear messaging
🔄 Agent Reuse Optimization
🚨 CRITICAL: Agent Reuse Architecture for Efficiency
The orchestration system implements intelligent agent reuse to optimize resource utilization while maintaining task isolation.
Agent Reuse Strategy:
- Check for Idle Agents: Before creating new agents, check for idle existing agents
- Reuse When Available: Reuse idle agents for new tasks (50-80% efficiency gains)
- Create When Needed: Create new agents only when no idle agents available
- Maintain Isolation: Each task still gets dedicated agent execution
- Resource Optimization: Strategic reuse without compromising task quality
Individual Agent Per Task Architecture:
- ✅ Parallel Execution: All tasks processed simultaneously (one agent per task)
- ✅ Resource Efficiency: Idle agents reused before creating new ones (50-80% token savings)
- ✅ Complete Isolation: Each agent has dedicated workspace and task focus
- ✅ No Task Conflicts: Worktrees and separate sessions prevent collisions
- ✅ 100% Coverage: Every task gets individual agent (no partial processing)
- ✅ Scalable: Handle 10+ tasks with optimal resource utilization
- ✅ Fault Tolerant: One agent failure doesn't affect others
- ✅ Real-time Visibility: Monitor all individual agents' progress
Agent Lifecycle Management:
# CORRECT: Agent reuse optimization workflow
for TASK in $TASK_LIST; do
/orchestrate "$TASK with agent reuse preference"
done
# Each task execution with reuse:
# 1. Check for idle agents first
# 2. Reuse existing idle agent if available
# 3. Create new agent only if no idle agents
# 4. Execute task in complete isolation
# 5. Mark agent as idle after completion (available for reuse)
Performance Benefits:
- Token Savings: 50-80% reduction in agent creation overhead
- Resource Efficiency: Better utilization of active agents
- Faster Execution: Reduced agent startup time through reuse
- Cost Optimization: Lower API costs through strategic reuse
- Scalability: Handle more concurrent tasks with same resources
Safety Guarantees:
- ❌ No Task Contamination: Each task gets clean agent state
- ❌ No Shared Context: Agents don't share previous task context
- ✅ Fresh Workspace: Each task gets isolated worktree regardless of reuse
- ✅ Complete Independence: Task execution is fully independent
- ✅ Error Isolation: Agent reuse doesn't propagate errors between tasks