save
Skill4 starsChanged 28 days agoMITView on GitHub
Checkpoints session progress to status tracking files. Use to save state mid-session, after a major task, before ending, or when nearing context limits.
36 other projects use a version of this.
Adopted by
Most recently taken up by
- FabianoArthur/claude-code-kitchentheir own version, first seen Nov 8, 2026
- paulogabriel/beryltheir own version, first seen Nov 8, 2026
- matthewwong525/WongStacktheir own version, first seen Nov 8, 2026
- pche-broken-artist/forge-of-thoughttheir own version, first seen Nov 6, 2026
- egregore-labs/egregoretheir own version, first seen Nov 6, 2026
- vidit19sharma/neogentstheir own version, first seen Nov 1, 2026
Used with
Projects with it also use load, ingest 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.
TheLatentSpaceLabSkillload
Load a document into memory for RAG
Also in 4 projects that use this
JaimeGBASkillingest
Digest an external source (article, paper, transcript, URL, book chapter) and integrate its content into the knowledge base
Also in 8 projects that use this
ArtemXTechSkillquery
Query data from this vault. USE WHEN user asks about projects, clients, tasks, daily notes. Use grep to extract frontmatter - do NOT read full files.
Also in 4 projects that use this
szweibelSkillidea
Generate a wide field of options when the user is brainstorming, exploring, expanding, or pressure-testing — not recommending or implementing
Also in 3 projects that use this
GoogleSkilldashboard
Configures and launches the GKE Capacity & Triage Dashboard scoped to a GCP project ID, GKE cluster name, or target ML workload ID. Uses the configure-and-launch-dashboard action and launch-workload-dashboard workflow to verify local dashboard health, discover cluster capacity, trigger live scans, and generate deep-linked URLs. Use when the user types "/dashboard", says "launch dashboard", "open dashboard", "show capacity", or "view triage dashboard" with a project, cluster, or workload. Don't use for general workload log querying or automated failure attribution (use the troubleshoot skill).
Also in 4 projects that use this
Microsoft AzureSkilllint
Run all linting and spell checking for TypeScript and Rust code. Run this before committing to catch style issues, clippy warnings, and misspellings.
Also in 5 projects that use this
Other versions36 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 36
- AgriciDaniel/claude-obsidian★ 16ksame name
- egregore-labs/egregore★ 293same name
- romarayt/raytsystem-public-os★ 140same name
- thiagofinch/mega-brain★ 95same name
- sturlese/hippocampus★ 28same name
- endlessblink/master-plan★ 26same name
- pche-broken-artist/forge-of-thought★ 12same name
- CarbeneAI/Forge★ 9same name
- seongjaeryu/bindly-claude-code★ 8same name
- ARCASSystems/FounderOS★ 7same name
26 more not listed
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 repository5 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- code-reviewSkill
- critical-reviewSkill
- implement-batchSkill
- security-auditSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
16 rules. 0 are common, 12 are distinctive, and 4 are very specific to this project.
0
Common
Most of the 31 edited versions we read keep these.
12
Distinctive
This author's own choices. Worth a look.
4
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 19
If tests ran recently in this session, reference those results (pass/fail counts).
- Distinctive: line 20
If no test results are available, record "No test results available this session."
- Distinctive: line 21
Do NOT invent results.
- Very specific: line 33
When in doubt, prefer decision — better to over-document rationale than lose it.
- Very specific: line 47
Appending to existing files: When updating an existing session-progress.md, preserve all existing entries verbatim — only append new ones.
- Very specific: line 49
Auto-captured entries: If a ## Auto-captured section exists (added by the auto-capture hook), review those entries:
- Very specific: line 52
Remove the ## Auto-captured section after processing.
- Distinctive: line 55
Per-batch/phase breakdown: when following a plan — what each batch accomplished
- Distinctive: line 80
Add new rows to phase/version tables for completed work
- Distinctive: line 81
Update test results with latest counts
- Distinctive: line 82
Update plans on disk (add new plans, mark completed ones)
- Distinctive: line 83
Update next steps to reflect current state
- Distinctive: line 84
Update git state if relevant
- Distinctive: line 85
Update last updated timestamp
- Distinctive: line 86
Do NOT delete or rewrite sections that haven't changed
- Distinctive: line 87
If the file uses different section names, match its existing structure — don't force the template above
“Common” is measured: kept by at least 6 in 10 of the 31 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
Save Progress
This skill must only be invoked from the main session, never from a subagent.
- Determine the project name (used for file paths in all later steps):
a. If a
~/.claude/status/*/session-progress.mdwas written earlier this session, reuse that project name. b. Else if inside a git repo with a remote, use theoriginremote. Parse the last path component, stripping any trailing.git(e.g.,my-libfromgit@github.com:user/my-lib.gitorhttps://github.com/user/my-lib.git). c. Else use the basename of the git root (git rev-parse --show-toplevel). d. Else use the basename of the current working directory. e. If still ambiguous, ask the user. - Capture test state (do NOT run tests yourself — a Stop hook already runs pytest automatically):
- If tests ran recently in this session, reference those results (pass/fail counts).
- If no test results are available, record "No test results available this session."
- Do NOT invent results.
- Create the directory
~/.claude/status/<project-name>/if it does not exist. - Write/update
~/.claude/status/<project-name>/session-progress.mdwith:- Timestamp:
YYYY-MM-DD HH:MM UTC - Current task: what you were working on
Completed: detailed progress using typed entries. Each entry is classified and formatted as follows:
Entry types:
- Decision: The change involved choosing between alternatives or a non-obvious approach. MUST include a
Why:line. - Observation: A factual record of what happened with no meaningful alternatives considered. Plain body, no
Why:required. - When in doubt, prefer
decision— better to over-document rationale than lose it.
Entry format:
### [decision] Title describing the choice <!-- id:a1b2c3d4e5f6a7b8 --> Why: Rationale for this decision (SACRED — never compress or paraphrase). What: Implementation details (optional). ### [observation] Title describing what happened <!-- id:e5f6a7b8c9d0e1f2 --> Plain body text describing the change.Entry IDs: Generate a unique ID for each new entry — 16 hex characters (e.g.,
a1b2c3d4e5f6a7b8). Just produce a random-looking 16-char hex string.Appending to existing files: When updating an existing
session-progress.md, preserve all existing entries verbatim — only append new ones.Auto-captured entries: If a
## Auto-capturedsection exists (added by the auto-capture hook), review those entries:- Promote useful ones to the main Completed section.
- Upgrade observations to decisions with a
Why:line where appropriate. - Remove the
## Auto-capturedsection after processing.
Entry body content — draw from these details as appropriate:
- Per-batch/phase breakdown when following a plan — what each batch accomplished
- Files created, modified, or deleted — explicit paths (e.g.,
src/foo/bar.py— addedMyClass, refactoredprocess()) - Implementation specifics — functions, classes, modules, config options added or changed
- Issues encountered and workarounds — anything the next session should know about (e.g., "ruff F401 requires atomic edits", "had to retry due to X")
- Prior session context — when resuming multi-session work, summarize what earlier sessions completed so the file is self-contained
- Decision: The change involved choosing between alternatives or a non-obvious approach. MUST include a
- Remaining: bullet list of what's left, with enough detail to pick up without re-reading the plan
- Test state: from step 2
- Key decisions: any architectural or design choices made
- Active plan: path to the current plan file in
~/.claude/plans/<project-name>/, or "None" - Context needed to continue: anything a fresh session needs to know (key file paths, uncommitted state, critical checkpoints, next batch to start)
- Timestamp:
Update or create
~/.claude/status/<project-name>/project-status.md— the cumulative project history across all sessions:If the file does not exist, create it with these sections (adapt to the project):
- Overview: one-line project description
- Last Updated: timestamp
- Version History: table of released versions with features (if applicable)
- Phase Progress: table of completed items with status and key files touched
- Plans on Disk: paths to active/completed plan files with status
- Test Results: latest pass/fail/skip counts, coverage, lint status
- Next Steps: what comes next
- Deferred Work: backlog items with references to where they're documented
- Git State: uncommitted changes summary (user handles git)
If the file already exists, read it first and update the sections that changed this session:
- Add new rows to phase/version tables for completed work
- Update test results with latest counts
- Update plans on disk (add new plans, mark completed ones)
- Update next steps to reflect current state
- Update git state if relevant
- Update last updated timestamp
- Do NOT delete or rewrite sections that haven't changed
- If the file uses different section names, match its existing structure — don't force the template above
- Confirm to the user what was saved and where.
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.

