Sync bundled mission-control to upstream 15fbc94
Pulls in 15 upstream commits since the April 3 bundling snapshot
(msieurthenardier/mission-control). Notable changes:
- agentic-workflow rewritten as the "fast" variant: per-leg design and
implement, single review and commit across the whole flight
- New Skill-Project Boundary section: skills no longer read or write
project-owned artifacts by literal heading
- routine-maintenance scoped to post-mission only; adds state-machine
reachability and cache freshness audits
- Test metrics capture threaded through debrief, maintenance, and flight
- Crew prompts no longer carry skill-required instructions; SKILL.md is
the protocol
- Worktree git strategy removed; standardized on {target-project}
- Jira artifact template removed upstream
Local URL correction in init-project/README.md preserved
(anthropics/flight-control -> msieurthenardier/mission-control).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -33,7 +33,7 @@ Check for legacy directory layouts and offer to migrate them.
|
||||
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:"
|
||||
> "Detected legacy directory layout in {target-project}. The following migrations are available:"
|
||||
>
|
||||
> - _Each applicable migration's user message_
|
||||
>
|
||||
@@ -61,13 +61,13 @@ The script outputs one of:
|
||||
Based on the status:
|
||||
|
||||
**If `missing`**:
|
||||
> "Flight operations directory not found. Create `{project}/.flightops/` with methodology references?"
|
||||
> "Flight operations directory not found. Create `{target-project}/.flightops/` with methodology references?"
|
||||
|
||||
**If `outdated`**:
|
||||
> "Flight operations references in {project} are outdated. Update?"
|
||||
> "Flight operations references in {target-project} are outdated. Update?"
|
||||
|
||||
**If `current`**:
|
||||
> "Flight operations references are up-to-date in {project}."
|
||||
> "Flight operations references are up-to-date in {target-project}."
|
||||
|
||||
If the user confirms, create/update the directory:
|
||||
|
||||
@@ -79,34 +79,13 @@ 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:
|
||||
**Only if ARTIFACTS.md doesn't exist**, copy the template:
|
||||
|
||||
```bash
|
||||
cp "${SKILL_DIR}/templates/ARTIFACTS-{selection}.md" \
|
||||
cp "${SKILL_DIR}/templates/ARTIFACTS-files.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
|
||||
@@ -166,7 +145,7 @@ This project uses [Flight Control](https://github.com/msieurthenardier/mission-c
|
||||
|
||||
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."
|
||||
> "If you have Claude Code running in {target-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.
|
||||
|
||||
@@ -175,7 +154,7 @@ This ensures Claude Code loads the new files into its context when working in th
|
||||
This skill creates/updates the following at project root:
|
||||
|
||||
```
|
||||
{project}/
|
||||
{target-project}/
|
||||
├── CLAUDE.md # Updated with Flight Operations section
|
||||
└── .flightops/ # Hidden directory for Flight Control
|
||||
├── README.md # Explains the directory purpose
|
||||
|
||||
@@ -6,7 +6,7 @@ human and project-side agents to capture both execution and design perspectives.
|
||||
## Crew
|
||||
|
||||
### Developer
|
||||
- **Context**: {project}/
|
||||
- **Context**: {target-project}/
|
||||
- **Model**: Sonnet
|
||||
- **Role**: Provides developer perspective on flight execution. Reviews what was
|
||||
built, identifies technical debt introduced, evaluates implementation quality,
|
||||
@@ -14,7 +14,7 @@ human and project-side agents to capture both execution and design perspectives.
|
||||
- **Actions**: debrief-interview
|
||||
|
||||
### Architect
|
||||
- **Context**: {project}/
|
||||
- **Context**: {target-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
|
||||
|
||||
@@ -6,7 +6,7 @@ technical spec and uses project-side agents to validate against the real codebas
|
||||
## Crew
|
||||
|
||||
### Architect
|
||||
- **Context**: {project}/
|
||||
- **Context**: {target-project}/
|
||||
- **Model**: Sonnet
|
||||
- **Role**: Reviews flight specs for technical soundness. Validates design
|
||||
decisions, prerequisites, technical approach, and leg breakdown against
|
||||
@@ -56,6 +56,20 @@ Evaluate:
|
||||
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?
|
||||
7. State-machine reachability — for every state, status, or lifecycle value the flight
|
||||
introduces or relies on (e.g. "agent_deleted", "draft", "queued"), audit which
|
||||
infrastructure layers could foreclose it: DB constraints (FK ON DELETE behaviors,
|
||||
NOT NULL, CHECK), application caches and their invalidation rules, API/protocol
|
||||
versions, fallback handlers that mask the state, and existing tests that pin
|
||||
contradictory behavior. A state that the schema or a cache can silently prevent
|
||||
is a design hole, not an implementation detail.
|
||||
8. Cache freshness contracts — for every cache (in-memory dict, query result cache,
|
||||
derived state, frontend session storage) the flight reads from or populates,
|
||||
the design must declare source of truth, rebuild trigger (per-call / TTL /
|
||||
invalidation event / accepted permanent staleness), maximum staleness, and which
|
||||
user actions should invalidate it. Vague answers ("eventually", "on next cycle")
|
||||
without a concrete trigger are a flag. Conflating "cached object works" with
|
||||
"cached object reflects current source" is a common category error worth catching.
|
||||
|
||||
Provide structured output:
|
||||
|
||||
|
||||
@@ -7,21 +7,21 @@ The Flight Director (Mission Control) orchestrates this phase using the
|
||||
## Crew
|
||||
|
||||
### Developer
|
||||
- **Context**: {working-directory}/
|
||||
- **Context**: {target-project}/
|
||||
- **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}/
|
||||
- **Context**: {target-project}/
|
||||
- **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}/
|
||||
- **Context**: {target-project}/
|
||||
- **Model**: Sonnet
|
||||
- **Enabled**: false
|
||||
- **Role**: Reviews UI changes for accessibility compliance. Evaluates against
|
||||
@@ -72,7 +72,6 @@ The Flight Director substitutes these variables in prompts at runtime:
|
||||
| `{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
|
||||
|
||||
@@ -6,7 +6,7 @@ both the human and a project-side Architect to capture strategic technical persp
|
||||
## Crew
|
||||
|
||||
### Architect
|
||||
- **Context**: {project}/
|
||||
- **Context**: {target-project}/
|
||||
- **Model**: Sonnet
|
||||
- **Role**: Provides architectural perspective on mission outcomes. Evaluates
|
||||
whether the system evolved well across flights, identifies structural issues,
|
||||
|
||||
@@ -6,7 +6,7 @@ and uses project-side agents to validate technical viability.
|
||||
## Crew
|
||||
|
||||
### Architect
|
||||
- **Context**: {project}/
|
||||
- **Context**: {target-project}/
|
||||
- **Model**: Sonnet
|
||||
- **Role**: Validates technical viability of proposed outcomes. Ensures business
|
||||
goals align with what's actually possible given the codebase, stack, and
|
||||
|
||||
@@ -7,7 +7,7 @@ for severity assessment and roundtable moderation.
|
||||
## Crew
|
||||
|
||||
### Inspector
|
||||
- **Context**: {project}/
|
||||
- **Context**: {target-project}/
|
||||
- **Model**: Sonnet
|
||||
- **Role**: Performs broad read-only codebase inspection across all applicable
|
||||
categories. Runs test suites, linters, type checkers, audit commands, and
|
||||
@@ -15,7 +15,7 @@ for severity assessment and roundtable moderation.
|
||||
- **Actions**: inspect-codebase
|
||||
|
||||
### Security Reviewer
|
||||
- **Context**: {project}/
|
||||
- **Context**: {target-project}/
|
||||
- **Model**: Sonnet
|
||||
- **Role**: Performs focused manual security review of authentication flows,
|
||||
injection surfaces, secrets handling, CORS/CSP configuration, and data
|
||||
@@ -24,7 +24,7 @@ for severity assessment and roundtable moderation.
|
||||
- **Actions**: review-security
|
||||
|
||||
### CI/CD Reviewer (optional)
|
||||
- **Context**: {project}/
|
||||
- **Context**: {target-project}/
|
||||
- **Model**: Sonnet
|
||||
- **Enabled**: false (enable when project has CI/CD pipelines)
|
||||
- **Role**: Reviews CI/CD pipeline configuration, build security, deployment
|
||||
@@ -33,7 +33,7 @@ for severity assessment and roundtable moderation.
|
||||
- **Actions**: review-cicd
|
||||
|
||||
### Accessibility Reviewer (optional)
|
||||
- **Context**: {project}/
|
||||
- **Context**: {target-project}/
|
||||
- **Model**: Sonnet
|
||||
- **Enabled**: false (enable when project has user-facing UI)
|
||||
- **Role**: Reviews codebase for accessibility compliance against WCAG 2.1 AA
|
||||
@@ -42,7 +42,7 @@ for severity assessment and roundtable moderation.
|
||||
- **Actions**: review-accessibility
|
||||
|
||||
### Architect
|
||||
- **Context**: {project}/
|
||||
- **Context**: {target-project}/
|
||||
- **Model**: Opus
|
||||
- **Role**: Reviews all reviewer findings alongside debrief context. Assigns
|
||||
severity per finding, challenges questionable assessments, moderates
|
||||
@@ -463,6 +463,7 @@ For each finding, assign one of:
|
||||
- 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 the infrastructure or framing this finding pertains to still serving its original purpose, or has it drifted into "maybe-someday" territory?
|
||||
- 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?
|
||||
|
||||
@@ -5,7 +5,7 @@ This project stores Flight Control artifacts as markdown files in the repository
|
||||
## Directory Structure
|
||||
|
||||
```
|
||||
{project}/
|
||||
{target-project}/
|
||||
├── missions/
|
||||
│ └── {NN}-{mission-slug}/
|
||||
│ ├── mission.md
|
||||
@@ -159,7 +159,7 @@ How the objective will be achieved.
|
||||
|
||||
- [ ] `{leg-slug}` - {Brief description}
|
||||
- [ ] `{leg-slug}` - {Brief description}
|
||||
- [ ] `uat-and-alignment` *(optional)* - Guided UAT session with iterative fixes
|
||||
- [ ] `hat-and-alignment` *(optional)* - Guided HAT (human acceptance test) session with iterative fixes
|
||||
|
||||
---
|
||||
|
||||
@@ -560,16 +560,3 @@ States are tracked in the frontmatter or status field of each artifact:
|
||||
- **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`.
|
||||
|
||||
@@ -1,408 +0,0 @@
|
||||
# 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`.
|
||||
Reference in New Issue
Block a user