Mission Control Explained

Claude Code skill

Mission Control, explained

A way to hand Claude a plan that touches several codebases and have it run as a supervised project. Claude does the coding. You approve the plan, watch the board and sign off before anything reaches production code.

One plan, many reposEach codebase (a "repo") gets its own dedicated worker. Workers never touch each other's repo.
Nothing starts unapprovedEvery section of the plan needs your tick before a single line of code is written.
Nothing ships uncheckedA conflict review runs, and you approve it, before work is merged into the main codebase.

The idea in one paragraph

Think of it as a project manager and a small crew. The project manager (Mission Control) interviews you, writes a plan, and waits for you to approve it. Then it assigns one worker per codebase, tracks their progress on a live board, and routes any new to-dos you add to the right worker. When the work is done, an independent checker looks for clashes with what other people have shipped in the meantime. Only after you approve that check does the work go into the main codebase. The project manager itself never writes code.

Who is involved

YouOwner

Answer the intake questions, approve or send back plan sections, add to-dos, answer the occasional blocker, and give the final go-ahead.

Mission ControlYour Claude Code session

Runs the interview, drafts the plan, holds the approval gates, launches and supervises the workers, merges finished work when your policy allows, and keeps the board current. Never writes feature code.

Repo agentsOne per codebase

Do the actual coding. Each works only in its own repo, in a separate copy of the code, on its own tasks. Each submits finished work as pull requests and reports back in a fixed format.

Pre-prod checkerOne per codebase, read-only

Runs at the end. Compares the finished work against what has changed in the main codebase since the mission started and flags conflicts in code, shared contracts, config and docs. Cannot change anything.

How a mission runs

The order below is fixed. Mission Control will not skip ahead, even if asked to "just start".

  1. 1

    Intake You answer

    A short interview, one question at a time. Which repos will change and which are read-only context (both as tick-lists you can also answer by typing; the repo you are in and its dependencies come pre-selected), is there a written plan, what does "done" look like, who may merge what, and what is off limits. Secrets, production config and deploys are always off limits.

  2. 2

    Plan Automatic

    Mission Control reads the repos and splits the plan into small sections: the scope, a task list for each codebase, and the order things will be integrated. No code is touched.

  3. 3

    Review Your gate

    The plan appears in a file called REVIEW.md. For each section you tick approve or changes and leave comments. Say "reviewed" in chat and Mission Control revises what you sent back. This repeats until every section is approved.

  4. 4

    Launch Automatic

    Mission Control creates a working area for each repo and starts one repo agent per codebase, all at once. Each agent gets only its own tasks and the approved scope.

  5. 5

    Execute Automatic, you can steer

    Agents work through their tasks and open pull requests. The live board (MISSION.md) shows every task, its status and any blocker that needs you. You can add to-dos in TODO.md at any time and they are routed to the right agent. A task only counts as done when there is a merged pull request to show for it.

  6. 6

    Integrate and verify Automatic

    Full test suites run on the combined work. If you named a test environment, the work is deployed there and smoke-tested. A fresh verification agent with no prior context checks each "done" outcome and demands evidence. Failures become new tasks.

  7. 7

    Pre-prod check Your gate

    The read-only checkers look for clashes with anything merged to main since the mission began, drifted contracts between repos, outdated docs, and migration or config collisions. Findings land in REVIEW.md with a proposed fix each. You approve every section before anything moves to main.

  8. 8

    Close Automatic

    Work is merged (or handed to you as a list of pull requests, depending on the policy you chose). You get a short summary: done criteria, findings and fixes, links, and anything still open.

The three files you will touch

Everything lives in plain text inside a folder called ~/.claude/missions/<mission-name>/ on your machine, outside the codebases themselves, so nothing about the mission ever gets committed. You can open it in any editor.

REVIEW.mdThe plan, section by sectionTick approve or changes, add comments, save. Later the pre-prod findings appear here too.
MISSION.mdThe live boardPhase, progress, what needs you, one table per repo, recent activity. Mission Control rewrites it; you just read it.
TODO.mdYour inbox to the crewAdd a line under the right repo. It becomes a task for that repo's agent and gets marked as routed.

What you decide up front

Two of the intake answers shape how much runs on its own.

Guardrails that always apply

The questions it will ask

See the intake list (useful to prepare answers)
  1. Repos to edit. Which codebases will change? A tick-list, with the repo you are already in pre-selected. Type names instead if you prefer; a rough name like "socket" or "the docs" is enough. Access is checked right away.
  2. Repos to reference. Which should be read for context but never changed? Anything the chosen repos depend on is pre-ticked; untick what you do not want.
  3. Plan source. Paste it, point to a file or issue, or say there is no plan yet.
  4. Mission name. A short slug. Your Claude Code session is renamed to it, so the sidebar shows which mission is which.
  5. Definition of done. Three to six checkable outcomes.
  6. Working branch. Where the combined work collects before main.
  7. Merge permissions. Who may merge what.
  8. Merge gates. What a pull request must pass.
  9. Off-limits. Anything to add beyond the standing defaults.
  10. Test environment. Optional. Where to deploy and check before main.
  11. Reviewers. Only you, or anyone who edits the review file.
  1. Then a short plan interview: the goal, what triggered it, what changes in each repo, what passes between repos, what is out of scope, and any order or deadline. It ends with a read-back: "Is this the plan?"

Get the skill

This bundle contains both skills — mission-control-code (runs the mission) and mission-control-update (the refresh pass) — plus the two subagents they launch and an INSTALL.md. It works on any Claude Code install; no account or org access needed.

⇩  Download mission-control-skill.zip ~16 KB · both skills + INSTALL.md

Unzip it, then from the unzipped folder:

Install (once):

mkdir -p ~/.claude/skills ~/.claude/agents
cp -R mission-control-code mission-control-update ~/.claude/skills/
cp mission-control-code/agents/*.md ~/.claude/agents/

Restart claude so it picks up the new skills and agents. You also need git and the GitHub CLI logged in (gh auth status). Full notes are in INSTALL.md.

Never installed a skill before? Step by step

  1. Get Claude Code. This is a skill for Claude Code, Anthropic's coding tool. Install it and sign in. You also need git and the GitHub CLI — run gh auth login once and choose GitHub.com so it can open pull requests for you.
  2. Download and unzip. Click the button above, then double-click mission-control-skill.zip. You get a folder named mission-control-skill.
  3. Open a terminal in that folder. On a Mac: right-click the folder → "New Terminal at Folder" (or drag the folder onto Terminal). On Windows: open the folder and type cmd in the address bar.
  4. Paste the three install commands from the box above and press Enter. They copy both skills into ~/.claude/skills and the two helper agents into ~/.claude/agents.
    Windows without WSL: copy the mission-control-code and mission-control-update folders into C:\Users\<you>\.claude\skills\, and the two files in mission-control-code\agents\ into C:\Users\<you>\.claude\agents\.
  5. Restart Claude Code so it picks up the new skill.
  6. Check it worked. Type /mission-control-code. If it starts asking the intake questions, you're set.

Getting started

Open Claude Code in a folder that holds your repos (or an empty folder; it will fetch them), then type /mission-control-code or say "start a mission".

Any time you want a refresh, type /mission-control-update. It verifies what the agents reported, sweeps pull requests, routes new to-dos, merges what your policy allows, and gives you a three-line status. For a long mission, ask for it on a timer, for example every 20 minutes.