cold-start-resume
Skill2 starsChanged 23 days agoApache-2.0View on GitHub
Survey what changed before resuming work after a literal interruption: an app restart, a context cap, a machine sleep, a crash, or "resume" / "continue from where we left off" after the session went quiet while other sessions, the user, or automated jobs could have touched the repository. Trigger phrases include "cold start", "resume", "I had to restart", "continue from where we left off", "we may have changed files during the pause", "verify before writing". Do NOT use on the first turn of a brand-new session, or for a plain status question ("what's the state of X"), which is answered directly.
In this repository7 other files it gives its agents.
- decision-packetSkill
- dreamSkill
- kill-zombiesSkill
- mirror-lookSkill
- move-and-repointSkill
- session-summarySkill
- transfer-promptSkill
The file
We split this skill into the rules it gives an agent
2 rules. About 0 are common, 2 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
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 27
Run it in one batch. Breadth first, depth only where something moved.
- Distinctive: line 58
Needs you: only what you cannot settle yourself.
≈ “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
Cold-Start Resume: survey before you write
A note is history. The system is state. Whatever this session remembers, and whatever any resume note, job file, or summary says, describes the repository as it was. Other sessions, the user, and scheduled jobs kept working while this one was offline. Resume from what is true now.
Resuming without checking produces three failures: redoing work a parallel session finished, overwriting edits made during the pause, and telling the user something is pending when it shipped an hour ago.
The survey (read-only: write nothing until it is done)
Run it in one batch. Breadth first, depth only where something moved.
- Your own artifacts. For each file or object this session was building, read it back by name. If it changed after your last edit, someone else touched it: read the new state, then confirm the markers your edit introduced are still there.
- What moved since you left.
git log --since=<when you paused>andgit status. New commits and uncommitted changes from other sessions are the map of parallel work. - The live record. The tracker, decision log, and changelog the repository uses. A row you were about to fill may be done. A decision made elsewhere may have retired your task entirely. Check for that before checking progress.
- Outside the repository. Files on disk do not capture what happened in other systems: a merged or closed PR, a CI result, an issue comment, a deploy, a reply in a message thread. Re-query every external system the work touched. This is the step most often skipped and the one that produces the most confident wrong claims.
- Other sessions' notes. Recent session records or drafts dated inside your pause window are parallel work. Read enough to know whether they overlap yours. Never silently continue another session's work.
An empty result is a finding to check, not a clean bill. A glob that is not recursive, a search run in the wrong directory, or a query against a source that does not hold the answer all return nothing, and nothing reads as "no changes". Before you report "no parallel work", confirm the probe could have found some.
Report, then continue
Give the user five short lines before the first write:
- Intact: your work that survived unchanged.
- Changed: what others moved, with where you saw it.
- Still open: items from before the pause that are still open now.
- No longer open: items that finished, or were retired by a decision, during the pause.
- Needs you: only what you cannot settle yourself.
Then resume on the current state, not the remembered one.
Anti-patterns
- Continuing "where we left off" by writing before the survey.
- Assuming a background agent from before the pause is still alive. It is not; treat its last output as final.
- Appending a second changelog entry for work a parallel session already logged.
- Treating another session's draft as authoritative. It may be unapplied or superseded.
- Trusting a state line in a note without re-running the check that produced it.
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.

