agentleFS
thepictishbeastthepictishbeast/claude-tools/skills/checkpoint/SKILL.md

checkpoint

Skill1 starsChanged 6 months agoMITView on GitHub

Capture the full Claude Code session state to disk so the user can safely restart Claude Code and pick up exactly where they left off. Pauses active loops, writes TaskList + background-process snapshot + handoff notes. Use when user says "checkpoint", "save state to restart", "I want to restart Claude safely", "pause everything", "/restart". After this runs, the user can /exit + relaunch + /restore.

91 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use aside, spinoff and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • TheKREATORSSkill

    aside

    Answer a quick side question without interrupting or losing context from the current task. Resume work automatically after answering.

    Also in 3 projects that use this

  • AhmedMerzaSkill

    spinoff

    After a branch is finished, harvest the work it made CHEAP — the helper you wrote that four other sites now hand-roll, the plumbing that turned a deferred feature small, the pattern that just split the codebase in two. Produces a follow-up backlog (0–3 candidates, feeding /issue), NEVER commits on the current branch. Invoke with /spinoff at the tail of the chain — after /fix-review has settled the review findings, before the MR merges — or when the user asks \"what else should we do while we're here / what did this unlock / anything to follow up on\". This is ship-check's optional twin — that finds what's MISSING and blocks the merge; this finds what's now CHEAP and blocks nothing. Restraint-gated: \"nothing spun off\" is the common and correct answer, and a finding that would have been equally valid before this branch is not a finding.

    Also in 3 projects that use this

  • TheKREATORSSkill

    instinct-export

    Export instincts from project/global scope to a file

    Also in 3 projects that use this

  • seek888Skill

    open-gstack-browser

    Launch GStack Browser — AI-controlled Chromium with the sidebar extension baked in. Opens a visible browser window where you can watch every action in real time. The sidebar shows a live activity feed and chat. Anti-bot stealth built in. Use when asked to "open gstack browser", "launch browser", "connect chrome", "open chrome", "real browser", "launch chrome", "side panel", or "control my browser". Voice triggers (speech-to-text aliases): "show me the browser".

    Also in 5 projects that use this

  • diego-tobalinaSkill

    build-fix

    Fix build and compilation errors systematically. Run when build fails.

    Also in 5 projects that use this

  • seek888Skill

    design-html

    Design finalization: generates production-quality Pretext-native HTML/CSS. Works with approved mockups from /design-shotgun, CEO plans from /plan-ceo-review, design review context from /plan-design-review, or from scratch with a user description. Text actually reflows, heights are computed, layouts are dynamic. 30KB overhead, zero deps. Smart API routing: picks the right Pretext patterns for each design type. Use when: "finalize this design", "turn this into HTML", "build me a page", "implement this design", or after any planning skill. Proactively suggest when user has approved a design or has a plan ready. (gstack) Voice triggers (speech-to-text aliases): "build the design", "code the mockup", "make it real".

    Also in 5 projects that use this

  • +2 more from TheKREATORS
  • +2 more from seek888

The file

Show its rules and text

We split this skill into the rules it gives an agent

