context-checkpoint
Skill0 starsChanged 5 months agoMITView on GitHub
Use whenever a session's context approaches its working limit OR the current atomic task completes. Cleanly checkpoint progress to a task file, commit, and end the session so a fresh one can resume — preventing quality loss from a bloated context window.
5 other projects use a version of this.
Adopted by
Most recently taken up by
- yogsoth-ai/context-managementtheir own version, first seen Oct 13, 2026
- adamentwistle/fable-skillstheir own version, first seen Sep 3, 2026
- cyrus-tt/claude-context-checkpointtheir own version, first seen Jul 4, 2026
- clarity-digital-development/tworkflowtheir own version, first seen Jul 1, 2026
- pauloribeiro16/my-skillstheir own version, first seen May 28, 2026
Other versions5 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 5
- adamentwistle/fable-skills★ 98same name
- clarity-digital-development/tworkflow★ 47same name
- cyrus-tt/claude-context-checkpoint★ 9same name
- yogsoth-ai/context-management★ 2same name
- pauloribeiro16/my-skills★ 1same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository7 other files it gives its agents.
- ai-proxy-guardSkill
- consent-complianceSkill
- monorepo-bootstrapSkill
- review-gateSkill
- rls-securitySkill
- security-reviewSkill
- test-and-fixSkill
The file
We split this skill into the rules it gives an agent
6 rules. 0 are common, 3 are distinctive, and 3 are very specific to this project.
0
Common
Most of the 4 edited versions we read keep these.
3
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
- Distinctive: line 8
Treat the context window like a budget.
- Distinctive: line 15
If you can't read token usage directly, estimate from files read + edits + tool output, and checkpoint early.
- Distinctive: line 20
Run your project's done-checks for what's complete (build, typecheck, lint, relevant tests).
- Very specific: line 23
Update tasks.md for the current task: set Status (DONE / BLOCKED / IN_PROGRESS).
- Very specific: line 30
Read tasks.md + MEMORY.md and only the files the next task needs — not the whole repo.
- Very specific: line 35
If a task won't fit one session, split it into independently completable sub-tasks in tasks.md, carry over dependencies, note why, and do …
“Common” is measured: kept by at least 6 in 10 of the 4 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.
Files
context-checkpoint
Treat the context window like a budget. One task ≈ one session. Checkpoint and resume cleanly
instead of letting a session drift toward its limit mid-task. Progress lives in a shared
tasks.md, so any session can stop and a fresh one can pick up with no lost work.
Thresholds
- Set a soft ceiling (e.g. ~70-80% of your model's context) and a hard ceiling you never cross. When you approach the soft ceiling OR finish the current atomic unit, checkpoint and end.
- If you can't read token usage directly, estimate from files read + edits + tool output, and checkpoint early. Early is always safe — resuming is cheap.
Checkpoint sequence (run at end of every session)
- Reach a safe stopping point — a complete function / file / passing test, not a half edit.
- Run your project's done-checks for what's complete (build, typecheck, lint, relevant tests).
git commitwith a message referencing the task id (wip:if intentionally partial). Uncommitted work is lost work.- Update
tasks.mdfor the current task: set Status (DONE/BLOCKED/IN_PROGRESS); if not done, record a Checkpoint (what's complete) and Resume notes (exact next step, files in play, decisions made). Append a line to a Session Log. - Append durable learnings to a
MEMORY.md(short bullets) so future sessions don't re-derive them. - End / clear the session. Do not keep working in the same context.
Resume sequence (new session)
- Read
tasks.md+MEMORY.mdand only the files the next task needs — not the whole repo. - Pick the first task whose dependencies are met. Set
IN_PROGRESS, record the session id, work. - Checkpoint again when near the soft ceiling or the task completes.
Splitting a too-large task
If a task won't fit one session, split it into independently completable sub-tasks in tasks.md,
carry over dependencies, note why, and do the first sub-task. Never carry a half-done task across a
session boundary without a written checkpoint.
Token tactics
Near-zero model cost — this is bookkeeping the agent runs itself. Keeping sessions small is the single biggest quality + cost win: a fresh lean context beats a bloated one every time.
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.