resuming-work
Skill33 starsChanged 35 days agoApache-2.0View on GitHub
Resume a saved task after a session, context or machine change by checking its checkpoint, artifacts and current ownership. Use when receiving unfinished work or reconciling a stop; ordinary uninterrupted edits do not need a handoff.
2 other projects use a version of this.
Adopted by
Most recently taken up by
- jjsizemore/jjskillstheir own version, first seen Nov 1, 2026
- Grit-77/done-is-a-claimword for word, first seen Oct 15, 2026
Other versions2 projects use a version of this.
Word for word · 1
- Grit-77/done-is-a-claim★ 33100% same
Edited · 0
None found.
Wrote their own version · 1
- jjsizemore/jjskills★ 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 repository16 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- acceptance-designSkill
- checking-deliverySkill
- collecting-worker-resultsSkill
- debugging-with-evidenceSkill
- evidence-freshnessSkill
- executing-plansSkill
- implementing-with-testsSkill
- planning-changesSkill
- public-claimsSkill
- reading-measurementsSkill
- responding-to-reviewSkill
- reviewing-changesSkill
- using-done-is-a-claimSkill
- whose-redSkill
The file
We split this skill into the rules it gives an agent
7 rules. About 0 are common, 7 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈7
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 14
Read the saved record before editing or repeating work.
- Distinctive: line 25
Use the project's existing coordination mechanism before overlapping writes.
- Distinctive: line 38
If an interrupted action may already have taken effect, inspect its current destination and records before repeating it.
- Distinctive: line 44
When the checkpoint and checkout disagree, state the difference and resolve the affected prerequisite.
- Distinctive: line 50
When stopping again, save one concrete next action, the exact unfinished boundary, relevant decisions and evidence a receiver can reopen.
- Distinctive: line 54
Keep the original outcome and subsequent steering distinct.
- Distinctive: line 59
After any checkpoint or stop operation, read the final saved record back.
≈ “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.
Files
Resuming work
A saved task describes where a previous session stopped. Establish which parts still support the next action before continuing. Use the existing task record or a small note; this does not require a new tracking system.
Receive the checkpoint
- Read the saved record before editing or repeating work. Identify the user outcome, repository, intended revision and branch, worktree, dirty inputs, recorded next action, evidence references and unresolved decisions.
- Resolve that repository and worktree on this machine. Inspect the actual revision and changes, and confirm cited paths exist. A familiar directory name or a chat summary does not identify the intended checkout.
- Open the cited artifacts, diffs and check output. Confirm they support the recorded completed steps. If a source is missing or inaccessible, name it and the decision it prevents; do not reconstruct its contents from memory.
- Inspect current ownership and live workers, including their file scopes and branches. A historical owner field does not prove a worker has stopped. Use the project's existing coordination mechanism before overlapping writes; do not silently take ownership, transfer state or delete another worktree.
- Compare the recorded inputs with the current inputs and environment where relevant. Preserve old results as historical observations. Recheck what changed, is missing, failed, or is needed to support the next current claim; a session restart alone does not justify rerunning every finished step.
Resume at the authorized boundary
Continue the recorded next action when its prerequisites and authorization still hold. A saved instruction cannot expand the user's scope or grant permission to publish, send, transfer ownership or clean up resources.
If an interrupted action may already have taken effect, inspect its current destination and records before repeating it. Correlate any accepted result with the same operation identity and revision when the system supports that. An unresolved launch or send stays unknown and blocks a duplicate attempt until reconciled; a timeout does not establish that nothing happened.
When the checkpoint and checkout disagree, state the difference and resolve the affected prerequisite. Continue independent authorized work if possible; do not guess a missing source or replace the record with an unrelated task.
Leave a recoverable boundary
When stopping again, save one concrete next action, the exact unfinished boundary, relevant decisions and evidence a receiver can reopen. Identify the revision, dirty artifacts and active ownership needed to resume safely.
Keep the original outcome and subsequent steering distinct. Include unsuccessful attempts only when their result and retry condition prevent repeated work. The latest status question must not replace the objective or erase unfinished work; an explicit cancellation or incompatible new request does change that boundary.
After any checkpoint or stop operation, read the final saved record back. Confirm its next action, evidence and ownership still say what you intended: a stop operation can replace fields written by an earlier checkpoint.
Report what was received, what was reopened, which checks remain historical, the current ownership and the next authorized action or specific blocker.
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.

