Note Writer Skill
You are now in note-writing mode. This skill covers creating, updating, validating, and commenting on structured knowledge notes, as well as diary conventions and identity file management.
When to Create Notes
Create notes when:
- •The operator shares important context that should persist across sessions
- •You discover something reusable (a pattern, a decision, a gotcha)
- •Research results should be preserved for future reference
- •A concept needs to be defined and tracked
Do NOT create notes for:
- •Ephemeral chat context (use
memory_captureinstead for quick inbox items) - •Reference material from external sources (use the reference-researcher skill)
- •Diary entries (use diary conventions below)
Archetypes
Archetypes are optional semantic classifications. Notes without an archetype are
valid unclassified notes. Set the archetype field in front matter (lowercase) when it
adds discoverability.
| Archetype | Purpose |
|---|---|
person | People, contacts, key individuals |
concept | Ideas, definitions, mental models |
decision | Choices with rationale and trade-offs |
event | Meetings, occurrences, milestones |
place | Locations, venues, geographic context |
project | Projects, initiatives, ongoing work |
organization | Companies, teams, groups |
procedure | How-tos, workflows, step-by-step guides |
media | Books, articles, films, podcasts |
quote | Notable quotes with attribution |
Trust Scores
- •1-3: Unverified, speculative, or from uncertain sources
- •4-6: Reasonable confidence, based on experience or documentation
- •7-8: Well-verified, cross-referenced with multiple sources
- •9-10: Authoritative, confirmed by operator or primary sources
Start at 5 for most notes. Adjust with note_write action validate as confidence
changes.
Tags
Use consistent, lowercase, hierarchical tags separated by slashes. Prefer existing tags
over creating new ones. Check what tags exist with knowledge_search before creating
notes.
Tags participate in search — they are prepended to the note's first chunk for both FTS and embedding indexing. The first tag determines the note's subfolder on disk.
- •Good tags:
rust/library,architecture/decisions,debugging/patterns - •Bad tags:
Important,TODO,misc
Note Length
Aim for atomic, information-dense notes:
- •Typical: 100-400 words
- •Maximum: ~1000 words
- •Notes under ~1500 characters are indexed as a single embedding vector for precise retrieval. Keep notes concise to benefit from this optimization.
Wiki Links
Link to related notes using [[Title]] or [[Title|alias]] syntax. Create links even
if the target note doesn't exist yet — they will be resolved when the target is created.
Links enable graph-depth traversal during search.
Updating vs. Creating
Before creating a new note, search first:
- •Use
knowledge_searchto check if a similar note exists - •If found, use
note_writeactionupdateto refine it - •If not found, use
note_writeactioncreate
Comments
Use note_write action comment to append timestamped observations to existing notes
without changing the main body. Good for:
- •Recording when a note was confirmed or contradicted
- •Adding context from new conversations
- •Noting that related information was found elsewhere
Deleting Notes
Use note_write action delete to remove a note that is no longer relevant. This
removes the file from disk and all associated DB records (chunks, tags, links).
Scope
- •private (default): Private to you. Use for personal observations and working notes.
- •shared: Visible to all ghosts. Use for established knowledge that benefits everyone.
Start with ghost scope. Promote to shared when the note is validated and broadly useful.
Diary Conventions
Diary entries are date-based (YYYY-MM-DD.md), plain markdown with no front matter.
They are append-only.
- •Use bullet points for events, decisions, and observations.
- •Keep entries brief — details belong in notes, diary is the timeline.
- •The system generates a deterministic ID (
diary:{ghost}:{date}) so re-indexing produces upserts, not duplicates.
Identity Files
Ghosts maintain three identity files in the workspace root:
- •BOOT.md: Core personality, values, and behavioral constraints. Rarely changes. Only modify when explicitly directed by the operator.
- •SOUL.md: Evolving self-model, communication style, and preferences. Update during reflection when significant self-awareness insights emerge.
- •USER.md: Accumulated knowledge about the operator (preferences, context, communication style). Update when new operator information is captured.
These files are loaded into the system prompt context, so keep them concise and
well-structured. Edit them with the shell tool or file_edit.