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

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 (or craft guidance manually)
   • •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: the target project
   • •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. •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.

1. •Spawn a Developer agent (Task tool, subagent_type: "general-purpose")
   • •Working directory: the target project
   • •Provide the "Implement" prompt from the leg-execution phase file's Prompts section
   • •The Developer reads the leg artifact, implements to acceptance criteria, updates flight log
   • •The Developer signals [HANDOFF:review-needed] when done — do NOT let it commit
2. •Spawn a Reviewer agent (Task tool, subagent_type: "general-purpose")
   • •Working directory: the target project
   • •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 updated leg status

2c: Leg Transition

After [COMPLETE:leg]:

1. •Increment legs_completed
2. •If more legs remain → return to 2a
3. •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. •Run flight debrief using the /flight-debrief skill
5. •Update flight status to landed
6. •Check off flight in mission artifact
7. •Signal [COMPLETE:flight]

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:

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

Commit message format:

leg/{number}: {description}

Flight: {flight-number}
Mission: {mission-number}

Error Handling