# Obsidian Project Normalizer

> Normalize a project-specific slice of the Obsidian vault into a derived operational map that clarifies canonical notes, active planning notes, research notes, and missing structure. Use for one project cluster at a time, not for whole-vault atlases or direct note refactors.

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

---


# Obsidian Project Normalizer

## When to Use
- A project area feels messy or duplicated but source notes must remain untouched
- The user wants one operational map for a workstream such as AiStats, attention systems, job search, or research
- Future agents need to distinguish dashboard notes, active state, concept notes, and archives inside one project cluster

## When Not to Use
- Do not use for whole-vault clustering; prefer `obsidian-topic-atlas`
- Do not use when the need is a single hub note for one concept family; prefer `obsidian-link-hub-builder`
- Do not use for rewriting filenames, folders, or tags
- Do not use when the scope is too broad to define as one project cluster

## Inputs
- Project scope, e.g. "AiStats cluster in `Knowledge/`" or "interview-prep notes in `Personal/`"
- Optional anchor notes already known to be central
- Safe write area, usually `learn/_codex/`
- Existing local docs such as `topic_atlas.md` if already available

## Output Files
- Primary: `_codex/<project_slug>_project_map.md`
- Optional companion audit: `_codex/<project_slug>_link_audit.md`

## Constraints
- Do not rename notes, move notes, or enforce a new taxonomy on the vault
- This skill creates derived operational structure only
- Keep scope tight; do not normalize the whole vault in one run
- Distinguish clearly between canonical notes and suggested derived support notes

## Procedure
1. Read `learn/AGENTS.md` and any existing `_codex` docs relevant to the project.
2. Define the project boundary explicitly before reading.
3. Inventory notes in the project cluster by role:
   - dashboard / hub
   - planning
   - concept
   - research
   - prompt
   - archive
4. Identify the actual source-of-truth notes for:
   - current state
   - research direction
   - supporting reference
5. Identify thin hubs, unresolved links, duplicate-looking notes, or split contexts.
6. Write a derived project map with:
   - project purpose
   - canonical notes
   - active reading order
   - weak structure points
   - safe future derived-note ideas
7. If needed, add a small link audit for missing or dangling project references.
8. Verify that the output helps future agents navigate the project without changing the vault itself.

## Definition of Done
- The project boundary is explicit and narrow enough to be stable
- Canonical notes are distinguished from auxiliary, archive, and derived notes
- Current-state notes, research notes, and reference notes are not collapsed into one bucket
- Weak structure points are called out with uncertainty where needed
- A future agent could start in the produced map and orient without rescanning the whole project

## Vault-Specific Guidance
- Strong candidates include:
  - AiStats / football analytics
  - attention / Nabla / Kandinsky notes
  - interview preparation
  - RL-theory research path
- In `learn`, project normalization should usually end in `_codex/<project>_project_map.md`, not in edits to the project notes.
- Use `references/project_map_template.md` if you want a fixed output skeleton.