agentleFS
Ar9avAr9av/obsidian-wiki/skills/session-brain/SKILL.md

session-brain

Skill3.7k starsChanged 7 days agoMITView on GitHub

Build or refresh a browser-viewable topic graph over Claude session history using local clustering. Use for mapping or clustering sessions, recent or stale topic analysis, or rebuilding/showing the session graph. Unlike wiki-history-ingest, it indexes raw sessions and never writes to the vault.

Adopted by

Steady: 0 new projects took it in the last 4 weeks, none the 4 weeks before.thin data

Week of Sep 13: 0 new projectsWeek of Sep 20: 0 new projectsWeek of Sep 27: 0 new projectsWeek of Oct 4: 0 new projectsWeek of Oct 11: 0 new projectsWeek of Oct 18: 0 new projectsWeek of Oct 25: 0 new projectsWeek of Nov 1: 0 new projects
Sep 2026Oct 2026Nov 2026
New projects taking a version of this file each week, over the 8 weeks our latest run read: only 0 in all, so this is a hint, not a trend.

Who's talking about Ar9av/obsidian-wiki

The biggest 5 of 27 mentions linking to the repository that our crawl found. Each line is their own headline.

See all 27

Talked about on GitHub and Bluesky (27 times).

On GitHub · 25

20 more on GitHub

On Bluesky · 2

The file

We split this skill into the rules it gives an agent

4 rules. About 0 are common, 0 are distinctive, and 4 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈0

    Distinctive · estimate

    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
  1. Very specific:

    All the heavy lifting is deterministic Python in the obsidian-wiki CLI.

    line 12
  2. Very specific:

    Write a 3–5 word name and a one-sentence summary per cluster, then:

    line 53
  3. Very specific:

    If a cluster's terms are genuinely incoherent, name it honestly ("mixed — short sessions") rather than inventing a theme.

    line 65
  4. Very specific:

    Read clusters.json and tell the user:

    line 70

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Session Brain

Builds a searchable topic graph over your agent session history. The output is a sidecar at ~/.claude/session-brain/ — the vault is never touched.

All the heavy lifting is deterministic Python in the obsidian-wiki CLI. Your only job is to name the clusters, which takes exactly one turn and requires reading no transcripts.

When to use which skill

GoalSkill
Build or refresh the graph; survey topicssession-brain (this one)
Find and load a specific past sessionsession-search
Distil sessions into permanent vault pageswiki-history-ingest / claude-history-ingest

Step 1: Build

obsidian-wiki sessions-build --json

Roughly 3 seconds cold on ~1000 sessions, well under a second incrementally — it re-reads only transcripts whose size or mtime changed. Useful flags:

FlagWhen
--fullIgnore all caches and re-read everything
--mutualTighter, smaller clusters (mutual-kNN edges only)
--half-life NChange the recency half-life (default 90 days)
--min-sim 0.15Fewer, stronger edges — use if the graph is too dense to read
--skip nameExclude a project. Match is substring-based; pass the bare name, because cache dirs start with - and argparse reads that as a flag

Report the headline numbers: total sessions, how many have transcripts vs. are history-only, edges, and cluster count.

Step 2: Name the unnamed clusters

obsidian-wiki sessions-clusters --unnamed --json

Each cluster comes with top_terms and exemplars (its three highest-degree sessions, whose titles are already in graph.json). That is all you need. Do not open transcripts to name a cluster — the whole design goal is that naming costs one turn regardless of corpus size.

Write a 3–5 word name and a one-sentence summary per cluster, then:

obsidian-wiki sessions-name --from - <<'EOF'
[{"id": 3, "name": "warden telemetry pipeline", "summary": "Building and debugging the redacted telemetry chain."}]
EOF

Names are stored in names.json keyed by the cluster's dominant vocabulary, not its id — so they survive rebuilds even though cluster ids are positional and shift as the corpus grows. On repeat runs --unnamed is usually empty and this step is free.

If a cluster's terms are genuinely incoherent, name it honestly ("mixed — short sessions") rather than inventing a theme.

Step 3: Report the map

Read clusters.json and tell the user:

  • Biggest topics — by size
  • What's hot — highest momentum (activity in the last 30 days vs. the 60 before it)
  • What's gone quiet — dormant: true (low recency and nothing in 60 days)
  • Where topics meet — bridges, the sessions that connect two otherwise separate topics. These are often the most interesting sessions in the graph.

Then offer the visualisation:

open ~/.claude/session-brain/graph.html

Node size is session length, brightness is recency, hollow rings are history-only sessions, and gold borders are bookmarked ones. The time slider and search box filter together.

Notes

  • Never write to the vault from this skill. If the user wants session knowledge in the vault, that is wiki-history-ingest.
  • History-only sessions are real. Roughly 40% of a long-lived cache exists only as prompts in history.jsonl; those get graph nodes and are findable, but can never be loaded. Say so plainly rather than implying they are missing.
  • The graph is derived data. If it looks wrong, --full rebuilds from scratch; nothing is lost.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.