fray

Explicit root-orchestrator mode for coordinating multiple concurrent or interrupting software workstreams with Codex-native subagents, model and effort routing, scoped ownership, return reconciliation, and outcome-oriented reporting. Invoke only when the user writes `$fray-orchestrator` or explicitly says "fray-orchestrator" and asks this chat to orchestrate. Do not invoke for a direct task, a Fray UI worker, ordinary research, audit, implementation, planning, verification, or review, or a generic mention of Fray.

The gh-CLI playbook for a fray-ui worker signed into GitHub (invoke as fray:gh). Load this whenever your effort touches GitHub — reading or triaging an issue or PR, reviewing a diff, checking CI/release status, or searching issues/PRs — to use `gh` eagerly and correctly: the read-vs-write boundary (never comment/label/close/merge unless the human asks), the toon absolute-path shim for large JSON, concrete read recipes, and active Monitor/background-Bash CI/PR watches. Only meaningful when you are signed in (`gh auth status --active` exit 0); the session-seed hook injects a pointer here when you are.

The worker contract for a fray-ui-spawned session (invoke as fray:worker). Load this when you are a fray-ui WORKER (env FRAY_UI_THREAD is set, and a THREAD: line is at the top of your prompt) to understand how to drive your one effort — how to SIGNAL through your final message (bare rest vs the done/awaiting/question fences), how to PERSIST through your scratchpad, and when to come to rest for a human decision. Not the orchestrator methodology skill: the human + the UI orchestrate; you drive one effort.

Coordinate multi-agent software work with a canonical task ledger, slot-aware subagent delegation, continuous dispatch, independent review, deployment, and live verification. Use when the user gives multiple standalone tasks, asks Codex to orchestrate subagents or todos, says to keep going or never stop, or expects work to continue through implementation, review, deploy, and live-validation gates without losing backlog items.

Use this skill when running a large, mixed set of Codex efforts - investigations, decided fixes, verifications, launch pushes, audits, or refactor campaigns - where the human wants to stay in the loop. Fray is an orchestrator-first Codex workflow: use the `.fray/` per-thread control surface, compute the board with `node .agents/plugins/fray-codex/scripts/fray/index.mjs`, reconcile returned sub-agents, preflight thread-scoped dispatches, and preserve the repo's thread, decision, and tracker constraints.

Use when driving ONE cohesive epic (a single block of functionality) to completion over a long, largely-autonomous run — you hold the full goal set, own ONE living epic mega-document as the single source of truth, and intelligently dispatch + steer + spot-check sub-agents on PIECES of that one epic, judging serialize-vs-parallelize dynamically per the dependency structure at each moment. Distinct from fray (which juggles MANY independent tasks): this is one coherent goal, one shared doc, long-running. Auto-triggers on "drive this epic", "work through the epic autonomously", "dynamic-orchestrator mode", or being handed a single large multi-unit implementation to see through.

Run a dueling-sub-agents DIALECTIC to resolve a hard or contested decision — two adversarial debater sub-agents are each assigned one side, then argue back and forth (research → steelman the opponent → refute) across at least two full round-trips, until one genuinely convinces the other on the merits OR an irreducible crux is isolated for the human. Invoke for contested design / product / architecture / naming / security / trade-off calls where a single agent's take is suspect and adversarial stress-testing adds real value. Do NOT invoke for clear, low-stakes, or already-decided questions — the ceremony isn't worth it. Triggers on "dialectic", "have two agents debate this", "steelman both sides", "argue this out adversarially", "red-team both positions".

Load this skill IMMEDIATELY — as your FIRST action, before any other tool call or response — whenever the user mentions "fray" in ANY form ("fray", "fray mode", "enter/start fray", "load fray", "use fray", "in fray", "the fray skill"), OR asks to orchestrate / run / coordinate a multi-effort push, audit, or campaign through sub-agents. Also the default for any large, mixed set of efforts — investigations + decided fixes + verifications — toward a goal (a launch push, a pre-release audit, a refactor campaign) where the human wants to stay in the loop on what the investigations surface; the default for any multi-effort push that is part "find out what's true" and part "land the decided thing." Use it instead of hardcoding a multi-agent DAG up front — those bury the decision points and fan out expensively before the facts are in. Treat any "fray" mention as an explicit instruction to load this skill, never as ambient context.

Use when orchestrating multi-threaded work in pi through the project-local pi-fray extension. Fray uses `.fray/` thread files, SDK-backed child AgentSessions, native follow-up reminders, captured child final outputs, optional raw sidecars, and explicit reconciliation.

Run a dueling-sub-agents DIALECTIC to resolve a hard or contested decision — two adversarial debater sub-agents are each assigned one side, then argue back and forth (research → steelman the opponent → refute) across at least two full round-trips, until one genuinely convinces the other on the merits OR an irreducible crux is isolated for the human. Invoke for contested design / product / architecture / naming / security / trade-off calls where a single agent's take is suspect and adversarial stress-testing adds real value. Do NOT invoke for clear, low-stakes, or already-decided questions — the ceremony isn't worth it. Triggers on "dialectic", "have two agents debate this", "steelman both sides", "argue this out adversarially", "red-team both positions".

Use this skill in OpenCode for large, mixed efforts: investigations, fixes, reviews, launch pushes, audits, or refactors where the human needs decisions surfaced as facts emerge. Fray uses `.fray/` thread files as the control surface, OpenCode `Task` sub-agents as bounded workers, task ids as durable agent handles, and explicit reconciliation after every return.