resume-mission
Skill0 starsChanged 7 months agoMITView on GitHub
Resume a Chariot mission. Spawns the autonomous runner or reconnects to an existing one.
In this repository4 other files it gives its agents.
- extendSkill
- haltSkill
- set-missionSkill
- statusSkill
The file
We split this skill into the rules it gives an agent
9 rules. About 0 are common, 3 are distinctive, and 6 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
6
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 14
Read .chariot/state.json and check current status.
- Distinctive: line 23
If status is "escalated":
- Very specific: line 24
Read escalations array in state.json for failure reasons
- Very specific: line 25
Read .chariot/worklog.md for failure history
- Very specific: line 30
After user's choice, update state.json accordingly (reset fail_count if retry, advance task if skip)
- Distinctive: line 35
Check if a runner is already alive:
- Distinctive: line 60
STOP. Do not spawn a new runner.
- Very specific: line 68
Use the dedicated launcher (bin/chariot-spawn.js).
- Very specific: line 74
Read plugin_root from state.json (recorded by SessionStart hook), then run the launcher:
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
/resume-mission
Resume the mission by launching (or reconnecting to) the autonomous runner.
Procedure
Step 1: Check State
Read .chariot/state.json and check current status.
status: "completed"→ "Mission already completed."status: "idle"or file missing → "No mission found. Run /chariot:set-mission first."status: "escalated"→ Go to Step 2 (Escalation Handling).status: "pending_restart"/"paused"/"running"→ Go to Step 3 (Runner Check).
Step 2: Escalation Handling
If status is "escalated":
- Read
escalationsarray in state.json for failure reasons - Read
.chariot/worklog.mdfor failure history - Explain the failure to the user and offer choices:
- Retry: Reset fail_count, retry the same task
- Skip: Jump to the next task
- Guided retry: User provides direction, then retry
- After user's choice, update state.json accordingly (reset fail_count if retry, advance task if skip)
- Proceed to Step 3.
Step 3: Check Runner Status
Check if a runner is already alive:
node -e "
const fs = require('fs');
const state = JSON.parse(fs.readFileSync('.chariot/state.json', 'utf-8'));
const pid = state.runner_pid;
if (pid) {
try { process.kill(pid, 0); console.log('ALIVE:' + pid); }
catch { console.log('DEAD:' + pid); }
} else {
console.log('NONE');
}
"If ALIVE:{pid} → Runner is already working. Show status:
Runner is already active (PID {pid}).
Log: tail -f .chariot/runner.log
Status: /chariot:status
Halt: /chariot:halt
No action needed. The runner continues autonomously.STOP. Do not spawn a new runner.
If DEAD:{pid} → Previous runner crashed. Clean up and respawn (Step 4).
If NONE → No runner. Spawn one (Step 4).
Step 4: Spawn Runner
Use the dedicated launcher (bin/chariot-spawn.js). It handles the
state update (status → running, reset fail counters, refresh
plugin_root, clear stale runner_pid) AND strips parent Claude session
env markers in one shot. Do NOT inline node -e blobs — zsh history
expansion mangles ! characters and the spawn fails.
Read plugin_root from state.json (recorded by SessionStart hook),
then run the launcher:
PLUGIN_ROOT=$(node -p "JSON.parse(require('fs').readFileSync('.chariot/state.json','utf-8')).plugin_root")
node "$PLUGIN_ROOT/bin/chariot-spawn.js"The launcher prints {"pid": <runner_pid>, "current_task": "..."} on
success. If it errors out (missing state.json, missing bin/chariot.js
under plugin_root), the message goes to stderr and exit code is 1.
Step 5: Confirm Launch
Display to the user:
══════════════════════════════════════════════════════════
CHARIOT RUNNER LAUNCHED
══════════════════════════════════════════════════════════
Current task: Task {current_task}
Progress: {completed_count}/{total_tasks}
Runner PID: {pid}
Log: .chariot/runner.log
The runner spawns fresh Claude sessions per task:
→ No context degradation (each task = clean slate)
→ Independent Inspector verification
→ Automatic commits on task completion
Commands:
/chariot:status — Check progress
/chariot:halt — Pause execution
tail -f .chariot/runner.log — Live log
You can close this session safely.
══════════════════════════════════════════════════════════Step 6: Done
STOP. Do not start any implementation work. The runner handles everything independently. This Claude session's job is done.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

