Conductor

Conductor

Purpose

conductor is a context isolation and branch registry protocol. It keeps one master session clean while messy exploration, implementation, research, review, or learning happens in separate user-interactive branch sessions.

Use it to decide whether a request belongs in the master session, an interactive branch, an explainer sidecar, or a merge flow. It does not replace Trellis executors or other workflow agents; it governs how branches are created, tracked, completed, and optionally merged.

Core Rules

• The master session owns the project overview: goal, constraints, branch map, global decisions, approved summaries, risks, and next steps.
• Use session registry first. Create visible branch cards before creating real sessions.
• Do not create a new session until the user confirms the branch card and its stable session title.
• Every session must have a stable ID, stable title, purpose card, expected output, and return condition.
• Never put mutable status such as active, done, or blocked in the session title. Status belongs in the branch map or Today View.
• Branch sessions are user-interactive threads, not one-shot background workers.
• A branch receives only a branch brief, approved summaries, explicit file references, and messages inside that branch.
• The master session must not read or absorb raw branch history by default.
• A completion report is generated only after the user confirms the branch is complete.
• The master session only edits and merges branch context after the user explicitly chooses to merge that completed branch.
• Explainer branches are pollution zones for learning and long explanations. They default to no merge.
• The explainer sidecar may read across all session contexts for explanation, but its output is non-authoritative and never merges by default.
• Decisions made inside a branch are not globally binding until confirmed in the master session.
• Do not assume all branches can run in parallel. Always run a dependency pass before opening branches.

Session Types And Names

Use exactly these session types:

Rules:

• Session titles must start with the Conductor ID.
• Session titles must include role and wave when relevant.
• Session titles must be short enough to identify in a thread list.
• Do not create multiple explainer sessions. Use one fixed explainer per project.
• Do not create multiple dispatch sessions. Use one fixed dispatch session per project.
• Prefer at most 2 active interactive branch sessions, plus the optional dispatch session and fixed explainer sidecar.

Session Registry First

Conductor creates branch cards before sessions. A branch card must include:

• ID and stable session title
• type and role
• one-sentence purpose
• why it exists
• dependency/wave placement
• allowed context
• expected artifact
• completion criteria
• return condition
• whether it should open now, stay planned, or stay blocked

Only after the user confirms the card should Conductor create or bind a real session. When entering a branch, the first visible content must be a Purpose Card:

You are branch CD-001: First confirmed branch
Purpose: do the first bounded task the user confirmed
Not for: unscoped work outside the branch card
Input: master snapshot snap-xxx; approved summaries only
Output: completion-report.md
Return to master when: branch output is ready and the user confirms completion

After creating, blocking, completing, merging, parking, or archiving a session, refresh a compact Today View in the master session:

Active now:
- CD-001 First confirmed branch — task — waiting for user review
- CD-E01 Dirty questions — sidecar explainer

Planned, not opened:
- CD-002 Implementation plan — waits for CD-001

Merge pending:
- none

Routing

Whenever this skill is active, route each new request before acting:

1. Keep in master session if it changes global goals, scope, constraints, priorities, branch structure, merge decisions, or project snapshots.
2. Use the dispatch session if the conversation is mainly about whether to open sessions, whether tasks are parallel or serial, dependency order, wave planning, or branch-card design.
3. Create or use an interactive branch if the work is exploratory, implementation-heavy, research-heavy, review-heavy, or likely to produce many intermediate details.
4. Send to the explainer sidecar if the user wants long-form explanation, background learning, conceptual clarification, or tutorial-style help.
5. Enter merge flow only after a branch is user-confirmed complete.

Keep this routing lightweight. Do not turn every message into process ceremony.

Dispatch Session

Do not open the dispatch session by default. Suggest opening [CD-DISPATCH][routing] Branch planning when:

• branch planning takes more than 2-3 turns
• there are more than 3 candidate branch cards
• dependency order is unclear
• the user asks whether work should be parallel or serial
• session proliferation is starting to make the project hard to navigate

The dispatch session is isolated from the master session. It may discuss:

• which sessions should exist
• which branches should be planned, opened, parked, blocked, or archived
• which work can run in parallel and which must be serial
• branch titles, roles, expected outputs, and completion criteria
• active-session budget

The dispatch session must not do implementation, research, review, or long-form explanation. It must not read raw branch histories by default. It returns only a compact dispatch decision to the master session, for example:

Dispatch decision:
- Open CD-001 and CD-E01 now.
- Keep CD-002 planned until CD-001 completion report is ready.
- Do not open implementation branch yet.

Dependency Pass And Wave Plan

Before creating or opening branches, identify execution order. Many branches depend on outputs from earlier branches and must remain planned or blocked until their prerequisites are done.

Classify each proposed branch:

• ready_parallel: can start now from the current master snapshot without waiting on another branch.
• dependent: needs a specific branch output, decision, artifact, or user confirmation first.
• gate: a review, merge, or master-session decision required before the next wave can start.
• optional: useful but not on the critical path.
• explainer: can run as a sidecar unless the user explicitly makes it blocking.

Output a compact wave plan before creating threads:

Rules:

• Only branches in the current unlocked wave should become active by default.
• Later-wave branches may be recorded as planned; mark them blocked if the user tries to start them before prerequisites are met.
• Parallel means "safe to run from the same snapshot without needing each other's outputs", not merely "different topics".
• If dependencies are ambiguous, ask the user to confirm the order before creating branch threads.
• After a wave completes, update the snapshot, note what it unlocks, and then propose the next wave.

Branch State Machine

Use these stable states:

Default active interactive branch limit: 2. The fixed explainer sidecar and optional dispatch session do not count as interactive branches. If creating a third active branch, suggest parking, completing, or archiving an existing branch first.