obsidian-note-creation
IDENTITY: Librarian.AtomicNote. ResolvePath→FindHome→SearchDupes→DraftOrPatch→Backlink→Index→Verify.
Law: UseFileToolsNotShell. AtomicBeforeLongform. ExistingHomeFirst.
WHENUSE: User mentions a concept/person/decision/research item that should become a note|Capturing stable knowledge|Promoting notes/ to wiki.
ESPECIALLY:NewEntityCreation|ExistingNotePatch|MOCUpdate|Promotion|DuplicateMerge|FrontmatterMaintenance.
NoSkip:PathResolution|DuplicateCheck|WikilinkRequirement|IndexUpdate.
Trigger
Use this when the user:
- mentions a new concept, entity, decision, or research item
- asks to capture, document, or file something in the vault
- wants atomic notes rather than sprawling documents
Vault path
Resolve before any file-tool call:
- Read
OBSIDIAN_VAULT_PATH from environment, typically ~/.hermes/.env.
- If missing or unset, use
~/Hermes Vault/Hermes for this user's vault.
- Once resolved, use the concrete absolute path for
read_file, write_file, patch, and search_files.
- Use terminal only to resolve the path; all other ops should stay in file tools.
- For full vault structure, Icarus conventions, and notes/icarus layout, see
note-taking/obsidian.
Preferred containers
This vault is wiki-first with a quick-capture layer. Pick the narrowest correct home:
llm-wiki/concepts/ — topics, frameworks, techniques
llm-wiki/entities/ — people, companies, products, models
llm-wiki/comparisons/ — side-by-side analyses
llm-wiki/alloys/ — narrative syntheses
llm-wiki/queries/ — past query results worth keeping
llm-wiki/operational/ — agent decisions, protocols, conventions
notes/ — emerging or low-stability captures; promotion target is llm-wiki/
Duplicate check (do this before creating)
Do both:
- filename search:
search_files(target='files', pattern='<slug>*', path='<container>')
- content search:
search_files(target='content', pattern='<Title or alias>', file_glob='*.md', path='<llm-wiki/>')
If a clear match exists, prefer patching it. If two candidates exist, read both and choose one canonical page; link the other as a redirect or merge them.
New note template
---
title: "Human-Readable Title"
type: concept|person|company|comparison|alloy|query
created: YYYY-MM-DD
updated: YYYY-MM-DD
tags: [stable, tags, here]
sources: ["<optional paths or URLs>"]
---
## Summary
One or two sentences defining the note.
## Facts
- bullet
- bullet with [[wikilink]]
## See Also
- [[related-note]]
Rules:
- Keep it atomic. One subject per note.
- Include at least one
[[wikilink]].
- Prefer short bullets over long prose.
- Keep frontmatter complete; missing
title, type, created, updated, or tags is a defect.
- When creating entities with known aliases, include aliases in the note body rather than creating duplicate pages.
Patch workflow when the note already exists
- Read the file.
- Identify the best anchor:
## Timeline → append a dated bullet
## Current → append a current-state bullet
- no good anchor → add a new short dated section
- Patch with minimal context to keep it surgical.
- Update
updated: in frontmatter.
- Keep or add wikilinks for any newly mentioned entity.
MOC / index update
After creating or materially updating a note:
- Identify the nearest index or category listing, typically
llm-wiki/index.md or a subcategory index.
- Add or update the entry under the appropriate heading.
- Keep it compact:
- [[Note Title]] — one-line description.
For promotions from notes/:
- Add a
promoted_to: or source relation if applicable.
- Leave the source
notes/ file in place unless the user wants it removed.
Verification
After write or patch:
- Re-read the target file and confirm rendered shape: frontmatter, summary, bullet facts, wikilinks.
- Confirm each
[[wikilink]] target exists; if not, create a stub or stop and report.
- Ensure the path does not contain shell-problematic characters.
- Ensure the note remains atomic and does not absorb unrelated subjects.
Promotion rules
Use references/promotion-rules.md for:
- when
notes/ content should move to llm-wiki/
- which tier becomes which
type
- how to preserve source/history during promotion
- promotion gateway checklist and fast type mapping
Use references/promotion-cheat-sheet.md for:
- quick promotion decisions during live note creation
- source preservation defaults and archive vs delete guidance
Common mistakes to avoid
- creating a new note when an existing note is the right home
- creating scattered session notes instead of updating an existing operational note
- longform sprawl inside a note meant to be atomic
- missing frontmatter fields
- wikilinks without an actual page target
- editing mirrored/read-only files without checking whether they are agent-generated
1---2name: obsidian-note-creation3description: Atomic Obsidian note creation: resolve vault path, pick the right container, check for duplicates, draft structured notes, patch existing pages, and update the nearest MOC/index.4license: MIT5---6
7# obsidian-note-creation
8
9IDENTITY: Librarian.AtomicNote. ResolvePath→FindHome→SearchDupes→DraftOrPatch→Backlink→Index→Verify.
10Law: UseFileToolsNotShell. AtomicBeforeLongform. ExistingHomeFirst.
11WHENUSE: User mentions a concept/person/decision/research item that should become a note|Capturing stable knowledge|Promoting notes/ to wiki.
12ESPECIALLY:NewEntityCreation|ExistingNotePatch|MOCUpdate|Promotion|DuplicateMerge|FrontmatterMaintenance.
13NoSkip:PathResolution|DuplicateCheck|WikilinkRequirement|IndexUpdate.
14
15## Trigger
16
17Use this when the user:
18- mentions a new concept, entity, decision, or research item
19- asks to capture, document, or file something in the vault
20- wants atomic notes rather than sprawling documents
21
22## Vault path
23
24Resolve before any file-tool call:
251. Read `OBSIDIAN_VAULT_PATH` from environment, typically `~/.hermes/.env`.
262. If missing or unset, use `~/Hermes Vault/Hermes` for this user's vault.
273. Once resolved, use the concrete absolute path for `read_file`, `write_file`, `patch`, and `search_files`.
284. Use terminal only to resolve the path; all other ops should stay in file tools.
295. For full vault structure, Icarus conventions, and notes/icarus layout, see `note-taking/obsidian`.
30
31## Preferred containers
32
33This vault is wiki-first with a quick-capture layer. Pick the narrowest correct home:
34
35- `llm-wiki/concepts/` — topics, frameworks, techniques
36- `llm-wiki/entities/` — people, companies, products, models
37- `llm-wiki/comparisons/` — side-by-side analyses
38- `llm-wiki/alloys/` — narrative syntheses
39- `llm-wiki/queries/` — past query results worth keeping
40- `llm-wiki/operational/` — agent decisions, protocols, conventions
41- `notes/` — emerging or low-stability captures; promotion target is `llm-wiki/`
42
43## Duplicate check (do this before creating)
44
45Do both:
46- filename search: `search_files(target='files', pattern='<slug>*', path='<container>')`
47- content search: `search_files(target='content', pattern='<Title or alias>', file_glob='*.md', path='<llm-wiki/>')`
48
49If a clear match exists, prefer patching it. If two candidates exist, read both and choose one canonical page; link the other as a redirect or merge them.
50
51## New note template
52
53```yaml
54---
55title: "Human-Readable Title"
56type: concept|person|company|comparison|alloy|query
57created: YYYY-MM-DD
58updated: YYYY-MM-DD
59tags: [stable, tags, here]
60sources: ["<optional paths or URLs>"]
61---
62
63## Summary
64One or two sentences defining the note.
65
66## Facts
67- bullet
68- bullet with [[wikilink]]
69
70## See Also
71- [[related-note]]
72```
73
74Rules:
75- Keep it atomic. One subject per note.
76- Include at least one `[[wikilink]]`.
77- Prefer short bullets over long prose.
78- Keep frontmatter complete; missing `title`, `type`, `created`, `updated`, or `tags` is a defect.
79- When creating entities with known aliases, include aliases in the note body rather than creating duplicate pages.
80
81## Patch workflow when the note already exists
82
831. Read the file.
842. Identify the best anchor:
85 - `## Timeline` → append a dated bullet
86 - `## Current` → append a current-state bullet
87 - no good anchor → add a new short dated section
883. Patch with minimal context to keep it surgical.
894. Update `updated:` in frontmatter.
905. Keep or add wikilinks for any newly mentioned entity.
91
92## MOC / index update
93
94After creating or materially updating a note:
95- Identify the nearest index or category listing, typically `llm-wiki/index.md` or a subcategory index.
96- Add or update the entry under the appropriate heading.
97- Keep it compact: `- [[Note Title]] — one-line description`.
98
99For promotions from `notes/`:
100- Add a `promoted_to:` or source relation if applicable.
101- Leave the source `notes/` file in place unless the user wants it removed.
102
103## Verification
104
105After write or patch:
106- Re-read the target file and confirm rendered shape: frontmatter, summary, bullet facts, wikilinks.
107- Confirm each `[[wikilink]]` target exists; if not, create a stub or stop and report.
108- Ensure the path does not contain shell-problematic characters.
109- Ensure the note remains atomic and does not absorb unrelated subjects.
110
111## Promotion rules
112
113Use `references/promotion-rules.md` for:
114- when `notes/` content should move to `llm-wiki/`
115- which tier becomes which `type`
116- how to preserve source/history during promotion
117- promotion gateway checklist and fast type mapping
118
119Use `references/promotion-cheat-sheet.md` for:
120- quick promotion decisions during live note creation
121- source preservation defaults and archive vs delete guidance
122
123## Common mistakes to avoid
124
125- creating a new note when an existing note is the right home
126- creating scattered session notes instead of updating an existing operational note
127- longform sprawl inside a note meant to be atomic
128- missing frontmatter fields
129- wikilinks without an actual page target
130- editing mirrored/read-only files without checking whether they are agent-generated