Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add KevinZai/commander --skill ccc-save-sessiongit clone --depth 1 https://github.com/KevinZai/commanderWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/kevinzai/commander/ccc-save-session)<a href="https://agentmods.dev/skills/kevinzai/commander/ccc-save-session"><img src="https://agentmods.dev/badge/skills/kevinzai/commander/ccc-save-session.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00038 | $0.01405 |
| Opus 5 | $0.00019 | $0.00702 |
| Sonnet 5 | $0.00008 | $0.00281 |
| Haiku 4.5 | $0.00004 | $0.00140 |
Grade A, and why
ccc-save-session scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 4d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 191 lines — stays where its author put it; the contents beside it link to each section on GitHub.
$ccc-save-session — Save Session State
Capture everything that happened in this session — what was built, what worked, what failed, what is left — and write it to a dated file so the next session can pick up exactly where this one left off.
When to Use
- End of a work session before closing Claude Code
- Before hitting context limits (run this first, then start a fresh session)
- After solving a complex problem you want to remember
- Any time you need to hand off context to a future session
Process
Step 1: Gather context
Before writing the file, collect:
- Read all files modified during this session (use git diff or recall from conversation)
- Review what was discussed, attempted, and decided
- Note any errors encountered and how they were resolved (or not)
- Check current test/build status if relevant
Step 2: Create the sessions folder if it does not exist
mkdir -p ~/.claude/sessions
Step 3: Write the session file
Create ~/.claude/sessions/YYYY-MM-DD-<short-id>-session.tmp, using today's actual date and a short-id that satisfies these rules:
- Allowed characters: lowercase
a-z, digits0-9, hyphens- - Minimum length: 8 characters
- No uppercase letters, no underscores, no spaces
Valid examples: abc123de, frontend-worktree-1
Invalid examples: ABC123de (uppercase), short (under 8 chars), test_id1 (underscore)
Full valid filename example: 2024-01-15-abc123de-session.tmp
Step 4: Populate all sections
Write every section honestly. Do not omit any section — write "Nothing yet" or "N/A" if a section genuinely has no content. An incomplete file is worse than an honest empty section.
Step 5: Show the file to the user
After writing, display the full contents and ask:
Session saved to [actual resolved path to the session file]
Does this look accurate? Anything to correct or add before we close?
Wait for confirmation. Make edits if requested.
Session File Format
# Session: YYYY-MM-DD
**Started:** [approximate time if known]
**Last Updated:** [current time]
**Project:** [project name or path]
**Topic:** [one-line summary of what this session was about]
---
## What We Are Building
[1-3 paragraphs describing the feature, bug fix, or task. Include enough
context that someone with zero memory of this session can understand the goal.
Include: what it does, why it is needed, how it fits into the larger system.]
---
## What WORKED (with evidence)
[List only things that are confirmed working. For each item include WHY you
know it works — test passed, ran in browser, Postman returned 200, etc.
Without evidence, move it to "Not Tried Yet" instead.]
- **[thing that works]** — confirmed by: [specific evidence]
If nothing is confirmed working yet: "Nothing confirmed working yet — all approaches still in progress or untested."
---
## What Did NOT Work (and why)
[This is the most important section. List every approach tried that failed.
For each failure write the EXACT reason so the next session does not retry it.
Be specific: "threw X error because Y" is useful. "did not work" is not.]
- **[approach tried]** — failed because: [exact reason / error message]
If nothing failed: "No failed approaches yet."
---
## What Has NOT Been Tried Yet
[Approaches that seem promising but have not been attempted. Ideas from the
conversation. Alternative solutions worth exploring.]
- [approach / idea]
If nothing is queued: "No specific untried approaches identified."
---
## Current State of Files
[Every file touched this session. Be precise about what state each file is in.]
| File | Status | Notes |
| ----------------- | -------------- | -------------------------- |
| `path/to/file.ts` | Done | [what it does] |
| `path/to/file.ts` | In Progress | [what is done, what is left] |
| `path/to/file.ts` | Broken | [what is wrong] |
| `path/to/file.ts` | Not Started | [planned but not touched] |
If no files were touched: "No files modified this session."
---
## Decisions Made
[Architecture choices, tradeoffs accepted, approaches chosen and why.
These prevent the next session from relitigating settled decisions.]
- **[decision]** — reason: [why this was chosen over alternatives]
If no significant decisions: "No major decisions made this session."
---
## Blockers and Open Questions
[Anything unresolved that the next session needs to address or investigate.
Questions that came up but were not answered. External dependencies waiting on.]
- [blocker / open question]
If none: "No active blockers."
---
## Exact Next Step
[If known: The single most important thing to do when resuming. Be precise
enough that resuming requires zero thinking about where to start.]
[If not known: "Next step not determined — review 'What Has NOT Been Tried Yet'
and 'Blockers' sections to decide on direction before starting."]
---
## Environment and Setup Notes
[Only fill this if relevant — commands needed to run the project, env vars
required, services that need to be running, etc. Skip if standard setup.]
[If none: omit this section entirely.]
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 4d ago First seen · 191 lines · 38 tokens per session scan A 2623dd718528
ccc-save-session is a skill published in the GitHub repository KevinZai/commander (6 stars, last pushed yesterday), licensed MIT. It adds 38 tokens to every session and 1,405 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-03.
Other skills, from other repositories
context-hygiene
Use when starting a project, reading project documentation or history, or resolving conflicts between documents. For current state, read only the latest documents designated by the project; do not proactively read archives; do not duplicate the spec; use long-term memory only for environment, people, and preferences…
agent-memory-mcp
A hybrid memory system that provides persistent, searchable knowledge management for AI agents (Architecture, Patterns, Decisions).
token-optimization
Use when the user says 'token optimization', 'save tokens', 'context window', 'reduce tokens', 'token stack', or 'TokenStack', or asks about extending context window capacity. Covers TokenStack, the built-in compression proxy that shrinks Claude Code tool output before it reaches the Anthropic API. Do NOT use for…
state
Use when the user says 'update state', 'project state', 'where was I', or at session start to load current context.
report
Writes the session final report to a file, then prints only the path and a one-line summary. Fires when the prompt contains "Report per memstack:report", and also when the prompt begins with a standing trigger configured through MEMSTACKREPORTONTASKPROMPTS or MEMSTACKREPORTTRIGGERS. Dormant otherwise.
atomic-wiki
Conversational wiki and capture-bucket routing. Fires when the user wants a place, space, or folder for notes, research, tickets, raw dumps, or knowledge capture — checks the block in /.claude/CLAUDE.md; if the cwd is under a registered realm, creates the folder as a bucket via atomic wiki bucket add rather than a…