agentleFS
dtiger1889-opsdtiger1889-ops/claude-harness-toolbox/skills/checkpoint/SKILL.md

checkpoint

Skill31 starsChanged 31 days agoMITView on GitHub

Updates the current project's CHECKPOINT.md in place so another session can resume from verified state. Use for /checkpoint, "save progress", "update checkpoint", a completed unit of work, or impending compaction. Preserves history, records unfinished work, and runs bundled validation and size checks. Project-specific conventions override the default schema.

91 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use aside, instinct-export and 9 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

  • 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

  • ayudaySkill

    setup-deploy

    Configure deployment settings for /land-and-deploy. Detects your deploy platform (Fly.io, Render, Vercel, Netlify, Heroku, GitHub Actions, custom), production URL, health check endpoints, and deploy status commands. Writes the configuration to CLAUDE.md so all future deploys are automatic. Use when: "setup deploy", "configure deployment", "set up land-and-deploy", "how do I deploy with gstack", "add deploy config".

    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

9 rules. 0 are common, 7 are distinctive, and 2 are very specific to this project.

  • 0

    Common

    Most of the 85 edited versions we read keep these.

  • 7

    Distinctive

    This author's own choices. Worth a look.

  • 2

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Update existing state in place.

    line 8
  2. Distinctive:

    Verify claims you carry forward against the relevant artifacts.

    line 18
  3. Distinctive:

    Research: only during active milestone research.

    line 27
  4. Distinctive:

    Remove completed open items after ensuring they have a durable record.

    line 36
  5. Very specific:

    Use low when an executor can act from the bullet alone, high when substantial analysis or judgment remains.

    line 47
  6. Very specific:

    Every completed unit gets an entry in the project's existing changelog, including research-only work.

    line 53
  7. Distinctive:

    Run once when each touched checkpoint is final.

    line 83
  8. Distinctive:

    Default limits are 120 lines and 30 KB.

    line 85
  9. Distinctive:

    Use a connected filesystem, checking reachable roots when necessary.

    line 97

“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

Update existing state in place; do not create timestamped handoffs or replace a project's established schema. Honor an explicit stop after saving the requested partial state.

Resolve <skill-dir> to the directory containing this loaded SKILL.md, including plugin installations. Bundled helpers require PowerShell 5.1+ or pwsh 7+. Run them through native PowerShell.

1. Read and choose depth

Locate the nearest project CHECKPOINT.md and read it to EOF, continuing targeted reads if output is truncated. Read applicable project instructions.

Use a light close when this session already read and kept the file current: reconcile the live sections, add the completed unit's changelog record where the project keeps one, then validate and finish. Use a full review on a cold start, when the stamp is older than 30 days, or when requested. A light close still runs validation.

Verify claims you carry forward against the relevant artifacts. Recheck stale claims, resolve relative dates to absolute dates, and label uncertainty. A current stamp is not proof that every claim has been tested.

2. Reconcile live state

Preserve the existing sections. Default project schema:

  • Last updated: UTC timestamp and existing version tag only.
  • Status: present state, normally one line; for live data, point to the live source.
  • Goal: concrete completion condition, normally one to three lines.
  • Research: only during active milestone research.
  • Key decisions: choices still relevant to current work, attributed to their actual author. Point to durable decision records for settled detail.
  • Open threads: actual unfinished actions, dependencies, or user-requested watches.
  • Files that matter: paths with a short explanation.
  • Harness changelog: immutable completed-work history when the project keeps one.
  • Next step: one action, an explicit hold, or a pointer to choose from open work. The live user request outranks this suggestion.

Sweep the session for decisions, constraints, corrections, rejected approaches, and unfinished work. Record rejected approaches with their evidence and any condition for revisiting them. Keep session-specific feedback scoped to this work; only explicit or established standing preferences belong in permanent instructions.

Remove completed open items after ensuring they have a durable record. Relocate content to its real owner before removing it; never silently discard useful state.

