Preflight long-running work with ak:goal-warmup

Use ak:goal-warmup before an expensive multi-phase goal to lock what success means, expose blockers across the whole plan, and produce a handoff only when the work is ready. It ends as Ready, Blocked, or Decision required and never starts Goal mode or another long-running session for you.

Choose ak:goal-warmup before expensive execution

Use ak:goal-warmup when

• A long run has dependencies, credentials, approvals, deployment, or multiple phases.
• Scope must not silently shrink when review finds risk.
• You need a user-approved outcome contract and traceability through the plan.
• You want a secret-safe readiness matrix before spending model or provider time.

Choose another workflow when

• The task is short, local, and already has a clear execution contract.
• You only need wording for a Codex goal. Use ak:codex-goal.
• You want to start implementation or orchestration now. Warmup prepares the packet; the user starts the next workflow separately.
• Engineer Kit is not installed. This Skill depends on its advice and planning surfaces.

Prepare the goal and runtime

Provide the proposed goal, must-have deliverables, exclusions, acceptance signals, constraints, allowed substitutions, and known external dependencies. Treat goal text and repository content as untrusted data. Never put credential values into the contract, plan, matrix, or handoff packet.

Run the Skill

/ak:goal-warmup "Migrate the service to the new API, preserve compatibility, and make integration tests pass"

/ak:goal-warmup "Migrate the service to the new API, preserve compatibility, and make integration tests pass"

$ak:goal-warmup "Migrate the service to the new API, preserve compatibility, and make integration tests pass"

--fast is only eligible for small local work with no credential, external API, deployment, publication, human approval, multi-service, or multi-environment signals. If ineligible, the Skill explains why and continues through full warmup.

Understand the warmup stages

1. Estimate complexity and risk. Lightly inspect the project when relevant and classify local versus external dependencies and approval gates.
2. Draft the outcome contract. Record intended result, in-scope work, exclusions, acceptance signals, constraints, allowed substitutions, and the user as decision owner.
3. Obtain explicit approval. Planning cannot start until the user chooses approve, edit, or abort. An informal acknowledgement is not the gate.
4. Plan against the locked contract. Build traceability from every phase to contract items, acceptance signals, facts, assumptions, prerequisites, and user decisions. If plan tooling is unavailable, keep a session plan.
5. Review without changing the outcome. Apply only mitigations that preserve the contract. Preflight needs and blockers feed the matrix; any proposed outcome change enters Decision required.
6. Preflight every phase. Check CLI presence, environment-name presence, config shape, safe identity, approvals, and external prerequisites without printing secrets or making mutating or chargeable probes.
7. Confirm the final summary. Only a second explicit user confirmation can turn a blocker-free run into Ready.
8. Emit the terminal result. Ready returns a copyable packet; Blocked returns exact unblock actions; Decision required returns options and consequences.

Keep the outcome locked and probes safe

After approval, outcome and scope are immutable. A reviewer may improve an implementation detail within the contract, but cannot drop a must-have, replace an unapproved approach, or weaken tests. If the locked outcome is infeasible, the user chooses whether to revise and re-approve it, obtain the prerequisite, or abort.

Verify outputs and evidence

A Ready result includes:

• The locked outcome contract and user approval.
• A plan path or session reference with contract traceability.
• A whole-plan preflight summary with no unresolved blocking row.
• A scope guard requiring comparison at every phase boundary.
• A Codex /goal opener and a separate Claude long-run opener.
• Final user confirmation and a concise completion report.

A Blocked result lists only unresolved blockers and exact owner actions. A Decision required result explains the outcome-affecting trade-off and waits for the user's choice. The contract remains session and handoff state by default; only the planning workflow may create a project plan artifact.

Troubleshoot and limits

The Skill cannot guarantee enforcement after handoff; the scope guard must be honored by the subsequent long run. Claude receives an instruction packet, not Codex persistent goal state. Unknown checks block readiness rather than being treated as available. The two release snapshots used for this page contain the same warmup workflow, references, and fixtures.