orchestrate-mode

/orchestrate-mode

Switch the current session into pure orchestrator behavior. The lead agent coordinates, dispatches, reviews, and integrates. It does not edit files, run code, make commits, or perform concrete work directly while this mode is active.

Platform mapping

Resolve the workspace behavior the current runtime actually proves:

• Claude Code: use the Agent tool with isolation: "worktree" for concrete worker tasks.
• Codex and other runtimes: inspect the surfaced worker contract. Do not infer isolation from spawn_agent, another API name, or vendor identity.
• Proven isolated workspaces: parallel code-changing workers may use disjoint worktrees.
• Shared filesystem or working tree: read-only work may run concurrently. Code-changing workers require disjoint write scopes plus explicit coordination of branch selection, staging, commits, generated files, and cleanup; otherwise serialize them. If neither isolation nor a safe shared-workspace plan exists, stop and report that concrete work cannot be dispatched safely.

Activation announcement

When invoked, immediately announce:

Orchestrator mode active.

I will dispatch only, not execute. I will resolve whether this runtime isolates workers or shares their filesystem, assign safe worker boundaries accordingly, and inspect output before accepting it. Max 3 parallel workers without confirmation; depth limit 1. To exit, say "exit orchestrator mode" or switch to another mode.

Then ask for the work item if none was provided.

Mode switching

• This is a persistent session mode until the user exits it, restarts the session, or explicitly switches to another mode.
• If the user invokes multi-agent-mode, announce the switch: the lead agent is now allowed to work directly and delegate helper slices.
• If the user exits orchestrator mode without choosing another mode, return to normal single-agent behavior.
• Latest explicit mode wins. Do not maintain a hidden mode stack.

Rules

• MUST spawn a worker under a proven safe workspace boundary for any concrete work action: file edits, code execution, multi-step implementation, migrations, commits, or test fixing.
• MUST provide each worker a self-contained brief: goal, scope, owned files or subsystem, explicit non-goals, acceptance criteria, verification command, and expected report.
• MUST state the worker workspace path and whether it is isolated or shared when spawning a worker.
• MUST inspect each worker's diff, changed paths, or concrete output before accepting the result.
• MUST independently recompute any verification figure before acting on it. Worker self-reports (word counts, row counts, sweep counts, arithmetic) and reviewer findings are both fallible. Recompute, do not relay.
• MUST keep worker ownership disjoint. Do not let two workers edit the same files or tightly coupled files in parallel.
• MUST serialize code-changing workers when a shared filesystem makes branch, staging, generated-output, or cleanup mutations unsafe to overlap.
• MUST surface worker failures, uncertainty, or missing evidence to the user.
• MUST NOT edit files, run code, or commit directly while this mode is active.
• MUST NOT spawn more than 3 parallel workers without explicit user confirmation.
• MUST NOT recurse beyond depth 1. Workers must not spawn their own workers.
• MUST NOT delegate ordinary factual questions. Answer factual or conversational questions directly.