Resume an existing Codex mission from `.mission/` state, recover safely from stale context, show progress, and re-enter the inline execution loop.
Use this skill whenever a Codex mission already exists and you need to continue it from durable state instead of relying on prior conversation history.
The shared loop contract is canonical regardless of install mode. Resolve shared references in this order:
.mission-kit/references/loop-contract.md and
.mission-kit/references/mission-file-contract.md~/.mission-kit/references/loop-contract.md and
~/.mission-kit/references/mission-file-contract.mdshared/references/loop-contract.md and
shared/references/mission-file-contract.mdIf none of those locations exist, stop with a clear install diagnostic instead of guessing.
Use that resolved loop contract path for shared resume rules, especially the
state -> action resume dispatch table. Use the same source-vs-installed path
rule for mission-file-contract.md when you need the canonical mission file
schemas. This skill only adds Codex-specific resume mechanics around inline
execution recovery and fresh-session reconstruction.
.mission/<slug>/ files as the only reliable mission
memory..mission-kit/references/,
~/.mission-kit/references/, then shared/references/.state.json or
features.json can answer it directly..mission/ in the working directory..mission/ does not exist or contains no mission directories, stop with a
clear diagnostic and direct the user to $start-mission..mission/<slug>/, inspect at minimum:
state.jsonmission.mdfeatures.jsonvalidation-state.jsonAGENTS.mdplanning, in_progress, validating, paused, and blocked as resumable
active states.When multiple mission directories exist:
state.json says they are active.updatedAt descending and
resume the most recent active mission.This satisfies the multiple-mission rule: never pick a mission at random.
Read the selected mission's files defensively.
state.json must exist and parse as valid JSON.features.json must exist and parse as either the canonical top-level
{ "features": [...] } object or a legacy top-level array from older Claude
dry runs.validation-state.json must exist and contain assertion entries.mission.md and AGENTS.md must exist so scope and boundaries can be
reconstructed.If features.json is the legacy top-level array shape, treat it as a
compatibility shim by reconstructing it as { "features": <array> }, and note
that the next write should normalize it back to the canonical object wrapper.
If any required file is missing, truncated, or invalid:
state.json with mission lifecycle
fields, or features.json with a features array).state.json is corrupted but other files still exist, mention that the
mission can be repaired manually from the remaining file-backed artifacts,
but do not pretend the state is healthy.The goal is a clear diagnostic error, never a crash and never silent recovery by guesswork.
Once the mission passes validation, rebuild context from files in this order:
mission.md — mission goal, milestones, environment, validation strategy.AGENTS.md — mission boundaries, off-limits areas, conventions,
pre-existing issues.features.json — ordered queue, current statuses, milestone grouping,
fulfills mappings.state.json — lifecycle state, current feature, timestamps, session
bookkeeping.validation-state.json — assertion pass/fail/blocked ledger..mission/<slug>/services.yaml — test, lint, typecheck, build, and service
commands..mission/<slug>/library/ notes — architecture, environment, and
user-testing guidance.If file contents disagree with earlier conversation, trust the files.
Before re-entering execution, print a concise progress summary containing:
passed / failed / blocked / pending),state.json.lastCommitId,updatedAt timestamp,continueHere.lastAction, continueHere.nextStep, and
continueHere.ephemeralNotes when state.json.continueHere exists.Example summary shape:
Mission: codex-skills-rollout
State: in_progress
Milestone: codex-skills (2 of 5)
Features: 4 / 7 completed
Current feature: codex-resume-and-config
Assertions: 9 passed, 0 failed, 2 pending
Last commit: 9e7544cdef02977c0fda8427bd5e76de7c047b2e
Last activity: 2026-03-07T22:15:00Z
Next action: resume feature execution
Continue here: finished validator triage -> update config and rerun checks
Use state.json plus features.json to determine where to continue.
state: planningin_progress.state: in_progress with currentFeatureIdin_progress.state.json.continueHere exists, display it in the progress summary and
carry lastAction, nextStep, and ephemeralNotes into the resumed feature
execution context before taking any new steps.continueHere notes.state: in_progress without currentFeatureIdpending feature whose preconditions are satisfied.state: validatingfulfills assertions.state: pausedcontinueHere context describing which milestone completed and
that human review was requested.state.json back to in_progress.mission_resumed event to progress_log.jsonl.state: blocked or failedstate: completedAfter reconstructing context and choosing the resume point, continue using the
same loop as $start-mission:
RED -> GREEN -> VERIFY.features.json and state.json immediately at feature start and
feature completion.When context becomes stale, noisy, or unreliable, use this restart pattern:
$resume-mission..mission/<slug>/mission.md.mission/<slug>/AGENTS.md.mission/<slug>/features.json.mission/<slug>/state.json.mission/<slug>/validation-state.json.mission/<slug>/services.yaml.mission/<slug>/library/ notesThis is the durable restart model for long missions: fresh session + file reconstruction, never “keep going and hope the old context is still right.”
validation-state.json.