Menú
Generate detailed implementation guidance for LLM execution. Use when creating atomic implementation steps from a flight.
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
Active orchestrator for multi-agent flight execution. Drives leg design per leg, then batches implementation across all autonomous legs, with a single code review and commit at the end of the flight.
Post-flight analysis for continuous improvement. Use after a flight is completed to capture lessons learned and improve the methodology.
Create technical flight specifications from missions. Use when breaking down a mission into implementable work or planning technical approach.
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.
Post-mission codebase health assessment. Run after `/mission-debrief` to verify the codebase is flight-ready or scaffold a maintenance mission. Per-flight findings instead roll into the next flight or accumulate into an end-of-mission maintenance flight — not into this skill.
Post-mission retrospective for outcomes assessment and methodology improvement. Use after a mission completes or aborts to capture overall lessons learned.
| name | leg |
| description | Generate detailed implementation guidance for LLM execution. Use when creating atomic implementation steps from a flight. |
Generate detailed implementation guidance for LLM execution.
/init-project (.flightops/ARTIFACTS.md must exist)Identify the target project
projects.md to find the project's pathVerify project is initialized
{target-project}/.flightops/ARTIFACTS.md exists/init-project firstRead the artifact configuration
{target-project}/.flightops/ARTIFACTS.md for artifact locations and formatsRead the parent flight
Read the flight log in detail (critical)
The flight log captures ground truth from actual implementation. Read it fully and extract:
Identify this leg's scope
Identify environment constraints
Deep dive into the specific implementation:
Identify exact files to modify
Understand existing patterns
Determine inputs and outputs
Identify edge cases
State-machine reachability audit
For every state, status, or lifecycle value this leg introduces or relies on, verify nothing in a lower layer makes the state unreachable.
test_X_does_Y → test_X_does_not_do_Y with the assertion inverted) is preferred over delete-and-readd because it documents the intent shift in git blame.ON DELETE CASCADE on a referencing column will silently delete the row your design needs to keep.Cache freshness contract
For every cache (in-memory dict, query result cache, computed derived state, frontend session storage) this leg reads from or populates, declare an explicit freshness contract.
Conflating "the cached object works fine" with "the cached object reflects current config" is a common error. State health and state freshness are different contracts.
Identify dependent code (for interface changes)
grep -rn '<changed_symbol>' tests/ src/; if any test or non-leg-scope source imports or calls it, signature changes break any "prior tests pass UNMODIFIED" acceptance criterion.Identify platform considerations
Create the leg artifact using the format defined in .flightops/ARTIFACTS.md.
Before marking the leg ready, mechanically validate every code-location citation in the draft artifact against current code. Citations drift between when a flight is designed and when its legs are designed (intervening legs commit changes; source artifacts age). Catching drift here prevents the implementing agent from chasing a stale file:line into the wrong code.
Extract citations
path/to/file.ext:line or path/to/file.ext:line-line patternspath/to/file.ext:symbol_namemission.md:42, flight.md:100) — those are out of scopeVerify each citation
OK — content at the cited location matches the descriptiondrifted — content moved; the description is still accurate but the line number is wronggone — described content no longer exists in the file (or the file itself is gone)unverifiable — citation has no snippet/symbol and the description is too vague to confirmRepair drift inline
drifted: locate the new line number via grep on the snippet/symbol and update the citation in the leg artifactgone: do not silently retire — flag for human review (the gap may have been independently fixed, OR the leg may now be obsolete)unverifiable: rewrite the citation using one of the durable forms (see "Citing Code Locations" guideline)Append a Citation Audit summary
## Citation Audit if the project's leg conventions don't dictate otherwise) summarizing the auditN citations verified against current code at leg design time.State exactly what the leg accomplishes:
Weak: "Set up the database stuff"
Strong: "Create the User model with email, password_hash, and timestamp fields"
Criteria must be:
Weak: "Code is clean" (subjective)
Strong: "User model exists in prisma/schema.prisma"
Tell the agent exactly how to confirm each criterion:
Weak: "Make sure it works"
Strong:
## 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:
When the leg artifact references specific code, prefer durable forms over bare line numbers. Line numbers drift; symbols and snippets do not.
| Form | Example | When to use |
|---|---|---|
file:symbol | the_one/api.py:create_provider | Most cases — symbol names survive line shifts |
file:line — "snippet" | the_one/api.py:805 — "raise ProviderConfigError" | When a specific line matters; the snippet is a self-verifier |
file:CONSTANT_NAME | web/middleware.py:GATED_METHODS | Module-level constants and assignments |
file:line (bare) | api.py:805 | Avoid — brittle, no way to verify drift |
The snippet form is especially valuable: it lets Phase 3b mechanically confirm the cited content didn't move, and it tells the implementing agent exactly what they're looking at without needing to chase the line number.
When in doubt, include both — the_one/api.py:805 (in create_provider) — "raise ProviderConfigError if base_url is empty" — symbol + line + snippet covers all three drift modes.
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."
Provide examples when:
A well-sized leg:
Too small: Single-line change with no meaningful criteria Too large: Would benefit from intermediate checkpoints
When implementing a workaround, document:
Once a leg is in-flight:
aborted (changes rolled back)Create the leg artifact using the location and format defined in .flightops/ARTIFACTS.md.