Prep for Launch — PBI-to-pre-flight pipeline with HITL clearance gate

Taxi a Linear PBI from the backlog to a fully-implemented, reviewed, but-not-yet-shipped state, then hold at the gate with chocks in place and present a Boeing list to the human for clearance.

The aircraft is fueled, checked, and ready, but does not move until ground control says so.

Trigger

ONLY when invoked exactly as /prep-for-launch. This skill does not auto-trigger, does not fuzzy-match, and does not apply to "do the next thing" requests. If the user did not type /prep-for-launch, do not use this skill — compose the underlying commands manually instead.

Goal

Run the full Linear-PBI-to-pre-flight pipeline:

1. Select a backlog item (via /next-task's logic) — or use the one in $ARGUMENTS if provided.
2. Spec the feature (via /spec's logic).
3. Assemble the implementation (via /assemble's Dev→Critic loop).
4. Hold at the gate. Produce a Boeing List for HITL approval. Do NOT run smoke tests. Do NOT push to remote. Do NOT invoke /ship.

Boundaries

• Does NOT run smoke tests (pnpm check / lint / test:run) without explicit HITL clearance.
• Does NOT commit or push — /ship is a separate, explicitly-invoked step.
• Does NOT modify Linear issue status to Done (status moves to "In Review" at most).
• Does NOT loop back into itself — one PBI per invocation.

Pipeline

Stage 1 — Gate Selection (Pick the Aircraft)

If $ARGUMENTS contains a Linear PBI ID or issue number, use it directly.

Otherwise, follow the /next-task workflow:

• Fetch all Backlog-state issues for the ASDLC team via Linear MCP.
• Fetch comments for each.
• Rank by priority × (1 / effort), accounting for defer/block comments.
• Pick the top candidate. Report the choice and why.

Output: the selected PBI, its acceptance criteria, and a one-line justification for the pick.

Stage 2 — Flight Plan (Spec)

Invoke the /spec workflow against the selected PBI:

• If a spec already exists in specs/{feature-domain}/spec.md, read it and update only where the PBI introduces new requirements.
• If no spec exists, create one following specs/content-articles/spec.md conventions.
• Link the Linear issue to the spec file (Linear issues reference specs, not vice versa).

Output: the spec path and a delta summary (new sections, changed sections, untouched sections).

Stage 3 — Taxi (Assemble)

Invoke the /assemble Dev→Critic loop against the PBI + spec:

• Spawn /dev sub-agent.
• Spawn /critic sub-agent.
• Loop until critic returns PASS or PASS WITH NOTES, with a 3-cycle circuit breaker.
• Capture every critic finding from every cycle, not just the final verdict.

Output: number of cycles, final verdict, and the consolidated list of all findings raised across cycles (resolved and unresolved).

Stage 4 — Chocks On (Boeing List + Hold)

Do NOT run pnpm check / smoke tests yet. Do NOT commit. Do NOT push. Compile the Boeing List and present it to the human.

Boeing List Format

## Boeing List — <PBI ID>: <title>

### Aircraft
- **PBI:** <Linear issue link>
- **Spec:** <spec path>
- **Branch:** <current branch>
- **Cycles:** <N dev-critic cycles>
- **Final verdict:** <PASS | PASS WITH NOTES>

### Q/A Findings
(from critic cycles — both resolved and unresolved)
- [resolved] <finding> — fixed in cycle <N>
- [unresolved] <finding> — <reason it was left>
- [note] <verdict-level note from final critic pass>

### Dev Findings
(from the dev sub-agent's own work — discoveries, assumptions, deviations)
- <assumption made about ambiguous requirement>
- <decision to deviate from spec, with rationale>
- <new constraint discovered that should be crystallized back to spec>
- <files modified, beyond the obvious>

### Held for HITL Clearance
(things the human must decide before clearance)
- [ ] Approve all Q/A findings as acceptable
- [ ] Approve all dev assumptions / deviations
- [ ] Confirm spec updates (if any) reflect intent
- [ ] Authorize smoke tests (`pnpm check`, `pnpm lint`, `pnpm test:run`)
- [ ] Authorize push to remote

### Recommended Next Steps (after clearance)
1. Run smoke tests locally
2. If green, invoke `/ship` to commit and push
3. If red, return to `/assemble` with the new findings

After printing the Boeing List, stop. Do not proceed further. Wait for the user to clear individual items or instruct the next move.

Sub-Agent Model Policy

Inherits from /assemble:

• haiku / flash — context gathering, Linear reads, file lookups
• sonnet / pro — spec writes, dev cycles, critic reviews
• opus — only with explicit user approval

Principles

• Single invocation, exact match. Do not run unless the user typed /prep-for-launch. No auto-triggering, no helpful inference.
• Hold at the gate. The skill's defining behavior is stopping before takeoff. Smoke tests and push are not part of the skill; they are explicitly the human's call after reviewing the Boeing List.
• Full findings, not just final verdict. The Boeing List preserves every Q/A and dev finding across all cycles, including ones the loop resolved. The human gets to judge whether the resolution was the right call, not just whether the test went green.
• Silent inside cycles. Within each stage, only interrupt the user if genuinely blocked. The HITL gate is at Stage 4, not scattered across the pipeline.

Instructions

$ARGUMENTS