git:20261014.5d6d9cd to git:20261015.ffae591

5 added, 1 removed. Audit A to A.

---

name: team-conductor

description: Orchestrate AgentChef team runs from Claude Code with bounded Codex workers, explicit user gates, isolated worktrees, and verified integration.

---

# Team Conductor

Read [the run protocol](references/run-protocol.md) before operating a team run.

This skill is explicit-only. Team mode is available on every install from

AgentChef 1.6.0. Set `AGENTCHEF_TEAM_MODE=off` to switch team execution off for

a process; this skill never changes this variable for you.

Start and merge approvals are written only by the dual-agent-brain (Beyin) chat

hook, and only for Beyin's board. When Beyin is installed (`~/.beyin/vault.txt`

exists), run every engine command as `beyin takim <command> ...` instead of

`node scripts/team-run.mjs`; it supplies Beyin's board, creates it when missing,

and opens the run and worker panels. Without Beyin, `doctor` reports a failing

`approval-writer` check: say that team runs need dual-agent-brain and stop.

1. Run `doctor`. If the `execution` check fails, explain that

`AGENTCHEF_TEAM_MODE=off` switches team execution off for this process and

stop. Never change the variable for the user.

2. Split the request into 1-4 independent tasks. Write one `agent-brief` per

worker and check each with

`npm run coordination:board -- brief-check --brief-file <file> --json`.

Choose roles from the allowlist in the team-mode catalog and default to a

read-only role. Fan-out rule: one worker per independent write scope; run

two or more workers only when their write scopes are disjoint and no task

needs another task's output; put dependent work in a later run; never more

than four. A change that touches one file stays with one worker. Tell an

implementing role to change code, not only diagnose it.

3. Run `plan`. Show the plan and worker table, then ask the user to send the

exact chat sentence `baslat <runId>`. Never create or edit an approval file.

If `start` returns 3, stop and ask again; do not retry around the gate.

4. Run `start`, then poll `status` every 60-120 seconds. Do not edit worker

scopes while they run. Never use taskkill or Stop-Process; use `abort` only

when the user asks to stop the run.

5. Run `collect`. On exit 4, show partial reports and ask how to proceed. Run

`integrate`; on exit 4, show conflicts and checks and ask how to proceed.

6. Run `verify` on the integration branch. Show integration statistics,

verification report, and verdict. Ask the user to send the exact chat

sentence `birlestir <runId>` before running `merge`.

7. `merge` creates a merge commit on the user's branch. Push/PR and

`onayla TASK-x` are separate actions and need their own request. If usage

limits pause a worker, report it and stop; when the user says the limit has

reset, run `resume` (same plan, same worktrees, each paused worker continues

its saved Codex thread); `resume --wait` waits for the reset time read from

the limit message (or 30 minutes, at most 12 hours) and then resumes. If an

integration check fails and you repair the integration branch yourself,

- commit the repair and run `integrate --recheck`; never merge it by hand. If the machine slept, crashed or restarted and the

+ commit the repair and run `integrate --recheck`; never merge it by hand.

+ If a worker finished without changes (for example it only diagnosed), finish

+ its scope yourself in the integration branch, commit, and run

+ `integrate --recheck --covers TASK-x`. Tell implementing roles to change

+ code, not only diagnose it. If the machine slept, crashed or restarted and the

run shows `running` with no supervisor heartbeat, the same `resume`

recovers it: orphaned workers continue their saved thread in the same

worktree. After abort, run cleanup only if the user asks.

Show the gate-specific command, exit code, affected tasks, and next action at

each step. Do not claim a later gate passed when an earlier gate is partial or

blocked.