Josh Knapp
2dffef0767
All checks were successful
Build App / compute-version (push) Successful in 2s
Build App / build-macos (push) Successful in 2m47s
Build Container / build-container (push) Successful in 9m0s
Build App / build-linux (push) Successful in 4m41s
Build App / build-windows (push) Successful in 5m33s
Build App / create-tag (push) Successful in 3s
Build App / sync-to-github (push) Successful in 10s
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>
161 lines
6.3 KiB
Markdown
161 lines
6.3 KiB
Markdown
---
|
|
name: flight-debrief
|
|
description: 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.md` must exist)
|
|
- A flight must have status `landed` before debriefing
|
|
|
|
## Workflow
|
|
|
|
### Phase 1: Context Loading
|
|
|
|
1. **Identify the target project**
|
|
- Read `projects.md` to find the project's path
|
|
|
|
2. **Verify project is initialized**
|
|
- Check if `{target-project}/.flightops/ARTIFACTS.md` exists
|
|
- **If missing**: STOP and tell the user to run `/init-project` first
|
|
- Do not proceed without the artifact configuration
|
|
|
|
3. **Read the artifact configuration**
|
|
- Read `{target-project}/.flightops/ARTIFACTS.md` for artifact locations and formats
|
|
|
|
4. **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
|
|
|
|
5. **Load project context**
|
|
- Read the target project's `README.md` and `CLAUDE.md`
|
|
- Identify key implementation files from leg outputs and flight log
|
|
|
|
6. **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
|
|
1. **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
|
|
1. **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.
|