Bundle mission-control into Triple-C instead of cloning from GitHub
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
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>
This commit is contained in:
@@ -0,0 +1,233 @@
|
||||
---
|
||||
name: agentic-workflow
|
||||
description: Active orchestrator for multi-agent flight execution. Drives the full leg cycle (design, implement, review, commit) using three separate Claude instances.
|
||||
---
|
||||
|
||||
# Agentic Workflow
|
||||
|
||||
Orchestrate multi-agent flight execution. You drive the full leg cycle — designing legs, spawning Developer and Reviewer agents, and managing git workflow — for a target project's flight.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- Project must be initialized with `/init-project` (`.flightops/ARTIFACTS.md` must exist)
|
||||
- A mission must exist and be `active`
|
||||
- A flight must exist and be `ready` or `in-flight`
|
||||
|
||||
## Invocation
|
||||
|
||||
```
|
||||
/agentic-workflow flight {number} for {project-slug} mission {number}
|
||||
```
|
||||
|
||||
Example: `/agentic-workflow flight 03 for epipen mission 04`
|
||||
|
||||
## Phase 1: Context Loading
|
||||
|
||||
1. **Read `projects.md`** to find the target project's path
|
||||
2. **Read `{target-project}/.flightops/ARTIFACTS.md`** for artifact locations
|
||||
3. **Read `{target-project}/.flightops/agent-crews/leg-execution.md`** for project crew definitions, interaction protocol, and prompts (fall back to defaults at `.claude/skills/init-project/defaults/agent-crews/leg-execution.md`)
|
||||
- **Validate structure**: The phase file MUST contain `## Crew`, `## Interaction Protocol`, and `## Prompts` sections. Each prompt subsection MUST have a fenced code block.
|
||||
- **If the file exists but is malformed**: STOP. Tell the user: "Phase file `leg-execution.md` is missing required sections. Either fix it manually or re-run `/init-project` to reset to defaults." Do NOT improvise missing prompts — halt and get the file fixed.
|
||||
4. **Read the mission artifact** — outcomes, success criteria, constraints
|
||||
5. **Read the flight artifact** — objective, design decisions, leg list
|
||||
6. **Read the flight log** — ground truth from prior execution
|
||||
7. **Count total legs** from the flight spec — track progress throughout
|
||||
8. **Determine starting point** — which leg is next based on flight log and leg statuses
|
||||
9. **Read git strategy** from `{target-project}/.flightops/ARTIFACTS.md` `## Git Workflow` section. Default to `branch` if the section is absent.
|
||||
10. **Set `{working-directory}`** — `branch`: the target project root; `worktree`: the worktree path (see Git Workflow section below)
|
||||
|
||||
**Mark flight as in-flight**: After loading the flight artifact, if the flight status is `ready`, update it to `in-flight` before proceeding. If already `in-flight`, leave it as-is.
|
||||
|
||||
If resuming a flight already in progress, verify state consistency:
|
||||
- Flight log entries must match leg statuses
|
||||
- If discrepancies exist, remediate before proceeding
|
||||
|
||||
## Phase 2: Leg Cycle
|
||||
|
||||
Repeat for each leg in the flight.
|
||||
|
||||
### 2a: Leg Design
|
||||
|
||||
1. **Design the leg** using the `/leg` skill (if the Skill tool is unavailable, read `.claude/skills/leg/SKILL.md` and follow the workflow directly)
|
||||
- Read the flight spec, flight log, and relevant source code
|
||||
- Create the leg artifact with acceptance criteria
|
||||
2. **Spawn a Developer agent for design review** (Task tool, `subagent_type: "general-purpose"`)
|
||||
- Working directory: `{working-directory}`
|
||||
- Provide the "Review Leg Design" prompt from the leg-execution phase file's Prompts section
|
||||
- The Developer reads the leg artifact and cross-references against actual codebase state
|
||||
- The Developer provides a structured assessment: approve, approve with changes, or needs rework
|
||||
3. **Incorporate feedback** — update the leg artifact to address any issues raised
|
||||
- High-severity issues: must fix before proceeding
|
||||
- Medium-severity issues: fix unless there's a clear reason not to
|
||||
- Low-severity issues and suggestions: apply at discretion
|
||||
4. **Re-review if substantive changes were made** — spawn another Developer for a second pass
|
||||
- Skip if only minor/cosmetic fixes were applied
|
||||
- If the second review raises new high-severity issues, fix and re-review once more
|
||||
- **Max 2 design review cycles** — if issues persist after 2 rounds, escalate to human
|
||||
5. **Update leg status** to `ready`
|
||||
6. **Signal `[HANDOFF:review-needed]`** when the leg design is finalized
|
||||
|
||||
### 2b: Leg Implementation
|
||||
|
||||
**NEVER implement code directly.** Spawn a Developer agent via the Task tool.
|
||||
|
||||
**Interactive/UAT legs**: If the leg is a UAT, alignment, or other interactive leg (identified by slug like `uat-*`, `alignment-*`, or explicit marking in the flight spec), do NOT spawn agents to execute it autonomously. The human performs verification — the Flight Director guides them through it:
|
||||
1. **Design the leg** normally (2a), but keep it lightweight — the acceptance criteria are verification steps, not implementation tasks
|
||||
2. **Skip the autonomous implementation cycle** (no Developer/Reviewer agents)
|
||||
3. **Guide the human through verification steps one at a time** — present a single step, wait for the human to perform it and report results, then proceed to the next step
|
||||
4. **Fix issues inline** — if the human reports a failure, diagnose and fix it (spawning a Developer agent if code changes are needed), then re-verify that step before moving on
|
||||
5. **Commit when all steps pass** — spawn a Developer agent to update artifacts and commit
|
||||
|
||||
**Standard (autonomous) legs**: Follow the Developer/Reviewer cycle below.
|
||||
|
||||
1. **Spawn a Developer agent** (Task tool, `subagent_type: "general-purpose"`)
|
||||
- Working directory: `{working-directory}`
|
||||
- Provide the "Implement" prompt from the leg-execution phase file's Prompts section
|
||||
- The Developer updates leg status to `in-flight`, implements to acceptance criteria
|
||||
- When done, the Developer updates leg status to `landed`, updates flight log, and signals `[HANDOFF:review-needed]` — do NOT let it commit
|
||||
2. **Spawn a Reviewer agent** (Task tool, `subagent_type: "general-purpose"`)
|
||||
- Working directory: `{working-directory}`
|
||||
- Provide the "Review" prompt from the leg-execution phase file's Prompts section
|
||||
- The Reviewer evaluates ALL uncommitted changes against acceptance criteria and code quality
|
||||
- The Reviewer signals `[HANDOFF:confirmed]` or lists issues with severity
|
||||
3. **If issues found**, spawn a new Developer agent to fix them
|
||||
- Provide the "Fix Review Issues" prompt from the leg-execution phase file with the Reviewer's feedback
|
||||
- Loop review/fix until the Reviewer confirms
|
||||
4. **Spawn the Developer agent to commit** after review passes
|
||||
- Provide the "Commit" prompt from the leg-execution phase file's Prompts section
|
||||
- The commit must include code changes, updated flight log, and leg status updated to `completed`
|
||||
|
||||
### 2c: Leg Transition
|
||||
|
||||
After `[COMPLETE:leg]` (all git/PR operations run from `{working-directory}`):
|
||||
1. Increment `legs_completed`
|
||||
2. **Manage PR**:
|
||||
- **First leg**: Open a draft PR with the leg checklist in the body (see PR Body Format below), then check off the completed leg
|
||||
- **Subsequent legs**: Use `gh pr edit --body` to check off the newly completed leg in the existing PR body
|
||||
3. If more legs remain → return to 2a
|
||||
4. If all legs complete → proceed to Phase 3
|
||||
|
||||
## Phase 3: Flight Completion
|
||||
|
||||
1. **Verify all legs** show `completed` status
|
||||
2. **Verify flight log** has entries for all legs
|
||||
3. **Verify documentation** — check that CLAUDE.md, README, and other project docs reflect any new commands, endpoints, configuration, or APIs introduced during the flight. If not, spawn a Developer agent to update them.
|
||||
4. **Update flight status** to `landed`
|
||||
5. **Check off flight** in mission artifact
|
||||
6. **Clean up worktree** (worktree strategy only) — run `git worktree remove` after the PR is marked ready for review
|
||||
7. **Signal `[COMPLETE:flight]`**
|
||||
|
||||
The flight debrief is a separate step run via `/flight-debrief` after the flight lands. The debrief transitions the flight to `completed`.
|
||||
|
||||
## Architecture
|
||||
|
||||
The Flight Director (you) orchestrates according to this skill. Project crew composition, roles, models, and prompts are defined in `{target-project}/.flightops/agent-crews/leg-execution.md`.
|
||||
|
||||
**Separation is mandatory.** Project crew agents run in the target project and load its CLAUDE.md and conventions. The Reviewer has no knowledge of the Developer's reasoning — only the resulting changes. This provides objective review.
|
||||
|
||||
**Model selection:** Follow the model preferences in the phase file. MC may use Opus for complex planning. Never use Opus for the Reviewer.
|
||||
|
||||
## Handoff Signals
|
||||
|
||||
Signals are part of the Flight Control methodology and are NOT configurable per-project. All crew agents must use these exact signals:
|
||||
|
||||
| Signal | Emitted By | Meaning |
|
||||
|--------|-----------|---------|
|
||||
| `[HANDOFF:review-needed]` | Developer | Code/artifact ready for review |
|
||||
| `[HANDOFF:confirmed]` | Reviewer | Review passed |
|
||||
| `[BLOCKED:reason]` | Any crew agent | Cannot proceed, needs resolution |
|
||||
| `[COMPLETE:leg]` | Developer | Leg finished and committed |
|
||||
| `[COMPLETE:flight]` | Flight Director | Flight landed |
|
||||
|
||||
## Flight Director Decision Log
|
||||
|
||||
The Flight Director must maintain transparency about its own decisions. After each major orchestration step, log what happened and why in the flight log under a `### Flight Director Notes` subsection:
|
||||
|
||||
1. **Phase file loading** — Record which phase file was loaded (project or default fallback) and what crew was extracted
|
||||
2. **Agent spawning** — Record which agent was spawned, with what prompt, and what model
|
||||
3. **Review cycle decisions** — When incorporating feedback, note what was accepted/rejected and why
|
||||
4. **Escalation decisions** — When choosing between "fix and re-review" vs "escalate to human," note the reasoning
|
||||
5. **Signal interpretation** — When a crew agent's output is ambiguous, note how it was interpreted
|
||||
|
||||
This is not a separate file — it goes in the flight log alongside leg entries. The goal is that anyone reviewing the flight log can understand not just what the crew did, but why the Flight Director made the orchestration choices it did.
|
||||
|
||||
## Git Workflow
|
||||
|
||||
### Strategy Selection
|
||||
|
||||
Read the `## Git Workflow` section from `{target-project}/.flightops/ARTIFACTS.md`. The `Strategy` property determines which workflow to use. If the section is absent, default to `branch`.
|
||||
|
||||
### Shared Elements
|
||||
|
||||
Both strategies use the same branch naming, commit format, PR lifecycle, and PR body format.
|
||||
|
||||
**Branch naming**: `flight/{number}-{slug}`
|
||||
|
||||
**Commit message format:**
|
||||
```
|
||||
leg/{number}: {description}
|
||||
|
||||
Flight: {flight-number}
|
||||
Mission: {mission-number}
|
||||
```
|
||||
|
||||
**PR lifecycle:**
|
||||
|
||||
| Event | Action |
|
||||
|-------|--------|
|
||||
| First leg complete | Open draft PR with leg checklist in body |
|
||||
| Each leg complete | Commit code + artifacts, update PR checklist |
|
||||
| Flight landed | Mark PR ready for review |
|
||||
|
||||
**PR body format:**
|
||||
|
||||
```markdown
|
||||
## {Flight Title}
|
||||
|
||||
{Flight objective — one paragraph}
|
||||
|
||||
**Mission**: {Mission Title}
|
||||
|
||||
## Legs
|
||||
|
||||
- [ ] `{leg-slug}` — {brief description}
|
||||
- [ ] `{leg-slug}` — {brief description}
|
||||
```
|
||||
|
||||
### Strategy: Branch
|
||||
|
||||
The default single-checkout workflow. One flight at a time per working copy.
|
||||
|
||||
| Step | Command |
|
||||
|------|---------|
|
||||
| Flight start | `git checkout -b flight/{number}-{slug}` |
|
||||
| Set `{working-directory}` | Target project root |
|
||||
| Agents work in | Project root |
|
||||
| Flight landed | PR marked ready for review |
|
||||
|
||||
### Strategy: Worktree
|
||||
|
||||
Worktree isolation enables parallel flights on a single repo clone.
|
||||
|
||||
| Step | Command |
|
||||
|------|---------|
|
||||
| Flight start | `git worktree add .worktrees/flight-{number}-{slug} -b flight/{number}-{slug}` |
|
||||
| Set `{working-directory}` | `.worktrees/flight-{number}-{slug}` |
|
||||
| Orchestrator stays on | Main branch (does not checkout the flight branch) |
|
||||
| Agents work in | Worktree path |
|
||||
| Flight landed | PR marked ready for review, then `git worktree remove .worktrees/flight-{number}-{slug}` |
|
||||
|
||||
**Note:** The `.worktrees/` directory must be in `.gitignore` when using this strategy.
|
||||
|
||||
## Error Handling
|
||||
|
||||
| Situation | Action |
|
||||
|-----------|--------|
|
||||
| Developer agent fails mid-leg | Spawn new Developer with context of what failed |
|
||||
| Design review loops > 2 times | Escalate to human with unresolved design issues |
|
||||
| Code review loops > 3 times | Escalate to human |
|
||||
| Leg marked aborted | Escalate to human with abort details |
|
||||
| Artifact discrepancy | Remediate before proceeding |
|
||||
| Off the rails | Roll back to last leg commit, escalate |
|
||||
| Stale worktree (worktree strategy) | Run `git worktree prune`, recreate if needed |
|
||||
| Agent hangs on tests | Kill the agent, spawn new Developer to isolate and fix hanging tests |
|
||||
206
container/mission-control/.claude/skills/daily-briefing/SKILL.md
Normal file
206
container/mission-control/.claude/skills/daily-briefing/SKILL.md
Normal file
@@ -0,0 +1,206 @@
|
||||
---
|
||||
name: daily-briefing
|
||||
description: Cross-project status report with health assessment, stale work detection, and methodology insights. Use for a quick overview of all managed projects.
|
||||
---
|
||||
|
||||
# Daily Briefing
|
||||
|
||||
Generate a comprehensive status report across managed projects with health assessments, staleness detection, and cross-project methodology insights.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- `projects.md` must exist (run `/init-mission-control` first)
|
||||
|
||||
## Output
|
||||
|
||||
Daily briefings are saved to the `daily-briefings/` directory in the mission-control repository root, named by date: `daily-briefings/YYYY-MM-DD.md`. This directory is gitignored — briefings are local-only, ephemeral documents.
|
||||
|
||||
If a briefing already exists for today, append a sequence number: `YYYY-MM-DD-2.md`, `YYYY-MM-DD-3.md`, etc.
|
||||
|
||||
## Workflow
|
||||
|
||||
### Phase 1: Load Projects Registry
|
||||
|
||||
1. **Read `projects.md`** to get the full list of managed projects
|
||||
2. Extract each project's slug, description, path, and status
|
||||
|
||||
### Phase 2: Project Selection Interview
|
||||
|
||||
Present the user with a **checkbox list** (AskUserQuestion with `multiSelect: true`) of all registered projects so they can select which ones to include in the briefing.
|
||||
|
||||
**AskUserQuestion limits each question to 4 options.** Split projects across multiple questions in groups of 3, reserving the 4th option as "None from this group" (description: "Skip these projects") so the user can opt out of an entire group without blocking submission. Send all questions in a single AskUserQuestion call.
|
||||
|
||||
Format each project option as:
|
||||
- **Label**: Project slug
|
||||
- **Description**: Short project description from the registry
|
||||
|
||||
### Phase 3: Project Scanning
|
||||
|
||||
For each selected project, gather data by spawning **parallel Explore agents** (Task tool, `subagent_type: "Explore"`) — one per project. Each agent should:
|
||||
|
||||
1. **Check initialization status**
|
||||
- Check if `{project-path}/.flightops/ARTIFACTS.md` exists
|
||||
- If missing, note the project as "not initialized" and skip artifact scanning
|
||||
|
||||
2. **Read artifact configuration**
|
||||
- Read `{project-path}/.flightops/ARTIFACTS.md` for directory structure and naming conventions
|
||||
|
||||
3. **Discover all artifacts**
|
||||
- For filesystem-based projects, scan `{project-path}/missions/` for mission directories
|
||||
- For each mission, scan for flights; for each flight, scan for legs
|
||||
- Read all discovered artifacts and capture:
|
||||
- **Status fields** from each mission, flight, and leg
|
||||
- **Titles and objectives**
|
||||
- **Checklist completion** (count checked vs unchecked items)
|
||||
|
||||
4. **Read debriefs**
|
||||
- Read any flight debriefs and mission debriefs found
|
||||
- Extract key learnings, recommendations, and action items
|
||||
|
||||
5. **Check git activity**
|
||||
- Run `git log --oneline --since="7 days ago" -20` in the project directory
|
||||
- Capture recent commit activity as a proxy for momentum
|
||||
|
||||
6. **Return structured findings**
|
||||
The agent should return a structured summary including:
|
||||
- Project initialization status
|
||||
- List of all missions with status
|
||||
- List of all flights with status
|
||||
- List of all legs with status
|
||||
- Debrief summaries (key learnings and recommendations)
|
||||
- Recent git activity summary
|
||||
- Any anomalies (e.g., in-flight legs with no recent commits)
|
||||
|
||||
### Phase 4: Health Analysis
|
||||
|
||||
For each scanned project, assess health across these dimensions:
|
||||
|
||||
#### Activity Status
|
||||
- **Active**: Has in-flight work AND recent commits
|
||||
- **Stalled**: Has in-flight work but NO recent commits (7+ days)
|
||||
- **Idle**: No in-flight work
|
||||
- **Fresh**: Recently completed work (within 7 days)
|
||||
|
||||
#### Staleness Detection
|
||||
Flag artifacts that appear stale or abandoned:
|
||||
- **Missions** with status `active` or `planning` but no flight activity in 14+ days
|
||||
- **Flights** with status `in-flight` or `planning` but no leg progress in 7+ days
|
||||
- **Legs** with status `in-flight` or `planning` but no recent commits in 7+ days
|
||||
- **Open questions** that remain unresolved across any active artifacts
|
||||
|
||||
#### Completion Assessment
|
||||
- Missions nearing completion (most success criteria checked)
|
||||
- Flights with all legs completed but not yet marked `landed`
|
||||
- Orphaned artifacts (legs without flights, flights without missions)
|
||||
|
||||
### Phase 5: Cross-Project Insights
|
||||
|
||||
Analyze all debriefs (flight and mission) across selected projects to extract:
|
||||
|
||||
#### Common Patterns
|
||||
- Recurring recommendations across projects
|
||||
- Shared technical or process challenges
|
||||
- Patterns in what goes well vs what struggles
|
||||
|
||||
#### Mission Control Methodology Improvements
|
||||
- Feedback about the mission/flight/leg hierarchy itself
|
||||
- Skill effectiveness observations (were leg specs clear enough? were flight plans accurate?)
|
||||
- Suggestions for new skills, templates, or workflow changes
|
||||
|
||||
#### Project-Specific Recommendations
|
||||
- Per-project action items drawn from debrief insights
|
||||
- Suggested next steps based on current state
|
||||
|
||||
### Phase 6: Generate Briefing
|
||||
|
||||
Create the daily briefing file at `daily-briefings/YYYY-MM-DD.md`. Ensure the `daily-briefings/` directory exists first.
|
||||
|
||||
**Format:**
|
||||
|
||||
```markdown
|
||||
# Daily Briefing — {YYYY-MM-DD}
|
||||
|
||||
## Executive Summary
|
||||
{2-3 sentence overview of portfolio health — how many projects active, key highlights, top concerns}
|
||||
|
||||
---
|
||||
|
||||
## Project Reports
|
||||
|
||||
### {Project Slug}
|
||||
|
||||
**Health**: {Active | Stalled | Idle | Fresh} {optional: brief qualifier}
|
||||
**Recent Activity**: {X commits in last 7 days | No recent commits}
|
||||
|
||||
#### Current State
|
||||
| Level | Active | Completed | Stale | Total |
|
||||
|-------|--------|-----------|-------|-------|
|
||||
| Missions | {n} | {n} | {n} | {n} |
|
||||
| Flights | {n} | {n} | {n} | {n} |
|
||||
| Legs | {n} | {n} | {n} | {n} |
|
||||
|
||||
#### In Progress
|
||||
- **Mission**: {title} — {status summary}
|
||||
- **Flight**: {title} — {status}, {X/Y legs complete}
|
||||
- {Current/next leg and its status}
|
||||
|
||||
#### Staleness Alerts
|
||||
- {Description of stale artifact and how long it's been inactive}
|
||||
|
||||
#### Recommendations
|
||||
- {Actionable recommendation based on current state and debrief insights}
|
||||
|
||||
---
|
||||
|
||||
{Repeat for each selected project}
|
||||
|
||||
---
|
||||
|
||||
## Not Initialized
|
||||
{List any selected projects that lack `.flightops/` — suggest running `/init-project`}
|
||||
|
||||
---
|
||||
|
||||
## Cross-Project Insights
|
||||
|
||||
### Common Patterns
|
||||
{Themes observed across multiple project debriefs}
|
||||
|
||||
### Methodology Observations
|
||||
{Feedback about Flight Control itself — what's working, what could improve}
|
||||
|
||||
### Recommended Actions
|
||||
1. {Highest-priority cross-project action}
|
||||
2. {Second priority}
|
||||
3. {Third priority}
|
||||
```
|
||||
|
||||
### Phase 7: Present Summary
|
||||
|
||||
After writing the briefing file, present a **concise verbal summary** to the user:
|
||||
|
||||
1. The file path where the full briefing was saved
|
||||
2. Portfolio-level health (X active, Y stalled, Z idle)
|
||||
3. Top 3 items needing attention (stale work, approaching completions, blockers)
|
||||
4. Any cross-project methodology insights worth highlighting
|
||||
|
||||
Keep the verbal summary short — the detailed report is in the file.
|
||||
|
||||
## Guidelines
|
||||
|
||||
### Read-Only
|
||||
This skill only reads project artifacts and git history. It **never** modifies any project files, artifacts, or source code.
|
||||
|
||||
### Parallel Scanning
|
||||
Spawn project scanning agents in parallel for efficiency. Don't scan projects sequentially.
|
||||
|
||||
### Graceful Degradation
|
||||
- Projects without `.flightops/` get noted but don't block the report
|
||||
- Projects with no missions directory get reported as "no Flight Control artifacts"
|
||||
- Missing or malformed artifacts get flagged, not crashed on
|
||||
|
||||
### Honest Assessment
|
||||
Report what you find. Don't sugarcoat stale projects or inflate activity. The briefing is for situational awareness — accuracy matters more than optimism.
|
||||
|
||||
### Brevity in Verbal Summary
|
||||
The written briefing is the detailed artifact. The verbal summary should be 5-10 lines max — just the highlights and the file path.
|
||||
160
container/mission-control/.claude/skills/flight-debrief/SKILL.md
Normal file
160
container/mission-control/.claude/skills/flight-debrief/SKILL.md
Normal file
@@ -0,0 +1,160 @@
|
||||
---
|
||||
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.
|
||||
183
container/mission-control/.claude/skills/flight/SKILL.md
Normal file
183
container/mission-control/.claude/skills/flight/SKILL.md
Normal file
@@ -0,0 +1,183 @@
|
||||
---
|
||||
name: flight
|
||||
description: Create technical flight specifications from missions. Use when breaking down a mission into implementable work or planning technical approach.
|
||||
---
|
||||
|
||||
# Flight Specification
|
||||
|
||||
Create a technical flight spec from a mission.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- Project must be initialized with `/init-project` (`.flightops/ARTIFACTS.md` must exist)
|
||||
- A mission must exist before creating a flight
|
||||
|
||||
## Workflow
|
||||
|
||||
### Phase 1: Context Gathering
|
||||
|
||||
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. **Read the parent mission**
|
||||
- Understand the outcome being pursued
|
||||
- Identify which success criteria this flight addresses
|
||||
- Note constraints that apply
|
||||
|
||||
5. **Check existing flights**
|
||||
- What flights already exist for this mission?
|
||||
- What's been completed vs. in progress?
|
||||
- Are there dependencies on other flights?
|
||||
|
||||
### Phase 2: Code Interrogation
|
||||
|
||||
Explore the target project's codebase to inform the technical approach:
|
||||
|
||||
1. **Identify relevant code areas**
|
||||
- What existing code relates to this flight?
|
||||
- What patterns are already established?
|
||||
- What dependencies exist?
|
||||
|
||||
2. **Find files likely to be affected**
|
||||
- Source files to modify
|
||||
- Test files to create/update
|
||||
- Configuration changes needed
|
||||
|
||||
3. **Understand existing patterns**
|
||||
- Code style and conventions
|
||||
- Error handling approaches
|
||||
- Testing patterns
|
||||
|
||||
4. **Check for schema/migration implications**
|
||||
- Does this flight add or modify database tables?
|
||||
- What migration tooling does the project use?
|
||||
- Are there existing migration patterns to follow?
|
||||
|
||||
### Phase 3: User Input
|
||||
|
||||
Before asking structured technical questions, share a brief summary of what you learned during context gathering and code interrogation, then prompt the user for open-ended input:
|
||||
|
||||
- "Here's what I've gathered about the mission context and codebase: [summary]. Before I ask specific technical questions, what are your thoughts on what this flight should cover? Feel free to share approach preferences, priorities, concerns — anything that should shape this flight."
|
||||
|
||||
Use the user's response to inform and focus the crew interview questions that follow.
|
||||
|
||||
### Phase 4: Crew Interview
|
||||
|
||||
Ask technical questions to resolve the approach:
|
||||
|
||||
1. **Technical approach**
|
||||
- "Should we extend existing code or create new modules?"
|
||||
- "What's the preferred pattern for [specific decision]?"
|
||||
- "Are there performance considerations?"
|
||||
|
||||
2. **Open questions**
|
||||
- Surface ambiguities in requirements
|
||||
- Clarify edge cases
|
||||
- Identify unknowns
|
||||
|
||||
3. **Design decisions**
|
||||
- Document choices and rationale
|
||||
- Get agreement on trade-offs
|
||||
- Note constraints discovered
|
||||
|
||||
4. **Prerequisites verification**
|
||||
- "Is [dependency] ready?"
|
||||
- "Do we have access to [resource]?"
|
||||
|
||||
5. **Validation approach**
|
||||
- "How will this flight be validated?"
|
||||
- "Is test automation needed, or is manual verification sufficient?"
|
||||
- "What tests should be created or updated?"
|
||||
|
||||
### Phase 5: Spec Creation
|
||||
|
||||
Create the flight artifact using the format defined in `.flightops/ARTIFACTS.md`.
|
||||
|
||||
Also create the flight log artifact (empty, ready for execution notes).
|
||||
|
||||
### Phase 5b: Design Review
|
||||
|
||||
Spawn an Architect agent to validate the flight spec against the real codebase before presenting it to the crew.
|
||||
|
||||
Read `{target-project}/.flightops/agent-crews/flight-design.md` for crew definitions and prompts (fall back to defaults at `.claude/skills/init-project/defaults/agent-crews/flight-design.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-design.md` is missing required sections. Either fix it manually or re-run `/init-project` to reset to defaults."
|
||||
|
||||
1. **Spawn an Architect agent** in the target project context (Task tool, `subagent_type: "general-purpose"`)
|
||||
- Provide the "Review Flight Design" prompt from the flight-design phase file's Prompts section
|
||||
- The Architect reads the flight spec and cross-references design decisions, prerequisites, technical approach, and leg breakdown against actual codebase state and architecture best practices
|
||||
- The Architect provides a structured assessment: approve, approve with changes, or needs rework
|
||||
2. **Incorporate feedback** — update the flight artifact to address issues raised
|
||||
- High-severity issues: must fix before proceeding
|
||||
- Medium-severity issues: fix unless there's a clear reason not to
|
||||
- Low-severity issues and suggestions: apply at discretion
|
||||
3. **Re-review if substantive changes were made** — spawn another Architect for a second pass
|
||||
- Skip if only minor/cosmetic fixes were applied
|
||||
- **Max 2 design review cycles** — if issues persist after 2 rounds, escalate to human
|
||||
4. **Proceed to Phase 6** with a codebase-validated spec
|
||||
|
||||
### Phase 6: Iterate
|
||||
|
||||
1. Walk through the spec with the crew
|
||||
2. Validate technical approach is sound
|
||||
3. Confirm leg breakdown is appropriate
|
||||
4. Refine until approved
|
||||
|
||||
## Guidelines
|
||||
|
||||
### Flight Sizing
|
||||
|
||||
A well-sized flight:
|
||||
- Takes 1-3 days of focused work
|
||||
- Breaks into 3-8 legs typically
|
||||
- Has a clear, verifiable objective
|
||||
- Addresses specific mission criteria
|
||||
|
||||
**Too small**: Single leg's worth of work
|
||||
**Too large**: More than a week of work, vague checkpoints
|
||||
|
||||
### Leg Identification
|
||||
|
||||
Break flights into legs based on technical boundaries:
|
||||
- Each leg should be atomic (independently completable)
|
||||
- Legs should have clear inputs and outputs
|
||||
- Consider dependencies between legs
|
||||
- Group related changes together
|
||||
|
||||
**For scaffolding flights**: Include a final `verify-integration` leg
|
||||
|
||||
**For interface changes**: Identify consumers that need updates
|
||||
|
||||
**For documentation**: Consider whether README, CLAUDE.md, or other docs need updates as part of this flight — especially for flights adding new CLI commands, API endpoints, or configuration options
|
||||
|
||||
**For schema changes**: Include explicit migration legs and verify against the live database, not just mocks
|
||||
|
||||
**For UAT and alignment**: During the crew interview, ask the user whether they'd like to include a UAT and alignment leg. Explain that this optional leg is a guided UAT session — the agent walks the user through a series of tests and verification steps, fixing issues along the way until the user is satisfied with the results. If the user opts in, include it in the breakdown, marked as optional.
|
||||
|
||||
### Pre-Flight Rigor
|
||||
|
||||
- Open questions MUST be resolved before execution
|
||||
- Design decisions MUST be documented with rationale
|
||||
- Prerequisites MUST be verified, not assumed
|
||||
- **Environment conflicts**: Flights introducing network services (ports, databases, containers) must check for conflicts with existing services on the developer's machine during planning. Ask: "What else is running that could conflict?"
|
||||
|
||||
### Adaptive Planning
|
||||
|
||||
- Flights can be modified during `planning` state
|
||||
- Once `in-flight`, flights may still be modified (e.g., changing planned legs) as long as the flight log captures the change and rationale
|
||||
- New legs can be added if scope grows
|
||||
|
||||
## Output
|
||||
|
||||
Create the following artifacts using locations and formats from `.flightops/ARTIFACTS.md`:
|
||||
|
||||
1. **Flight spec** — The flight plan
|
||||
2. **Flight log** — Empty, ready for execution notes
|
||||
@@ -0,0 +1,97 @@
|
||||
---
|
||||
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.
|
||||
---
|
||||
|
||||
# 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.md` doesn'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:**
|
||||
1. Copy `projects.md.template` to `projects.md`
|
||||
2. Remove the example entries
|
||||
3. Interview the user to register their first project (see step 3)
|
||||
|
||||
**If updating:**
|
||||
1. Read existing `projects.md`
|
||||
2. Ask: add new project, or update existing?
|
||||
3. 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**
|
||||
1. Ask for the parent directory path (e.g., `~/projects`)
|
||||
2. Scan immediate subdirectories for git repos
|
||||
3. Present the list and ask which ones to register
|
||||
4. Auto-detect details for each selected project
|
||||
5. Ask for descriptions in batch (or let the user provide them later)
|
||||
|
||||
**Option B: Add a single project**
|
||||
1. Ask for the project path (e.g., `~/projects/my-app`)
|
||||
2. Verify it exists and is a git repo
|
||||
3. Auto-detect details
|
||||
4. 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:"
|
||||
> 1. **`/init-project`** — Run this in each project to set up `.flightops/` with methodology references and configure the project crew
|
||||
> 2. **`/mission`** — Define what you want to achieve (outcomes, not tasks)
|
||||
> 3. **`/flight`** — Break a mission into technical specs
|
||||
> 4. **`/leg`** — Generate implementation steps for each flight leg
|
||||
> 5. **`/agentic-workflow`** — Execute legs with automated Developer + Reviewer agents
|
||||
|
||||
> "Start with `/init-project` on the project you just registered."
|
||||
|
||||
### 5. Offer Next Step
|
||||
|
||||
> "Want to run `/init-project` for {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.
|
||||
@@ -0,0 +1,182 @@
|
||||
# Flight Operations Quick Reference
|
||||
|
||||
> For full methodology docs, see [mission-control](https://github.com/msieurthenardier/mission-control)
|
||||
|
||||
## Before You Start
|
||||
|
||||
**Read these files in order:**
|
||||
1. `.flightops/ARTIFACTS.md` — Where and how artifacts are stored (project-specific)
|
||||
2. The **flight log** for your active flight — Ground truth for what happened
|
||||
3. The **leg artifact** you're implementing — Your acceptance criteria
|
||||
|
||||
---
|
||||
|
||||
## Project Crew & Phases
|
||||
|
||||
Each phase of the Flight Control workflow has a crew definition in `.flightops/agent-crews/`:
|
||||
|
||||
| Crew | Purpose |
|
||||
|------|---------|
|
||||
| `mission-design.md` | Crew for `/mission` (e.g., Architect validates viability) |
|
||||
| `flight-design.md` | Crew for `/flight` (e.g., Architect reviews spec) |
|
||||
| `leg-execution.md` | Crew for `/agentic-workflow` (e.g., Developer + Reviewer) |
|
||||
| `flight-debrief.md` | Crew for `/flight-debrief` (e.g., Developer provides perspective) |
|
||||
| `mission-debrief.md` | Crew for `/mission-debrief` (e.g., Architect provides perspective) |
|
||||
|
||||
Crew files define: roles, models, interaction protocols, prompts, and signals. Customize these to change your project's agent configuration.
|
||||
|
||||
---
|
||||
|
||||
## Multi-Agent Workflow
|
||||
|
||||
Legs must be implemented by a **separate Developer instance** and reviewed by a **separate Reviewer instance** (or whatever crew is defined in `leg-execution.md`). Mission Control designs legs and orchestrates — it does NOT implement code directly.
|
||||
|
||||
The Reviewer has no knowledge of the Developer's reasoning — only the resulting changes. This separation provides objective code review. Use the `/agentic-workflow` skill in mission-control to drive this cycle.
|
||||
|
||||
---
|
||||
|
||||
## ⚠️ Leg Completion Checklist (MANDATORY)
|
||||
|
||||
**You MUST complete ALL of these before emitting `[COMPLETE:leg]`:**
|
||||
|
||||
| Step | Action |
|
||||
|------|--------|
|
||||
| 1 | All acceptance criteria verified |
|
||||
| 2 | Tests passing |
|
||||
| 3 | **Update flight log** — Add leg progress entry (see below) |
|
||||
| 4 | **Mark leg completed** — Update leg status to `completed` |
|
||||
| 5 | **Update flight** — Check off the leg in flight artifact |
|
||||
| 6 | **Commit/save with all artifact updates** |
|
||||
|
||||
**Flight log entry MUST include:**
|
||||
- Leg status, started date, completed date
|
||||
- Changes Made (what was implemented)
|
||||
- Verification (how acceptance criteria were confirmed)
|
||||
- Any decisions, deviations, or anomalies
|
||||
|
||||
Refer to `.flightops/ARTIFACTS.md` for exact locations and formats.
|
||||
|
||||
---
|
||||
|
||||
## Workflow Signals
|
||||
|
||||
Emit at the end of your response, on its own line:
|
||||
|
||||
| Signal | When |
|
||||
|--------|------|
|
||||
| `[HANDOFF:review-needed]` | Artifact changes ready for validation |
|
||||
| `[HANDOFF:confirmed]` | Review complete, no issues |
|
||||
| `[BLOCKED:reason]` | Cannot proceed |
|
||||
| `[COMPLETE:leg]` | Leg done AND checklist complete |
|
||||
|
||||
---
|
||||
|
||||
## Implementing a Leg
|
||||
|
||||
### Pre-Implementation
|
||||
1. Read mission, flight, and leg artifacts
|
||||
2. Read flight log for context from prior legs
|
||||
3. Verify leg accuracy against existing code
|
||||
4. **Update leg status** to `in-flight`
|
||||
5. Present summary and get approval before proceeding
|
||||
|
||||
### Implementation
|
||||
5. Implement to acceptance criteria
|
||||
6. Run tests with a timeout — use the test runner's timeout flag (e.g., `--timeout`,
|
||||
`--test-timeout`, `-timeout`) so hanging tests fail fast instead of stalling.
|
||||
If a test hangs, kill it, isolate the hanging test, and fix the root cause before
|
||||
continuing. Log hanging tests and their resolution in the flight log.
|
||||
7. Run code review, fix Critical/Major issues
|
||||
8. Re-review until clean
|
||||
|
||||
### Post-Implementation
|
||||
9. Propagate changes (project docs, flight artifacts if scope changed)
|
||||
10. **Complete the Leg Completion Checklist above**
|
||||
11. Signal `[COMPLETE:leg]`
|
||||
|
||||
---
|
||||
|
||||
## Just-in-Time Planning
|
||||
|
||||
Flights and legs are created one at a time, not upfront.
|
||||
|
||||
| Reviewing... | Should exist | Should NOT exist yet |
|
||||
|--------------|--------------|----------------------|
|
||||
| Mission | Mission artifact | Flight artifacts (only listed) |
|
||||
| Flight | Flight artifact | Leg artifacts (only listed) |
|
||||
| Leg | Leg artifact | Ready to implement |
|
||||
|
||||
Listed flights/legs are **tentative suggestions** that evolve based on discoveries.
|
||||
|
||||
---
|
||||
|
||||
## Reviewing Artifacts
|
||||
|
||||
When reviewing a mission, flight, or leg:
|
||||
|
||||
1. Read the artifact thoroughly
|
||||
2. Validate against project goals and existing code
|
||||
3. Check for ambiguities or missing details
|
||||
4. Make changes directly if needed
|
||||
5. Describe any changes made
|
||||
6. Signal `[HANDOFF:confirmed]` if no issues, or describe changes for validation
|
||||
|
||||
---
|
||||
|
||||
## Code Review Gate
|
||||
|
||||
```
|
||||
Implement → Test → Review → Fix → Re-review → Complete
|
||||
```
|
||||
|
||||
| Severity | Action |
|
||||
|----------|--------|
|
||||
| Critical | Must fix |
|
||||
| Major | Must fix |
|
||||
| Minor | Fix if safe, else defer |
|
||||
|
||||
Deferred issues go in the flight log.
|
||||
|
||||
---
|
||||
|
||||
## ⚠️ Flight Completion Checklist (MANDATORY)
|
||||
|
||||
**When you complete the FINAL leg of a flight, also complete these steps:**
|
||||
|
||||
| Step | Action |
|
||||
|------|--------|
|
||||
| 1 | Complete all items in the Leg Completion Checklist above |
|
||||
| 2 | **Update flight log** — Add flight completion entry with summary |
|
||||
| 3 | **Update flight status** — Set `**Status**: landed` in flight.md |
|
||||
| 4 | **Update mission** — Check off this flight in mission.md |
|
||||
| 5 | **Verify all legs** — Confirm all legs show `completed` status |
|
||||
| 6 | **Update project docs** — Ensure CLAUDE.md, README, and other docs reflect any new commands, endpoints, configuration, or APIs introduced during the flight |
|
||||
| 7 | Signal `[COMPLETE:leg]` (the orchestrator will trigger Phase 4) |
|
||||
|
||||
The orchestrator will then:
|
||||
- Mark the PR ready for human review
|
||||
|
||||
The flight debrief is a separate step run via `/flight-debrief`, which transitions the flight from `landed` to `completed`.
|
||||
|
||||
---
|
||||
|
||||
## Database Schema Changes
|
||||
|
||||
When a flight modifies database schemas:
|
||||
|
||||
1. **Include migration steps in the leg** — schema changes need explicit CREATE/ALTER statements or migration commands
|
||||
2. **Verify migrations run** — acceptance criteria must include confirming the migration executed successfully against the live database
|
||||
3. **Update SCHEMA docs** — if the project maintains a SCHEMA reference, update it in the same leg that creates the migration
|
||||
4. **Test against real DB** — unit tests with mocks are not sufficient for schema changes; verify against the actual database
|
||||
|
||||
A table defined in SCHEMA but never created via migration is a gap — treat schema documentation and migration execution as a single atomic operation.
|
||||
|
||||
---
|
||||
|
||||
## Key Principles
|
||||
|
||||
1. **Flight log is ground truth** — Read it first, update it always
|
||||
2. **Never modify in-flight legs** — Create new ones instead
|
||||
3. **Binary acceptance criteria** — Met or not met
|
||||
4. **Log everything** — Decisions, deviations, anomalies
|
||||
5. **Signal clearly** — End of response, own line
|
||||
@@ -0,0 +1,29 @@
|
||||
# Flight Operations
|
||||
|
||||
This directory contains reference materials for the [Flight Control](https://github.com/anthropics/flight-control) development methodology.
|
||||
|
||||
## Contents
|
||||
|
||||
- **FLIGHT_OPERATIONS.md** — Quick reference for implementing missions, flights, and legs
|
||||
- **ARTIFACTS.md** — Project-specific configuration for how artifacts are stored
|
||||
- **agent-crews/** — Project crew definitions for each phase (who Mission Control works with)
|
||||
|
||||
## For AI Agents
|
||||
|
||||
When working on this project with Flight Control:
|
||||
|
||||
1. Read `ARTIFACTS.md` to understand how this project stores missions, flights, and legs
|
||||
2. Read `FLIGHT_OPERATIONS.md` for the implementation workflow
|
||||
3. Read the relevant `agent-crews/*.md` file for crew definitions and prompts
|
||||
4. Check the artifact locations defined in `ARTIFACTS.md` for active work
|
||||
5. Follow the code review gate before marking any leg complete
|
||||
6. Update flight-log after each leg (location depends on artifact system)
|
||||
|
||||
## Sync Behavior
|
||||
|
||||
| File | Synced? | Notes |
|
||||
|------|---------|-------|
|
||||
| README.md | Yes | Updated via `/init-project` |
|
||||
| FLIGHT_OPERATIONS.md | Yes | Updated via `/init-project` |
|
||||
| ARTIFACTS.md | No | Project-specific, customize freely |
|
||||
| agent-crews/*.md | No | Project-specific, customize freely |
|
||||
215
container/mission-control/.claude/skills/init-project/SKILL.md
Normal file
215
container/mission-control/.claude/skills/init-project/SKILL.md
Normal file
@@ -0,0 +1,215 @@
|
||||
---
|
||||
name: init-project
|
||||
description: 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.
|
||||
---
|
||||
|
||||
# Project Initialization
|
||||
|
||||
Prepare a project for Flight Control by creating the `.flightops/` directory with methodology references and artifact configuration.
|
||||
|
||||
## When to Use
|
||||
|
||||
Run `/init-project` when:
|
||||
- Starting to use Flight Control on a new project
|
||||
- You suspect the .flightops reference may be outdated
|
||||
- Another skill indicates the reference needs to be synced
|
||||
|
||||
## Workflow
|
||||
|
||||
### 1. Identify Target Project
|
||||
|
||||
1. **Read `projects.md`** to find the project's path, remote, and description
|
||||
2. If the project isn't listed, ask the user for:
|
||||
- Project name/slug
|
||||
- Filesystem path
|
||||
- Brief description
|
||||
3. Optionally offer to add the project to `projects.md`
|
||||
|
||||
### 2. Check and Apply Migrations
|
||||
|
||||
Check for legacy directory layouts and offer to migrate them.
|
||||
|
||||
1. **Read `migrations.md`** from the skill directory (`${SKILL_DIR}/migrations.md`)
|
||||
2. **Run detection checks** for each migration in order (001, 002, ...)
|
||||
3. **If no migrations are needed**, proceed silently to the next step
|
||||
4. **If any migrations are needed**, present a summary to the user:
|
||||
> "Detected legacy directory layout in {project}. The following migrations are available:"
|
||||
>
|
||||
> - _Each applicable migration's user message_
|
||||
>
|
||||
> "Apply these migrations?"
|
||||
5. **On confirmation**, apply the actions for each applicable migration in order
|
||||
6. **On decline**, warn the user that some skills may not work correctly with the old layout, but continue using whatever directory structure exists
|
||||
|
||||
### 3. Check Sync Status
|
||||
|
||||
Run the hash comparison script to determine sync status:
|
||||
|
||||
```bash
|
||||
bash "${SKILL_DIR}/check-sync.sh" \
|
||||
"${SKILL_DIR}" \
|
||||
"{target-project}/.flightops"
|
||||
```
|
||||
|
||||
The script outputs one of:
|
||||
- `missing` - Directory doesn't exist in target project
|
||||
- `outdated` - Directory exists but files differ from source
|
||||
- `current` - All files are up-to-date
|
||||
|
||||
### 4. Prompt and Sync Methodology Files
|
||||
|
||||
Based on the status:
|
||||
|
||||
**If `missing`**:
|
||||
> "Flight operations directory not found. Create `{project}/.flightops/` with methodology references?"
|
||||
|
||||
**If `outdated`**:
|
||||
> "Flight operations references in {project} are outdated. Update?"
|
||||
|
||||
**If `current`**:
|
||||
> "Flight operations references are up-to-date in {project}."
|
||||
|
||||
If the user confirms, create/update the directory:
|
||||
|
||||
```bash
|
||||
mkdir -p "{target-project}/.flightops"
|
||||
cp "${SKILL_DIR}/FLIGHT_OPERATIONS.md" "{target-project}/.flightops/"
|
||||
cp "${SKILL_DIR}/README.md" "{target-project}/.flightops/"
|
||||
```
|
||||
|
||||
### 5. Configure Artifact System (New Projects Only)
|
||||
|
||||
**Only if ARTIFACTS.md doesn't exist**, ask the user to select an artifact system:
|
||||
|
||||
> "How should mission, flight, and leg artifacts be stored?"
|
||||
|
||||
Available templates:
|
||||
- **files** — Markdown files in the repository (`templates/ARTIFACTS-files.md`)
|
||||
- **jira** — Jira issues: Epics, Stories, Sub-tasks (`templates/ARTIFACTS-jira.md`)
|
||||
|
||||
#### 5a. Check for Setup Questions
|
||||
|
||||
After the user selects a template, read the template file and check if it contains a `## Setup Questions` section with a table of questions.
|
||||
|
||||
If setup questions exist:
|
||||
1. Parse the questions from the table (first column contains the questions)
|
||||
2. Ask the user each question interactively
|
||||
3. Replace the placeholder answers in the table with the user's responses
|
||||
|
||||
#### 5b. Copy and Populate Template
|
||||
|
||||
Copy the selected template, with answers populated if setup questions were asked:
|
||||
|
||||
```bash
|
||||
cp "${SKILL_DIR}/templates/ARTIFACTS-{selection}.md" \
|
||||
"{target-project}/.flightops/ARTIFACTS.md"
|
||||
```
|
||||
|
||||
If setup questions were answered, update the ARTIFACTS.md file to replace the placeholder answers with the user's responses.
|
||||
|
||||
**If ARTIFACTS.md already exists**, do not modify it — it's project-specific and may have been customized.
|
||||
|
||||
### 6. Configure Project Crew
|
||||
|
||||
Set up phase-specific crew definitions that control how Mission Control interacts with project-side agents.
|
||||
|
||||
1. **Check if `.flightops/agent-crews/` exists**
|
||||
|
||||
**If missing** (first run):
|
||||
- Copy all defaults from `${SKILL_DIR}/defaults/agent-crews/` to `{target-project}/.flightops/agent-crews/`
|
||||
- Brief the user:
|
||||
> "Default crew has been set up for all phases. Your agent crews define who Mission Control (Flight Director) works with during each phase — which agents exist, their roles, models, and prompts."
|
||||
- Ask about customization:
|
||||
> "Want to customize any agent crew? (Most projects work fine with defaults)"
|
||||
- If yes: ask which crew → show current definitions → walk through changes (add/remove/modify roles, adjust prompts, change interaction protocol)
|
||||
- If no: proceed with defaults
|
||||
|
||||
**If exists** (re-run):
|
||||
- Copy any missing crew files from defaults (new crews added to the methodology)
|
||||
- Ask the user:
|
||||
> "Agent crew files already exist. Default crew definitions may have been updated since your project was initialized. Want to review and update any crew files to the latest defaults?"
|
||||
- If yes: for each file, show what changed between their version and the current default, ask whether to overwrite or keep their version
|
||||
- If no: leave all existing files untouched
|
||||
|
||||
### 7. Update CLAUDE.md
|
||||
|
||||
Check if the project's `CLAUDE.md` file references the flight operations directory:
|
||||
|
||||
1. **If CLAUDE.md doesn't exist**, create it with a Flight Operations section
|
||||
2. **If CLAUDE.md exists but lacks a Flight Operations section**, append one
|
||||
3. **If CLAUDE.md already has a Flight Operations section**, leave it unchanged
|
||||
|
||||
#### 7a. Fix Stale Path References
|
||||
|
||||
If migrations were applied in Step 2, scan the project's `CLAUDE.md` for stale path references within the Flight Operations section and fix them:
|
||||
|
||||
- Replace `.flight-ops/` → `.flightops/`
|
||||
- Replace `phases/` → `agent-crews/` (only within Flight Operations context)
|
||||
|
||||
This ensures the CLAUDE.md instructions point to the correct post-migration paths.
|
||||
|
||||
Add this section:
|
||||
|
||||
```markdown
|
||||
## Flight Operations
|
||||
|
||||
This project uses [Flight Control](https://github.com/msieurthenardier/mission-control).
|
||||
|
||||
**Before any mission/flight/leg work, read these files in order:**
|
||||
1. `.flightops/README.md` — What the flightops directory contains
|
||||
2. `.flightops/FLIGHT_OPERATIONS.md` — **The workflow you MUST follow**
|
||||
3. `.flightops/ARTIFACTS.md` — Where all artifacts are stored
|
||||
4. `.flightops/agent-crews/` — Project crew definitions for each phase (read the relevant crew file)
|
||||
```
|
||||
|
||||
### 8. Post-Sync Instructions
|
||||
|
||||
After creating or updating the directory, inform the user:
|
||||
|
||||
> "If you have Claude Code running in {project}, restart it to pick up the new flight operations references."
|
||||
|
||||
This ensures Claude Code loads the new files into its context when working in the target project.
|
||||
|
||||
## Output
|
||||
|
||||
This skill creates/updates the following at project root:
|
||||
|
||||
```
|
||||
{project}/
|
||||
├── CLAUDE.md # Updated with Flight Operations section
|
||||
└── .flightops/ # Hidden directory for Flight Control
|
||||
├── README.md # Explains the directory purpose
|
||||
├── FLIGHT_OPERATIONS.md # Quick reference for implementation (synced)
|
||||
├── ARTIFACTS.md # Artifact system configuration (project-specific)
|
||||
└── agent-crews/ # Project crew definitions (project-specific)
|
||||
├── mission-design.md
|
||||
├── flight-design.md
|
||||
├── leg-execution.md
|
||||
├── flight-debrief.md
|
||||
├── mission-debrief.md
|
||||
└── routine-maintenance.md
|
||||
```
|
||||
|
||||
## File Sync Behavior
|
||||
|
||||
| File | Synced on update? | Notes |
|
||||
|------|-------------------|-------|
|
||||
| CLAUDE.md | Append only | Adds Flight Operations section if missing |
|
||||
| README.md | Yes | Methodology reference |
|
||||
| FLIGHT_OPERATIONS.md | Yes | Methodology reference |
|
||||
| ARTIFACTS.md | No | Created once from template, then project-specific |
|
||||
| agent-crews/*.md | Ask on re-run | Created from defaults; on re-run, user can choose to update to latest defaults |
|
||||
|
||||
## Guidelines
|
||||
|
||||
### Don't Over-Prompt
|
||||
|
||||
If everything is `current`, just inform the user briefly and move on. No confirmation needed.
|
||||
|
||||
### Respect ARTIFACTS.md
|
||||
|
||||
Never overwrite ARTIFACTS.md — it may contain project-specific customizations. Only create it if missing.
|
||||
|
||||
### Keep It Quick
|
||||
|
||||
This is a setup step, not the main work. Complete it efficiently so the user can proceed to their actual task.
|
||||
119
container/mission-control/.claude/skills/init-project/check-sync.sh
Executable file
119
container/mission-control/.claude/skills/init-project/check-sync.sh
Executable file
@@ -0,0 +1,119 @@
|
||||
#!/bin/bash
|
||||
# check-sync.sh - Compare .flightops directory between source and target
|
||||
#
|
||||
# Usage: check-sync.sh <source-dir> <target-dir>
|
||||
#
|
||||
# Outputs:
|
||||
# missing - Target directory doesn't exist (neither .flightops/ nor .flight-ops/)
|
||||
# outdated - Target exists but one or more files differ from source
|
||||
# current - All files match source
|
||||
#
|
||||
# Additional output lines:
|
||||
# agent-crews:{missing|empty|present} - Crew directory status
|
||||
# crew-missing:{filename} - Default crew file not found in project (repeats per file)
|
||||
# legacy-layout:flight-ops - .flight-ops/ detected (old name)
|
||||
# legacy-layout:phases - phases/ detected (old name)
|
||||
#
|
||||
# Note: Only checks synced files (README.md, FLIGHT_OPERATIONS.md).
|
||||
# ARTIFACTS.md and agent-crews/ are project-specific and not synced.
|
||||
|
||||
set -e
|
||||
|
||||
SOURCE_DIR="$1"
|
||||
TARGET_DIR="$2"
|
||||
|
||||
if [[ -z "$SOURCE_DIR" || -z "$TARGET_DIR" ]]; then
|
||||
echo "Usage: check-sync.sh <source-dir> <target-dir>" >&2
|
||||
exit 1
|
||||
fi
|
||||
|
||||
if [[ ! -d "$SOURCE_DIR" ]]; then
|
||||
echo "Error: Source directory not found: $SOURCE_DIR" >&2
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# Resolve the actual target directory, falling back to legacy name
|
||||
EFFECTIVE_TARGET="$TARGET_DIR"
|
||||
LEGACY_FLIGHT_OPS=false
|
||||
|
||||
if [[ ! -d "$TARGET_DIR" ]]; then
|
||||
# Derive the legacy path: replace trailing .flightops with .flight-ops
|
||||
LEGACY_DIR="${TARGET_DIR%/.flightops}/.flight-ops"
|
||||
if [[ "$LEGACY_DIR" != "$TARGET_DIR" && -d "$LEGACY_DIR" ]]; then
|
||||
EFFECTIVE_TARGET="$LEGACY_DIR"
|
||||
LEGACY_FLIGHT_OPS=true
|
||||
else
|
||||
echo "missing"
|
||||
exit 0
|
||||
fi
|
||||
fi
|
||||
|
||||
# Compare each file in source directory
|
||||
FILES_TO_CHECK=("FLIGHT_OPERATIONS.md" "README.md")
|
||||
ALL_CURRENT=true
|
||||
|
||||
for FILE in "${FILES_TO_CHECK[@]}"; do
|
||||
SOURCE_FILE="$SOURCE_DIR/$FILE"
|
||||
TARGET_FILE="$EFFECTIVE_TARGET/$FILE"
|
||||
|
||||
if [[ ! -f "$SOURCE_FILE" ]]; then
|
||||
continue
|
||||
fi
|
||||
|
||||
if [[ ! -f "$TARGET_FILE" ]]; then
|
||||
ALL_CURRENT=false
|
||||
break
|
||||
fi
|
||||
|
||||
SOURCE_HASH=$(sha256sum "$SOURCE_FILE" | cut -d' ' -f1)
|
||||
TARGET_HASH=$(sha256sum "$TARGET_FILE" | cut -d' ' -f1)
|
||||
|
||||
if [[ "$SOURCE_HASH" != "$TARGET_HASH" ]]; then
|
||||
ALL_CURRENT=false
|
||||
break
|
||||
fi
|
||||
done
|
||||
|
||||
if $ALL_CURRENT; then
|
||||
echo "current"
|
||||
else
|
||||
echo "outdated"
|
||||
fi
|
||||
|
||||
# Report on agent-crews directory existence, checking both current and legacy names
|
||||
CREW_DIR=""
|
||||
LEGACY_PHASES=false
|
||||
|
||||
if [[ -d "$EFFECTIVE_TARGET/agent-crews" ]]; then
|
||||
CREW_DIR="$EFFECTIVE_TARGET/agent-crews"
|
||||
elif [[ -d "$EFFECTIVE_TARGET/phases" ]]; then
|
||||
CREW_DIR="$EFFECTIVE_TARGET/phases"
|
||||
LEGACY_PHASES=true
|
||||
fi
|
||||
|
||||
if [[ -z "$CREW_DIR" ]]; then
|
||||
echo "agent-crews:missing"
|
||||
elif [[ -z "$(ls -A "$CREW_DIR" 2>/dev/null)" ]]; then
|
||||
echo "agent-crews:empty"
|
||||
else
|
||||
echo "agent-crews:present"
|
||||
# Check for missing crew files (new skills added since init)
|
||||
DEFAULT_CREWS_DIR="$SOURCE_DIR/defaults/agent-crews"
|
||||
if [[ -d "$DEFAULT_CREWS_DIR" ]]; then
|
||||
for DEFAULT_FILE in "$DEFAULT_CREWS_DIR"/*.md; do
|
||||
BASENAME=$(basename "$DEFAULT_FILE")
|
||||
if [[ ! -f "$CREW_DIR/$BASENAME" ]]; then
|
||||
echo "crew-missing:$BASENAME"
|
||||
fi
|
||||
done
|
||||
fi
|
||||
fi
|
||||
|
||||
# Report legacy layout detection
|
||||
if $LEGACY_FLIGHT_OPS; then
|
||||
echo "legacy-layout:flight-ops"
|
||||
fi
|
||||
|
||||
if $LEGACY_PHASES; then
|
||||
echo "legacy-layout:phases"
|
||||
fi
|
||||
@@ -0,0 +1,126 @@
|
||||
# Flight Debrief — Project Crew
|
||||
|
||||
Crew definitions for post-flight analysis. The Flight Director interviews the
|
||||
human and project-side agents to capture both execution and design perspectives.
|
||||
|
||||
## Crew
|
||||
|
||||
### Developer
|
||||
- **Context**: {project}/
|
||||
- **Model**: Sonnet
|
||||
- **Role**: Provides developer perspective on flight execution. Reviews what was
|
||||
built, identifies technical debt introduced, evaluates implementation quality,
|
||||
and surfaces issues that flight logs may not capture.
|
||||
- **Actions**: debrief-interview
|
||||
|
||||
### Architect
|
||||
- **Context**: {project}/
|
||||
- **Model**: Sonnet
|
||||
- **Role**: Closes the design feedback loop. Evaluates whether the design decisions
|
||||
made during flight planning held up in practice. Reviews architectural impact of
|
||||
what was built and whether the approach should be adjusted for future flights.
|
||||
- **Actions**: debrief-design-review
|
||||
|
||||
## Interaction Protocol
|
||||
|
||||
### Developer Interview
|
||||
1. Flight Director loads flight context (mission, flight, legs, log, actual code)
|
||||
2. Flight Director spawns **Developer** to review implementation and provide feedback
|
||||
3. Developer examines code changes, test coverage, patterns used, debt introduced
|
||||
4. Developer provides structured debrief input
|
||||
|
||||
### Architect Interview
|
||||
1. Flight Director spawns **Architect** to review whether design decisions held up
|
||||
2. Architect compares flight-design spec against actual implementation
|
||||
3. Architect evaluates architectural impact and provides feedback for future flights
|
||||
|
||||
### Human Interview
|
||||
1. Flight Director interviews human with targeted questions based on flight log
|
||||
2. Keep lightweight — 2-3 questions max
|
||||
|
||||
### Synthesis
|
||||
1. Flight Director synthesizes Developer input + Architect input + human input + document analysis
|
||||
2. Generates debrief artifact
|
||||
|
||||
## Template Variables
|
||||
|
||||
The Flight Director substitutes these variables in prompts at runtime:
|
||||
|
||||
| Variable | Description |
|
||||
|----------|-------------|
|
||||
| `{project-slug}` | Project identifier from projects.md |
|
||||
| `{flight-number}` | Current flight number |
|
||||
| `{flight-artifact-path}` | Path to the flight artifact file |
|
||||
|
||||
## Prompts
|
||||
|
||||
### Developer: Debrief Interview
|
||||
|
||||
```
|
||||
role: developer
|
||||
phase: flight-debrief
|
||||
project: {project-slug}
|
||||
flight: {flight-number}
|
||||
action: debrief-interview
|
||||
|
||||
Review the implementation produced during this flight. Examine the code changes,
|
||||
test coverage, and architectural decisions made.
|
||||
|
||||
Provide structured input for the debrief:
|
||||
|
||||
**Implementation Quality**:
|
||||
- Does the code follow project conventions?
|
||||
- Are there patterns that should be documented?
|
||||
- What technical debt was introduced?
|
||||
|
||||
**Leg Spec Accuracy**:
|
||||
- Were leg specs clear and sufficient for implementation?
|
||||
- What was missing or misleading?
|
||||
- Were acceptance criteria verifiable?
|
||||
|
||||
**Testing Assessment**:
|
||||
- Is test coverage adequate?
|
||||
- Are there untested edge cases?
|
||||
- Do tests meaningfully validate behavior?
|
||||
|
||||
**Recommendations**:
|
||||
- What should future flights in this area account for?
|
||||
- Are there refactoring opportunities?
|
||||
- What documentation is missing?
|
||||
```
|
||||
|
||||
### Architect: Debrief Design Review
|
||||
|
||||
```
|
||||
role: architect
|
||||
phase: flight-debrief
|
||||
project: {project-slug}
|
||||
flight: {flight-number}
|
||||
action: debrief-design-review
|
||||
|
||||
Read the flight artifact at {flight-artifact-path}. Compare the design decisions,
|
||||
technical approach, and leg breakdown that were planned against what was actually
|
||||
implemented.
|
||||
|
||||
Provide structured input for the debrief:
|
||||
|
||||
**Design Decisions Assessment**:
|
||||
- Which design decisions held up well in practice?
|
||||
- Which decisions had to be revised during implementation? Why?
|
||||
- Were there decisions that should have been made differently?
|
||||
|
||||
**Architectural Impact**:
|
||||
- Did the implementation maintain or improve the system's architecture?
|
||||
- Were there unplanned structural changes? Are they sound?
|
||||
- Did the approach create any architectural debt?
|
||||
|
||||
**Flight Design Accuracy**:
|
||||
- Was the technical approach feasible as specified?
|
||||
- Were prerequisites correctly identified?
|
||||
- Was the leg breakdown appropriate for the actual work?
|
||||
|
||||
**Forward-Looking**:
|
||||
- What should future flight designs in this area account for?
|
||||
- Are there architectural patterns that emerged worth standardizing?
|
||||
- What design assumptions should be revisited?
|
||||
```
|
||||
@@ -0,0 +1,72 @@
|
||||
# Flight Design — Project Crew
|
||||
|
||||
Crew definitions for flight specification. The Flight Director designs the
|
||||
technical spec and uses project-side agents to validate against the real codebase.
|
||||
|
||||
## Crew
|
||||
|
||||
### Architect
|
||||
- **Context**: {project}/
|
||||
- **Model**: Sonnet
|
||||
- **Role**: Reviews flight specs for technical soundness. Validates design
|
||||
decisions, prerequisites, technical approach, and leg breakdown against
|
||||
architecture best practices and actual codebase state. Ensures the flight
|
||||
is buildable and well-structured.
|
||||
- **Actions**: review-flight-design
|
||||
|
||||
## Interaction Protocol
|
||||
|
||||
### Design Review
|
||||
1. Flight Director creates flight spec and interviews human
|
||||
2. Flight Director spawns **Architect** to review against codebase
|
||||
3. Architect evaluates design decisions, prerequisites, approach, leg breakdown
|
||||
4. Flight Director incorporates feedback
|
||||
5. Max 2 review cycles — escalate to human if unresolved
|
||||
|
||||
## Template Variables
|
||||
|
||||
The Flight Director substitutes these variables in prompts at runtime:
|
||||
|
||||
| Variable | Description |
|
||||
|----------|-------------|
|
||||
| `{project-slug}` | Project identifier from projects.md |
|
||||
| `{flight-number}` | Current flight number |
|
||||
| `{flight-artifact-path}` | Path to the flight artifact file |
|
||||
|
||||
## Prompts
|
||||
|
||||
### Architect: Review Flight Design
|
||||
|
||||
```
|
||||
role: architect
|
||||
phase: flight-design-review
|
||||
project: {project-slug}
|
||||
flight: {flight-number}
|
||||
action: review-flight-design
|
||||
|
||||
Read the flight artifact at {flight-artifact-path}. Cross-reference its design
|
||||
decisions, prerequisites, technical approach, and leg breakdown against the actual
|
||||
codebase state and architecture best practices.
|
||||
|
||||
Evaluate:
|
||||
1. Design decisions — are they sound given the real codebase and architecture?
|
||||
2. Prerequisites — are they accurate? Is anything missing or already done?
|
||||
3. Technical approach — is it feasible? Does it follow existing patterns?
|
||||
4. Leg breakdown — are legs well-scoped, properly ordered, with correct dependencies?
|
||||
5. Codebase state — does the spec account for current working tree, existing tooling,
|
||||
and conventions that might affect implementation?
|
||||
6. Architecture — does the approach maintain or improve system structure?
|
||||
|
||||
Provide structured output:
|
||||
|
||||
**Overall assessment**: approve | approve with changes | needs rework
|
||||
|
||||
**Issues** (ranked by severity):
|
||||
- [high/medium/low] Description — recommended fix
|
||||
|
||||
**Suggestions** (non-blocking improvements):
|
||||
- Description
|
||||
|
||||
**Questions** (for the designer to clarify):
|
||||
- Question
|
||||
```
|
||||
@@ -0,0 +1,216 @@
|
||||
# Leg Execution — Project Crew
|
||||
|
||||
Crew definitions and interaction protocol for implementing flight legs.
|
||||
The Flight Director (Mission Control) orchestrates this phase using the
|
||||
/agentic-workflow skill.
|
||||
|
||||
## Crew
|
||||
|
||||
### Developer
|
||||
- **Context**: {working-directory}/
|
||||
- **Model**: Sonnet
|
||||
- **Role**: Implements code changes. Also performs design reviews against real
|
||||
codebase to validate leg specs before implementation.
|
||||
- **Actions**: implement, fix-review-issues, commit, review-leg-design
|
||||
|
||||
### Reviewer
|
||||
- **Context**: {working-directory}/
|
||||
- **Model**: Sonnet (NEVER Opus)
|
||||
- **Role**: Reviews code changes for quality, correctness, and criteria compliance.
|
||||
Has NO knowledge of Developer's reasoning — only sees resulting changes.
|
||||
- **Actions**: review
|
||||
|
||||
### Accessibility Reviewer (optional)
|
||||
- **Context**: {working-directory}/
|
||||
- **Model**: Sonnet
|
||||
- **Enabled**: false
|
||||
- **Role**: Reviews UI changes for accessibility compliance. Evaluates against
|
||||
WCAG 2.1 AA standards, screen reader compatibility, keyboard navigation,
|
||||
color contrast, ARIA usage, and semantic HTML. Only spawn when the leg
|
||||
involves user-facing interface changes.
|
||||
- **Actions**: review-accessibility
|
||||
|
||||
## Separation Rules
|
||||
|
||||
- Developer and Reviewer load the target project's CLAUDE.md and conventions
|
||||
- Reviewer has NO knowledge of Developer's reasoning — only resulting changes
|
||||
- Each agent instance gets fresh context (no carryover between legs)
|
||||
|
||||
**Note:** Handoff signals (`[HANDOFF:review-needed]`, `[HANDOFF:confirmed]`, `[BLOCKED:reason]`, `[COMPLETE:leg]`) are defined by the Flight Control methodology in the agentic-workflow skill, not in this file. Do not modify signal names here — they must match what the Flight Director expects.
|
||||
|
||||
## Interaction Protocol
|
||||
|
||||
### Design Review
|
||||
1. Flight Director spawns **Developer** for design review
|
||||
2. Developer reviews leg against codebase, provides structured assessment
|
||||
3. Flight Director incorporates feedback
|
||||
4. Max 2 review cycles — escalate to human if unresolved
|
||||
|
||||
### Implementation
|
||||
1. Flight Director spawns **Developer** to implement
|
||||
2. Developer implements to acceptance criteria, updates flight log
|
||||
3. Developer signals [HANDOFF:review-needed] — does NOT commit
|
||||
|
||||
### Code Review
|
||||
1. Flight Director spawns **Reviewer** to evaluate all uncommitted changes
|
||||
2. If **Accessibility Reviewer** is enabled and leg involves UI changes,
|
||||
spawn in parallel with Reviewer
|
||||
3. If issues: Flight Director spawns new **Developer** to fix
|
||||
4. Loop until all reviewers signal [HANDOFF:confirmed] — max 3 cycles
|
||||
|
||||
### Commit
|
||||
1. Flight Director spawns **Developer** to commit
|
||||
2. Developer commits code + artifacts, signals [COMPLETE:leg]
|
||||
|
||||
## Template Variables
|
||||
|
||||
The Flight Director substitutes these variables in prompts at runtime:
|
||||
|
||||
| Variable | Description | Available In |
|
||||
|----------|-------------|-------------|
|
||||
| `{project-slug}` | Project identifier from projects.md | All prompts |
|
||||
| `{flight-number}` | Current flight number | All prompts |
|
||||
| `{leg-number}` | Current leg number | Leg-scoped prompts |
|
||||
| `{leg-artifact-path}` | Path to the leg artifact file | review-leg-design |
|
||||
| `{working-directory}` | Resolved working directory for the agent (project root for branch strategy, worktree path for worktree strategy) | All prompts |
|
||||
| `{reviewer-issues}` | Full text of reviewer feedback (dynamic) | fix-review-issues |
|
||||
|
||||
## Prompts
|
||||
|
||||
### Developer: Review Leg Design
|
||||
|
||||
```
|
||||
role: developer
|
||||
phase: leg-design-review
|
||||
project: {project-slug}
|
||||
flight: {flight-number}
|
||||
leg: {leg-number}
|
||||
action: review-leg-design
|
||||
|
||||
Read the leg artifact at {leg-artifact-path}. Cross-reference its acceptance
|
||||
criteria, implementation guidance, and file references against the actual codebase.
|
||||
|
||||
Evaluate:
|
||||
1. Acceptance criteria — specific, verifiable, complete?
|
||||
2. Implementation guidance — complete and correctly ordered?
|
||||
3. Edge cases — missing scenarios?
|
||||
4. Codebase state — account for working tree, existing tooling, uncommitted changes?
|
||||
5. File/line references — accurate against current codebase?
|
||||
6. Dependencies — prerequisite legs completed? Outputs available?
|
||||
|
||||
Provide structured output:
|
||||
|
||||
**Overall assessment**: approve | approve with changes | needs rework
|
||||
|
||||
**Issues** (ranked by severity):
|
||||
- [high/medium/low] Description — recommended fix
|
||||
|
||||
**Suggestions** (non-blocking):
|
||||
- Description
|
||||
|
||||
**Questions** (for the designer):
|
||||
- Question
|
||||
```
|
||||
|
||||
### Developer: Implement
|
||||
|
||||
```
|
||||
role: developer
|
||||
phase: leg-implementation
|
||||
project: {project-slug}
|
||||
flight: {flight-number}
|
||||
leg: {leg-number}
|
||||
action: implement
|
||||
|
||||
Read leg artifact. Update leg status to in-flight. Implement to acceptance criteria.
|
||||
Run tests with a timeout flag appropriate to this project's test runner — fail fast,
|
||||
do not wait indefinitely for hanging tests. If a test hangs, isolate and fix it.
|
||||
Update flight log with outcomes. Propagate changes to artifacts (flight, mission, leg),
|
||||
CLAUDE.md, README, and other project documentation as needed. Do NOT commit yet —
|
||||
signal [HANDOFF:review-needed] when implementation is complete.
|
||||
```
|
||||
|
||||
### Reviewer: Review
|
||||
|
||||
```
|
||||
role: reviewer
|
||||
phase: leg-review
|
||||
project: {project-slug}
|
||||
flight: {flight-number}
|
||||
leg: {leg-number}
|
||||
action: review
|
||||
|
||||
Review all changes since the last commit. Evaluate against:
|
||||
1. Leg acceptance criteria — are all criteria met?
|
||||
2. Code quality — style, clarity, maintainability
|
||||
3. Correctness — edge cases, error handling, security
|
||||
4. Tests — coverage, meaningful assertions, no regressions
|
||||
5. Artifacts — flight log updated, leg status correct
|
||||
|
||||
Signal [HANDOFF:confirmed] if all changes are satisfactory.
|
||||
If issues found, list them with severity (blocking/non-blocking) and specific
|
||||
file:line references.
|
||||
```
|
||||
|
||||
### Accessibility Reviewer: Review Accessibility
|
||||
|
||||
```
|
||||
role: accessibility-reviewer
|
||||
phase: leg-review
|
||||
project: {project-slug}
|
||||
flight: {flight-number}
|
||||
leg: {leg-number}
|
||||
action: review-accessibility
|
||||
|
||||
Review all UI changes since the last commit for accessibility compliance.
|
||||
|
||||
Evaluate against:
|
||||
1. WCAG 2.1 AA — do changes meet Level AA success criteria?
|
||||
2. Semantic HTML — proper heading hierarchy, landmark regions, form labels?
|
||||
3. Keyboard navigation — all interactive elements reachable and operable?
|
||||
4. Screen readers — ARIA attributes correct and meaningful? Live regions?
|
||||
5. Color and contrast — minimum 4.5:1 for text, 3:1 for large text/UI?
|
||||
6. Focus management — visible focus indicators, logical tab order?
|
||||
|
||||
Signal [HANDOFF:confirmed] if all changes are accessible.
|
||||
If issues found, list them with severity (blocking/non-blocking), WCAG criterion
|
||||
reference, and specific file:line references.
|
||||
```
|
||||
|
||||
### Developer: Fix Review Issues
|
||||
|
||||
```
|
||||
role: developer
|
||||
phase: leg-implementation
|
||||
project: {project-slug}
|
||||
flight: {flight-number}
|
||||
leg: {leg-number}
|
||||
action: fix-review-issues
|
||||
|
||||
Address the following review feedback:
|
||||
{reviewer-issues}
|
||||
|
||||
Fix all blocking issues. Non-blocking issues: fix if straightforward, otherwise
|
||||
note as accepted. Signal [HANDOFF:review-needed] when fixes are complete.
|
||||
```
|
||||
|
||||
### Developer: Commit
|
||||
|
||||
```
|
||||
role: developer
|
||||
phase: leg-implementation
|
||||
project: {project-slug}
|
||||
flight: {flight-number}
|
||||
leg: {leg-number}
|
||||
action: commit
|
||||
|
||||
Review has passed. Before committing, complete ALL post-completion checklist items
|
||||
in the leg artifact:
|
||||
1. Check off all acceptance criteria in the leg artifact
|
||||
2. Update leg status to completed
|
||||
3. Check off this leg in flight.md
|
||||
4. If final leg: update flight.md status to landed, check off flight in mission.md
|
||||
|
||||
Then commit all changes (code + artifacts) with appropriate message.
|
||||
Signal [COMPLETE:leg].
|
||||
```
|
||||
@@ -0,0 +1,74 @@
|
||||
# Mission Debrief — Project Crew
|
||||
|
||||
Crew definitions for post-mission retrospective. The Flight Director interviews
|
||||
both the human and a project-side Architect to capture strategic technical perspective.
|
||||
|
||||
## Crew
|
||||
|
||||
### Architect
|
||||
- **Context**: {project}/
|
||||
- **Model**: Sonnet
|
||||
- **Role**: Provides architectural perspective on mission outcomes. Evaluates
|
||||
whether the system evolved well across flights, identifies structural issues,
|
||||
and assesses long-term maintainability of what was built.
|
||||
- **Actions**: debrief-interview
|
||||
|
||||
## Interaction Protocol
|
||||
|
||||
### Architect Interview
|
||||
1. Flight Director loads full mission context (all flights, logs, debriefs, code)
|
||||
2. Flight Director spawns **Architect** to review overall system evolution
|
||||
3. Architect examines architectural changes across all flights
|
||||
4. Architect provides structured debrief input
|
||||
|
||||
### Human Interview
|
||||
1. Flight Director interviews human with mission-level questions
|
||||
2. Covers coordination experience, outcome satisfaction, process feedback
|
||||
|
||||
### Synthesis
|
||||
1. Flight Director synthesizes Architect input + human input + document analysis
|
||||
2. Generates mission debrief artifact
|
||||
|
||||
## Template Variables
|
||||
|
||||
The Flight Director substitutes these variables in prompts at runtime:
|
||||
|
||||
| Variable | Description |
|
||||
|----------|-------------|
|
||||
| `{project-slug}` | Project identifier from projects.md |
|
||||
|
||||
## Prompts
|
||||
|
||||
### Architect: Debrief Interview
|
||||
|
||||
```
|
||||
role: architect
|
||||
phase: mission-debrief
|
||||
project: {project-slug}
|
||||
action: debrief-interview
|
||||
|
||||
Review the system changes produced across all flights in this mission. Examine
|
||||
the architectural evolution, pattern consistency, and structural health.
|
||||
|
||||
Provide structured input for the debrief:
|
||||
|
||||
**Architectural Assessment**:
|
||||
- Did the system's architecture improve, maintain, or degrade?
|
||||
- Are there structural issues that emerged across flights?
|
||||
- Were design decisions consistent across the mission?
|
||||
|
||||
**Pattern Analysis**:
|
||||
- What patterns were established? Are they good ones?
|
||||
- Is there inconsistency that should be reconciled?
|
||||
- Are there reusable patterns worth documenting?
|
||||
|
||||
**Technical Debt**:
|
||||
- What debt was introduced across the mission?
|
||||
- What's the priority for addressing it?
|
||||
- Are there quick wins vs. long-term concerns?
|
||||
|
||||
**Forward-Looking**:
|
||||
- What architectural considerations should the next mission account for?
|
||||
- Are there scaling or performance concerns on the horizon?
|
||||
- What documentation or conventions should be established?
|
||||
```
|
||||
@@ -0,0 +1,72 @@
|
||||
# Mission Design — Project Crew
|
||||
|
||||
Crew definitions for mission planning. The Flight Director interviews the human
|
||||
and uses project-side agents to validate technical viability.
|
||||
|
||||
## Crew
|
||||
|
||||
### Architect
|
||||
- **Context**: {project}/
|
||||
- **Model**: Sonnet
|
||||
- **Role**: Validates technical viability of proposed outcomes. Ensures business
|
||||
goals align with what's actually possible given the codebase, stack, and
|
||||
constraints. Does NOT add implementation details — focuses on feasibility,
|
||||
risks, and architectural implications.
|
||||
- **Actions**: validate-mission
|
||||
|
||||
## Interaction Protocol
|
||||
|
||||
### Research & Interview
|
||||
1. Flight Director researches codebase and external context
|
||||
2. Flight Director interviews human about outcomes, stakeholders, constraints, criteria
|
||||
3. Human must explicitly sign off before proceeding — iterate until approved
|
||||
|
||||
### Technical Viability Check
|
||||
1. Flight Director spawns **Architect** to review draft mission against codebase
|
||||
2. Architect evaluates: Are proposed outcomes achievable? Are there technical risks
|
||||
the mission doesn't account for? Does the stack support what's being asked?
|
||||
3. Architect provides assessment — feasible / feasible with caveats / not feasible
|
||||
4. Flight Director incorporates feedback, re-interviews human if scope changes
|
||||
5. Human gives final sign-off
|
||||
|
||||
## Template Variables
|
||||
|
||||
The Flight Director substitutes these variables in prompts at runtime:
|
||||
|
||||
| Variable | Description |
|
||||
|----------|-------------|
|
||||
| `{project-slug}` | Project identifier from projects.md |
|
||||
|
||||
## Prompts
|
||||
|
||||
### Architect: Validate Mission
|
||||
|
||||
```
|
||||
role: architect
|
||||
phase: mission-design
|
||||
project: {project-slug}
|
||||
action: validate-mission
|
||||
|
||||
Read the draft mission artifact. Cross-reference proposed outcomes and success
|
||||
criteria against the actual codebase, stack, and project constraints.
|
||||
|
||||
Evaluate:
|
||||
1. Technical feasibility — can the proposed outcomes be achieved with this stack?
|
||||
2. Architectural implications — does this require significant structural changes?
|
||||
3. Risk factors — what technical risks could block success?
|
||||
4. Constraints accuracy — are stated constraints complete and correct?
|
||||
5. Sizing — is the scope realistic for a mission (days-to-weeks)?
|
||||
|
||||
Provide structured output:
|
||||
|
||||
**Feasibility**: feasible | feasible with caveats | not feasible
|
||||
|
||||
**Risks** (ranked by impact):
|
||||
- [high/medium/low] Description — mitigation
|
||||
|
||||
**Caveats** (if feasible with caveats):
|
||||
- Description
|
||||
|
||||
**Questions** (for the Flight Director):
|
||||
- Question
|
||||
```
|
||||
@@ -0,0 +1,592 @@
|
||||
# Routine Maintenance — Project Crew
|
||||
|
||||
Crew definitions for codebase health inspection. The Flight Director
|
||||
coordinates specialist reviewers for automated checks and an Architect
|
||||
for severity assessment and roundtable moderation.
|
||||
|
||||
## Crew
|
||||
|
||||
### Inspector
|
||||
- **Context**: {project}/
|
||||
- **Model**: Sonnet
|
||||
- **Role**: Performs broad read-only codebase inspection across all applicable
|
||||
categories. Runs test suites, linters, type checkers, audit commands, and
|
||||
manual code review. Returns structured findings without modifying any files.
|
||||
- **Actions**: inspect-codebase
|
||||
|
||||
### Security Reviewer
|
||||
- **Context**: {project}/
|
||||
- **Model**: Sonnet
|
||||
- **Role**: Performs focused manual security review of authentication flows,
|
||||
injection surfaces, secrets handling, CORS/CSP configuration, and data
|
||||
exposure risks. Goes deeper than the Inspector's Category 1 automated checks
|
||||
with targeted code path analysis.
|
||||
- **Actions**: review-security
|
||||
|
||||
### CI/CD Reviewer (optional)
|
||||
- **Context**: {project}/
|
||||
- **Model**: Sonnet
|
||||
- **Enabled**: false (enable when project has CI/CD pipelines)
|
||||
- **Role**: Reviews CI/CD pipeline configuration, build security, deployment
|
||||
practices, and environment consistency. Evaluates pipeline definitions,
|
||||
secret management in CI, and deployment safeguards.
|
||||
- **Actions**: review-cicd
|
||||
|
||||
### Accessibility Reviewer (optional)
|
||||
- **Context**: {project}/
|
||||
- **Model**: Sonnet
|
||||
- **Enabled**: false (enable when project has user-facing UI)
|
||||
- **Role**: Reviews codebase for accessibility compliance against WCAG 2.1 AA
|
||||
standards. Evaluates semantic HTML, keyboard navigation, screen reader
|
||||
compatibility, color contrast, ARIA usage, and focus management.
|
||||
- **Actions**: review-accessibility
|
||||
|
||||
### Architect
|
||||
- **Context**: {project}/
|
||||
- **Model**: Opus
|
||||
- **Role**: Reviews all reviewer findings alongside debrief context. Assigns
|
||||
severity per finding, challenges questionable assessments, moderates
|
||||
roundtable discussion with specialist reviewers, and produces final codebase
|
||||
assessment with maintenance scope recommendation.
|
||||
- **Actions**: assess-findings, moderate-roundtable
|
||||
|
||||
## Separation Rules
|
||||
|
||||
- All reviewers are strictly **read-only** — they may run commands but must NEVER modify files
|
||||
- Each reviewer operates independently during Phase 4 — no cross-reviewer communication
|
||||
- The Architect sees all reviewer findings but not their internal reasoning
|
||||
- Roundtable discussion is mediated by the Flight Director, not direct agent-to-agent
|
||||
|
||||
**Note:** Handoff signals are not used in this crew. The routine-maintenance workflow is
|
||||
sequential (review → assess → roundtable → report) and does not use the leg-based
|
||||
handoff protocol.
|
||||
|
||||
## Interaction Protocol
|
||||
|
||||
### Delegation Planning
|
||||
1. Flight Director loads context, conducts scoping interview with human
|
||||
2. Flight Director assesses project size and identifies module boundaries
|
||||
3. Flight Director builds delegation plan (agent count, scope assignments, partitioning)
|
||||
4. Human approves or adjusts the plan
|
||||
|
||||
### Specialist Review
|
||||
1. Flight Director spawns agents per the delegation plan — Inspector(s) + Security Reviewer always, CI/CD and Accessibility if enabled
|
||||
2. Each agent receives its scope assignment and output discipline rules
|
||||
3. All reviewers perform read-only checks and return structured findings
|
||||
4. For partitioned Inspectors: Flight Director merges and de-duplicates findings
|
||||
|
||||
### Initial Assessment
|
||||
1. Flight Director spawns **Architect** (Opus) with all reviewer findings + debrief context
|
||||
2. Architect assigns initial severity per finding
|
||||
3. Architect raises challenges or questions directed at specific reviewers
|
||||
|
||||
### Roundtable
|
||||
1. Flight Director routes Architect's challenges to the relevant reviewers
|
||||
2. Each challenged reviewer responds with evidence, rebuttals, or concurrence
|
||||
3. Flight Director collects responses and spawns Architect for final resolution
|
||||
4. Architect produces final assessment incorporating roundtable discussion
|
||||
5. Max 2 roundtable cycles — unresolved disagreements go to the human
|
||||
|
||||
### Human Review and Scoping
|
||||
1. Flight Director presents findings to human, grouped by severity
|
||||
2. Human confirms, overrides, or adjusts findings
|
||||
3. If Maintenance Required: Flight Director recommends a shortlist (~5-7 items); human selects scope for maintenance mission
|
||||
4. Deferred findings remain in the report for future cycles
|
||||
|
||||
### Synthesis
|
||||
1. Flight Director generates maintenance report artifact
|
||||
2. If confirmed: Flight Director creates maintenance mission scaffold
|
||||
|
||||
## Template Variables
|
||||
|
||||
The Flight Director substitutes these variables in prompts at runtime:
|
||||
|
||||
| Variable | Description |
|
||||
|----------|-------------|
|
||||
| `{project-slug}` | Project identifier from projects.md |
|
||||
| `{applicable-categories}` | Numbered list of categories to inspect (1-7 always, 8-10 conditional) |
|
||||
| `{project-stack}` | Language, framework, test runner, linter, formatter, type checker, audit tool |
|
||||
| `{known-debt}` | Debt items from mission debrief and flight debriefs (if available, otherwise "None — ad-hoc inspection") |
|
||||
| `{known-security-debt}` | Security-specific debt items extracted from debriefs (if available, otherwise "None") |
|
||||
| `{known-cicd-debt}` | CI/CD-specific debt items extracted from debriefs (if available, otherwise "None") |
|
||||
| `{areas-of-concern}` | User-specified areas of concern from scoping interview |
|
||||
| `{scope-assignment}` | Scope restriction from the delegation plan (files, directories, or "full project") |
|
||||
| `{all-reviewer-findings}` | Combined structured findings from all reviewers (used in Architect prompts) |
|
||||
| `{architect-challenges}` | Architect's challenges directed at a specific reviewer (used in roundtable) |
|
||||
| `{roundtable-responses}` | All reviewer rebuttals and responses from the roundtable (used in resolution) |
|
||||
|
||||
## Prompts
|
||||
|
||||
### Inspector: Inspect Codebase
|
||||
|
||||
```
|
||||
role: inspector
|
||||
phase: routine-maintenance
|
||||
project: {project-slug}
|
||||
action: inspect-codebase
|
||||
|
||||
Perform a read-only codebase inspection across the following categories:
|
||||
{applicable-categories}
|
||||
|
||||
Project stack: {project-stack}
|
||||
|
||||
Known debt from prior debriefs, if available (do not re-flag as new discoveries):
|
||||
{known-debt}
|
||||
|
||||
User areas of concern:
|
||||
{areas-of-concern}
|
||||
|
||||
IMPORTANT: You are strictly READ-ONLY. You may run test suites, linters, type
|
||||
checkers, audit commands, and read any file. You must NEVER modify source files,
|
||||
configuration, dependencies, or any other project file.
|
||||
|
||||
**Scope assignment**: If a scope restriction is provided, inspect only the
|
||||
specified files and directories. Run automated tools against the full project
|
||||
(tools are fast and comprehensive), but limit manual code review to the assigned
|
||||
scope. If no scope restriction is given, inspect the full project.
|
||||
|
||||
For each applicable category, perform the checks listed below and report findings.
|
||||
|
||||
**Category 1 — Security**:
|
||||
- Review auth paths (focus on recently changed code if mission context is available)
|
||||
- Check input sanitization on endpoints
|
||||
- Verify CORS/CSP configuration
|
||||
- Scan for hardcoded secrets (API keys, tokens, passwords)
|
||||
- Review third-party data flow for exposure risks
|
||||
|
||||
**Category 2 — Test Systems**:
|
||||
- Run the test suite and report results
|
||||
- Check coverage delta (if tooling available)
|
||||
- Find new code paths without test coverage
|
||||
- Detect flaky tests (tests that pass/fail inconsistently)
|
||||
- Check test performance (slow tests)
|
||||
- Find hardcoded test data that should be fixtures
|
||||
|
||||
**Category 3 — Dependency Health**:
|
||||
- Run the dependency audit command (npm audit, cargo audit, etc.)
|
||||
- Check for outdated dependencies
|
||||
- Find unused dependencies
|
||||
- Verify lockfile is consistent
|
||||
- Check license compliance
|
||||
- Check for Dependabot/Renovate PRs and security alerts
|
||||
- Assess auto-merge eligibility for patch updates
|
||||
|
||||
**Category 4 — Code Quality**:
|
||||
- Run linter and formatter check (report violations, do NOT fix)
|
||||
- Find dead code (unused exports, unreachable branches)
|
||||
- Grep for TODOs/FIXMEs/HACKs (focus on recently introduced ones if mission context is available)
|
||||
- Detect code duplication
|
||||
- Check pattern consistency with existing codebase
|
||||
|
||||
**Category 5 — Type & API Safety**:
|
||||
- Run the type checker and report errors
|
||||
- Find `any` casts (TypeScript), `unsafe` blocks (Rust), or equivalent
|
||||
- Check for unhandled errors or missing error types
|
||||
- Detect API contract drift (mismatched types between client/server)
|
||||
- Find deprecated API usage
|
||||
|
||||
**Category 6 — Documentation**:
|
||||
- Check README accuracy against current state
|
||||
- Verify new public interfaces have documentation
|
||||
- Find stale comments referencing old behavior
|
||||
- Check CHANGELOG for completeness
|
||||
- Verify CLAUDE.md accuracy
|
||||
|
||||
**Category 7 — Git & Branch Hygiene**:
|
||||
- List stale branches (merged but not deleted)
|
||||
- Find large committed files (>1MB)
|
||||
- Scan for secrets in recent git history
|
||||
- Check commit message quality
|
||||
- Check for GitHub/remote warnings (secret scanning, code scanning alerts)
|
||||
- Find merge conflicts against main
|
||||
- Check upstream divergence
|
||||
|
||||
**Category 8 — CI/CD Pipeline** (if applicable):
|
||||
- Check CI status on main/default branch
|
||||
- Detect build time regression
|
||||
- Find skipped or disabled checks
|
||||
- Check config drift between environments
|
||||
|
||||
**Category 9 — Infrastructure & Config** (if applicable):
|
||||
- Check env var documentation (.env.example vs actual usage)
|
||||
- Find pending database migrations
|
||||
- Find temporary feature flags that should be removed
|
||||
|
||||
**Category 10 — Performance & Observability** (if applicable):
|
||||
- Find new operations without logging/tracing
|
||||
- Detect potential N+1 queries
|
||||
- Check bundle size (if web project)
|
||||
- Find resource cleanup issues (unclosed connections, missing cleanup)
|
||||
|
||||
**Output discipline**: Keep findings concise. Do not paste full command output,
|
||||
full file contents, or long dependency lists. Summarize and reference.
|
||||
|
||||
**Output format**: Return findings as a structured list per category:
|
||||
|
||||
## Category {N}: {Name}
|
||||
|
||||
### Finding: {title}
|
||||
- **Evidence**: {one-line summary with file paths and line numbers}
|
||||
- **Impact**: {what could go wrong}
|
||||
- **Recommendation**: {what to do about it}
|
||||
|
||||
Include code excerpts only for Critical or High severity findings.
|
||||
|
||||
If a category has no issues, report:
|
||||
## Category {N}: {Name}
|
||||
No issues found.
|
||||
```
|
||||
|
||||
### Security Reviewer: Review Security
|
||||
|
||||
```
|
||||
role: security-reviewer
|
||||
phase: routine-maintenance
|
||||
project: {project-slug}
|
||||
action: review-security
|
||||
|
||||
Perform a focused, manual security review of the codebase. You go deeper than
|
||||
automated scanning — trace actual code paths and evaluate security posture.
|
||||
|
||||
Project stack: {project-stack}
|
||||
|
||||
Known security debt from prior debriefs (do not re-flag as new discoveries):
|
||||
{known-security-debt}
|
||||
|
||||
User areas of concern:
|
||||
{areas-of-concern}
|
||||
|
||||
IMPORTANT: You are strictly READ-ONLY. You may run commands and read any file.
|
||||
You must NEVER modify source files, configuration, dependencies, or any other
|
||||
project file.
|
||||
|
||||
**Scope assignment**: Review only the files and areas specified. If no scope
|
||||
restriction is given, review the full project.
|
||||
|
||||
**Output discipline**: Keep findings concise. Include code excerpts only for
|
||||
Critical or High severity findings. Do not paste full file contents or raw
|
||||
command output.
|
||||
|
||||
**Review areas**:
|
||||
|
||||
1. **Authentication & Authorization**
|
||||
- Trace auth flows end-to-end (login, token refresh, logout)
|
||||
- Check for missing auth checks on protected routes/endpoints
|
||||
- Verify role-based access control is enforced consistently
|
||||
- Look for privilege escalation paths
|
||||
|
||||
2. **Injection Surfaces**
|
||||
- SQL/NoSQL injection: check all database queries for parameterization
|
||||
- Command injection: check shell executions, subprocess calls
|
||||
- XSS: check output encoding in templates and API responses
|
||||
- Path traversal: check file system operations with user input
|
||||
|
||||
3. **Secrets & Configuration**
|
||||
- Scan for hardcoded credentials, API keys, tokens in source
|
||||
- Check .env files are gitignored
|
||||
- Verify secrets are not logged or included in error responses
|
||||
- Check for overly permissive CORS configuration
|
||||
|
||||
4. **Data Handling**
|
||||
- Review PII/sensitive data flows — where is it stored, logged, transmitted?
|
||||
- Check encryption at rest and in transit
|
||||
- Verify sensitive data is not cached inappropriately
|
||||
- Check for data leakage in error messages or debug output
|
||||
|
||||
5. **Dependency Risk**
|
||||
- Cross-reference critical dependencies against known CVE databases
|
||||
- Check for dependencies with known supply-chain risks
|
||||
- Verify integrity checks (lockfile hashes, checksums)
|
||||
|
||||
**Output format**: Return findings as a structured list:
|
||||
|
||||
### Finding: {title}
|
||||
- **Severity estimate**: critical | high | medium | low
|
||||
- **Attack vector**: {how this could be exploited}
|
||||
- **Evidence**: {specific code paths, file:line references}
|
||||
- **Recommendation**: {what to do about it}
|
||||
|
||||
If no security issues found, state: "No security issues identified."
|
||||
```
|
||||
|
||||
### CI/CD Reviewer: Review CI/CD
|
||||
|
||||
```
|
||||
role: cicd-reviewer
|
||||
phase: routine-maintenance
|
||||
project: {project-slug}
|
||||
action: review-cicd
|
||||
|
||||
Perform a focused review of the project's CI/CD pipeline configuration,
|
||||
build security, and deployment practices.
|
||||
|
||||
Project stack: {project-stack}
|
||||
|
||||
Known CI/CD debt from prior debriefs (do not re-flag as new discoveries):
|
||||
{known-cicd-debt}
|
||||
|
||||
User areas of concern:
|
||||
{areas-of-concern}
|
||||
|
||||
IMPORTANT: You are strictly READ-ONLY. You may run commands and read any file.
|
||||
You must NEVER modify source files, configuration, dependencies, or any other
|
||||
project file.
|
||||
|
||||
**Output discipline**: Keep findings concise. Include code excerpts only for
|
||||
Critical or High severity findings. Do not paste full file contents or raw
|
||||
command output.
|
||||
|
||||
**Review areas**:
|
||||
|
||||
1. **Pipeline Configuration**
|
||||
- Review pipeline definitions (GitHub Actions, GitLab CI, Concourse, etc.)
|
||||
- Check for outdated action/image versions
|
||||
- Verify branch protection rules are consistent with pipeline triggers
|
||||
- Detect redundant or overlapping pipeline steps
|
||||
|
||||
2. **Build Security**
|
||||
- Check for secrets exposed in build logs or artifacts
|
||||
- Verify pipeline secrets are scoped appropriately (not org-wide when repo-level suffices)
|
||||
- Check for unpinned dependencies in build steps (e.g., `uses: action@main` vs `@v4.1.0`)
|
||||
- Review build artifact permissions and retention policies
|
||||
|
||||
3. **Deployment Safeguards**
|
||||
- Verify deployment gates exist (approval steps, environment protection rules)
|
||||
- Check rollback capability — is there a documented or automated rollback path?
|
||||
- Verify environment promotion flow (dev → staging → prod) is enforced
|
||||
- Check for drift between environment configurations
|
||||
|
||||
4. **Pipeline Health**
|
||||
- Check recent build success rates and durations
|
||||
- Identify flaky pipeline steps
|
||||
- Find disabled or skipped checks that should be active
|
||||
- Check for resource waste (oversized runners, unnecessary matrix builds)
|
||||
|
||||
**Output format**: Return findings as a structured list:
|
||||
|
||||
### Finding: {title}
|
||||
- **Severity estimate**: critical | high | medium | low
|
||||
- **Evidence**: {specific config files, pipeline definitions, line references}
|
||||
- **Impact**: {what could go wrong}
|
||||
- **Recommendation**: {what to do about it}
|
||||
|
||||
If no CI/CD issues found, state: "No CI/CD issues identified."
|
||||
```
|
||||
|
||||
### Accessibility Reviewer: Review Accessibility
|
||||
|
||||
```
|
||||
role: accessibility-reviewer
|
||||
phase: routine-maintenance
|
||||
project: {project-slug}
|
||||
action: review-accessibility
|
||||
|
||||
Perform a focused accessibility review of the project's user-facing UI.
|
||||
Evaluate against WCAG 2.1 AA standards.
|
||||
|
||||
Project stack: {project-stack}
|
||||
|
||||
IMPORTANT: You are strictly READ-ONLY. You may run commands and read any file.
|
||||
You must NEVER modify source files, configuration, dependencies, or any other
|
||||
project file.
|
||||
|
||||
**Output discipline**: Keep findings concise. Include code excerpts only for
|
||||
Critical or High severity findings. Do not paste full file contents or raw
|
||||
command output.
|
||||
|
||||
**Review areas**:
|
||||
|
||||
1. **Semantic HTML & Structure**
|
||||
- Check heading hierarchy (h1-h6 in logical order)
|
||||
- Verify landmark regions (main, nav, aside, footer)
|
||||
- Check form labels and fieldset/legend usage
|
||||
- Verify list markup for list-like content
|
||||
|
||||
2. **Keyboard Navigation**
|
||||
- Check all interactive elements are reachable via Tab
|
||||
- Verify custom widgets have appropriate keyboard handlers
|
||||
- Check for keyboard traps (modals, dropdowns)
|
||||
- Verify skip-to-content links exist
|
||||
|
||||
3. **Screen Reader Compatibility**
|
||||
- Check ARIA attributes for correctness and necessity
|
||||
- Verify dynamic content updates use live regions
|
||||
- Check image alt text (present, meaningful, not redundant)
|
||||
- Verify form error messages are associated with inputs
|
||||
|
||||
4. **Visual & Color**
|
||||
- Check text contrast ratios (4.5:1 normal, 3:1 large text)
|
||||
- Verify UI component contrast (3:1 against background)
|
||||
- Check that color is not the sole indicator of meaning
|
||||
- Verify visible focus indicators on all interactive elements
|
||||
|
||||
5. **Motion & Timing**
|
||||
- Check for prefers-reduced-motion support on animations
|
||||
- Verify no auto-playing media without controls
|
||||
- Check for appropriate timeouts with user notification
|
||||
|
||||
**Output format**: Return findings as a structured list:
|
||||
|
||||
### Finding: {title}
|
||||
- **WCAG criterion**: {e.g., 1.1.1 Non-text Content, Level A}
|
||||
- **Severity estimate**: critical | high | medium | low
|
||||
- **Evidence**: {specific components, file:line references}
|
||||
- **Recommendation**: {what to do about it}
|
||||
|
||||
If no accessibility issues found, state: "No accessibility issues identified."
|
||||
```
|
||||
|
||||
### Architect: Assess Findings
|
||||
|
||||
```
|
||||
role: architect
|
||||
phase: routine-maintenance
|
||||
project: {project-slug}
|
||||
action: assess-findings
|
||||
|
||||
Review all specialist findings and assign severity ratings. You have access to:
|
||||
- All reviewer findings (provided below)
|
||||
- Known debt context from debriefs and prior maintenance reports (if available)
|
||||
|
||||
{all-reviewer-findings}
|
||||
|
||||
Known debt from debriefs, if available (already acknowledged — note as "previously identified" if re-found):
|
||||
{known-debt}
|
||||
|
||||
For each finding, assign one of:
|
||||
- **Pass** — No issue (reviewer flagged something that is actually fine)
|
||||
- **Advisory** — Minor issue, acceptable to defer
|
||||
- **Action Required** — Should be addressed before next major work cycle
|
||||
- **Critical** — Blocks further work, immediate attention needed
|
||||
|
||||
**Assessment criteria**:
|
||||
- Does this finding represent a real risk, or is it noise?
|
||||
- Is the severity proportional to the actual impact?
|
||||
- Would this compound if left for another cycle?
|
||||
- Is this a new discovery or previously acknowledged debt?
|
||||
- Do multiple reviewers corroborate the same issue?
|
||||
- Are any reviewer assessments questionable — too alarmist or too dismissive?
|
||||
|
||||
**Challenge reviewers** where you disagree or need clarification. For each
|
||||
challenge, name the reviewer and provide your specific question or objection.
|
||||
This initiates the roundtable discussion.
|
||||
|
||||
**Output format**:
|
||||
|
||||
## Overall Assessment
|
||||
{Flight Ready | Maintenance Required}
|
||||
|
||||
## Findings
|
||||
|
||||
| # | Source | Category | Finding | Initial Severity | New/Known | Notes |
|
||||
|---|--------|----------|---------|-----------------|-----------|-------|
|
||||
| 1 | {reviewer} | {cat} | {title} | {severity} | {new/known} | {brief note} |
|
||||
|
||||
## Challenges for Roundtable
|
||||
|
||||
### To {Reviewer Name}: {question or objection}
|
||||
{Context for why you're challenging this finding — what seems off, what
|
||||
additional evidence would change your assessment, or why you think the
|
||||
severity should be different.}
|
||||
|
||||
## Severity Summary
|
||||
- Critical: {N}
|
||||
- Action Required: {N}
|
||||
- Advisory: {N}
|
||||
- Pass: {N}
|
||||
|
||||
## Recommended Maintenance Scope
|
||||
(Only if Maintenance Required)
|
||||
|
||||
Group related Action Required and Critical findings into suggested flight scopes:
|
||||
|
||||
### Flight: {suggested title}
|
||||
- Finding #{N}: {title}
|
||||
- Finding #{N}: {title}
|
||||
- Rationale: {why these group together}
|
||||
```
|
||||
|
||||
### Reviewer: Roundtable Rebuttal
|
||||
|
||||
```
|
||||
role: {reviewer-role}
|
||||
phase: routine-maintenance
|
||||
project: {project-slug}
|
||||
action: roundtable-rebuttal
|
||||
|
||||
The Architect has challenged one or more of your findings during the
|
||||
severity assessment roundtable. Respond to each challenge with evidence.
|
||||
|
||||
Architect's challenges:
|
||||
{architect-challenges}
|
||||
|
||||
For each challenge:
|
||||
1. **Provide additional evidence** — code paths, specific examples, tool output
|
||||
that supports your finding
|
||||
2. **Concede if appropriate** — if the Architect raises a valid point, adjust
|
||||
your assessment rather than defending a weak position
|
||||
3. **Clarify misunderstandings** — if the Architect misread your finding,
|
||||
restate it with more precision
|
||||
|
||||
Be direct and evidence-based. The goal is consensus, not debate for its own sake.
|
||||
|
||||
**Output format**:
|
||||
|
||||
### Re: {Architect's challenge title}
|
||||
- **Response**: {concur | rebut | clarify}
|
||||
- **Evidence**: {additional code paths, line references, tool output}
|
||||
- **Revised assessment** (if changed): {updated severity or recommendation}
|
||||
```
|
||||
|
||||
### Architect: Roundtable Resolution
|
||||
|
||||
```
|
||||
role: architect
|
||||
phase: routine-maintenance
|
||||
project: {project-slug}
|
||||
action: roundtable-resolution
|
||||
|
||||
Review the roundtable responses from specialist reviewers and produce your
|
||||
final assessment.
|
||||
|
||||
Reviewer responses:
|
||||
{roundtable-responses}
|
||||
|
||||
For each challenged finding:
|
||||
1. **Weigh the evidence** — did the reviewer provide convincing support?
|
||||
2. **Assign final severity** — this is your call, but account for reviewer expertise
|
||||
3. **Note reasoning** — briefly explain why you maintained or changed severity
|
||||
|
||||
If any disagreements remain unresolved, flag them for human review rather than
|
||||
forcing consensus.
|
||||
|
||||
**Output format**:
|
||||
|
||||
## Roundtable Resolution
|
||||
|
||||
### Finding #{N}: {title}
|
||||
- **Original severity**: {severity}
|
||||
- **Reviewer response**: {concur | rebut | clarify} — {summary}
|
||||
- **Final severity**: {severity}
|
||||
- **Reasoning**: {why}
|
||||
|
||||
## Updated Overall Assessment
|
||||
{Flight Ready | Maintenance Required}
|
||||
|
||||
## Updated Severity Summary
|
||||
- Critical: {N}
|
||||
- Action Required: {N}
|
||||
- Advisory: {N}
|
||||
- Pass: {N}
|
||||
|
||||
## Unresolved Disagreements (if any)
|
||||
{Finding and both perspectives — for human to decide}
|
||||
|
||||
## Updated Recommended Maintenance Scope
|
||||
(Only if Maintenance Required — incorporate roundtable outcomes)
|
||||
|
||||
### Flight: {suggested title}
|
||||
- Finding #{N}: {title}
|
||||
- Finding #{N}: {title}
|
||||
- Rationale: {why these group together}
|
||||
```
|
||||
@@ -0,0 +1,104 @@
|
||||
# Init-Project Migrations
|
||||
|
||||
When `/init-project` runs, it checks for legacy directory layouts from earlier versions of Flight Control and offers to migrate them. Migrations are idempotent — they only apply when the old layout is detected and the new layout doesn't yet exist.
|
||||
|
||||
## Migration Registry
|
||||
|
||||
### 001 — Rename `.flight-ops/` to `.flightops/`
|
||||
|
||||
Early versions of Flight Control used `.flight-ops/` (with a hyphen). The current convention is `.flightops/` (no hyphen).
|
||||
|
||||
**Detection** (returns true if migration is needed):
|
||||
|
||||
```bash
|
||||
[[ -d "{target-project}/.flight-ops" && ! -d "{target-project}/.flightops" ]]
|
||||
```
|
||||
|
||||
**Actions:**
|
||||
|
||||
1. Rename the directory:
|
||||
```bash
|
||||
mv "{target-project}/.flight-ops" "{target-project}/.flightops"
|
||||
```
|
||||
2. Update `.gitignore` if it references the old name:
|
||||
```bash
|
||||
sed -i 's/\.flight-ops/\.flightops/g' "{target-project}/.gitignore"
|
||||
```
|
||||
|
||||
**User message:**
|
||||
> Renaming `.flight-ops/` → `.flightops/` (updated naming convention)
|
||||
|
||||
---
|
||||
|
||||
### 002 — Rename `phases/` to `agent-crews/`
|
||||
|
||||
Early versions stored crew definitions in `.flightops/phases/`. The current convention is `.flightops/agent-crews/`.
|
||||
|
||||
**Detection** (returns true if migration is needed):
|
||||
|
||||
```bash
|
||||
[[ -d "{target-project}/.flightops/phases" && ! -d "{target-project}/.flightops/agent-crews" ]]
|
||||
```
|
||||
|
||||
> **Note:** This runs after migration 001, so it checks the post-rename `.flightops/` path.
|
||||
|
||||
**Actions:**
|
||||
|
||||
1. Rename the subdirectory:
|
||||
```bash
|
||||
mv "{target-project}/.flightops/phases" "{target-project}/.flightops/agent-crews"
|
||||
```
|
||||
|
||||
**User message:**
|
||||
> Renaming `phases/` → `agent-crews/` (updated naming convention)
|
||||
|
||||
---
|
||||
|
||||
### 003 — Update lifecycle states to unified model
|
||||
|
||||
Flight Control now uses a unified lifecycle for both flights and legs: `planning → ready → in-flight → landed → completed` (or `aborted`). This replaces the old divergent states:
|
||||
|
||||
- **Flights**: `diverted` → `aborted`; added `completed` after `landed`
|
||||
- **Legs**: `queued` → `planning`; `review` → `landed`; `blocked` → `aborted`; added `ready` and `completed`
|
||||
|
||||
**Detection** (returns true if migration is needed):
|
||||
|
||||
```bash
|
||||
grep -rql 'queued\|diverted\|blocked\|review.*completed' "{target-project}/.flightops/ARTIFACTS.md" 2>/dev/null
|
||||
```
|
||||
|
||||
> **Note:** This runs after migrations 001 and 002, so it checks the post-rename `.flightops/` path.
|
||||
|
||||
**Actions:**
|
||||
|
||||
1. Update state definitions in ARTIFACTS.md:
|
||||
- Replace flight status line: `planning | ready | in-flight | landed | diverted` → `planning | ready | in-flight | landed | completed | aborted`
|
||||
- Replace leg status line: `queued | in-flight | review | completed | blocked` → `planning | ready | in-flight | landed | completed | aborted`
|
||||
- Replace flight state tracking: `planning` → `ready` → `in-flight` → `landed` (or `diverted`) → `planning` → `ready` → `in-flight` → `landed` → `completed` (or `aborted`)
|
||||
- Replace leg state tracking: `queued` → `in-flight` → `review` → `completed` (or `blocked`) → `planning` → `ready` → `in-flight` → `landed` → `completed` (or `aborted`)
|
||||
- Replace `landed | diverted` → `landed | aborted` in debrief templates
|
||||
- Replace `landed/diverted` → `landed/aborted` in debrief templates
|
||||
- Replace `completed | in-flight | blocked` → `completed | landed | in-flight | aborted` in flight log templates
|
||||
|
||||
2. Update existing artifact files in the project (if any):
|
||||
- In flight artifacts: replace `**Status**: diverted` → `**Status**: aborted`
|
||||
- In leg artifacts: replace `**Status**: queued` → `**Status**: planning`, `**Status**: review` → `**Status**: landed`, `**Status**: blocked` → `**Status**: aborted`
|
||||
- In flight log entries: replace `**Status**: blocked` → `**Status**: aborted`
|
||||
|
||||
Find artifacts using the locations defined in ARTIFACTS.md (typically `missions/` directory for file-based projects).
|
||||
|
||||
**User message:**
|
||||
> Updating lifecycle states to unified model: flights and legs now share `planning → ready → in-flight → landed → completed (or aborted)`
|
||||
|
||||
---
|
||||
|
||||
## Adding Future Migrations
|
||||
|
||||
To add a new migration:
|
||||
|
||||
1. Assign the next sequential ID (e.g., `003`)
|
||||
2. Write a **Detection** check that returns true only when the migration is needed and false if already applied (idempotent)
|
||||
3. List the **Actions** to perform — prefer `mv` over copy-and-delete to preserve file contents and git history
|
||||
4. Write a short **User message** shown during the migration summary
|
||||
5. Consider ordering — if the migration depends on a previous one having run, note that in the detection section
|
||||
6. Keep migrations non-destructive: rename and update references, never delete user content
|
||||
@@ -0,0 +1,575 @@
|
||||
# Artifact System: Filesystem
|
||||
|
||||
This project stores Flight Control artifacts as markdown files in the repository.
|
||||
|
||||
## Directory Structure
|
||||
|
||||
```
|
||||
{project}/
|
||||
├── missions/
|
||||
│ └── {NN}-{mission-slug}/
|
||||
│ ├── mission.md
|
||||
│ ├── mission-debrief.md
|
||||
│ └── flights/
|
||||
│ └── {NN}-{flight-slug}/
|
||||
│ ├── flight.md
|
||||
│ ├── flight-log.md
|
||||
│ ├── flight-briefing.md
|
||||
│ ├── flight-debrief.md
|
||||
│ └── legs/
|
||||
│ └── {NN}-{leg-slug}.md
|
||||
└── maintenance/
|
||||
└── {YYYY-MM-DD}.md
|
||||
```
|
||||
|
||||
## Naming Conventions
|
||||
|
||||
- **Slugs**: Lowercase, kebab-case, derived from title (e.g., "User Authentication" → `user-authentication`)
|
||||
- **Sequence numbers**: Missions, flights, and legs use two-digit prefixes (`01`, `02`, etc.) for ordering
|
||||
|
||||
---
|
||||
|
||||
## Core Artifacts
|
||||
|
||||
### Mission
|
||||
|
||||
| Property | Value |
|
||||
|----------|-------|
|
||||
| Location | `missions/{NN}-{slug}/mission.md` |
|
||||
| Created | During mission planning |
|
||||
| Updated | Until status changes to `active` |
|
||||
|
||||
**Format:**
|
||||
|
||||
```markdown
|
||||
# Mission: {Title}
|
||||
|
||||
**Status**: planning | active | completed | aborted
|
||||
|
||||
## Outcome
|
||||
What success looks like in human terms.
|
||||
|
||||
## Context
|
||||
Why this mission matters now. Background information.
|
||||
|
||||
## Success Criteria
|
||||
- [ ] Criterion 1 (observable, binary)
|
||||
- [ ] Criterion 2
|
||||
- [ ] Criterion 3
|
||||
|
||||
## Stakeholders
|
||||
Who cares about this outcome and why.
|
||||
|
||||
## Constraints
|
||||
Non-negotiable boundaries.
|
||||
|
||||
## Environment Requirements
|
||||
- Development environment (devcontainer, local toolchain, cloud IDE)
|
||||
- Runtime requirements (GUI, audio hardware, network access)
|
||||
- Special tooling (Docker, specific CLI versions)
|
||||
|
||||
## Open Questions
|
||||
Unknowns that need resolution during execution.
|
||||
|
||||
## Known Issues
|
||||
Emergent blockers and issues discovered during execution. Add items here as flights surface problems that affect the broader mission — things not anticipated during planning but visible at the mission level.
|
||||
|
||||
- [ ] {Issue description} — discovered in Flight {N}, affects {scope}
|
||||
|
||||
## Flights
|
||||
|
||||
> **Note:** These are tentative suggestions, not commitments. Flights are planned and created one at a time as work progresses. This list will evolve based on discoveries during implementation.
|
||||
|
||||
- [ ] Flight 1: {description}
|
||||
- [ ] Flight 2: {description}
|
||||
- [ ] Flight N *(optional)*: Alignment — vibe coding session for creative collaboration and hands-on adjustments
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Flight
|
||||
|
||||
| Property | Value |
|
||||
|----------|-------|
|
||||
| Location | `missions/{mission}/flights/{NN}-{slug}/flight.md` |
|
||||
| Created | During flight planning |
|
||||
| Updated | Until status changes to `in-flight` |
|
||||
|
||||
**Format:**
|
||||
|
||||
```markdown
|
||||
# Flight: {Title}
|
||||
|
||||
**Status**: planning | ready | in-flight | landed | completed | aborted
|
||||
**Mission**: [{Mission Title}](../../mission.md)
|
||||
|
||||
## Contributing to Criteria
|
||||
- [ ] {Relevant success criterion 1}
|
||||
- [ ] {Relevant success criterion 2}
|
||||
|
||||
---
|
||||
|
||||
## Pre-Flight
|
||||
|
||||
### Objective
|
||||
What this flight accomplishes (one paragraph).
|
||||
|
||||
### Open Questions
|
||||
- [ ] Question needing resolution
|
||||
- [x] Resolved question → see Design Decisions
|
||||
|
||||
### Design Decisions
|
||||
|
||||
**{Decision Title}**: {Choice made}
|
||||
- Rationale: Why this choice
|
||||
- Trade-off: What we're giving up
|
||||
|
||||
### Prerequisites
|
||||
- [ ] {What must be true before execution}
|
||||
|
||||
### Pre-Flight Checklist
|
||||
- [ ] All open questions resolved
|
||||
- [ ] Design decisions documented
|
||||
- [ ] Prerequisites verified
|
||||
- [ ] Validation approach defined
|
||||
- [ ] Legs defined
|
||||
|
||||
---
|
||||
|
||||
## In-Flight
|
||||
|
||||
### Technical Approach
|
||||
How the objective will be achieved.
|
||||
|
||||
### Checkpoints
|
||||
- [ ] {Milestone 1}
|
||||
- [ ] {Milestone 2}
|
||||
|
||||
### Adaptation Criteria
|
||||
|
||||
**Divert if**:
|
||||
- {Condition requiring re-planning}
|
||||
|
||||
**Acceptable variations**:
|
||||
- {Minor changes that don't require diversion}
|
||||
|
||||
### Legs
|
||||
|
||||
> **Note:** These are tentative suggestions, not commitments. Legs are planned and created one at a time as the flight progresses. This list will evolve based on discoveries during implementation.
|
||||
|
||||
- [ ] `{leg-slug}` - {Brief description}
|
||||
- [ ] `{leg-slug}` - {Brief description}
|
||||
- [ ] `uat-and-alignment` *(optional)* - Guided UAT session with iterative fixes
|
||||
|
||||
---
|
||||
|
||||
## Post-Flight
|
||||
|
||||
### Completion Checklist
|
||||
- [ ] All legs completed
|
||||
- [ ] Code merged
|
||||
- [ ] Tests passing
|
||||
- [ ] Documentation updated
|
||||
|
||||
### Verification
|
||||
How to confirm the flight achieved its objective.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Leg
|
||||
|
||||
| Property | Value |
|
||||
|----------|-------|
|
||||
| Location | `missions/{mission}/flights/{flight}/legs/{NN}-{slug}.md` |
|
||||
| Created | Before leg execution |
|
||||
| Updated | Never once `in-flight` (immutable) |
|
||||
|
||||
**Format:**
|
||||
|
||||
```markdown
|
||||
# Leg: {slug}
|
||||
|
||||
**Status**: planning | ready | in-flight | landed | completed | aborted
|
||||
**Flight**: [{Flight Title}](../flight.md)
|
||||
|
||||
## Objective
|
||||
Single sentence: what this leg accomplishes.
|
||||
|
||||
## Context
|
||||
- Relevant design decisions from the flight
|
||||
- How this fits into the broader technical approach
|
||||
- Key learnings from prior legs (from flight log)
|
||||
|
||||
## Inputs
|
||||
What exists before this leg runs:
|
||||
- Files that must exist
|
||||
- State that must be true
|
||||
|
||||
## Outputs
|
||||
What exists after this leg completes:
|
||||
- Files created or modified
|
||||
- State changes
|
||||
|
||||
## Acceptance Criteria
|
||||
- [ ] Criterion 1 (specific, observable)
|
||||
- [ ] Criterion 2
|
||||
- [ ] Criterion 3
|
||||
|
||||
## Verification Steps
|
||||
How to confirm each criterion is met:
|
||||
- {Command or manual check for criterion 1}
|
||||
- {Command or manual check for criterion 2}
|
||||
|
||||
## Implementation Guidance
|
||||
|
||||
1. **{First step}**
|
||||
- Details about what to do
|
||||
|
||||
2. **{Second step}**
|
||||
- Details
|
||||
|
||||
## Edge Cases
|
||||
- **{Edge case 1}**: How to handle
|
||||
|
||||
## Files Affected
|
||||
- `path/to/file.ext` - {What changes}
|
||||
|
||||
---
|
||||
|
||||
## Post-Completion Checklist
|
||||
|
||||
**Complete ALL steps before signaling `[COMPLETE:leg]`:**
|
||||
|
||||
- [ ] All acceptance criteria verified
|
||||
- [ ] Tests passing
|
||||
- [ ] Update flight-log.md with leg progress entry
|
||||
- [ ] Set this leg's status to `completed` (in this file's header)
|
||||
- [ ] Check off this leg in flight.md
|
||||
- [ ] If final leg of flight:
|
||||
- [ ] Update flight.md status to `landed`
|
||||
- [ ] Check off flight in mission.md
|
||||
- [ ] Commit all changes together (code + artifacts)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Supporting Artifacts
|
||||
|
||||
### Flight Log
|
||||
|
||||
| Property | Value |
|
||||
|----------|-------|
|
||||
| Location | `missions/{mission}/flights/{flight}/flight-log.md` |
|
||||
| Created | When flight is created |
|
||||
| Updated | Continuously during execution (append-only) |
|
||||
|
||||
**Format:**
|
||||
|
||||
```markdown
|
||||
# Flight Log: {Flight Title}
|
||||
|
||||
**Flight**: [{Flight Title}](flight.md)
|
||||
|
||||
## Summary
|
||||
Brief overview of execution status and key outcomes.
|
||||
|
||||
---
|
||||
|
||||
## Leg Progress
|
||||
|
||||
### {Leg Name}
|
||||
**Status**: completed | landed | in-flight | aborted
|
||||
**Started**: {timestamp}
|
||||
**Completed**: {timestamp}
|
||||
|
||||
#### Changes Made
|
||||
- {Summary of what was implemented}
|
||||
|
||||
#### Notes
|
||||
{Observations during execution}
|
||||
|
||||
---
|
||||
|
||||
## Decisions
|
||||
Runtime decisions not in original plan.
|
||||
|
||||
### {Decision Title}
|
||||
**Context**: Why needed
|
||||
**Decision**: What was chosen
|
||||
**Impact**: Effect on flight or future legs
|
||||
|
||||
---
|
||||
|
||||
## Deviations
|
||||
Departures from planned approach.
|
||||
|
||||
### {Deviation Title}
|
||||
**Planned**: What the flight specified
|
||||
**Actual**: What was done instead
|
||||
**Reason**: Why the deviation was necessary
|
||||
|
||||
---
|
||||
|
||||
## Anomalies
|
||||
Unexpected issues encountered.
|
||||
|
||||
### {Anomaly Title}
|
||||
**Observed**: What happened
|
||||
**Severity**: blocking | degraded | cosmetic
|
||||
**Resolution**: How handled or "unresolved"
|
||||
|
||||
---
|
||||
|
||||
## Session Notes
|
||||
Chronological notes from work sessions.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Flight Briefing
|
||||
|
||||
| Property | Value |
|
||||
|----------|-------|
|
||||
| Location | `missions/{mission}/flights/{flight}/flight-briefing.md` |
|
||||
| Created | Before flight execution begins |
|
||||
| Purpose | Pre-flight summary for crew alignment |
|
||||
|
||||
**Format:**
|
||||
|
||||
```markdown
|
||||
# Flight Briefing: {Flight Title}
|
||||
|
||||
**Date**: {briefing date}
|
||||
**Flight**: [{Flight Title}](flight.md)
|
||||
**Status**: Flight is ready for execution
|
||||
|
||||
## Mission Context
|
||||
{Brief reminder of mission outcome and how this flight contributes}
|
||||
|
||||
## Objective
|
||||
{What this flight will accomplish}
|
||||
|
||||
## Key Decisions
|
||||
{Summary of critical design decisions crew should know}
|
||||
|
||||
## Risks and Mitigations
|
||||
| Risk | Mitigation |
|
||||
|------|------------|
|
||||
| {risk} | {mitigation} |
|
||||
|
||||
## Legs Overview
|
||||
1. `{leg-slug}` - {description} - {estimated complexity}
|
||||
2. `{leg-slug}` - {description} - {estimated complexity}
|
||||
|
||||
## Environment Requirements
|
||||
{Any special setup needed before starting}
|
||||
|
||||
## Success Criteria
|
||||
{How we'll know the flight succeeded}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Flight Debrief
|
||||
|
||||
| Property | Value |
|
||||
|----------|-------|
|
||||
| Location | `missions/{mission}/flights/{flight}/flight-debrief.md` |
|
||||
| Created | After flight lands or diverts |
|
||||
| Purpose | Post-flight analysis and lessons learned |
|
||||
|
||||
**Format:**
|
||||
|
||||
```markdown
|
||||
# Flight Debrief: {Flight Title}
|
||||
|
||||
**Date**: {debrief date}
|
||||
**Flight**: [{Flight Title}](flight.md)
|
||||
**Status**: {landed | aborted}
|
||||
**Duration**: {start} - {end}
|
||||
**Legs Completed**: {X of Y}
|
||||
|
||||
## Outcome Assessment
|
||||
|
||||
### Objectives Achieved
|
||||
{What the flight accomplished}
|
||||
|
||||
### Mission Criteria Advanced
|
||||
{Which success criteria this flight contributed to}
|
||||
|
||||
## What Went Well
|
||||
{Specific things that worked effectively}
|
||||
|
||||
## What Could Be Improved
|
||||
|
||||
### Process
|
||||
- {Recommendations for flight execution}
|
||||
|
||||
### Technical
|
||||
- {Code quality, architecture, debt}
|
||||
|
||||
### Documentation
|
||||
- {Gaps identified}
|
||||
|
||||
## Deviations and Lessons Learned
|
||||
|
||||
| Deviation | Reason | Standardize? |
|
||||
|-----------|--------|--------------|
|
||||
| {what changed} | {why} | {yes/no} |
|
||||
|
||||
## Key Learnings
|
||||
{Insights for future flights}
|
||||
|
||||
## Recommendations
|
||||
1. {Most impactful recommendation}
|
||||
2. {Second recommendation}
|
||||
3. {Third recommendation}
|
||||
|
||||
## Action Items
|
||||
- [ ] {Immediate actions}
|
||||
- [ ] {Near-term improvements}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Mission Debrief
|
||||
|
||||
| Property | Value |
|
||||
|----------|-------|
|
||||
| Location | `missions/{NN}-{mission}/mission-debrief.md` |
|
||||
| Created | After mission completes or aborts |
|
||||
| Purpose | Post-mission retrospective and methodology improvements |
|
||||
|
||||
**Format:**
|
||||
|
||||
```markdown
|
||||
# Mission Debrief: {Mission Title}
|
||||
|
||||
**Date**: {debrief date}
|
||||
**Mission**: [{Mission Title}](mission.md)
|
||||
**Status**: {completed | aborted}
|
||||
**Duration**: {start} - {end}
|
||||
**Flights Completed**: {X of Y}
|
||||
|
||||
## Outcome Assessment
|
||||
|
||||
### Success Criteria Results
|
||||
| Criterion | Status | Notes |
|
||||
|-----------|--------|-------|
|
||||
| {criterion} | {met/not met} | {notes} |
|
||||
|
||||
### Overall Outcome
|
||||
{Did we achieve what we set out to do?}
|
||||
|
||||
## Flight Summary
|
||||
| Flight | Status | Key Outcome |
|
||||
|--------|--------|-------------|
|
||||
| {flight} | {landed/aborted} | {outcome} |
|
||||
|
||||
## What Went Well
|
||||
{Effective patterns and successes}
|
||||
|
||||
## What Could Be Improved
|
||||
{Process, planning, execution improvements}
|
||||
|
||||
## Lessons Learned
|
||||
{Insights to carry forward}
|
||||
|
||||
## Methodology Feedback
|
||||
{Improvements to Flight Control process itself}
|
||||
|
||||
## Action Items
|
||||
- [ ] {Follow-up work}
|
||||
- [ ] {Process improvements}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Maintenance Report
|
||||
|
||||
| Property | Value |
|
||||
|----------|-------|
|
||||
| Location | `maintenance/{YYYY-MM-DD}.md` |
|
||||
| Created | After a mission or ad-hoc, during routine maintenance |
|
||||
| Purpose | Codebase health assessment and maintenance recommendation |
|
||||
|
||||
**Format:**
|
||||
|
||||
```markdown
|
||||
# Maintenance Report: {YYYY-MM-DD}
|
||||
|
||||
**Date**: {report date}
|
||||
**Triggered by**: [{Mission Title}](missions/{NN}-{slug}/mission.md) *(optional — omit if ad-hoc)*
|
||||
**Assessment**: {Flight Ready | Maintenance Required}
|
||||
|
||||
## Categories Inspected
|
||||
{Numbered list of categories that were checked}
|
||||
|
||||
## Executive Summary
|
||||
{2-3 sentence overview of codebase health and key findings}
|
||||
|
||||
## Findings by Category
|
||||
|
||||
### Category {N}: {Name}
|
||||
|
||||
| # | Finding | Severity | New/Known | Recommendation |
|
||||
|---|---------|----------|-----------|----------------|
|
||||
| {n} | {title} | {severity} | {new/known} | {recommendation} |
|
||||
|
||||
**Details:**
|
||||
{Per-finding evidence with file paths and line numbers}
|
||||
|
||||
## Severity Summary
|
||||
|
||||
| Severity | Count |
|
||||
|----------|-------|
|
||||
| Critical | {N} |
|
||||
| Action Required | {N} |
|
||||
| Advisory | {N} |
|
||||
| Pass | {N} |
|
||||
|
||||
## Known Debt Carried Forward
|
||||
{Debt items from debriefs that were acknowledged but not addressed, or "None — no prior debt context"}
|
||||
|
||||
## Recommendations
|
||||
1. {Most impactful recommendation}
|
||||
2. {Second recommendation}
|
||||
3. {Third recommendation}
|
||||
|
||||
## Maintenance Mission
|
||||
{Link to scaffolded mission if created, or "Not required — codebase is flight ready"}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## State Tracking
|
||||
|
||||
States are tracked in the frontmatter or status field of each artifact:
|
||||
|
||||
| Artifact | States |
|
||||
|----------|--------|
|
||||
| Mission | `planning` → `active` → `completed` (or `aborted`) |
|
||||
| Flight | `planning` → `ready` → `in-flight` → `landed` → `completed` (or `aborted`) |
|
||||
| Leg | `planning` → `ready` → `in-flight` → `landed` → `completed` (or `aborted`) |
|
||||
|
||||
## Conventions
|
||||
|
||||
- **Immutability**: Never modify legs once `in-flight`; create new ones instead
|
||||
- **Append-only logs**: Flight logs are append-only during execution
|
||||
- **Flight briefings**: Created before execution, not modified after
|
||||
- **Debriefs**: Created after completion, may be updated with follow-up notes
|
||||
- **Mission as briefing**: The mission.md document serves as both definition and briefing (no separate mission-briefing.md)
|
||||
|
||||
## Git Workflow
|
||||
|
||||
| Property | Value |
|
||||
|----------|-------|
|
||||
| Strategy | `branch` |
|
||||
|
||||
**Options:**
|
||||
|
||||
- **`branch`** (default) — Single-checkout workflow. The orchestrator creates a feature branch and all agents work in the project root. One flight at a time per working copy.
|
||||
- **`worktree`** — Worktree isolation. The orchestrator creates a git worktree under `.worktrees/` for each flight. Agents work in the worktree path. Parallel flights are possible on a single repo clone.
|
||||
|
||||
When using the `worktree` strategy, add `.worktrees/` to `.gitignore`.
|
||||
@@ -0,0 +1,408 @@
|
||||
# Artifact System: Jira
|
||||
|
||||
This project stores Flight Control artifacts as Jira issues.
|
||||
|
||||
## Issue Type Mapping
|
||||
|
||||
| Flight Control | Jira Issue Type | Hierarchy |
|
||||
|----------------|-----------------|-----------|
|
||||
| Mission | Epic | Parent |
|
||||
| Flight | Story | Child of Epic |
|
||||
| Leg | Sub-task | Child of Story |
|
||||
|
||||
## Setup Questions
|
||||
|
||||
Answer these questions when configuring Jira artifacts for your project:
|
||||
|
||||
| Question | Answer |
|
||||
|----------|--------|
|
||||
| What is the Jira project key? | `PROJECT` |
|
||||
| JQL query for discovering flight documentation? | (e.g., `project = PROJECT AND labels = flight-control`) |
|
||||
|
||||
## Configuration
|
||||
|
||||
| Property | Value |
|
||||
|----------|-------|
|
||||
| Project Key | `PROJECT` |
|
||||
| Board | (specify board name or ID) |
|
||||
| Labels | `flight-control` |
|
||||
|
||||
---
|
||||
|
||||
## Custom Fields
|
||||
|
||||
<!-- Add your project's custom Jira fields here -->
|
||||
|
||||
| Custom Field | Jira Field ID | Required | Used For | Notes |
|
||||
|--------------|---------------|----------|----------|-------|
|
||||
| (example) Team | `customfield_10001` | Yes | All issues | Select from predefined teams |
|
||||
| (example) Sprint | `customfield_10002` | No | Stories, Sub-tasks | Assign to sprint |
|
||||
|
||||
## Project Rules
|
||||
|
||||
<!-- Document project-specific Jira rules and conventions here -->
|
||||
|
||||
### Required Fields by Issue Type
|
||||
|
||||
**Epic (Mission):**
|
||||
- (list required fields for your project)
|
||||
|
||||
**Story (Flight):**
|
||||
- (list required fields for your project)
|
||||
|
||||
**Sub-task (Leg):**
|
||||
- (list required fields for your project)
|
||||
|
||||
### Workflow Rules
|
||||
|
||||
- (document any workflow restrictions or automation rules)
|
||||
- (e.g., "Stories cannot move to In Progress without Epic Link")
|
||||
|
||||
### Naming Conventions
|
||||
|
||||
- (document any naming patterns required by your project)
|
||||
- (e.g., "Epic summaries must start with [MISSION]")
|
||||
|
||||
---
|
||||
|
||||
## Core Artifacts
|
||||
|
||||
### Mission → Epic
|
||||
|
||||
| Field | Mapping |
|
||||
|-------|---------|
|
||||
| Summary | Mission title |
|
||||
| Description | See format below |
|
||||
| Labels | `flight-control`, `mission` |
|
||||
|
||||
**Description Format:**
|
||||
|
||||
```
|
||||
## Outcome
|
||||
{What success looks like in human terms}
|
||||
|
||||
## Context
|
||||
{Why this mission matters now}
|
||||
|
||||
## Success Criteria
|
||||
- [ ] {Criterion 1}
|
||||
- [ ] {Criterion 2}
|
||||
|
||||
## Stakeholders
|
||||
{Who cares about this outcome}
|
||||
|
||||
## Constraints
|
||||
{Non-negotiable boundaries}
|
||||
|
||||
## Environment Requirements
|
||||
{Development and runtime requirements}
|
||||
|
||||
## Open Questions
|
||||
{Unknowns needing resolution}
|
||||
|
||||
## Known Issues
|
||||
Emergent blockers and issues discovered during execution. Add items here as flights surface problems that affect the broader mission — things not anticipated during planning but visible at the mission level.
|
||||
|
||||
- [ ] {Issue description} — discovered in Flight {N}, affects {scope}
|
||||
|
||||
## Flights
|
||||
> **Note:** These are tentative suggestions, not commitments. Flights are planned and created one at a time as work progresses. This list will evolve based on discoveries during implementation.
|
||||
|
||||
- [ ] Flight 1: {description}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Flight → Story
|
||||
|
||||
| Field | Mapping |
|
||||
|-------|---------|
|
||||
| Summary | Flight title |
|
||||
| Description | See format below |
|
||||
| Epic Link | Parent mission epic |
|
||||
| Labels | `flight-control`, `flight` |
|
||||
|
||||
**Description Format:**
|
||||
|
||||
```
|
||||
## Objective
|
||||
{What this flight accomplishes}
|
||||
|
||||
## Contributing to Criteria
|
||||
- {Relevant success criterion 1}
|
||||
- {Relevant success criterion 2}
|
||||
|
||||
## Design Decisions
|
||||
{Key technical decisions and rationale}
|
||||
|
||||
## Prerequisites
|
||||
- [ ] {What must be true before execution}
|
||||
|
||||
## Technical Approach
|
||||
{How the objective will be achieved}
|
||||
|
||||
## Legs
|
||||
> **Note:** These are tentative suggestions, not commitments. Legs are planned and created one at a time as the flight progresses. This list will evolve based on discoveries during implementation.
|
||||
|
||||
- [ ] {leg-slug} - {description}
|
||||
|
||||
## Validation Approach
|
||||
{How will this flight be validated? Manual testing, automated tests, or both?}
|
||||
|
||||
## Verification
|
||||
{How to confirm success}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Leg → Sub-task
|
||||
|
||||
| Field | Mapping |
|
||||
|-------|---------|
|
||||
| Summary | Leg title |
|
||||
| Description | See format below |
|
||||
| Parent | Flight story |
|
||||
| Labels | `flight-control`, `leg` |
|
||||
|
||||
**Description Format:**
|
||||
|
||||
```
|
||||
## Objective
|
||||
{Single sentence: what this leg accomplishes}
|
||||
|
||||
## Context
|
||||
{Design decisions and learnings from prior legs}
|
||||
|
||||
## Inputs
|
||||
{What must exist before this leg runs}
|
||||
|
||||
## Outputs
|
||||
{What exists after completion}
|
||||
|
||||
## Acceptance Criteria
|
||||
- [ ] {Criterion 1}
|
||||
- [ ] {Criterion 2}
|
||||
|
||||
## Verification Steps
|
||||
How to confirm each criterion is met:
|
||||
- {Command or manual check for criterion 1}
|
||||
- {Command or manual check for criterion 2}
|
||||
|
||||
## Implementation Guidance
|
||||
{Step-by-step guidance}
|
||||
|
||||
## Files Affected
|
||||
{List of files to modify}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Supporting Artifacts
|
||||
|
||||
### Flight Log → Story Comments
|
||||
|
||||
| Property | Value |
|
||||
|----------|-------|
|
||||
| Location | Comments on the Flight (Story) |
|
||||
| Format | Timestamped comments with prefix |
|
||||
| Update pattern | Append new comments during execution |
|
||||
|
||||
**Comment Format:**
|
||||
|
||||
```
|
||||
[Flight Log] {YYYY-MM-DD HH:MM}
|
||||
|
||||
## {Entry Type}: {Title}
|
||||
|
||||
{Content based on entry type - see below}
|
||||
```
|
||||
|
||||
**Entry Types:**
|
||||
|
||||
- `Leg Progress` - Status updates for leg completion
|
||||
- `Decision` - Runtime decisions not in original plan
|
||||
- `Deviation` - Departures from planned approach
|
||||
- `Anomaly` - Unexpected issues encountered
|
||||
- `Session Notes` - General progress notes
|
||||
|
||||
---
|
||||
|
||||
### Flight Briefing → Story Comment
|
||||
|
||||
| Property | Value |
|
||||
|----------|-------|
|
||||
| Location | Comment on the Flight (Story) |
|
||||
| Created | Before flight execution begins |
|
||||
| Label | `[Flight Briefing]` |
|
||||
|
||||
**Comment Format:**
|
||||
|
||||
```
|
||||
[Flight Briefing] {YYYY-MM-DD}
|
||||
|
||||
## Mission Context
|
||||
{How this flight contributes to mission}
|
||||
|
||||
## Objective
|
||||
{What this flight will accomplish}
|
||||
|
||||
## Key Decisions
|
||||
{Critical decisions crew should know}
|
||||
|
||||
## Risks
|
||||
| Risk | Mitigation |
|
||||
|------|------------|
|
||||
| {risk} | {mitigation} |
|
||||
|
||||
## Legs Overview
|
||||
1. {leg} - {description}
|
||||
2. {leg} - {description}
|
||||
|
||||
## Success Criteria
|
||||
{How we'll know the flight succeeded}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Flight Debrief → Story Comment
|
||||
|
||||
| Property | Value |
|
||||
|----------|-------|
|
||||
| Location | Comment on the Flight (Story) |
|
||||
| Created | After flight lands or diverts |
|
||||
| Label | `[Flight Debrief]` |
|
||||
|
||||
**Comment Format:**
|
||||
|
||||
```
|
||||
[Flight Debrief] {YYYY-MM-DD}
|
||||
|
||||
**Status**: {landed | aborted}
|
||||
**Duration**: {start} - {end}
|
||||
**Legs Completed**: {X of Y}
|
||||
|
||||
## Outcome Assessment
|
||||
{What the flight accomplished}
|
||||
|
||||
## What Went Well
|
||||
{Effective patterns}
|
||||
|
||||
## What Could Be Improved
|
||||
{Recommendations}
|
||||
|
||||
## Deviations
|
||||
| Deviation | Reason | Standardize? |
|
||||
|-----------|--------|--------------|
|
||||
| {what} | {why} | {yes/no} |
|
||||
|
||||
## Key Learnings
|
||||
{Insights for future flights}
|
||||
|
||||
## Recommendations
|
||||
1. {Most impactful recommendation}
|
||||
2. {Second recommendation}
|
||||
3. {Third recommendation}
|
||||
|
||||
## Action Items
|
||||
- [ ] {action}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Mission Debrief → Epic Comment
|
||||
|
||||
| Property | Value |
|
||||
|----------|-------|
|
||||
| Location | Comment on the Mission (Epic) |
|
||||
| Created | After mission completes or aborts |
|
||||
| Label | `[Mission Debrief]` |
|
||||
|
||||
**Comment Format:**
|
||||
|
||||
```
|
||||
[Mission Debrief] {YYYY-MM-DD}
|
||||
|
||||
**Status**: {completed | aborted}
|
||||
**Duration**: {start} - {end}
|
||||
**Flights Completed**: {X of Y}
|
||||
|
||||
## Success Criteria Results
|
||||
| Criterion | Status | Notes |
|
||||
|-----------|--------|-------|
|
||||
| {criterion} | {met/not met} | {notes} |
|
||||
|
||||
## Flight Summary
|
||||
| Flight | Status | Outcome |
|
||||
|--------|--------|---------|
|
||||
| {flight} | {status} | {outcome} |
|
||||
|
||||
## What Went Well
|
||||
{Successes}
|
||||
|
||||
## What Could Be Improved
|
||||
{Improvements}
|
||||
|
||||
## Lessons Learned
|
||||
{Insights}
|
||||
|
||||
## Action Items
|
||||
- [ ] {action}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## State Mapping
|
||||
|
||||
### Mission (Epic)
|
||||
|
||||
| Flight Control | Jira Status |
|
||||
|----------------|-------------|
|
||||
| planning | To Do |
|
||||
| active | In Progress |
|
||||
| completed | Done |
|
||||
| aborted | Cancelled |
|
||||
|
||||
### Flight (Story)
|
||||
|
||||
| Flight Control | Jira Status |
|
||||
|----------------|-------------|
|
||||
| planning | To Do |
|
||||
| ready | Ready |
|
||||
| in-flight | In Progress |
|
||||
| landed | In Review |
|
||||
| completed | Done |
|
||||
| aborted | Cancelled |
|
||||
|
||||
### Leg (Sub-task)
|
||||
|
||||
| Flight Control | Jira Status |
|
||||
|----------------|-------------|
|
||||
| planning | To Do |
|
||||
| ready | Ready |
|
||||
| in-flight | In Progress |
|
||||
| landed | In Review |
|
||||
| completed | Done |
|
||||
| aborted | Cancelled |
|
||||
|
||||
---
|
||||
|
||||
## Conventions
|
||||
|
||||
- **Naming**: Use clear, action-oriented summaries
|
||||
- **Linking**: Always link Stories to Epic, Sub-tasks to Story
|
||||
- **Labels**: Apply `flight-control` label to all artifacts
|
||||
- **Immutability**: Never modify Sub-tasks once In Progress; create new ones
|
||||
- **Comments**: Use prefixes (`[Flight Log]`, `[Flight Briefing]`, etc.) for filtering
|
||||
|
||||
## Git Workflow
|
||||
|
||||
| Property | Value |
|
||||
|----------|-------|
|
||||
| Strategy | `branch` |
|
||||
|
||||
**Options:**
|
||||
|
||||
- **`branch`** (default) — Single-checkout workflow. The orchestrator creates a feature branch and all agents work in the project root. One flight at a time per working copy.
|
||||
- **`worktree`** — Worktree isolation. The orchestrator creates a git worktree under `.worktrees/` for each flight. Agents work in the worktree path. Parallel flights are possible on a single repo clone.
|
||||
|
||||
When using the `worktree` strategy, add `.worktrees/` to `.gitignore`.
|
||||
177
container/mission-control/.claude/skills/leg/SKILL.md
Normal file
177
container/mission-control/.claude/skills/leg/SKILL.md
Normal file
@@ -0,0 +1,177 @@
|
||||
---
|
||||
name: leg
|
||||
description: Generate detailed implementation guidance for LLM execution. Use when creating atomic implementation steps from a flight.
|
||||
---
|
||||
|
||||
# Leg Implementation Guidance
|
||||
|
||||
Generate detailed implementation guidance for LLM execution.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- Project must be initialized with `/init-project` (`.flightops/ARTIFACTS.md` must exist)
|
||||
- A flight must exist before creating legs
|
||||
|
||||
## 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. **Read the parent flight**
|
||||
- Understand the objective being achieved
|
||||
- Review design decisions and constraints
|
||||
- Note the technical approach defined
|
||||
|
||||
5. **Read the flight log in detail** (critical)
|
||||
|
||||
The flight log captures ground truth from actual implementation. Read it fully and extract:
|
||||
- Actual outcomes from completed legs
|
||||
- Deviations from the original plan
|
||||
- Anomalies discovered during execution
|
||||
- Environment details (versions, configurations)
|
||||
- Decisions made during implementation
|
||||
- Workarounds for issues encountered
|
||||
|
||||
6. **Identify this leg's scope**
|
||||
- Which leg from the flight's leg list?
|
||||
- What comes before and after?
|
||||
- Dependencies on other legs?
|
||||
- How do prior leg outcomes affect this leg?
|
||||
|
||||
7. **Identify environment constraints**
|
||||
- Execution environment (devcontainer, WSL, cloud)?
|
||||
- User context (root, specific user)?
|
||||
- Environment variables or shell setup needed?
|
||||
- Commands inside vs outside containers?
|
||||
|
||||
### Phase 2: Implementation Analysis
|
||||
|
||||
Deep dive into the specific implementation:
|
||||
|
||||
1. **Identify exact files to modify**
|
||||
- Read existing files that will be changed
|
||||
- Understand current code structure
|
||||
- Note imports, dependencies, patterns
|
||||
|
||||
2. **Understand existing patterns**
|
||||
- How is similar functionality implemented?
|
||||
- What conventions does the codebase follow?
|
||||
- What testing patterns are used?
|
||||
|
||||
3. **Determine inputs and outputs**
|
||||
- What state exists before this leg?
|
||||
- What state must exist after completion?
|
||||
- What can the implementing agent assume?
|
||||
|
||||
4. **Identify edge cases**
|
||||
- What could go wrong?
|
||||
- What validation is needed?
|
||||
- What error handling is required?
|
||||
- If this leg modifies database schemas: does it include migration creation AND execution? Both must happen in the same leg — a schema defined but never migrated is a gap.
|
||||
|
||||
5. **Identify dependent code** (for interface changes)
|
||||
- Does this leg modify shared interfaces?
|
||||
- What files consume these interfaces?
|
||||
- Should updating consumers be part of this leg?
|
||||
|
||||
6. **Identify platform considerations**
|
||||
- Does this leg touch OS-specific features?
|
||||
- What platform differences might affect implementation?
|
||||
|
||||
### Phase 3: Guidance Generation
|
||||
|
||||
Create the leg artifact using the format defined in `.flightops/ARTIFACTS.md`.
|
||||
|
||||
## Guidelines
|
||||
|
||||
### Writing Effective Objectives
|
||||
|
||||
State exactly what the leg accomplishes:
|
||||
|
||||
**Weak**: "Set up the database stuff"
|
||||
|
||||
**Strong**: "Create the User model with email, password_hash, and timestamp fields"
|
||||
|
||||
### Acceptance Criteria
|
||||
|
||||
Criteria must be:
|
||||
- **Binary**: Either met or not met
|
||||
- **Observable**: Can be verified by inspection or test
|
||||
- **Complete**: Nothing else needed for "done"
|
||||
|
||||
**Weak**: "Code is clean" (subjective)
|
||||
|
||||
**Strong**: "User model exists in `prisma/schema.prisma`"
|
||||
|
||||
### Verification Steps
|
||||
|
||||
Tell the agent exactly *how* to confirm each criterion:
|
||||
|
||||
**Weak**: "Make sure it works"
|
||||
|
||||
**Strong**:
|
||||
```markdown
|
||||
## Verification Steps
|
||||
- Run `npx prisma migrate status` — should show no pending migrations
|
||||
- Run `npm test` — all tests pass
|
||||
- Tab through form fields — focus order matches visual order
|
||||
```
|
||||
|
||||
For accessibility work, include specific checks:
|
||||
- Keyboard navigation sequences
|
||||
- Screen reader commands to test
|
||||
- Automated tool commands (Lighthouse, axe-core)
|
||||
|
||||
### Implementation Guidance
|
||||
|
||||
Be explicit, not implicit:
|
||||
|
||||
**Implicit**: "Add validation to the email field"
|
||||
|
||||
**Explicit**: "Add email validation using the `validator` library's `isEmail` function. Return HTTP 400 with `{ "error": "Invalid email format" }` on validation failure."
|
||||
|
||||
### Code Examples
|
||||
|
||||
Provide examples when:
|
||||
- The codebase has specific patterns to follow
|
||||
- There are multiple valid approaches
|
||||
- The implementation isn't obvious from context
|
||||
|
||||
### Leg Sizing
|
||||
|
||||
A well-sized leg:
|
||||
- Takes minutes to a few hours
|
||||
- Is atomic (can be completed independently)
|
||||
- Has clear, verifiable acceptance criteria
|
||||
- Produces a working increment
|
||||
|
||||
**Too small**: Single-line change with no meaningful criteria
|
||||
**Too large**: Would benefit from intermediate checkpoints
|
||||
|
||||
### Documenting Workarounds
|
||||
|
||||
When implementing a workaround, document:
|
||||
- **What**: The workaround clearly
|
||||
- **Why**: Why the ideal solution wasn't feasible
|
||||
- **When to remove**: Condition for replacement
|
||||
|
||||
### Immutability
|
||||
|
||||
Once a leg is `in-flight`:
|
||||
- Do NOT modify the leg document
|
||||
- If requirements change, mark it `aborted` (changes rolled back)
|
||||
- Create a new leg with updated requirements
|
||||
|
||||
## Output
|
||||
|
||||
Create the leg artifact using the location and format defined in `.flightops/ARTIFACTS.md`.
|
||||
@@ -0,0 +1,184 @@
|
||||
---
|
||||
name: mission-debrief
|
||||
description: Post-mission retrospective for outcomes assessment and methodology improvement. Use after a mission completes or aborts to capture overall lessons learned.
|
||||
---
|
||||
|
||||
# Mission Debrief
|
||||
|
||||
Perform comprehensive post-mission retrospective and methodology assessment.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- Project must be initialized with `/init-project` (`.flightops/ARTIFACTS.md` must exist)
|
||||
- A mission must have at least one completed or aborted flight 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 mission documentation**
|
||||
- Read the mission for original outcome, success criteria, and constraints
|
||||
- Read ALL flight documents for objectives and results
|
||||
- Read ALL flight debriefs for per-flight lessons learned
|
||||
- Read flight logs for execution details
|
||||
|
||||
5. **Load project context**
|
||||
- Read the target project's `README.md` and `CLAUDE.md`
|
||||
- Understand what was built during this mission
|
||||
|
||||
### Phase 2: Crew Debrief Interviews
|
||||
|
||||
Read `{target-project}/.flightops/agent-crews/mission-debrief.md` for crew definitions and prompts (fall back to defaults at `.claude/skills/init-project/defaults/agent-crews/mission-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 `mission-debrief.md` is missing required sections. Either fix it manually or re-run `/init-project` to reset to defaults."
|
||||
|
||||
#### Architect Interview
|
||||
1. **Spawn an Architect agent** in the target project context (Task tool, `subagent_type: "general-purpose"`)
|
||||
- Provide the "Debrief Interview" prompt from the mission-debrief phase file's Prompts section
|
||||
- The Architect reviews architectural evolution across all flights, pattern consistency, and structural health
|
||||
- The Architect provides structured debrief input
|
||||
|
||||
#### Human Interview
|
||||
Interview the crew to capture qualitative insights that documents alone cannot reveal.
|
||||
|
||||
##### Flight Log Clarifications
|
||||
Surface specific observations from flight logs and ask for context:
|
||||
- Anomalies or deviations noted in logs — what caused them?
|
||||
- Decisions made during execution — what drove those choices?
|
||||
- Blockers or delays — were these predictable in hindsight?
|
||||
- Workarounds implemented — should these become standard practice?
|
||||
|
||||
##### Mission Control Experience
|
||||
For the human(s) who served as mission control:
|
||||
- "What was your experience coordinating this mission?"
|
||||
- "Were there moments of confusion or uncertainty about status?"
|
||||
- "Did the flight/leg structure help or hinder your oversight?"
|
||||
- "What information was missing when you needed it?"
|
||||
|
||||
##### Project-Specific Feedback
|
||||
- "What surprised you most during this mission?"
|
||||
- "What would you do differently if starting over?"
|
||||
- "Are there project-specific conventions that should be documented?"
|
||||
- "Did any tools, libraries, or patterns prove particularly valuable or problematic?"
|
||||
|
||||
##### Agentic Orchestration Feedback (if applicable)
|
||||
If the mission used automated orchestration (LLM agents executing legs):
|
||||
- "How well did handoffs between agents work?"
|
||||
- "Were there failures in agent coordination or context transfer?"
|
||||
- "Did agents make decisions that required human correction?"
|
||||
- "What guardrails or checkpoints would have helped?"
|
||||
- "Was the level of autonomy appropriate for the tasks?"
|
||||
|
||||
**Note**: Adapt questions based on what the flight logs and artifacts reveal. Surface specific examples rather than asking in the abstract.
|
||||
|
||||
### Phase 3: Outcome Assessment (synthesize Architect + human input)
|
||||
|
||||
#### Success Criteria Evaluation
|
||||
For each success criterion:
|
||||
- Was it met? Partially met? Not met?
|
||||
- What evidence supports this assessment?
|
||||
- If not met, what blocked it?
|
||||
|
||||
#### Overall Outcome
|
||||
- Did the mission achieve its stated outcome?
|
||||
- Was the outcome still the right goal by the end?
|
||||
- What value was delivered to stakeholders?
|
||||
|
||||
### Phase 4: Flight Analysis
|
||||
|
||||
#### Flight Summary
|
||||
For each flight:
|
||||
- Status (landed/completed/aborted)
|
||||
- Key accomplishments
|
||||
- Major challenges
|
||||
|
||||
#### Flight Patterns
|
||||
- Which flights went smoothly? Why?
|
||||
- Which flights struggled? Why?
|
||||
- Were there common issues across flights?
|
||||
|
||||
### Phase 5: Process Analysis
|
||||
|
||||
#### Planning Effectiveness
|
||||
- Was the initial flight plan accurate?
|
||||
- How many flights were added/removed/changed?
|
||||
- Were estimates reasonable?
|
||||
|
||||
#### Execution Patterns
|
||||
- What worked well in execution?
|
||||
- What friction points emerged?
|
||||
- Were the right artifacts being created?
|
||||
|
||||
#### Methodology Assessment
|
||||
- Did the mission/flight/leg hierarchy work for this project?
|
||||
- Were briefings and debriefs valuable?
|
||||
- What would you change about the process?
|
||||
|
||||
### Phase 6: Knowledge Capture
|
||||
|
||||
#### Lessons Learned
|
||||
- Technical lessons (architecture, patterns, tools)
|
||||
- Process lessons (planning, execution, communication)
|
||||
- Domain lessons (business logic, requirements)
|
||||
|
||||
#### Reusable Patterns
|
||||
- What patterns emerged that could be templated?
|
||||
- What conventions should be documented?
|
||||
|
||||
#### Documentation Updates
|
||||
- Does CLAUDE.md need updates?
|
||||
- Does README need updates?
|
||||
- Are there new runbooks or guides needed?
|
||||
|
||||
### Phase 7: Generate Debrief
|
||||
|
||||
Create the mission debrief artifact using the format defined in `.flightops/ARTIFACTS.md`.
|
||||
|
||||
### Phase 8: Mission Status Transition
|
||||
|
||||
If the mission is not already marked as `completed` or `aborted`, update the mission artifact's status to `completed`.
|
||||
|
||||
## Guidelines
|
||||
|
||||
### Holistic View
|
||||
Look at the mission as a whole, not just individual flights. Identify patterns and systemic issues.
|
||||
|
||||
### Stakeholder Perspective
|
||||
Frame outcomes in terms stakeholders care about. Did we deliver what was promised?
|
||||
|
||||
### Honest Assessment
|
||||
Be candid about what didn't work. The debrief is for learning, not for blame.
|
||||
|
||||
### Actionable Insights
|
||||
Every lesson should have a "so what?" — how should future missions be different?
|
||||
|
||||
### Methodology Feedback
|
||||
This is the best time to identify improvements to Flight Control itself.
|
||||
|
||||
### Interview Integration
|
||||
Weave interview insights throughout the debrief, not as a separate section. Crew perspectives should inform:
|
||||
- Why certain outcomes were achieved or missed
|
||||
- Root causes behind process friction
|
||||
- Context that flight logs alone cannot capture
|
||||
- Recommendations that reflect lived experience, not just document analysis
|
||||
|
||||
## Output
|
||||
|
||||
Create the debrief artifact using the location and format defined in `.flightops/ARTIFACTS.md`.
|
||||
|
||||
After creating the debrief, summarize:
|
||||
1. Overall mission outcome assessment
|
||||
2. Top 3 things that went well
|
||||
3. Top 3 things to improve
|
||||
4. Recommended methodology changes
|
||||
157
container/mission-control/.claude/skills/mission/SKILL.md
Normal file
157
container/mission-control/.claude/skills/mission/SKILL.md
Normal file
@@ -0,0 +1,157 @@
|
||||
---
|
||||
name: mission
|
||||
description: Create outcome-driven missions through research and user interview. Use when starting a new project, feature, or initiative that needs planning.
|
||||
---
|
||||
|
||||
# Mission Creation
|
||||
|
||||
Create a new mission through research and collaborative discovery.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- Project must be initialized with `/init-project` (`.flightops/ARTIFACTS.md` must exist)
|
||||
|
||||
## Workflow
|
||||
|
||||
### Phase 1: Research
|
||||
|
||||
Before asking questions, gather context:
|
||||
|
||||
1. **Identify the target project**
|
||||
- Read `projects.md` to find the project's path
|
||||
- If not listed, ask the user for details
|
||||
|
||||
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. **Explore the target project's codebase**
|
||||
- Project structure and architecture
|
||||
- Existing patterns and conventions
|
||||
- Related functionality
|
||||
|
||||
5. **Read existing documentation**
|
||||
- README and project docs
|
||||
- Any existing missions
|
||||
- Technical specs or design documents
|
||||
|
||||
6. **Search external sources if needed**
|
||||
- API documentation
|
||||
- Library documentation
|
||||
- Relevant patterns or best practices
|
||||
|
||||
### Phase 2: User Input
|
||||
|
||||
Before asking structured questions, share a brief summary of what you learned during research and prompt the user for open-ended input:
|
||||
|
||||
- "Here's what I've gathered about the project so far: [summary]. Before I ask specific questions, what are your thoughts on what this mission should include? Feel free to share goals, ideas, concerns, scope preferences — anything that should shape this mission."
|
||||
|
||||
Use the user's response to inform and focus the interview questions that follow.
|
||||
|
||||
### Phase 3: Interview
|
||||
|
||||
Ask about outcomes, not tasks. Focus on:
|
||||
|
||||
1. **Desired outcomes**
|
||||
- "What does success look like when this is done?"
|
||||
- "What problem does this solve for users/stakeholders?"
|
||||
- "How will you know this mission succeeded?"
|
||||
|
||||
2. **Stakeholders and their needs**
|
||||
- "Who benefits from this outcome?"
|
||||
- "Are there competing interests to balance?"
|
||||
- "Who needs to approve or review?"
|
||||
|
||||
3. **Constraints**
|
||||
- "What technical constraints exist?"
|
||||
- "Are there timeline or resource boundaries?"
|
||||
- "What's out of scope?"
|
||||
|
||||
4. **Success criteria**
|
||||
- "What specific, observable criteria indicate completion?"
|
||||
- "How will each criterion be verified?"
|
||||
- "Do any criteria name specific tools or technologies? Reframe as capabilities."
|
||||
- "Could each criterion be satisfied by more than one implementation approach?"
|
||||
|
||||
5. **Environment requirements**
|
||||
- "What development environment will be used?"
|
||||
- "Are there runtime dependencies?"
|
||||
- "What tooling versions are required?"
|
||||
|
||||
### Phase 4: Draft
|
||||
|
||||
Create the mission artifact using the format defined in `.flightops/ARTIFACTS.md`.
|
||||
|
||||
### Phase 4b: Technical Viability Check
|
||||
|
||||
Read `{target-project}/.flightops/agent-crews/mission-design.md` for crew definitions and prompts (fall back to defaults at `.claude/skills/init-project/defaults/agent-crews/mission-design.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 `mission-design.md` is missing required sections. Either fix it manually or re-run `/init-project` to reset to defaults."
|
||||
|
||||
1. **Spawn an Architect agent** in the target project context (Task tool, `subagent_type: "general-purpose"`)
|
||||
- Provide the "Validate Mission" prompt from the mission-design phase file's Prompts section
|
||||
- The Architect reviews the draft mission against the codebase, stack, and constraints
|
||||
- The Architect provides a structured assessment: feasible / feasible with caveats / not feasible
|
||||
2. **Incorporate feedback** — update the mission artifact to address issues raised
|
||||
- If not feasible: discuss with user, adjust scope or approach
|
||||
- If feasible with caveats: present caveats to user, adjust if needed
|
||||
3. **Human gives final sign-off** before proceeding
|
||||
|
||||
### Phase 5: Iterate
|
||||
|
||||
Present the draft and iterate:
|
||||
|
||||
1. Walk through each section with the user
|
||||
2. Validate success criteria are measurable
|
||||
3. Screen each criterion for technology names, tool names, config file paths, or specific libraries — reframe any that describe implementation rather than capability
|
||||
4. Confirm flight breakdown makes sense
|
||||
5. Refine until the user explicitly approves
|
||||
|
||||
## Guidelines
|
||||
|
||||
### Mission Sizing
|
||||
|
||||
A well-sized mission:
|
||||
- Takes days to weeks to complete
|
||||
- Spawns 5-7 flights typically
|
||||
- Represents a meaningful outcome stakeholders recognize
|
||||
- Has clear success criteria
|
||||
|
||||
**Too small**: Can be completed in a single flight
|
||||
**Too large**: Success criteria are vague or numerous (>10)
|
||||
|
||||
### Outcome vs. Activity
|
||||
|
||||
Frame missions around results, not tasks:
|
||||
|
||||
**Activity-focused** (avoid):
|
||||
> Implement user authentication
|
||||
|
||||
**Outcome-focused** (prefer):
|
||||
> Users can securely access their personal data without sharing credentials
|
||||
|
||||
This applies equally to success criteria. Criteria that name specific tools or technologies constrain the solution space prematurely — if the prescribed tool doesn't work, the criteria become misaligned with reality.
|
||||
|
||||
**Implementation-specific criterion** (avoid):
|
||||
> OAuth tokens are stored in Redis with a 24-hour TTL
|
||||
|
||||
**Capability-focused criterion** (prefer):
|
||||
> Authenticated sessions persist across browser restarts for up to 24 hours
|
||||
|
||||
### Alignment Flight
|
||||
|
||||
During the interview phase, ask the user whether they'd like to include an alignment flight. Explain that this optional flight is a vibe coding session — the user and agent work together interactively, exploring the codebase, trying ideas, and making hands-on adjustments that benefit from human judgment and real-time feedback. It's a space for creative collaboration rather than structured execution. If the user opts in, include it in the suggested breakdown, marked as optional.
|
||||
|
||||
### Adaptive Planning
|
||||
|
||||
- Missions can be updated as understanding develops
|
||||
- New flights can be added during execution
|
||||
- Success criteria can be refined (with stakeholder agreement)
|
||||
|
||||
## Output
|
||||
|
||||
Create the mission artifact using the location and format defined in `.flightops/ARTIFACTS.md`.
|
||||
@@ -0,0 +1,117 @@
|
||||
---
|
||||
name: preflight-check
|
||||
description: Verify all registered projects have current methodology files and crew definitions. Reports status and offers to re-initialize projects that need it.
|
||||
---
|
||||
|
||||
# Preflight Check
|
||||
|
||||
Verify all registered projects have current Flight Control methodology files and crew definitions. Reports findings and offers to run `/init-project` on projects that need it.
|
||||
|
||||
## When to Use
|
||||
|
||||
- After updating methodology files or adding new skills to mission-control
|
||||
- After adding new default crew files
|
||||
- Periodically, to catch drift across managed projects
|
||||
- When onboarding a new team member who may have stale project setups
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- `projects.md` must exist (run `/init-mission-control` first)
|
||||
|
||||
## Workflow
|
||||
|
||||
### Phase 1: Load Projects Registry
|
||||
|
||||
1. **Read `projects.md`** to get the full list of managed projects
|
||||
2. Extract each project's slug, path, and description
|
||||
|
||||
### Phase 2: Check Each Project
|
||||
|
||||
For each project in the registry:
|
||||
|
||||
1. **Verify project path exists** — if the directory doesn't exist on disk, mark as `unreachable` and skip
|
||||
2. **Run the sync check**:
|
||||
```bash
|
||||
bash "${SKILL_DIR}/../init-project/check-sync.sh" \
|
||||
"${SKILL_DIR}/../init-project" \
|
||||
"{project-path}/.flightops"
|
||||
```
|
||||
3. **Parse the output** and classify the project:
|
||||
|
||||
| Status | Meaning | Action Needed |
|
||||
|--------|---------|---------------|
|
||||
| `missing` | No `.flightops/` directory | Needs `/init-project` |
|
||||
| `outdated` | Methodology files differ from source | Needs `/init-project` |
|
||||
| `current` | Methodology files match | None for methodology |
|
||||
| `agent-crews:missing` | No crew directory at all | Needs `/init-project` |
|
||||
| `agent-crews:empty` | Crew directory exists but empty | Needs `/init-project` |
|
||||
| `crew-missing:{file}` | Specific crew file missing (new skill) | Needs crew file added |
|
||||
| `legacy-layout:*` | Old directory naming detected | Needs migration via `/init-project` |
|
||||
|
||||
### Phase 3: Report
|
||||
|
||||
Present a summary table:
|
||||
|
||||
> **Project Sync Status**
|
||||
>
|
||||
> | Project | Path | Methodology | Crew | Issues |
|
||||
> |---------|------|-------------|------|--------|
|
||||
> | my-app | ~/projects/my-app | current | 1 missing | `routine-maintenance.md` not found |
|
||||
> | api-server | ~/projects/api-server | outdated | current | Methodology files stale |
|
||||
> | frontend | ~/projects/frontend | current | current | — |
|
||||
>
|
||||
> **{N} projects need attention, {M} are current.**
|
||||
|
||||
Group issues by type:
|
||||
- **Needs full init**: projects with `missing`, `agent-crews:missing`, or legacy layouts
|
||||
- **Needs methodology update**: projects with `outdated` status
|
||||
- **Needs new crew files**: projects with `crew-missing` entries (list which files)
|
||||
- **Unreachable**: projects whose paths don't exist on disk
|
||||
|
||||
### Phase 4: Remediate
|
||||
|
||||
If any projects need attention:
|
||||
|
||||
> "Want me to run `/init-project` on the projects that need it?"
|
||||
>
|
||||
> Options:
|
||||
> - **All** — re-init every project that needs attention
|
||||
> - **Select** — choose which projects to update
|
||||
> - **Skip** — just take the report, no changes
|
||||
|
||||
For each project the user selects:
|
||||
|
||||
1. **Run `/init-project`** using the skill workflow (read `.claude/skills/init-project/SKILL.md` and execute)
|
||||
- For projects that only need new crew files: skip straight to Step 6 (Configure Project Crew) — the "If exists (re-run)" path will copy missing crew files from defaults without touching existing ones
|
||||
- For projects that need methodology updates: run the full workflow
|
||||
- For projects with legacy layouts: run from Step 2 (migrations)
|
||||
2. **Report result** — confirm what was updated for each project
|
||||
|
||||
### Phase 5: Summary
|
||||
|
||||
After remediation (or if skipped), output a final status:
|
||||
|
||||
> **Sync complete.**
|
||||
> - {N} projects checked
|
||||
> - {M} projects updated
|
||||
> - {K} projects already current
|
||||
> - {J} projects unreachable (verify paths in `projects.md`)
|
||||
|
||||
## Guidelines
|
||||
|
||||
### Non-Destructive
|
||||
|
||||
This skill never overwrites customized files without user consent. The underlying `/init-project` workflow:
|
||||
- Copies missing crew files from defaults (safe — fills gaps)
|
||||
- Asks before updating existing crew files (respects customization)
|
||||
- Never overwrites `ARTIFACTS.md` (project-specific)
|
||||
|
||||
### Missing Crew Files vs. Drift
|
||||
|
||||
These are distinct situations:
|
||||
- **Missing crew file**: A new default crew was added to mission-control but the project doesn't have it yet. This is a gap — the file should be copied from defaults.
|
||||
- **Crew file drift**: A project's crew file differs from the current default. This is expected — projects customize their crews. Report it as informational but do not flag it as needing remediation.
|
||||
|
||||
### Quick and Quiet
|
||||
|
||||
If all projects are current, say so in one line and stop. No confirmation prompts needed when there's nothing to do.
|
||||
@@ -0,0 +1,387 @@
|
||||
---
|
||||
name: routine-maintenance
|
||||
description: Codebase health assessment and maintenance recommendation. Use after a mission or ad-hoc to verify codebase is flight-ready or scaffold a maintenance mission.
|
||||
---
|
||||
|
||||
# Routine Maintenance
|
||||
|
||||
Perform an exhaustive, aviation-style codebase inspection. Can be triggered after a mission completes or run ad-hoc at any time. Produces a findings report and optionally scaffolds a maintenance mission for significant issues.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- Project must be initialized with `/init-project` (`.flightops/ARTIFACTS.md` must exist)
|
||||
|
||||
## 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 prior maintenance reports (if any exist)**
|
||||
- Read previous reports in `maintenance/` to identify deferred findings from earlier cycles
|
||||
- Deferred findings are those documented in prior reports but not addressed by a maintenance mission
|
||||
- This ensures recurring issues are tracked across cycles rather than re-discovered as "new"
|
||||
|
||||
5. **Load mission and debrief documentation (if available)**
|
||||
- If a recent mission exists, read it for outcome, success criteria, and known issues
|
||||
- If a mission debrief exists, read it for lessons learned and action items
|
||||
- If flight debriefs exist, read them for per-flight technical debt and recommendations
|
||||
- This provides known-debt context so the inspection can distinguish new issues from acknowledged ones
|
||||
- If no mission context is available (ad-hoc run), proceed without known-debt context
|
||||
|
||||
6. **Identify project stack**
|
||||
- Read `README.md`, `CLAUDE.md`, and package files (`package.json`, `Cargo.toml`, `go.mod`, etc.)
|
||||
- Determine language, framework, test runner, linter, formatter, type checker, and dependency audit tool
|
||||
|
||||
### Phase 2: Scoping Interview
|
||||
|
||||
Two parts: category enablement and inspection focus.
|
||||
|
||||
#### Category Enablement
|
||||
|
||||
Categories 1–7 always apply to every project. Ask the user yes/no for optional categories:
|
||||
|
||||
> "Before I begin the inspection, a few quick questions:"
|
||||
>
|
||||
> 1. "Does this project have CI/CD pipelines?" → enables Category 8 + CI/CD Reviewer
|
||||
> 2. "Does this project have deployments, databases, or environment-specific configs?" → enables Category 9
|
||||
> 3. "Does this project have monitoring, metrics, or observability tooling?" → enables Category 10
|
||||
> 4. "Does this project have user-facing UI (web pages, components, forms)?" → enables Accessibility Reviewer
|
||||
|
||||
#### Inspection Focus
|
||||
|
||||
> 5. "Where should the inspection focus?"
|
||||
> - **Recent changes** — "Since when? (last mission, last flight, specific date, N days)"
|
||||
> - **Specific areas** — "Which modules, directories, or concerns?"
|
||||
> - **Full codebase** — "Everything"
|
||||
>
|
||||
> "Any specific areas of concern for this project?"
|
||||
|
||||
Record all responses. The focus selection and areas of concern drive the delegation plan in Phase 3.
|
||||
|
||||
### Phase 3: Delegation Planning
|
||||
|
||||
Before spawning any agents, the Flight Director creates an explicit plan for how to partition work across sub-agents. Each sub-agent has its own context window — the delegation plan ensures no single agent is overwhelmed by project scale.
|
||||
|
||||
#### 3a: Assess Project Size
|
||||
|
||||
Run a quick structural assessment:
|
||||
|
||||
1. **Count source files** — `find {target-project} -name "*.{ext}" -not -path "*/node_modules/*" -not -path "*/.git/*" | wc -l` (use appropriate extensions for the stack)
|
||||
2. **Identify module boundaries** — check for workspace configs (`Cargo.toml` workspaces, `package.json` workspaces, `go.work`), top-level directories with independent configs, or monorepo structure
|
||||
3. **Classify project size**:
|
||||
- **Small**: < 100 source files
|
||||
- **Medium**: 100–500 source files
|
||||
- **Large**: > 500 source files
|
||||
|
||||
#### 3b: Determine Scope
|
||||
|
||||
Based on the interview focus selection:
|
||||
|
||||
- **Recent changes**: Run `git log` / `git diff` to identify changed files since the user's specified cutoff. Map changed files to their containing modules. The inspection scope is the changed files plus their immediate dependencies (imports, shared types, test files).
|
||||
- **Specific areas**: Scope is the user-specified modules/directories. Identify their boundaries and dependencies.
|
||||
- **Full codebase**: Scope is everything. For large projects, this triggers module partitioning (see 3c).
|
||||
|
||||
#### 3c: Build the Delegation Plan
|
||||
|
||||
The plan determines how many agents to spawn, what each one covers, and in what order. Present it to the user for approval before executing.
|
||||
|
||||
**Concurrency constraint**: Claude Code supports a default maximum of **4 concurrent sub-agents**. Additional agents are queued automatically and start as running agents complete. The delegation plan must account for this by organizing agents into **waves** of up to 4.
|
||||
|
||||
**Sub-agent context constraint**: Each sub-agent starts with a fresh context window containing only its prompt. All sub-agent output returns to the Flight Director's context. Verbose results from multiple agents accumulate and can exhaust the Flight Director's context — this makes output discipline a hard constraint, not a suggestion.
|
||||
|
||||
**Delegation rules by scope and size:**
|
||||
|
||||
| Scope | Small/Medium Project | Large Project |
|
||||
|-------|---------------------|---------------|
|
||||
| **Recent changes** | One agent per role, scoped to changed files | Same — changed files are naturally bounded |
|
||||
| **Specific areas** | One agent per role, scoped to specified areas | Same — user has already bounded the scope |
|
||||
| **Full codebase** | One agent per role, full project | **Partition**: see below |
|
||||
|
||||
**Full codebase on large projects — partitioning strategy:**
|
||||
|
||||
The Inspector is the most context-hungry role. Partition it:
|
||||
|
||||
1. **Tool-pass Inspector**: One agent that runs all automated tools (linters, type checkers, test suite, audit commands) across the full project. Tool output is structured and concise — this agent reads command output, not source code.
|
||||
2. **Module Inspectors**: One agent per identified module boundary. Each performs manual code review (dead code, patterns, TODOs, duplication) only within its module. If no clear module boundaries exist, partition by top-level source directories.
|
||||
|
||||
Specialist reviewers (Security, CI/CD, Accessibility) are naturally scoped by their domain and generally do not need partitioning. If a specialist reviewer's scope is too broad (e.g., security review of a 1000-file project), scope it to: files flagged by the tool-pass Inspector + files in security-critical paths (auth, API handlers, data access).
|
||||
|
||||
**Wave planning**: Assign agents to waves of up to 4 concurrent agents. Prioritize by dependency:
|
||||
- **Wave 1**: Tool-pass Inspector + specialist reviewers (Security, CI/CD, Accessibility) — up to 4 agents. The tool pass runs automated commands; specialists do independent manual review. These have no dependencies on each other.
|
||||
- **Wave 2** (if partitioned): Module Inspectors — these can optionally use tool-pass findings to focus their manual review, so they benefit from running after Wave 1. Up to 4 module agents per wave.
|
||||
|
||||
For small/medium projects or scoped inspections, everything fits in a single wave.
|
||||
|
||||
**The delegation plan structure:**
|
||||
|
||||
> **Delegation Plan**
|
||||
>
|
||||
> Scope: {recent changes since X | specific areas: X, Y | full codebase}
|
||||
> Project size: {small | medium | large} (~{N} source files)
|
||||
> Modules: {list of identified modules, or "flat project"}
|
||||
>
|
||||
> **Wave 1** (concurrent):
|
||||
> | # | Agent | Role | Scope | Strategy |
|
||||
> |---|-------|------|-------|----------|
|
||||
> | 1 | Inspector (tools) | Run automated tools | Full project | Commands only, no code reads |
|
||||
> | 2 | Security Reviewer | Auth & injection review | src/auth/, src/api/handlers/ | Manual code path analysis |
|
||||
> | 3 | CI/CD Reviewer | Pipeline review | .github/workflows/ | Config review |
|
||||
> | 4 | Accessibility Reviewer | WCAG 2.1 AA review | src/components/ | UI review |
|
||||
>
|
||||
> **Wave 2** (after Wave 1 completes):
|
||||
> | # | Agent | Role | Scope | Strategy |
|
||||
> |---|-------|------|-------|----------|
|
||||
> | 5 | Inspector (module A) | Manual code review | src/api/ | Categories 4-6 |
|
||||
> | 6 | Inspector (module B) | Manual code review | src/core/ | Categories 4-6 |
|
||||
>
|
||||
> "Here's how I plan to partition the inspection. Want to adjust anything?"
|
||||
|
||||
For small/medium projects or scoped inspections, the plan is straightforward (one wave, one agent per role) and can be presented briefly. Only expand the full table for large/full-codebase inspections.
|
||||
|
||||
#### 3d: Refinement
|
||||
|
||||
This delegation strategy is expected to evolve. After each maintenance run, note in the flight log or maintenance report whether the partitioning was effective:
|
||||
- Did any agent hit context limits or return shallow results?
|
||||
- Were module boundaries appropriate?
|
||||
- Should specialists have been scoped differently?
|
||||
|
||||
These observations inform future delegation plans for the same project.
|
||||
|
||||
### Phase 4: Specialist Review
|
||||
|
||||
Read `{target-project}/.flightops/agent-crews/routine-maintenance.md` for crew definitions and prompts (fall back to defaults at `.claude/skills/init-project/defaults/agent-crews/routine-maintenance.md`).
|
||||
|
||||
**Validate structure**: The crew 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: "Crew file `routine-maintenance.md` is missing required sections. Either fix it manually or re-run `/init-project` to reset to defaults."
|
||||
|
||||
Execute the delegation plan from Phase 3, wave by wave. Spawn all agents within a wave in parallel (up to 4 concurrent). Wait for a wave to complete before starting the next. Every reviewer is strictly **read-only** — they may run test suites, linters, type checkers, and audit commands, but must NEVER modify source files, configuration, or dependencies.
|
||||
|
||||
Each agent receives:
|
||||
- Its assigned scope from the delegation plan
|
||||
- The relevant prompt from the crew file
|
||||
- The output discipline rules (see Guidelines)
|
||||
|
||||
**Context management**: As each agent completes, summarize its findings before storing them for downstream use. Do not accumulate full raw output from every agent — the Flight Director's context is finite.
|
||||
|
||||
#### Inspector
|
||||
|
||||
1. **Spawn Inspector agent(s)** per the delegation plan (Agent tool, `subagent_type: "general-purpose"`)
|
||||
- Provide the "Inspect Codebase" prompt from the crew file's Prompts section
|
||||
- Include: applicable category list, project stack info, known debt from debriefs, user's areas of concern, and **scope assignment from the delegation plan**
|
||||
- For partitioned inspections: each Inspector agent receives its module/area scope and only the categories relevant to its assignment
|
||||
- The Inspector performs broad automated checks and returns structured findings per category
|
||||
|
||||
#### Security Reviewer
|
||||
|
||||
1. **Spawn a Security Reviewer agent** (Agent tool, `subagent_type: "general-purpose"`)
|
||||
- Provide the "Review Security" prompt from the crew file's Prompts section
|
||||
- Include: project stack info, known security debt from debriefs, and **scope assignment from the delegation plan**
|
||||
- The Security Reviewer performs focused manual analysis of auth flows, injection surfaces, secrets handling, and data exposure — deeper than the Inspector's Category 1 automated checks
|
||||
|
||||
#### CI/CD Reviewer (if enabled)
|
||||
|
||||
1. **Spawn a CI/CD Reviewer agent** (Agent tool, `subagent_type: "general-purpose"`)
|
||||
- Provide the "Review CI/CD" prompt from the crew file's Prompts section
|
||||
- Include: project stack info, known CI/CD debt from debriefs
|
||||
- The CI/CD Reviewer evaluates pipeline definitions, build security, deployment safeguards, and environment consistency
|
||||
|
||||
#### Accessibility Reviewer (if enabled)
|
||||
|
||||
1. **Spawn an Accessibility Reviewer agent** (Agent tool, `subagent_type: "general-purpose"`)
|
||||
- Provide the "Review Accessibility" prompt from the crew file's Prompts section
|
||||
- The Accessibility Reviewer evaluates against WCAG 2.1 AA standards, semantic HTML, keyboard navigation, screen reader compatibility, and color contrast
|
||||
|
||||
#### Merge Partitioned Results
|
||||
|
||||
If the Inspector was partitioned into multiple agents, merge their findings into a single consolidated findings list before proceeding to Phase 5. De-duplicate findings that appear in multiple modules.
|
||||
|
||||
### Phase 5: Severity Assessment & Roundtable
|
||||
|
||||
#### 5a: Initial Assessment
|
||||
|
||||
1. **Spawn an Architect agent** (Opus) with all reviewer findings + debrief context (Agent tool, `subagent_type: "general-purpose"`)
|
||||
- Provide the "Assess Findings" prompt from the crew file's Prompts section
|
||||
- Include: all reviewer findings, known debt items (if available from debriefs)
|
||||
- The Architect assigns an initial severity to each finding and raises challenges or questions directed at specific reviewers where findings seem incorrect, overlapping, or missing context
|
||||
|
||||
#### 5b: Roundtable
|
||||
|
||||
The Architect and specialist reviewers hash out findings through structured discussion. The Flight Director mediates.
|
||||
|
||||
1. **Route Architect's challenges** to the relevant reviewers
|
||||
- For each reviewer with outstanding challenges, spawn them with the "Roundtable Rebuttal" prompt from the crew file
|
||||
- Include the Architect's specific challenges directed at that reviewer
|
||||
- Reviewers respond with evidence, rebuttals, or concurrence
|
||||
2. **Collect responses** from all challenged reviewers
|
||||
3. **Return to Architect** with roundtable responses
|
||||
- Spawn Architect with the "Roundtable Resolution" prompt from the crew file
|
||||
- Include all reviewer rebuttals and new evidence
|
||||
- Architect produces final assessment incorporating the discussion
|
||||
4. **Max 2 roundtable cycles** — if consensus isn't reached after 2 rounds, present both perspectives to the human in Phase 6 and let them decide
|
||||
|
||||
#### Severity Scale
|
||||
|
||||
| Severity | Meaning |
|
||||
|----------|---------|
|
||||
| **Pass** | No issue found |
|
||||
| **Advisory** | Minor issue, deferring is acceptable |
|
||||
| **Action Required** | Should be addressed before next major work cycle |
|
||||
| **Critical** | Blocks further work, immediate attention needed |
|
||||
|
||||
The Architect produces an overall assessment:
|
||||
- **Flight Ready** — All findings are Pass or Advisory
|
||||
- **Maintenance Required** — Any finding is Action Required or Critical
|
||||
|
||||
### Phase 6: Human Review and Scoping
|
||||
|
||||
Present findings grouped by severity (Critical first, then Action Required, Advisory, Pass):
|
||||
|
||||
> **Overall Assessment: {Flight Ready | Maintenance Required}**
|
||||
>
|
||||
> {Findings summary table}
|
||||
|
||||
Then ask:
|
||||
1. "Do these findings match your sense of the codebase health?"
|
||||
2. "Any findings to override or adjust severity?"
|
||||
|
||||
Apply any overrides the user requests.
|
||||
|
||||
#### Scope Selection
|
||||
|
||||
If the assessment is Maintenance Required, help the user choose a manageable scope rather than scaffolding everything. Present a recommended shortlist:
|
||||
|
||||
> **Recommended scope** (Critical items are always included):
|
||||
>
|
||||
> {Numbered list of Critical + top Action Required findings, capped at ~5-7 items}
|
||||
>
|
||||
> {Count} additional Action Required and {count} Advisory findings are documented in the report for a future cycle.
|
||||
>
|
||||
> "Want me to scaffold a maintenance mission for these items? You can add or remove findings from the list."
|
||||
|
||||
The goal is a mission that can land in a single focused session. All findings are captured in the report regardless — deferred items aren't lost, they'll surface again in the next maintenance cycle. This keeps maintenance approachable even when the backlog is large.
|
||||
|
||||
### Phase 7: Generate Maintenance Report
|
||||
|
||||
Create the maintenance report artifact at the location defined in `.flightops/ARTIFACTS.md` (typically `maintenance/YYYY-MM-DD.md`). If a report already exists for today's date, append a numeric suffix (e.g., `2026-03-26-2.md`).
|
||||
|
||||
**Report contents:**
|
||||
- Title (date-based) and date
|
||||
- Optional "Triggered by" link to the mission that prompted the inspection (if applicable)
|
||||
- Inspection scope and delegation plan summary
|
||||
- Overall assessment (Flight Ready / Maintenance Required)
|
||||
- Categories inspected
|
||||
- Executive summary
|
||||
- Findings by category (each with severity, description, evidence, recommendation)
|
||||
- Severity summary (counts per level)
|
||||
- Known debt carried forward (from debriefs, acknowledged but not addressed)
|
||||
- Delegation effectiveness notes (for refining future inspections)
|
||||
- Recommendations
|
||||
|
||||
### Phase 8: Scaffold Maintenance Mission (conditional)
|
||||
|
||||
**Only if**: Overall assessment is Maintenance Required AND the user confirmed they want a maintenance mission. Only the findings the user selected in Phase 6 are scaffolded — deferred findings remain in the report for future cycles.
|
||||
|
||||
This phase produces the full artifact tree — mission, flights, and legs — so the maintenance work is ready for `/agentic-workflow` execution without running `/mission`, `/flight`, or `/leg` separately.
|
||||
|
||||
#### 8a. Mission
|
||||
|
||||
Scan existing `missions/` directories to determine the next sequence number `{NN}`. Create `missions/{NN}-maintenance/mission.md` using the standard mission format from `.flightops/ARTIFACTS.md`:
|
||||
- **Status**: `planning`
|
||||
- **Outcome**: "Resolve codebase health issues identified in maintenance report {YYYY-MM-DD}"
|
||||
- **Context**: Link to the maintenance report in `maintenance/{YYYY-MM-DD}.md`
|
||||
- **Success Criteria**: One criterion per selected finding
|
||||
- **Flights**: List the flights from step 8b
|
||||
- Populate all standard mission sections. Mark sections with no relevant content as "N/A" (e.g., Open Questions, Stakeholders).
|
||||
|
||||
#### 8b. Flights
|
||||
|
||||
Re-group the user's selected findings into flights. Use the Architect's recommended groupings as a starting point, but adjust for any findings the user removed or added during Phase 6 scoping. Typical groupings: one flight per category with actionable findings, or by technical area when findings from different categories affect the same subsystem.
|
||||
|
||||
Each flight gets its own directory with `flight.md` and `flight-log.md`. Use the standard formats from `.flightops/ARTIFACTS.md` with these maintenance-specific notes:
|
||||
|
||||
- **Status**: `ready` — maintenance flights skip the Pre-Flight phase (no open questions or design decisions to resolve for concrete fixes). Mark Pre-Flight Checklist items as N/A.
|
||||
- **Mission**: Link back to the maintenance mission
|
||||
- **Objective**: What this group of fixes accomplishes
|
||||
- **Technical Approach**: Brief description of the fix strategy per finding
|
||||
- **Legs**: List the legs from step 8c
|
||||
- Populate all other standard flight sections. Mark sections with no relevant content as "N/A".
|
||||
|
||||
The `flight-log.md` is created empty (header only) — it will be populated during execution.
|
||||
|
||||
#### 8c. Legs
|
||||
|
||||
Each flight gets one leg per discrete fix. Create leg files using the standard format from `.flightops/ARTIFACTS.md` with these fields populated:
|
||||
|
||||
- **Status**: `ready`
|
||||
- **Flight**: Link back to the flight
|
||||
- **Objective**: Fix one specific finding (reference the finding number from the report)
|
||||
- **Context**: Link to the maintenance report finding and the Architect's recommendation
|
||||
- **Inputs/Outputs**: Files that exist before and after the fix
|
||||
- **Acceptance Criteria**: The specific condition that resolves the finding — derived from the Architect's recommendation
|
||||
- **Verification Steps**: How to confirm the fix (e.g., "run `npm audit` and confirm no high/critical vulnerabilities", "run `cargo clippy` with no warnings")
|
||||
- **Implementation Guidance**: Concrete steps to resolve the finding, based on the Inspector's evidence and the Architect's recommendation
|
||||
- **Files Affected**: List files identified in the Inspector's evidence
|
||||
- Mark sections with no relevant content as "N/A" (e.g., Edge Cases for straightforward dependency updates).
|
||||
|
||||
Keep legs atomic — one finding, one fix. If a finding requires touching many files but is conceptually one change (e.g., "replace all `any` casts"), that's still one leg.
|
||||
|
||||
#### 8d. Update Report Backlink
|
||||
|
||||
After scaffolding, update the "Maintenance Mission" section at the bottom of the maintenance report (from Phase 7) with a link to the newly created mission.
|
||||
|
||||
## Guidelines
|
||||
|
||||
### Read-Only Inspection
|
||||
|
||||
This skill NEVER modifies source files, configuration, or dependencies in the target project. The Inspector runs checks and reports findings. The only files created are the maintenance report and optionally a full maintenance mission scaffold (mission, flights, and legs) — all are Flight Control artifacts.
|
||||
|
||||
### Output Discipline
|
||||
|
||||
This is a **hard constraint**, not a suggestion. All sub-agent output returns to the Flight Director's context window. With 4+ reviewers plus roundtable agents, verbose output will exhaust the Flight Director's context and break the workflow.
|
||||
|
||||
All reviewer agents must follow these rules:
|
||||
|
||||
1. **Summary-first**: Each finding includes a title, severity estimate, file path, and a one-line evidence summary
|
||||
2. **Selective detail**: Include code excerpts or extended evidence only for Critical and High severity findings
|
||||
3. **No raw dumps**: Never paste full command output, full file contents, or long dependency lists — summarize and reference
|
||||
4. **Drill-down on demand**: If the Architect or roundtable needs deeper evidence for a specific finding, the Flight Director spawns a follow-up agent scoped to that single finding
|
||||
|
||||
The Flight Director must also enforce this when collecting results — if an agent returns excessively verbose output, summarize it before passing to downstream agents.
|
||||
|
||||
### Known Debt Awareness
|
||||
|
||||
Cross-reference Inspector findings against known debt from debriefs. Findings that match acknowledged debt should note "previously identified in {debrief}" rather than presenting them as new discoveries. This prevents alarm fatigue.
|
||||
|
||||
### Proportional Response
|
||||
|
||||
Not every codebase needs a maintenance mission. If the inspection finds only Advisory items, the report should clearly state "Flight Ready" and not push for unnecessary work.
|
||||
|
||||
### Honest Assessment
|
||||
|
||||
Report what you find, even if the codebase is in great shape. A clean report is valuable — it confirms the team's work quality and builds confidence for the next mission.
|
||||
|
||||
### Severity Calibration
|
||||
|
||||
- **Critical** is reserved for issues that would cause failures, security vulnerabilities, or data loss
|
||||
- **Action Required** means the issue will compound or cause problems if left for another cycle
|
||||
- **Advisory** is for genuine improvements that have no urgency
|
||||
- **Pass** means the category was inspected and is healthy
|
||||
|
||||
## Output
|
||||
|
||||
Create the maintenance report artifact using the location and format defined in `.flightops/ARTIFACTS.md`.
|
||||
|
||||
After generating the report, summarize:
|
||||
1. Overall assessment (Flight Ready or Maintenance Required)
|
||||
2. Count of findings by severity
|
||||
3. Top recommendations
|
||||
4. Whether a maintenance mission was scaffolded (and if so, how many flights and legs)
|
||||
Reference in New Issue
Block a user