# Obsidian Topic Atlas

> Build or refresh a thematic atlas for the user's Obsidian vault or one bounded subtree, identifying clusters, hubs, weakly linked areas, and navigation entry points. Use for vault mapping, not for note rewriting, generic summaries, or cross-machine discovery.

- Skill: `kirillklem/obsidian-topic-atlas` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add kirillklem/obsidian-topic-atlas`
- Raw SKILL.md: https://api.skillmd.com/api/skills/kirillklem/obsidian-topic-atlas/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: KirillKlem (https://skillmd.com/u/kirillklem)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/kirillklem/obsidian-topic-atlas

---


# Obsidian Topic Atlas

## When to Use
- The user wants a cluster map of the vault or a subtree such as `Knowledge/` or `Personal/`
- Future agents need a fast entry point into a dense note area
- You need to identify hub notes, thin hubs, and under-linked regions
- You want a derived atlas under `_codex/` without touching canonical notes

## When Not to Use
- Do not use for rewriting or reorganizing canonical notes
- Do not use for generic note summaries when no cluster map is needed
- Do not use for a whole-machine discovery pass outside the vault
- Do not use when the real need is a project-specific operational map; prefer `obsidian-project-normalizer`

## Inputs
- Vault root, usually `~/Documents/Obsidian_base/learn`
- Optional subtree such as `Knowledge/`, `Personal/`, or `Journal/`
- Safe write area, usually `learn/_codex/`
- Existing local guides:
  - `learn/AGENTS.md`
  - `learn/_codex/write_policy.md` if it exists

## Output Files
- Primary: `_codex/topic_atlas.md`
- Variant for bounded runs: `_codex/<scope_slug>_topic_atlas.md`

## Constraints
- Do not edit, rename, move, or delete existing notes
- Treat canonical notes as read-only unless the user explicitly asks otherwise
- Ignore `Cache/` and `.obsidian/` for semantic analysis
- Prefer high-confidence clustering over exhaustive coverage
- Mark uncertain boundaries explicitly

## Procedure
1. Read the nearest `AGENTS.md` files before scanning the vault.
2. Confirm the safe output area. Default to `learn/_codex/`.
3. Inventory folders and note counts for the target scope.
4. Identify candidate hubs from:
   - dashboard notes
   - atlas/index notes
   - backlog/planning notes
   - repeated wiki-link targets
5. Sample a small set of representative notes from each suspected cluster.
6. Group notes into thematic clusters that predict future navigation value, not just naming similarity.
7. For each cluster, record:
   - short summary
   - core notes
   - hub notes
   - whether the cluster is strong, thin, or weakly linked
8. Add a short uncertainty section for ambiguous overlaps or missing nodes.
9. Write the atlas as a derived note under `_codex/`.
10. Verify the atlas does not claim certainty where only filenames or sparse samples were available.

## Definition of Done
- The output identifies a bounded set of thematic clusters rather than listing folders mechanically
- Each cluster includes anchor notes or hub notes that improve future navigation
- Weakly linked or thin areas are called out explicitly
- Uncertainty is visible wherever the cluster boundary depends on sparse evidence
- The note links back to canonical sources and does not impersonate them

## Vault-Specific Guidance
- For `learn`, expect high-value clusters around:
  - vault control and planning
  - AiStats / football analytics
  - VLM / CV / detection
  - RL / theory
  - math / university
  - personal operating notes
  - prompt libraries
- Use `Home.md`, `Backlog.md`, `Knowledge/Knowledge.md`, `Personal/Personal.md`, and `Journal/Journal.md` as initial anchors.
- Use `references/atlas_note_template.md` when you want a stable output shape without rethinking the section layout from scratch.