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>
6.3 KiB
name, description
| name | description |
|---|---|
| flight-debrief | Post-flight analysis for continuous improvement. Use after a flight is completed to capture lessons learned and improve the methodology. |
Flight Debrief
Perform comprehensive post-flight analysis for continuous improvement.
Prerequisites
- Project must be initialized with
/init-project(.flightops/ARTIFACTS.mdmust exist) - A flight must have status
landedbefore debriefing
Workflow
Phase 1: Context Loading
-
Identify the target project
- Read
projects.mdto find the project's path
- Read
-
Verify project is initialized
- Check if
{target-project}/.flightops/ARTIFACTS.mdexists - If missing: STOP and tell the user to run
/init-projectfirst - Do not proceed without the artifact configuration
- Check if
-
Read the artifact configuration
- Read
{target-project}/.flightops/ARTIFACTS.mdfor artifact locations and formats
- Read
-
Load flight documentation
- Read the mission for overall context and success criteria
- Read the flight for objectives, design decisions, and checkpoints
- Read ALL legs to understand the planned implementation
- Read the complete flight log for ground truth on what happened
-
Load project context
- Read the target project's
README.mdandCLAUDE.md - Identify key implementation files from leg outputs and flight log
- Read the target project's
-
Examine actual implementation
- Read files created or modified during the flight
- Compare intended vs actual implementation
- Note deviations, workarounds, or unexpected discoveries
Phase 2: Crew Debrief Interviews
Read {target-project}/.flightops/agent-crews/flight-debrief.md for crew definitions and prompts (fall back to defaults at .claude/skills/init-project/defaults/agent-crews/flight-debrief.md).
Validate structure: The phase file MUST contain ## Crew, ## Interaction Protocol, and ## Prompts sections with fenced code blocks. If the file exists but is malformed, STOP and tell the user: "Phase file flight-debrief.md is missing required sections. Either fix it manually or re-run /init-project to reset to defaults."
Developer Interview
- Spawn a Developer agent in the target project context (Task tool,
subagent_type: "general-purpose")- Provide the "Debrief Interview" prompt from the flight-debrief phase file's Prompts section
- The Developer examines code changes, test coverage, patterns, and technical debt
- The Developer provides structured debrief input
Architect Interview
- Spawn an Architect agent in the target project context (Task tool,
subagent_type: "general-purpose")- Provide the "Debrief Design Review" prompt from the flight-debrief phase file's Prompts section
- The Architect compares planned design decisions against actual implementation
- The Architect evaluates whether the flight design held up and provides feedback for future flights
- This closes the design feedback loop — the same role that reviewed the spec now evaluates the outcome
Human Interview
Brief questions to capture insights documents may miss. Keep this lightweight — 2-3 questions max based on what you observed in the flight log.
- On anomalies/deviations: "The log mentions [X] — what drove that decision?"
- On leg quality: "Were any leg specs unclear or missing key context?"
- On blockers: "What slowed you down most? Was it predictable?"
Skip the human interview if the flight log is comprehensive and there are no obvious gaps.
Phase 3: Deep Analysis
Synthesize Developer input, Architect input, human input, and document analysis across multiple dimensions:
Outcome Analysis
- Did the flight achieve its objective?
- Which mission success criteria did this flight advance?
- Were all checkpoints met?
- What value was delivered?
Process Analysis
- How accurate were the leg specifications?
- Were there gaps requiring improvisation?
- Did the leg sequence make sense?
- Were legs appropriately sized?
- Did acceptance criteria prove verifiable?
Technical Analysis
- What technical decisions were made during flight that weren't planned?
- Were there architectural surprises?
- What technical debt was introduced?
- Does implementation align with project conventions?
Deviation Analysis
- What deviations occurred and why?
- Were deviations captured in the flight log?
- Should any deviations become standard practice?
Knowledge Capture
- What was learned that should be documented?
- Are there reusable patterns that emerged?
- Are README or CLAUDE.md updates needed?
Phase 4: Skill Effectiveness Analysis
Evaluate whether the mission-control skills could be improved:
Mission Skill
- Did the mission provide adequate context?
- Were success criteria clear and measurable?
Flight Skill
- Did the flight structure support execution?
- Were design decisions adequately captured?
- Was the leg breakdown appropriate?
Leg Skill
- Did legs provide sufficient implementation guidance?
- Were acceptance criteria verifiable?
- Were edge cases adequately identified?
Phase 5: Generate Debrief
Create the flight debrief artifact using the format defined in .flightops/ARTIFACTS.md.
Phase 6: Flight Status Transition
Ask the user if the flight should be marked as completed. If confirmed, update the flight artifact's status from landed to completed.
Guidelines
Thoroughness Over Speed
- Read files completely, not just skim
- Consider root causes, not just symptoms
- Think about systemic improvements
Be Specific and Actionable
Avoid vague recommendations. Instead of "improve documentation," say:
- "Add a 'Devcontainer Commands' section to CLAUDE.md documenting the docker exec workflow"
Distinguish Severity
- Critical: Would have prevented significant rework or failure
- Important: Would have meaningfully improved efficiency
- Minor: Nice-to-have improvements
Credit What Worked
Identify effective patterns that should be reinforced or codified.
Consider the Meta-Level
- Did the mission/flight/leg hierarchy work?
- Were the right artifacts being created?
- Is there friction that could be eliminated?
Output
Create the debrief artifact using the location and format defined in .flightops/ARTIFACTS.md.
After creating the debrief, summarize the top 3-5 most impactful recommendations.