Codex inter agent communication and fleet skills

codex-interagent-communication_SKILL.md

name	codex-interagent-communication
description	Discover and message independent Codex CLI sessions using `codex agents` and `codex queue`. Use for communication between separately launched Codex root sessions; use native collaboration tools for agents in the same multi-agent tree.

Codex inter-agent communication

Communicate with an independent Codex session through the installed CLI.

Choose the channel

• For an agent in the current multi-agent tree, use the native collaboration tools.
• For a separately launched local or remote Codex session, use this workflow.

Discover a target

Use a thread UUID or exact session name supplied by the user. If it is missing, codex agents can interactively browse sessions on the shared local app-server; add --remote <ADDR> for a remote server. Do not guess a target or treat codex resume --all history as proof that a session is currently running.

Send a message

Sending changes another session, so require authorization for the message and target. An explicit user request to send that message is sufficient.

Verify support with codex queue --help, then run:

codex queue --thread <UUID_OR_EXACT_NAME> --message <TEXT>

Pass --remote <ADDR> only when the target is on that app-server. If remote authentication is required, reference its environment-variable name with --remote-auth-token-env; never expose the token value.

Report the target and queued-message ID. A successful queue operation proves acceptance by the app-server, not that the recipient has read or answered it. Do not send follow-ups, poll, or wait for a reply unless requested.

fleet_SKILL.md

name	fleet
description	Orchestrate a fleet of manually-launched Codex sessions as workers. Use when a task is big enough to split across several terminals, with each session working in its own git worktree and coordinated through native collaboration or codex queue.

Fleet orchestration

You are the orchestrator. Workers are Codex sessions the user launches in separate terminals. For workers in the current multi-agent tree, use Codex's native collaboration tools. For independently launched local or remote sessions, use codex agents and codex queue.

Invariants

1. Never message a session the user did not name. codex agents shows sessions on the shared app-server; unrelated sessions may be present.

2. Keep source out of the orchestrator context. Delegate repository reading and diff inspection to workers or reviewers, and retain their conclusions.

3. Do not route a permission block through another worker. Return it to the user.

4. Treat worker self-reports as leads, not evidence. Verify claims by having a worker or reviewer inspect the actual files and tests.

5. Every worker uses its own git worktree. The main checkout stays on its current branch. Create worktrees with:

   git -C <main-checkout> worktree add <path> -b <branch>

   Verify with git worktree list before accepting a worker's first commit.

6. Workers never write to production out of band. Schema and data changes go through the repository's migration and deployment flow. Reading production for diagnosis is fine; writing is not.

Phase 1 — Plan the roster

Understand the task first. If that needs code reading, delegate exploration and keep only the findings. Split work into genuinely independent units: separate files or modules with no shared edits.

Present the roster and stop:

#	Worker	Scope	Model	Start in
1	importer parser	tires/importer/parse.py	selected for task	plan first
2	migrations	tires/migrations/	selected for task	plan first

Give each worker a self-contained launch brief. Codex does not provide the Claude -n/--name launch option assumed by the original workflow; after the user launches a session, obtain its exact name or UUID from codex agents. Use codex -m <model> -C <project-dir> when model or directory selection is needed. Do not guess a session identity.

Phase 2 — Brief each worker

Every brief must include:

Goal:        <one sentence>
Worktree:    <exact path; create with git worktree add ...>
Files:       <exact paths owned by this worker, and only these>
Constraints: <conventions and what not to touch>
Done means:  <observable criterion>
Reply:       Return the complete plan or result to the orchestrator through
             the applicable Codex collaboration channel.

For an independent session, queue the brief only after the user has named or confirmed the target:

codex queue --thread <UUID_OR_EXACT_NAME> --message '<brief>'

Queueing requires authorization for the target and message. A successful queue reports acceptance by the app-server, not that the worker read or answered. Do not poll or send follow-ups unless requested.

Phase 3 — Planning and edits

Codex has no directly equivalent documented CLI flag to launch a worker in Claude's permission plan mode. State the planning boundary explicitly in the brief, and ask the user to keep the worker at its plan/approval boundary when that matters. Do not claim that wording enforces a mode.

The orchestrator must not silently switch a worker's mode or permissions. Ask the user to make that change in the worker session.

Phase 4 — Collect

Workers should report plans and results through native collaboration tools when they are in the same Codex tree. For independent sessions, the user must relay the response, or the worker can be queried through the normal session UI; the codex queue command is one-way queueing, not an inbox reader.

If a worker goes quiet, ask the user to check that terminal. Do not re-send the brief blindly.

Phase 5 — Review each plan and result

Review both plans and results through a separate reviewer or worker:

• Plan critique: does the plan match the actual code, and what does it miss?
• Result review: inspect the changed files, tests, and worktree state.

If the tree is not a git repository, say that diff-level review is weaker. Report findings by severity and state what was not verified.

Phase 6 — Iterate or close

Send corrections as a fresh brief to the same named worker. At close, summarize per worker: changed files, review findings, verification, and remaining work.

Failure modes worth naming early

• Overlapping scope: split by file; shared edits silently corrupt the fleet.
• Under-specified briefs: workers invent scope when paths are absent.
• Orchestrator context bloat: delegate reads and retain conclusions.
• Unverified self-report: inspect the actual diff and test evidence.
• Wrong session target: use only a user-confirmed exact name or UUID.