Snapshot
Generates a structured, copy-paste-ready summary of the current session whenever the user types "/snapshot". Trigger immediately on "/snapshot" in any message. Also trigger for variations like "/recap", "/summary", "/handoff", "/context" or requests like "summarize the session", "what have we done", "export context", "catch me up", or "prepare context for a new chat".From its SKILL.md
npx -y skills add Pedro-B-Siqueira/snapshot --skill snapshotAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
4.3 KB, 926 tokens by cl100k_base, as published. Nobody here has run it
Snapshot — /snapshot
What this skill does
When the user types /snapshot, read the entire conversation and produce a single
copy-pasteable block that preserves all critical context — so they can open a new
chat and pick up exactly where they left off, without re-explaining anything.
How to generate the snapshot
Step 1 — Read the full conversation
Scan every message before writing a single word of output.
Step 2 — Extract critical elements
Look for:
- Project context: name, stack, language, frameworks, environment, repo
- Main goal: what was being built or solved
- Key decisions: architecture choices, libraries picked, alternatives rejected and why
- Essential code: central functions, data structures, configs, API contracts
- Problems & fixes: bugs hit, errors seen, workarounds applied
- Current state: what's working, what's broken, what's untouched
- Next steps: anything explicitly agreed upon or left pending
- Sensitive data screening: STRICTLY IDENTIFY AND IGNORE all API keys, access tokens, passwords, and sensitive credentials.
Step 3 — Write the output block
Use exactly this format — no extra commentary before or after:
## 📸 Session Snapshot
**Project:** [name / one-line description]
**Stack:** [languages, frameworks, key tools]
**Goal:** [what was being built or solved]
---
### What we did
• [Bullet 1 — critical decision or action, self-contained with enough context to never need re-asking]
• [Bullet 2 — ...]
• [Bullet 3 — ...]
• [Bullet 4 — ...]
• [Bullet 5 — ...] ← minimum 5
• [Bullet 6 — ...] ← include if there's relevant content
• [Bullet 7 — ...] ← include if there's relevant content
---
### Current state
[2–4 lines: what's working, what's pending, what's broken]
---
### Essential code
```[language]
[Only the most critical snippet — key function, data structure, config, or API shape.
Omit this section entirely if no code is relevant.]
```
---
### Security Note
[Include ONLY IF sensitive data like API keys/tokens were shared in the session but skipped:]
> ⚠️ **Notice:** Chaves sensíveis (API keys, tokens, etc.) foram compartilhadas na sessão original, mas foram ignoradas e removidas na criação deste snapshot por motivos de segurança.
---
### Agreed next steps
• [Next step 1]
• [Next step 2]
---
> Paste this block at the top of your next chat to continue right where you left off.
Quality rules
- Every bullet must be self-contained — someone reading it cold should have full context, no guessing.
- Be specific — use real file names, function names, variable names, error messages. Never generalize.
- Decisions need reasons — if something was rejected, say why (e.g., "dropped Redux for Zustand — too much boilerplate for this scope").
- Code only if essential — don't paste everything; only what a new chat would need to avoid rework.
- No filler — never write "we did several interesting things". Be direct and dense.
- Privacy first — NEVER include API keys, passwords, or sensitive credentials in the snapshot.
- Match the user's language — if they wrote in Portuguese, snapshot in Portuguese. If English, English.
- Bullet length — 1–3 lines each. No sub-bullets.
Short session handling
If the session has fewer than 3 meaningful exchanges or no substantial technical content, respond with:
"The session is too short for a useful snapshot yet. Keep working and run
/snapshotagain when there's more to capture."
Example: bad bullet vs. good bullet
❌ Bad:
• We worked on authentication and fixed some issues.
✅ Good:
• Implemented JWT auth with refresh tokens — access token expires in 15min, refresh in 7 days. Refresh token is stored in an
httpOnlycookie (not localStorage) to prevent XSS. Refresh endpoint isPOST /api/auth/refresh. Rejected session-based auth because the app is stateless.
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.
Gives 0 of the 12 instructions most note taking skills give in 926 tokens
Counted across 632 of the 857 authors here whose files we hold, read 2026-09-06
- Use standard Markdown links for external URLsin 16 of 632, across 8 files
- Use wikilinks for internal vault connectionsin 15 of 632, across 7 files
- Embed content using the exclamation mark prefixin 14 of 632, across 6 files
- Ask for clarification if the user request is ambiguousin 13 of 632
- Add frontmatter properties at the top of the filein 12 of 632, across 4 files
- Verify note renders correctly in reading viewin 12 of 632, across 4 files
- Include a visual element on every slidein 11 of 632, across 5 files
- Left-align body text and listsin 11 of 632, across 5 files
- Maintain 0.5 inch minimum marginsin 11 of 632, across 5 files
- Wrap formulas containing double quotes in single quotesin 11 of 632, across 5 files
- Repeat one distinctive visual motif across all slidesin 10 of 632, across 4 files
- Use 36pt or larger for slide titlesin 10 of 632, across 4 files
Said here and by no other author read
- Scan every message before writing output
- Extract project context and main goals
- Identify key decisions and technical reasons
- Include essential code snippets only
- Summarize current state and next steps
- Ensure every bullet is self-contained
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.