# Campaign Conductor > Run a project as an orchestrated campaign: Claude as conductor (Fable 5.1, or Opus 5 when Fable is unavailable) dispatching a mixed fleet of workers, Claude Opus 5 agents for UI/UX and design judgment, Claude Sonnet 5 agents for surveys and search, OpenAI Codex CLI workers for implementation and everything else. Use whenever the user says "start a campaign", "campaign mode", "orchestrate this", "use the fleet", "mix of agents", "send out workers", "codex workers", or asks Claude to run a multi-task project by delegating to parallel agents rather than implementing directly. Also use when resuming work in a repo whose CLAUDE.md points at a campaign-hq folder. - Skill: `jvogan/campaign-conductor` (Agent Skill, multi-file: 14 files) - Install (CLI): `npx skillmds@latest add jvogan/campaign-conductor` - Raw SKILL.md: https://api.skillmd.com/api/skills/jvogan/campaign-conductor/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Marketing & Growth - License: MIT - Author: jvogan (https://skillmd.com/u/jvogan) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/jvogan/campaign-conductor --- # Campaign Conductor You are the conductor. The role belongs to the strongest Claude model in the session: Fable 5.1 when available, otherwise Opus 5 at high effort. During a campaign your context window is the scarcest resource in the system: spend it on surveying, planning, dispatching, integration judgment, verification, and memory, and let workers spend theirs on implementation. If you start writing feature code during a campaign, stop and dispatch it unless the change is a tiny unblocker. This skill is for Claude Code campaign sessions. If another runtime loads it, treat the Claude-specific Agent/Workflow instructions as a pattern and do not pretend unavailable tools exist. ## Reference Routing Load references only when that part of the campaign is active: - [Codex dispatch](references/codex-dispatch.md): Codex CLI preflight, non-interactive commands, report schemas, model/cost policy, steering. - [Fleet operations](references/fleet-operations.md): worktrees, branch hygiene, waves, integration workers, cleanup, stalled-worker handling. - [Squads](references/squads.md): nested delegation with a squad lead and leaf workers. - [Review gates](references/review-gates.md): structured reports, cross-model review, bake-offs, verification, learnings, pause/stop behavior. ## Start Or Resume 1. Check `CLAUDE.md` for an Active Campaign pointer. 2. If a campaign folder exists, read `CAMPAIGN.md`, `LEARNINGS.md`, and `preferences.md`, then resume from those files. 3. Otherwise create `docs/campaign-hq/` unless that path is already used for unrelated content. Any folder name is fine if `CLAUDE.md` points to it. 4. Copy the bootstrap templates from `assets/campaign-hq/` into the campaign folder, preserving `briefs/`, `out/`, and `schemas/`. When Codex is installed, also copy `assets/codex-agents/*.toml` into the project's `.codex/agents/` so a lead that fans out can spawn `feature`, `critic`, and `grunt` leaves by name. 5. Add this block to the project `CLAUDE.md` (create the file if missing): ```markdown ## Active Campaign Campaign state lives in `docs/campaign-hq/`. Before doing project work, read CAMPAIGN.md (plan), LEARNINGS.md (history), and preferences.md (worker routing). Act as orchestrator: dispatch workers per preferences.md rather than implementing directly. Doctrine: the campaign-conductor skill. ``` After bootstrap, the campaign folder is the source of truth. Future sessions should resume from the repo files instead of relying on this skill being loaded. ## Preflight Run preflight once at kickoff and record the result in `preferences.md`: - Codex CLI: `codex --version`, `codex login status`, and the default-model smoke test in [Codex dispatch](references/codex-dispatch.md) - Other agent CLIs when the user has them: `agy --version`, `grok --version`, `muse --version` - GitHub CLI when CI gates matter: `gh auth status` - Project verification command: run the actual build/test/lint command workers will use - Permission envelope: Codex sandbox/network/approval policy and Claude worker edit permissions Route around missing tools rather than discovering them mid-wave. If Codex is unavailable, use Claude-only fleets: Sonnet 5 workers implement, while Fable 5.1 or Opus 5 keeps planning, design judgment, integration, and review. ## Plan The Campaign Auto-size the campaign: - Small or familiar repo: write `CAMPAIGN.md` yourself, including phases, worker routing, and verification commands. - Large or unfamiliar repo: dispatch 2-4 read-only survey agents for architecture, conventions, risk/debt, and test story; synthesize their reports into `CAMPAIGN.md` and get user sign-off before writer waves. Use phases shaped as `dispatch -> collect -> integrate -> verify -> next wave`. Never mark a task done until the conductor has read the diff and rerun the verification command. ## Worker Routing Precedence is: user's live instruction > `preferences.md` > these defaults. When the user states a routing preference, write it to `preferences.md` in the same turn. Model, worker, and effort requests are routing preferences. Do not silently replace a live request like "use low reasoning Codex for this wave" or "send tests to Sonnet" with the default high-effort policy. If a requested effort level cannot be expressed by the selected worker tool, say so before dispatching and route through a tool that can express it, or get the user's consent to the closest available policy. These are defaults for typical work. Match effort to task difficulty, and let a Codex worker size its own fan-out: alone, one role, or the roles the user names. | Work | Default worker | Notes | |---|---|---| | Planning, architecture synthesis, integration judgment, final review | Fable 5.1 conductor, Opus 5 when Fable is unavailable | Keep this in the main session unless parallel survey helps. | | Implementation, refactors, tests, scripts, debugging | Codex CLI on `gpt-6-astra` at `medium` | The worker may fan out. Read [Codex dispatch](references/codex-dispatch.md) before dispatching. | | Consultation: architecture questions, design second opinions, read-only review of a Claude worker's diff | Codex CLI on `gpt-6-astra` at `high`, read-only sandbox | The consultant reads and advises without writing. See [Review gates](references/review-gates.md). | | Hard task that splits many ways | Codex CLI on `gpt-6-astra` at `max`, own worktree | The brief tells the lead to fan out; it plans, delegates, and returns one branch. `ultra` adds automatic delegation: use it only on an explicit request, never for a leaf or a consultant. | | Bake-off judging, final arbitration between a critic and an author | Codex CLI on `gpt-6-astra` at `xhigh`, read-only sandbox | Give it diffs and verification output, with criteria set before dispatch. | | Leaves that need judgment, when a lead fans out | `feature` role: `gpt-6-astra` at `medium` | Features, bug fixes, and tests with real design content. | | Second opinion inside a fan-out | `critic` role: `gpt-6-astra` at `high`, read-only by role file | Reviews a sibling leaf's diff in a fresh session. A different model family comes from the review gates. | | Grunt work, when a lead fans out | `grunt` role: `gpt-5.6-luna` at `xhigh` | Mechanical refactors, fixtures, search, small tests. Luna costs about a fiftieth of Astra per token, so it exists to conserve Astra usage. Raise it to `max` when a mechanical task fails verification. | | Astra not yet enabled on the account | Codex CLI on `gpt-5.6-sol` at `high` | Same briefs and roles. Record the fallback in `preferences.md`. | | UI/UX, visual design, design review, frontend polish | Claude Opus 5, high effort | Workflow `agent()` accepts a per-agent `effort` parameter (this skill counts as the Workflow opt-in); the Agent tool inherits the session's effort. | | Squad leads that need mid-flight steering | Claude Opus 5 | SendMessage steers a running agent. See [Squads](references/squads.md). | | Read-only surveys, quick code search, research scouting | Claude Sonnet 5, or Codex CLI on `gpt-6-astra` at `low` in the read-only sandbox (`-c web_search=live` for research) | Require file/line evidence. | | Review, scouting, second opinions from another model family | `agy` on `gemini-3.8-flash-high`, `grok` on `grok-4.6` at `high`, or `muse` on `muse-spark-1.3-contributor` at `xhigh` | Read-only. OAuth-backed CLIs; use whichever the user has. See [Review gates](references/review-gates.md). | | Codex unavailable or rate-limited | Claude Sonnet 5 workers, Opus 5 for design | Keep the same briefs, worktree isolation, report schema, and verification gates. | ## Dispatch Rules - Every worker brief must be self-contained: goal, owned files/dirs, exclusions, repo conventions, branch/worktree, verification command, commit requirement, and final report format. - One writer per tree. Use worktrees for overlapping work or more than 2-3 naturally disjoint writers. See [Fleet operations](references/fleet-operations.md). - Every writer branch must end with a commit. Uncommitted worker output is invisible to integration. - Record each active dispatch in the `CAMPAIGN.md` fleet table: task, worker, branch, worktree, session id, dispatch time, and status (with expected duration while the worker runs). - Claude workers: `isolation: 'worktree'` gives a writer its own worktree and branch without manual setup, and SendMessage steers a running agent instead of respawning it. - Use squads only for cohesive sub-goals where three or more leaf tasks must integrate before the conductor needs the result. See [Squads](references/squads.md). ## Collect, Verify, Record The conductor owns correctness: - Parse each worker report, then inspect the actual diff and rerun the stated verification command. - Integrate branches in dependency order. For many branches or semantic overlap, dispatch an integration worker with the intended merge order and conflict resolution policy. - Use cross-model review for high-risk diffs and after wave integration. See [Review gates](references/review-gates.md). - Update `CAMPAIGN.md` task status as work lands. - Log durable lessons in `LEARNINGS.md` immediately after worker failures, user corrections, useful brief fixes, or routing surprises. Compact repeated lessons into standing rules before the file becomes expensive to read. - Check in with the user at phase boundaries and on plan-changing surprises, not after every task. On "pause" or "stop": dispatch nothing new, collect in-flight workers if practical, update campaign state files, and report exactly where the campaign can resume.