session-notes
Skill9 starsChanged 4 months agoMITView on GitHub
Distill the tools, CLI commands, queries, and reasoning/investigation moves used in this Claude Code session into per-topic HTML learning notes under ~/notes/session-notes/topics/ (e.g. terminal tricks, ClickStack queries, gradle/kotlin) — appending to existing topic files rather than creating a new file per session. Use when the user asks to save session notes, write up what was learned, capture the techniques/tricks used, make a note of how a problem was investigated, or invokes /session-notes.
6 other projects use a version of this.
Adopted by
Most recently taken up by
- GoogleCloudPlatform/devrel-demostheir own version, first seen Nov 8, 2026
- webcane/skillstheir own version, first seen Nov 4, 2026
- bbeny123/pragmatheir own version, first seen Nov 1, 2026
- fabioc-aloha/alex-cognitive-architecturetheir own version, first seen Apr 26, 2026
- aemerson-commits/shareable-skillstheir own version, first seen Mar 30, 2026
- dl-portfolio/claude-skillstheir own version, first seen Feb 25, 2026
Other versions6 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 6
- GoogleCloudPlatform/devrel-demos★ 397same name
- bbeny123/pragma★ 2same name
- aemerson-commits/shareable-skills★ 1same name
- dl-portfolio/claude-skills★ 0same name
- fabioc-aloha/alex-cognitive-architecture★ 0same name
- webcane/skills★ 0same 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.
The file
We split this skill into the rules it gives an agent
8 rules. 0 are common, 5 are distinctive, and 3 are very specific to this project.
0
Common
Most of the 6 edited versions we read keep these.
5
Distinctive
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 14
If non-empty, scope extraction to that focus (e.g.
- Distinctive: line 33
Do not include: routine file edits, boilerplate tool-call narration, anything already obvious from reading the diff, or invented commands …
- Distinctive: line 35
If the session was thin (few tool calls, mostly conversation) or nothing extracted meets this bar, say so and write nothing rather than …
- Distinctive: line 37
Before saving anything, treat the session as potentially sensitive:
- Distinctive: line 39
Use only transcript content currently available in context.
- Very specific: line 48
Check INDEX.md for an existing matching slug.
- Very specific: line 49
If none fits, invent a short kebab-slug + one-line scope (e.g.
- Very specific: line 116
Read INDEX.md (create an empty file if missing) to see known topics.
“Common” is measured: kept by at least 6 in 10 of the 6 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
Session Notes
Turn this session into personal learning artifacts, filed by topic — not a diary entry per session. The point is for the user to learn from watching Claude work and to build up a small, durable set of reference pages (one per recurring kind of tool/technique) that grow over time, rather than accumulating one throwaway HTML file per session.
Request
$ARGUMENTS
If non-empty, scope extraction to that focus (e.g. "just the gcp cli stuff", "the debugging flow, skip the code changes"). If empty, cover the whole session.
Storage layout
~/notes/session-notes/topics/INDEX.md— plain markdown, one line per known topic:- <slug> — <title> — <one-line scope>. This is the registry of topic files that exist. Read it first; create it (withmkdir -p) if missing.~/notes/session-notes/topics/<slug>.html— one accumulating page per topic. Newest session's material goes at the top (just under the page intro), older entries stay below it, unmodified.
Topics grow organically: match extracted material against INDEX.md first. Only add a new topic (new slug + line in INDEX.md + new HTML file) when something genuinely doesn't fit any existing topic — don't fragment a topic that already exists into a near-duplicate (e.g. don't create gcloud-cli if terminal-tricks already covers general CLI usage and gcloud specifically doesn't come up often enough to warrant its own file — but do split it out once gcloud material recurs across sessions). When unsure whether something fits an existing topic, prefer reusing the existing one over fragmenting.
What to extract
Re-read the actual transcript of this session (tool calls and their real arguments/output), not just your final summary to the user. Pull out things a learner would want to remember — skip anything routine or self-explanatory:
- Exact commands run:
gcloud,grep/rg,gh,docker,curl,jq, gradle/sbt/pnpm invocations — especially non-obvious flags or pipelines, not "ran the tests." - Exact queries: ClickStack/HyperDX SQL, BigQuery, jOOQ, GraphQL — the ones that actually produced an insight, plus what each one proved.
- Code-reading strategy: which file/symbol you looked at first and why, how you decided a hypothesis was wrong, when you reached for Explore/a subagent vs. reading directly.
- Investigation shape: the sequence of questions asked → observation → next question, if the session was a debugging/investigation task.
- Reusable techniques: any move that generalizes beyond this specific bug/task (e.g. "aggregate by trace ID before bucketing," "attributes can lie, count the real spans instead").
Do not include: routine file edits, boilerplate tool-call narration, anything already obvious from reading the diff, or invented commands you didn't actually run this session.
If the session was thin (few tool calls, mostly conversation) or nothing extracted meets this bar, say so and write nothing rather than padding a topic file with filler.
Before saving anything, treat the session as potentially sensitive:
- Use only transcript content currently available in context. Never reconstruct missing commands, outputs, or reasoning.
- Redact API keys, passwords, access tokens, cookies, authorization headers, private URLs, internal hostnames, customer data, and other sensitive values as
[REDACTED]. - HTML-escape all inserted text, including commands, queries, labels, and explanations, so
<,>,&, and quotes cannot break the document or become markup.
Classify into topics
Group the extracted material by topic (e.g. a session that both greps logs and writes a ClickStack query produces two small entries — one for a terminal/grep topic, one for a ClickStack topic — not one mixed entry). A single session commonly touches 1-3 topics; that's expected.
For each topic touched:
- Check
INDEX.mdfor an existing matching slug. - If none fits, invent a short kebab-slug + one-line scope (e.g.
clickstack-queries — HyperDX/ClickStack SQL patterns for reading prod logs), append it toINDEX.md.
Per-topic HTML format
Self-contained HTML, no external CSS/JS/fonts, inline <style> only. If the topic file doesn't exist yet, create it from this skeleton:
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>{{Topic title}} — session notes</title>
<style>
:root { color-scheme: light; }
body { font: 15px/1.6 -apple-system, system-ui, sans-serif; max-width: 880px; margin: 40px auto; padding: 0 20px; color: #222; background: #fff; }
h1 { font-size: 22px; margin-bottom: 2px; }
h2 { font-size: 14px; margin-top: 20px; color: #444; }
.sub { color: #666; font-size: 13px; margin-bottom: 20px; }
table { border-collapse: collapse; width: 100%; margin: 12px 0; font-size: 14px; }
th, td { border: 1px solid #e3e3e3; padding: 7px 10px; text-align: left; vertical-align: top; }
th { background: #f6f8fa; }
code { font: 13px ui-monospace, Menlo, monospace; background: #f0f0f0; padding: 1px 5px; border-radius: 4px; }
pre { background: #f6f8fa; border: 1px solid #e3e3e3; border-radius: 6px; padding: 12px 14px; overflow-x: auto; font: 12.5px/1.5 ui-monospace, Menlo, monospace; }
.flow { background: #f6f8fa; border: 1px solid #e3e3e3; border-radius: 6px; padding: 14px; white-space: pre; font: 12.5px/1.45 ui-monospace, Menlo, monospace; overflow-x: auto; }
.q { color: #555; margin: 14px 0 4px; font-weight: 600; }
.tag { display:inline-block; background:#eef; color:#336; font-size:11px; padding:1px 6px; border-radius:4px; }
.entry { margin-top: 28px; padding-top: 18px; border-top: 2px solid #e3e3e3; }
.entry:first-of-type { border-top: none; padding-top: 0; margin-top: 18px; }
.date { color: #888; font-size: 12px; margin: 0 0 8px; }
</style>
</head>
<body>
<h1>{{Topic title}}</h1>
<p class="sub">{{one-line scope of this topic file}}</p>
<!-- ENTRIES: newest first. Insert new sections immediately after this marker. -->
</body>
</html>Each session's contribution to a topic is one <section class="entry">, inserted immediately after the <!-- ENTRIES --> marker (i.e. above all existing entries — newest first):
<section class="entry">
<p class="date">{{YYYY-MM-DD}} — {{one-line session focus}}</p>
<h2>Commands & queries</h2>
<p class="q">{{short label}}</p>
<pre>{{the actual verbatim command/query}}</pre>
<p class="sub">→ {{what it proved / why it mattered}}</p>
<!-- repeat per command/query -->
<h2>Techniques</h2>
<div class="flow"><!-- 1-3 generalizable lessons for this topic, each with a one-line "why this works" --></div>
</section>Omit the Commands & queries or Techniques block within an entry if there's nothing genuine for it. Use date +%F for the date — don't guess it.
Dedupe before writing: before adding a command/query block to a topic file, check whether an identical (or trivially-varied) command already appears somewhere in that file. If so, don't re-add it — this keeps topic files from bloating with repeats of the same grep/gcloud invocation across sessions. A genuinely new variant (different flags, different insight) is fine to add.
Saving
mkdir -p ~/notes/session-notes/topics- Read
INDEX.md(create an empty file if missing) to see known topics. - For each topic touched this session: read the existing topic file if present (to dedupe against and to insert above), or start from the skeleton if new; write the updated file; update
INDEX.mdif a new topic was added. - Report back only the topic file(s) touched (created vs. appended) and a one-line description each — do not paste the full HTML into the chat.
Note: earlier sessions may have used a now-retired per-session format (~/notes/session-notes/<date>-<slug>.html, one file per session). Leave those alone; don't migrate them automatically unless asked.
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.

