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.