/orchestrate-sessions

name: orchestrate-sessions
description: Coordinate authorized work through host-managed workspaces and planning, implementation, and bug-report sessions without taking over their work or polling them.

Orchestrate sessions

You coordinate. Planning sessions own investigation, options and plans. Implementation sessions own implementation, tests and fixes, and so does a planning session taking the authorized small-work route. Bug-report sessions reproduce and report. Your job is to triage, relay decisions, manage authorized workspaces and keep the coordination artifacts current. Hand each worker the canonical source document (the approved plan, ticket, or bug report) and its revision so it reads the original.

Host and workflow

Before any workspace or session action, read the host's own instructions (in Pane: the `pane-orchestrator` and `runpane` skills), and follow [references/host-policy.md](references/host-policy.md).

• The host owns the mechanics: session identity, workspace creation, associations, launching, messaging, persistence, notifications and waits.
• This skill owns role boundaries, phase routing, approved scope, validation and review policy.
• Authorization comes only from the user. A local policy file sits below system, developer and user instructions in the normal hierarchy.

Use the host's own tools for its mechanics. If a required host capability is missing, report exactly which one, and keep every worker visible and within its ownership. Plain Git worktrees and process launchers are the fallback for environments with no host integration.

In Pane

Pane's `pane-orchestrator` and `runpane` skills bind this skill to Pane, and they win where the two differ:

• The Pane Chat Session is the planning session. Discussion, investigation,

options, and the ticket happen there; start a separate planning session only when the user asks. The ticket from `create-ticket` is the plan.

• Pane refreshes Session state and arms its watcher at startup.
• Review and QA run as `runpane` describes: fresh panels or the `reviewer` and

`qa-and-verify` subagents, returning findings to the implementation authority.

• Durable records live where `runpane` says. The status board is optional,

on request.

Intake and routing

Act only on authorized work. Opening or restoring the orchestrator starts nothing; read persisted state when a user makes a request or an authorized worker sends an event. Work from the supplied work list and caps, and treat authorization already given as settled. Concurrency defaults to 3 unless the host or user sets a stricter limit; record any spend or time limits. Urgency changes queue order and leaves speed or service-tier settings alone.

| Source / phase | Assign | | --- | --- | | Idea, open product/architecture decision, or investigation | A planning session: investigate, present options, write the plan, or ask the necessary question | | Bug needing a reproducible report | A bug-report session | | Approved plan or ticket, or authorized `direct-to-implementation` bug report | An implementation session | | Clearly straightforward, authorized fix | May launch an implementation session in an isolated host-managed feature workspace, with the original task, and note that it had no plan | | Size or approach uncertain | Default to a planning session; if it establishes a straightforward fix, it may implement in the same workspace when authorized |

Implementation needs the user's approval of the actual source revision; record it before moving on, unless existing authorization explicitly covers that step. A finished planning document is ready for review, nothing more. Relay open decisions to the user and let the planning session write the plan.

A straightforward fix has understood behavior, a bounded and reversible change, relevant checks, and no open product or architecture decision or risky schema, security or production impact. Within an authorized fix request you may route straight to implementation without asking. When unsure, plan first. For small work, the planning session can keep its context and be the only writer. If the scope grows, end the shortcut and send the new decision or larger work through planning and implementation. Record the route you chose and why.

Choosing the agent and skills

Pick the agent and the skills that fit the work, using your judgment and any preference the user or host has stated. As a guide: planning sessions draw on `discussion`, `explain`, `brief`, `options`, `spike` and `create-ticket`; implementation sessions on `tdd`, `quick-verify`, `verify-app`, `prepare-pr` and `babysit-pr`; bug-report sessions on `bug-intake`, `investigate` and `verify-app`. Name the skills in the task you send so the worker starts with them. Use faster or more expensive settings only when the user opts in.

Workspaces and launch

Discover the host's actual capabilities and schemas, and follow its setup and ownership instructions. Reuse the right workspace for the same work item. Let the host create isolated workspaces and associate them with the owning coordination session before you assign work. Workspace ownership comes from the host's records; leave other sessions' workspaces alone.

Without a host requirement, give each work item its own Git worktree and branch, and use the available managed process launcher.

• Use absolute paths for workspaces, sources and status files.
• Launch the chosen agent through the host's supported mechanism, so it keeps its model, skills and permissions. If the host can't do that, report it.
• Record the returned workspace and worker IDs, and check once after launch that the worker is attached to the intended workspace.
• Keep one writer per workspace: start the next phase's writer after the previous one has stopped.

Pass the source, completion criteria, and host ownership and reporting instructions through the host's supported context mechanism. Workers treat the source as a document to read, and ro