Triple-C/container/mission-control/.claude/skills/init-project/defaults/agent-crews/leg-execution.md

# 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].
```