Menu
Onboard to Mission Control by setting up the projects registry. Use when projects.md is missing or when adding new projects.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | init-mission-control |
| description | Onboard to Mission Control by setting up the projects registry. Use when projects.md is missing or when adding new projects. |
Set up the projects registry (projects.md) and orient the user to the Flight Control workflow.
Run /init-mission-control when:
projects.md doesn't exist (first time using Mission Control)Check if projects.md exists in the mission-control repository root.
If missing:
"No projects registry found. Let's set one up — this tells Mission Control where your projects live."
If exists:
"Projects registry found. Want to add a new project or update an existing one?"
If creating new:
projects.md.template to projects.mdIf updating:
projects.mdAsk the user how they want to add projects:
"Want to scan a directory for projects, or add a single project?"
Option A: Scan a directory
~/projects)Option B: Add a single project
~/projects/my-app)Auto-detection: For each project directory, run:
git -C <path> remote get-url originOnly ask the user for fields that can't be auto-detected.
After the registry is set up, briefly orient the user:
"You're all set. Here's the workflow:"
/init-project— Run this in each project to set up.flightops/with methodology references and configure the project crew/mission— Define what you want to achieve (outcomes, not tasks)/flight— Break a mission into technical specs/leg— Generate implementation steps for each flight leg/agentic-workflow— Execute legs with automated Developer + Reviewer agents
"Start with
/init-projecton the project you just registered."
"Want to run
/init-projectfor {project-slug} now?"
If yes, invoke the /init-project skill for the registered project.
This is onboarding, not the main work. Get the registry set up and move on.
The user will learn the methodology by using it. Give the orientation but don't lecture.
When the user provides a filesystem path, verify it exists before adding to the registry.
Initialize a project for Flight Control. Creates .flightops directory with methodology reference and artifact configuration. Run before using other Flight Control skills on a new project.
Run a behavior test — spawn two live agents (an Executor that performs each step's actions and a Validator that judges each step's expected results), drive them through the spec's step table communicating mid-test so failures surface immediately, then write a run log with evidence. Tests are specs that follow the Witnessed pattern: every action is judged by an independent agent. Verifies system properties through observables (UI state, HTTP responses, shell output, filesystem state) measured via whichever apparatus (MCP, tool) is registered. Invocation: `/behavior-test <slug>` to run a test by slug. Specs are authored inline during flight/leg/mission planning — see `AUTHORING.md` sibling file for the authoring guide. Spec format lives in the target project's `.flightops/ARTIFACTS.md`.
Active orchestrator for multi-agent flight execution. Drives leg design per leg, then batches implementation across all autonomous legs, with a single code review and commit at the end of the flight.
Create technical flight specifications from missions. Use when breaking down a mission into implementable work or planning technical approach.
Between-mission codebase health assessment. Run after `/mission-debrief`, never after an individual flight, to verify the codebase is flight-ready or scaffold a maintenance mission. Per-flight findings instead roll into the next flight or accumulate into an end-of-mission maintenance flight — not into this skill.
Generate detailed implementation guidance for LLM execution. Use when creating atomic implementation steps from a flight.