Orchestrate Command (Legacy Shim)

Use this only if you still invoke /orchestrate. The maintained orchestration guidance lives in skills/dmux-workflows/SKILL.md and skills/autonomous-agent-harness/SKILL.md.

Canonical Surface

• Prefer dmux-workflows for parallel panes, worktrees, and multi-agent splits.
• Prefer autonomous-agent-harness for longer-running loops, governance, scheduling, and control-plane style execution.
• Keep this file only as a compatibility entry point.

Arguments

$ARGUMENTS

Delegation

Apply the orchestration skills instead of maintaining a second workflow spec here.

• Start with dmux-workflows for split/parallel execution.
• Pull in autonomous-agent-harness when the user is really asking for persistent loops, governance, or operator-layer behavior.
• Keep handoffs structured, but let the skills define the maintained sequencing rules.

FILES CHANGED

[List all files modified]

TEST RESULTS

[Test pass/fail summary]

SECURITY STATUS

[Security findings]

RECOMMENDATION

[SHIP / NEEDS WORK / BLOCKED]

Parallel Execution
For independent checks, run agents in parallel:

Parallel Phase

• code-reviewer (quality)
• security-reviewer (security)
• architect (design)

Merge Results

For external tmux-pane workers with separate git worktrees, use node scripts/orchestrate-worktrees.js plan.json --execute. The built-in orchestration pattern stays in-process; the helper is for long-running or cross-harness sessions.
When workers need to see dirty or untracked local files from the main checkout, add seedPaths to the plan file. ECC overlays only those selected paths into each worker worktree after git worktree add, which keeps the branch isolated while still exposing in-flight local scripts, plans, or docs.

To export a control-plane snapshot for a live tmux/worktree session, run:

The snapshot includes session activity, tmux pane metadata, worker states, objectives, seeded overlays, and recent handoff summaries in JSON form.
Operator Command-Center Handoff
When the workflow spans multiple sessions, worktrees, or tmux panes, append a control-plane block to the final handoff:

• active session ID or alias
• branch + worktree path for each active worker
• tmux pane or detached session name when applicable

• git status summary
• git diff --stat for touched files
• merge/conflict risk notes

• pending user approvals
• blocked steps awaiting confirmation

• last activity timestamp or idle signal
• estimated token or cost drift
• policy events raised by hooks or reviewers

This keeps planner, implementer, reviewer, and loop workers legible from the operator surface.
Workflow Arguments
$ARGUMENTS:
feature <description> - Full feature workflow
bugfix <description> - Bug fix workflow
refactor <description> - Refactoring workflow
security <description> - Security review workflow
custom <agents> <description> - Custom agent sequence

Custom Workflow Example

Tips

• Start with planner for complex features
• Always include code-reviewer before merge
• Use security-reviewer for auth/payment/PII
• Keep handoffs concise - focus on what next agent needs
• Run verification between agents if needed