An unresolved known defect remains open even when it cannot be checked now. Run checks within the current authorized scope when feasible. Do not invent future reassurance checks or watches with no evidence of a problem; retain watches the user explicitly requested.

3. Tag actionable threads

For the default tagged schema, end each top-level open bullet with:

  • [owner] [low] or [owner] [high] when the next step needs the user's hands or an explicit decision.
  • [agent] [low] or [agent] [high] for agent work.

Use low when an executor can act from the bullet alone, high when substantial analysis or judgment remains. Spell out the action in plain words. Optional [gates: go] or [blocked-by: dependency] tags precede the final pair. Sub-bullets need no tags.

The finisher sorts owner-low, owner-high, agent-low, agent-high. Model selection still follows the host's policy; these tags are planning hints.

4. Preserve history

Every completed unit gets an entry in the project's existing changelog, including research-only work. Default inline entries are newest-first ### YYYY-MM-DD -- summary (vN) blocks under Harness changelog. If the project uses a different history store or append helper, follow it.

Existing entries are immutable, including entries added earlier this session. Use surgical edits; carry old history byte-identically. Only correct a factual error when needed and record that correction in the new entry. Do not summarize or merge history to fit a cap.

Archive old entries only for overflow, using the bundled byte-preserving mover. Keep live sections concise and history in its proper section.

5. Validate before finishing

& "<skill-dir>/verify_checkpoint_claims.ps1" -Checkpoint "<checkpoint path>"

Exit 2 blocks completion for dead paths or undispositioned stale dated threads. Fix errors and rerun. Reconcile advisory prompts about state, attribution, tags, jargon, and verification claims; do not relay internal diagnostics as the user-facing report.

For a dated thread older than 30 days, verify and prune if resolved, or add [kept YYYY-MM-DD: specific reason]. A kept date must be within 30 days; its reason must be at least 12 characters and not reused for another bullet. An undated owner thread is advisory.

Configuration:

  • HARNESS_WORKSPACE_ROOT overrides the default parent directory used for cross-project paths.
  • HARNESS_NOTES_ROOT supplies the notes root when required.
  • HARNESS_OWNER_TAG names your own owner tag (for example Sam makes [Sam] count like [owner]).
  • staleness: advisory in the project's .checkpoint-verify-ignore changes stale-date errors to prompts; dead paths still fail.

These checks detect structural claims and date patterns, not semantic correctness. Read and assess the evidence yourself.

6. Finish and enforce limits

& "<skill-dir>/finish-checkpoint.ps1" -Checkpoint "<checkpoint path>"

Run once when each touched checkpoint is final. The helper stamps actual UTC, preserves the existing bare version tag, sorts threads, and measures limits. Update a changed version tag before running.

Default limits are 120 lines and 30 KB. Section guidance: Status one line/about 300 characters, Goal three lines, Next step two lines/about 350 characters. Open bullets over 700 characters get warnings. Section budgets are advisory unless <!-- checkpoint-budgets: strict --> appears in the first five lines.

On overflow, the finisher archives oldest changelog entries byte-verbatim to archive/harness_changelog.md, keeps the newest two inline, and maintains an Older entries pointer. If it still exits 2, re-read the modified file, relocate live detail to its owner, tighten live sections, and rerun. Report a remaining blocker; do not claim successful completion.

Re-read before any edit after a helper run because it changed the file on disk. For rare manual archive ranges, use the bundled archive-changelog.ps1 with -Checkpoint, -Archive, -FromLine, -ToLine, and -AtTop; read its parameter help before choosing a range. Verify the pointer afterward. Never use model regeneration for the move.

7. Report

Confirm the state saved and its path briefly. Include material open work or validation limitations; omit housekeeping output.

Restricted runtimes

Use a connected filesystem, checking reachable roots when necessary. Do not assume a container shell reaches the user's disk.

Without PowerShell, reconcile state manually, use a real UTC clock, measure line and byte counts with available tools, and preserve history exactly. Record "helpers not run" and the missing validation in the new entry. If a byte-preserving archive move is unavailable, leave history intact and record the overflow blocker rather than approximate the move or claim success.

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.