mission-control

Produce a mission checkpoint report showing progress, blockers, and budget.

Close the active mission, extract learnings, and archive mission state.

Launch a new mission. Initializes mission state and begins the orchestration workflow.

List, create, or execute mission playbooks. Playbooks are reusable mission templates.

Code implementation from detailed specifications. Writes code, creates files, runs builds. Use when a task has a clear specification and needs code written. Always follows existing patterns found in the codebase. <example> Context: Orchestrator assigns an implementation task from the mission plan user: "Run a mission to add a user preferences page" assistant: "Spawning implementer agent with the task card for the PreferencesPage component." <commentary> Clear spec with defined file ownership and acceptance criteria makes this a perfect implementer task. </commentary> </example> <example> Context: Task card is ready after planning phase user: "Orchestrate adding email notifications" assistant: "Plan complete. Spawning implementer agents for the notification service and email template tasks in parallel." <commentary> Implementers can run in parallel when their file ownership lists don't overlap. </commentary> </example> <example> Context: User wants code written from a detailed spec user: "Implement the task described in this spec: create a retry middleware for the API client" assistant: "I'll use the implementer agent to write this from the spec, running in an isolated worktree." <commentary> Isolated worktree prevents partial changes from contaminating the working branch during implementation. </commentary> </example>

Decomposes high-level goals into task dependency graphs. Use when a mission needs to be broken into subtasks with dependencies, risk assessment, and agent assignment. Produces structured task cards and execution plans. <example> Context: Orchestrator needs to decompose a complex feature request user: "Run a mission to add user authentication to the app" assistant: "I'll use the mission-planner agent to break this into a task dependency graph before spawning implementation agents." <commentary> Multi-phase feature touching multiple files requires structured decomposition before action. </commentary> </example> <example> Context: User wants to plan a large refactoring user: "Plan a mission to refactor the payment module" assistant: "I'll invoke mission-planner to produce a dependency graph with risk tiers and execution waves." <commentary> Refactoring requires careful task ordering and risk assessment before implementation begins. </commentary> </example> <example> Context: Orchestrator is at the planning step of a migration mission user: "Orchestrate a migration from REST to GraphQL" assistant: "Spawning mission-planner to decompose the migration into parallelizable tasks with clear file ownership." <commentary> Migrations need explicit dependency mapping to identify safe parallelism and rollback points. </commentary> </example>

Deep codebase exploration and analysis. Read-only agent for finding patterns, understanding architecture, mapping dependencies, and answering questions about the codebase. Use when tasks require understanding before action. <example> Context: Orchestrator needs to investigate an unfamiliar codebase area user: "Run a mission to fix the flaky test suite" assistant: "I'll spawn a researcher agent first to map the test infrastructure before planning fixes." <commentary> Investigation before action prevents misguided implementation in unfamiliar areas. </commentary> </example> <example> Context: User asks a question requiring codebase exploration user: "How does authentication work in this codebase?" assistant: "I'll use the researcher agent to trace the auth flow and map all relevant files." <commentary> Read-only exploration is a natural fit for the researcher's constrained toolset. </commentary> </example> <example> Context: Implementer task needs prior investigation user: "Orchestrate adding rate limiting to all API endpoints" assistant: "Spawning researcher to identify all API endpoint locations before the implementer task is planned." <commentary> Research phase ensures implementers have complete file ownership lists before they start. </commentary> </example>

Post-mission learning extraction. Analyzes completed missions to identify patterns, anti-patterns, and reusable knowledge. Produces structured learnings for mission memory. Use during /debrief to extract lessons learned. <example> Context: User runs /debrief after a completed mission user: "/debrief" assistant: "Spawning retrospective agent to analyze the mission and extract learnings for mission memory." <commentary> The /debrief command always triggers the retrospective agent to ensure learnings are captured. </commentary> </example> <example> Context: Orchestrator reaches the final task in a mission plan user: "Run a mission to migrate the database schema" assistant: "All tasks complete. Spawning retrospective agent as the final step to extract learnings from this mission." <commentary> Every mission plan includes a retrospective task as the last step to build project memory over time. </commentary> </example> <example> Context: User wants to review what was learned from past missions user: "What did we learn from the last mission?" assistant: "I'll use the retrospective agent to analyze the completed mission logs and summarize the key learnings." <commentary> Retrospective agents analyze mission state and logs — they never need to write or run commands. </commentary> </example>

Independent quality assurance and code review. Validates implementation against acceptance criteria, checks for bugs, security issues, and architectural violations. Required for Tier 1+ tasks. Produces pass/fail verdict with required fixes. <example> Context: Orchestrator needs to review a completed Tier 1 implementation task user: "Run a mission to add user authentication" assistant: "Implementation complete. Spawning reviewer agent to validate against acceptance criteria before merging." <commentary> All Tier 1+ tasks require an independent reviewer — never skip review for non-trivial changes. </commentary> </example> <example> Context: User wants independent validation of completed work user: "Review the authentication implementation for security issues" assistant: "I'll use the reviewer agent to audit the implementation against OWASP criteria and produce a verdict." <commentary> The reviewer's read-only constraint ensures it can't accidentally modify the code it's reviewing. </commentary> </example> <example> Context: Orchestrator is in the review wave of a mission user: "Orchestrate a database migration" assistant: "All implementation tasks complete. Spawning reviewer agents for each Tier 2 task in the review wave." <commentary> Review wave runs after all implementation is done, with reviewers checking each task independently. </commentary> </example>

This skill should be used when the user asks about "mission learnings", "memory files", "view or manage memory", "how the learning system works", or wants to understand how mission-control persists and loads learnings from past missions.

Coordinate multiple specialized agents through a structured 7-step operational workflow. Use when: (1) task is too large for a single pass, (2) user asks to "break down", "orchestrate", "parallelize", "delegate", or "run a mission", (3) multiple independent investigations or actions needed concurrently, (4) project-wide refactoring/migration/analysis, (5) user asks for multi-agent coordination, (6) task decomposes into research, planning, implementation, validation phases, (7) work requires risk controls, quality gates, or structured monitoring.

This skill should be used when the user asks about "playbooks", "available playbook types", "create a custom playbook", "which playbook fits", or "reusable mission templates". Also use when deciding whether a built-in playbook matches a mission type or when the user needs guidance on orchestration workflow selection.

3 hooks across 3 events