Mission Control: Check-in · git:20261104.5a782e0 · 2026-11-04 · sha256 cd5605cc84ba192c

Mission Control: Check-in git:20261104.5a782e0A

Immutable. This exact content never changes and is served at /api/v1/blob/cd5605cc84ba192c.

---
name: "Mission Control: Check-in"
description: "Ask every crew session the three check-in questions, wait for the replies, and give the user one list of what they need to do, in three buckets, every command complete with its directory"
when_to_use: "From the coordinator session when the user asks what they need to do, 'anything needed from me?', 'check in with each session', or when the coordinator has not heard from a session in a while."
model: opus
effort: medium
metadata:
  glyph: ᛟ
  family: mission-control
  goblin-spinner: checking in|waiting for replies|rolling up needs
disable-model-invocation: false # the trigger is the user asking what they need to do, which the coordinator sees first; the skill only sends messages and edits the needs list
allowed-tools: ["Read", "Bash(python3:*)", "mcp__mission-control__mc_board", "mcp__mission-control__mc_send", "mcp__mission-control__mc_need"]
argument-hint: "(no arguments)"
---

# Mission Control: Check-in

Three questions out, one list back. The list is the whole output; the user asked for it twice on the first run because prose updates scrolled away.

## Step 1: Ask

`mc_board` first, so the list starts from what the ledger already knows (states, slots, open needs), then `python3 "${CLAUDE_PLUGIN_ROOT}"/scripts/mc.py reconcile`. Fix what it prints before asking anyone: a merged PR's row to `done` with `mc_report`, a need the user has plainly done marked done, so the questions go to sessions that are still working and the list does not repeat an item already handled. Drift that cannot be fixed from here (a crew task never joined, a claim the roadmap on main lacks) opens the list as its own bucket; an `unlisted` line is not drift and stays off the list. A crew row that reads `waiting on you` is skipped: that session sits on a permission prompt or a question in its own window and cannot answer, so the list opens with its window, the way coordinate step 0a says, rather than waiting on a reply that arrives only after the user has been there. Then one message to every other live crew session (`mc_send` to `all`):

```text
Check-in from mission control; reply in three lines. (1) Current state of your branch and anything uncommitted. (2) Exactly what you need from the user right now, as the commands they would type, or "nothing". (3) Anything blocking you that is not the user.
```

## Step 2: Wait

Replies arrive as messages over the next minutes. A session that is mid-tool answers when its turn ends. Wait for every live session, up to a few minutes; a silent one is reported as `no reply; last report <summary> at <time>`, never guessed at.

## Step 3: The list

Record every item from a reply's answer 2 with `mc_need` (why, the exact command, the absolute directory), so the board carries it too. Then write the list in this chat, in three buckets, nothing else above it:

```markdown
## Needs you

### Drift

- <task>: <what reconcile found and the one command or action that fixes it>.

### Now

1. **<task>: <one line>.** `cd <absolute worktree>/<run_from> && <command>`: <what it unblocks>.

### Right after <the thing it queues behind>

2. ...

### Running

- <task>: need <n>, <what it is>, since <start time>; <where it is watched>. Paste the result with `/mc done <n>` when it finishes.

### Nothing from you

- <task>: <state, one line>.
```

Rules for the list: every command is complete, with its `cd`, because the user's `!` shell may be standing in another checkout; a hosted command says `read-only` or `writes` in the line; an approval names the session to visit; a slot that the coordinator will grant on a release is stated as such, with who it waits on; a PR waits on the reviewer `reconcile` names, never on "the user" unless the user is that reviewer or the merge is theirs. A need whose status is `started` (the user typed it and it runs on; the board's `Running` group) goes under `Running` and never under `Now`: it needs nothing typed until its result is in. A bucket with nothing in it is left out, `Drift` and `Running` included.

## Step 4: Keep it true

When the user does an item, they press `d` on it in the board or run `/mc done <n>`; the session that asked can also clear it with the next `mc_report`. When the user says they have typed one that runs on (a backfill, a long hosted measurement), mark it started on their word: `python3 "${CLAUDE_PLUGIN_ROOT}"/scripts/mc.py needs start <n> --note "<the background task id, or the session watching it>"` from here, or the user's own `s` on the board or `/mc started <n> [note]`. It then leaves the `Now` bucket and the needs-Jason count and closes as every need does, with `/mc done <n>` and the result. An open item that stays past the next check-in is repeated at the top of the new list, marked `still open`.