13 rules. 0 are common, 5 are distinctive, and 8 are very specific to this project.

  • 0

    Common

    Most of the 85 edited versions we read keep these.

  • 5

    Distinctive

    This author's own choices. Worth a look.

  • 8

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    When you (the agent) execute /checkpoint:

    line 30
  2. Very specific:

    Wait for a safe stopping point: Don't checkpoint mid-tool-call.

    line 32
  3. Very specific:

    If a long-running background process is mid-flight (Bash with run_in_background: true), explicitly mention it to the user and ask whether …

    line 33
  4. Distinctive:

    Default: ask, don't decide silently.

    line 39
  5. Very specific:

    Call TaskList, then for each task call TaskGet to get the full description.

    line 55
  6. Very specific:

    If none: write a single line # no background processes.

    line 96
  7. Very specific:

    Write a short prose summary of "what was being worked on" to $HOME/.claude/.checkpoint/handoff.md.

    line 109
  8. Very specific:

    Write $HOME/.claude/.checkpoint/MANIFEST.json summarizing what was captured (file list, timestamps, counts):

    line 139
  9. Distinctive:

    If anything was lost (a bg process that couldn't be paused, etc.), say so explicitly with a recovery hint.

    line 178
  10. Distinctive:

    Don't write secret material to the checkpoint files.

    line 183
  11. Distinctive:

    Don't auto-commit dirty git trees.

    line 186
  12. Very specific:

    Don't try to capture the conversation history itself — that's Claude Code's --continue flag's job, not ours.

    line 187
  13. Distinctive:

    Don't checkpoint twice without an intervening /restore.

    line 189

“Common” is measured: kept by at least 6 in 10 of the 85 edited versions of this file we could read. “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

/checkpoint — save full session state for clean restart

Why this exists

Claude Code session state is partly persistent and partly not:

Survives a restart?Where it lives
✓ Files on diskregular filesystem
✓ User memory~/.claude/projects/*/memory/
✓ Conversation contextonly via claude --continue / equivalent
✗ TaskListsession-scoped, dies on exit
✗ Cron jobs from CronCreatesession-scoped, dies on exit
✗ Background Bash run_in_background processessession-scoped, dies on exit
✗ Loaded skill changes since startupreloaded fresh on next launch
✗ Anything in /tmp not on tmpfs persistencedepends on system reboot vs Claude restart

/checkpoint is a single command that drains the not-survives column to disk so /restore (in the next session) can re-hydrate the parts that can be rehydrated and tell you about the parts that can't.

Behavior summary

When you (the agent) execute /checkpoint:

  1. Wait for a safe stopping point. Don't checkpoint mid-tool-call. If a long-running background process is mid-flight (Bash with run_in_background: true), explicitly mention it to the user and ask whether to: a) wait for it to finish before checkpointing b) leave it running (it'll die at exit) and note the loss c) cancel it via TaskStop and then checkpoint Default: ask, don't decide silently.
  2. Capture the data (see Steps below).
  3. Report back with a clear "safe to restart now" signal AND a one-line summary of what was captured + what couldn't be.

Steps

State directory: $HOME/.claude/.checkpoint/ (mode 700). Create if absent. Delete any prior checkpoint at start — checkpoints are single-shot, not stacked. Warn the user if they're about to overwrite an unrestored prior checkpoint.

1. Tasks

Call TaskList, then for each task call TaskGet to get the full description. Write to $HOME/.claude/.checkpoint/tasks.json:

[
  {
    "subject": "Build foo",
    "description": "Full description here",
    "activeForm": "Building foo",
    "status": "in_progress",
    "owner": "agent-name-or-empty",
    "blockedBy": ["3", "5"]
  },
  ...
]

chmod 600.

2. Active loops

Reuse /loop-pause (invoke via the Skill tool). It writes $HOME/.claude/.paused-loops.json and CronDeletes each. The /checkpoint skill doesn't duplicate that work — just delegates.

3. Background processes

Capture any Bash run_in_background=true tasks that are still running. Use TaskList for the harness's task-runner tasks, OR look at the conversation for recent Bash calls with that flag and check their pid via pgrep. Write to $HOME/.claude/.checkpoint/processes.txt:

# Background processes at checkpoint time
# (cannot be auto-restarted; user must manually re-kick if needed)
2026-05-17T07:50:00Z pid=12345 cmd="nohup cargo build --release ..." cwd=/opt/vaultwarden
2026-05-17T07:50:00Z pid=23456 cmd="nohup aideinit -y -f"             cwd=/

If none: write a single line # no background processes.

4. Git state

For each directory in $HOME/projects/ (and $HOME/code/, $HOME/work/ if they exist), run git status --porcelain and write any non-clean repos to $HOME/.checkpoint/git-status.txt. If there are uncommitted changes, warn the user in the final report. Don't commit automatically — that's a user decision.

5. Handoff note

Write a short prose summary of "what was being worked on" to $HOME/.claude/.checkpoint/handoff.md. Pull from:

  • the in-progress tasks (priority 1)
  • the last few substantive turns of the conversation (priority 2)
  • any loop session log files (priority 3)

Format: ~10 lines max. Bullet form. Read like a sticky note to the next session's agent. Example:

# Checkpoint 2026-05-17T07:50:00Z

Last session was finishing the vaultwarden install on plausiden-prime.

In flight:
- Vaultwarden running on 127.0.0.1:8888 but Caddy vhost not hooked
  in yet (waiting on cert expansion)
- LE cert needs --expand to include vault.plausiden.com
- DNS for vault.plausiden.com is propagated

Tasks list saved: 2 in_progress, 1 pending.
Active loop: 1 paused (security/forge loop, cron */1 * * * *).

Run /restore in the new session to re-hydrate.

chmod 600.

6. Manifest

Write $HOME/.claude/.checkpoint/MANIFEST.json summarizing what was captured (file list, timestamps, counts):

{
  "checkpoint_at": "2026-05-17T07:50:00Z",
  "captured": {
    "tasks": 3,
    "active_loops_paused": 1,
    "background_processes": 0,
    "dirty_git_repos": 1
  },
  "files": [
    "tasks.json",
    "processes.txt",
    "git-status.txt",
    "handoff.md"
  ]
}

7. Tell the user

Format:

Checkpoint complete.

Captured:
- 3 tasks (2 in_progress, 1 pending) → ~/.claude/.checkpoint/tasks.json
- 1 active loop (security/forge, every minute) → paused via /loop-pause
- 0 background processes
- 1 dirty git tree (claude-tools — uncommitted README.md edit)

Safe to /exit and relaunch Claude Code now.

After relaunch, run /restore to re-hydrate.

If anything was lost (a bg process that couldn't be paused, etc.), say so explicitly with a recovery hint.

Don't

  • Don't write secret material to the checkpoint files. If a task description contains a secret, the checkpoint will leak it. Trust the user's task descriptions to already be clean.
  • Don't auto-commit dirty git trees. Only show them.
  • Don't try to capture the conversation history itself — that's Claude Code's --continue flag's job, not ours.
  • Don't checkpoint twice without an intervening /restore. Refuse if an old checkpoint is still on disk (or ask to overwrite).

What this is NOT

  • It's NOT a transaction log. There's no "rewind" — just save + restore + (eventually) delete-on-restore.
  • It's NOT a backup tool. ZFS snapshots / sanoid handle that layer.
  • It's NOT an alternative to git commits — uncommitted code stays uncommitted; we just inventory.

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.