| name | session-notes |
| description | 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. |
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 (with mkdir -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.md for 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 to INDEX.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>
</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>
<h2>Techniques</h2>
<div class="flow"></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.md if 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.
