Josh Knapp
2dffef0767
The mission-control (Flight Control) project is being closed upstream. This embeds the project files directly in the repo under container/mission-control/, bakes them into the Docker image at /opt/mission-control, and copies them into place at container startup instead of git cloning from GitHub. Also adds missing osc52-clipboard, audio-shim, and triple-c-sso-refresh to the programmatic Docker build context in image.rs. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
3.1 KiB
name, description
| name | description |
|---|---|
| init-mission-control | Onboard to Mission Control by setting up the projects registry. Use when projects.md is missing or when adding new projects. |
Mission Control Onboarding
Set up the projects registry (projects.md) and orient the user to the Flight Control workflow.
When to Use
Run /init-mission-control when:
projects.mddoesn't exist (first time using Mission Control)- Adding a new project to the registry
- Updating an existing project's details
Workflow
1. Check Registry Status
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?"
2. Create or Update Registry
If creating new:
- Copy
projects.md.templatetoprojects.md - Remove the example entries
- Interview the user to register their first project (see step 3)
If updating:
- Read existing
projects.md - Ask: add new project, or update existing?
- Proceed accordingly
3. Discover Projects
Ask 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
- Ask for the parent directory path (e.g.,
~/projects) - Scan immediate subdirectories for git repos
- Present the list and ask which ones to register
- Auto-detect details for each selected project
- Ask for descriptions in batch (or let the user provide them later)
Option B: Add a single project
- Ask for the project path (e.g.,
~/projects/my-app) - Verify it exists and is a git repo
- Auto-detect details
- Ask only for what can't be detected: description, and optionally stack/status
Auto-detection: For each project directory, run:
- Slug: directory name
- Remote:
git -C <path> remote get-url origin
Only ask the user for fields that can't be auto-detected.
4. Orientation
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."
5. Offer Next Step
"Want to run
/init-projectfor {project-slug} now?"
If yes, invoke the /init-project skill for the registered project.
Guidelines
Keep It Quick
This is onboarding, not the main work. Get the registry set up and move on.
Don't Over-Explain
The user will learn the methodology by using it. Give the orientation but don't lecture.
Validate Paths
When the user provides a filesystem path, verify it exists before adding to the registry.