agentleFS
dc143cDevdc143cDev/claude-chariot/skills/resume-mission/SKILL.md

resume-mission

Skill0 starsChanged 7 months agoMITView on GitHub

Resume a Chariot mission. Spawns the autonomous runner or reconnects to an existing one.

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
  1. Very specific:

    Read .chariot/state.json and check current status.

    line 14
  2. Distinctive:

    If status is "escalated":

    line 23
  3. Very specific:

    Read escalations array in state.json for failure reasons

    line 24
  4. Very specific:

    Read .chariot/worklog.md for failure history

    line 25
  5. Very specific:

    After user's choice, update state.json accordingly (reset fail_count if retry, advance task if skip)

    line 30
  6. Distinctive:

    Check if a runner is already alive:

    line 35
  7. Distinctive:

    STOP. Do not spawn a new runner.

    line 60
  8. Very specific:

    Use the dedicated launcher (bin/chariot-spawn.js).

    line 68
  9. Very specific:

    Read plugin_root from state.json (recorded by SessionStart hook), then run the launcher:

    line 74

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

/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":

  1. Read escalations array in state.json for failure reasons
  2. Read .chariot/worklog.md for failure history
  3. 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
  4. After user's choice, update state.json accordingly (reset fail_count if retry, advance task if skip)
  5. 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.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.