agentleFS
Noah-OSNoah-OS/longhaul/skills/checkpoint/SKILL.md

checkpoint

Skill4 starsChanged 24 days agoMITView on GitHub

Save this conversation's state as a checkpoint: the goal, the next action, what the user said, the facts found, the decisions and why, what failed, the files the next step needs, what is done, in progress and blocked, and how to verify. Longhaul puts it back after a compaction or a resume, with its age and what changed since. Use it when the state is worth keeping: before a compaction, at the end of a step, before stopping. The user can ask for it too.

93 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

We split this skill into the rules it gives an agent

4 rules. 0 are common, 1 is distinctive, and 3 are very specific to this project.

  • 0

    Common

    Most of the 87 edited versions we read keep these.

  • 1

    Distinctive

    This author's own choices. Worth a look.

  • 3

    Very specific

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

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

    Write this conversation's state as one JSON object with these twelve keys to the file named below, then save it with the command below.

    line 8
  2. Very specific:

    Start from the last checkpoint, the one that came back after the last compaction, if one did.

    line 33
  3. Distinctive:

    Only the main conversation saves a checkpoint.

    line 60
  4. Very specific:

    Write the JSON with the Write tool, as the whole content of one file, at this path (Longhaul's own folder, keyed to this session):

    line 63

“Common” is measured: kept by at least 6 in 10 of the 87 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

Write this conversation's state as one JSON object with these twelve keys to the file named below, then save it with the command below. goal and next_action are texts and required; the other ten are lists of texts and may be empty.

{
  "goal": "what this conversation is for, in a sentence or two",
  "next_action": "the one thing to do first when work resumes",
  "owner_said": ["2026-10-27: an instruction, preference or correction of the user's, near their own words"],
  "facts": ["a fact from tool output that would cost work to find again (a root cause, src/app.py:120, an id, a commit, a value, a test count), and where it came from"],
  "decisions": ["a choice made, because of why"],
  "tried_failed": ["an approach that failed, and why"],
  "working_set": ["a file or symbol the next step needs, with its lines: src/app.py 120-180"],
  "done": ["a step finished"],
  "in_progress": ["a step started and not finished, and where it stands"],
  "blocked": ["what waits, and on whom or what"],
  "changed_files": ["a/path/relative/to/this/folder.py"],
  "verification": ["the command that shows the work is right"]
}

Rules:

  • The next you starts from this and nothing else. Fill it: aim for 5,000 to 9,000 characters, with exact ids, file:line locations and numbers.
  • Start from the last checkpoint, the one that came back after the last compaction, if one did. Keep each owner_said and facts entry that still holds, word for word; drop only what no longer holds. When a fact changed, write the new one ending with (replaces: <the old one, short>) and leave the old one out. The save says how many of the last checkpoint's entries are missing.
  • Each decision gives its why on the same line.
  • next_action is the work itself, never a wait: if the user paused, put that in owner_said and write what to do first when they go on. An open question goes in blocked with the answer you would take.
  • Facts the next turn needs, not a narrative. Name files and commands rather than copying their contents.
  • Nothing secret: no tokens, keys or passwords. The save refuses a value shaped like one.
  • Caps: 1,000 characters per text, 20 entries per list, 16,000 bytes in all. A text up to 10% over is cut at the cap on a word and ends in …; the save's line says which. Further over, or a total more than 10% over, the save refuses and names each field with its size against the cap; shorten those and save again. What comes back is in the order above, up to about 9,000 characters, with one line naming what stayed in the file.
  • One line per text; no tabs. A newline or a tab in a text comes back as ?.
  • changed_files are absolute paths, or relative to the folder the command runs in (the Bash tool's current directory, which a cd changes). When the checkpoint comes back, Longhaul says which of them changed or went since it was written, and marks a facts or working_set entry that names a file changed since.
  • Only the main conversation saves a checkpoint. A subagent must not run this; it reports its state to its caller instead.

Write the JSON with the Write tool, as the whole content of one file, at this path (Longhaul's own folder, keyed to this session):

!echo "${LONGHAUL_HOME:-$HOME/.longhaul}/checkpoints/${CLAUDE_SESSION_ID}.state.json"

Then save it from that file. No session id is needed: the save takes this session's from the Bash tool's environment. In a print-mode run (claude -p) the Write tool is denied, so no checkpoint is saved there.

${CLAUDE_PLUGIN_ROOT}/bin/longhaul checkpoint save --file <that path>

Repeat the command's one line to the user as it is; do not show the JSON. The state file is removed once the save has saved it. If the save refuses, the file stays and the refusal names each field that is over: fix those with Edit, not by writing the whole file again, and save again. (A refusal for a credential removes the file: write it again without it.) The checkpoint is private (0600) under Longhaul's own folder, keyed to this session, and is read only by Longhaul's SessionStart hook, which puts the state back after a compaction or a resume, with its age and what changed since. If the user added a note ($ARGUMENTS), fold it into the state where it belongs.

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.