Memory Curate

Memory Curate

Maintain a healthy, well-connected knowledge graph. As notes accumulate, it pays to periodically organize, link, and curate the knowledge base so isolated notes become a connected graph.

This skill curates the knowledge graph — the notes, relations, and tags that make up the knowledge base. (For hygiene on an agent's own memory files — splitting bloated files, pruning stale entries — see memory-defrag.)

When to Use

• Asked to organize, clean up, or improve the knowledge base
• Asked to find connections between notes, or what isn't linked yet
• Orphan or unlinked notes are mentioned
• Asked about duplicate or similar notes
• Asked for help with folder organization or tag consistency
• Phrases like "help me organize", "find related notes", "what's not linked", "clean up my notes"

Curation Capabilities

1. Find Orphan Notes

Orphans have no relations to other notes — they're islands in the graph.

# List notes, then read each to inspect its Relations section
search_notes(query="*", page_size=50)
read_note(identifier="note-to-check")
# Orphans have an empty (or missing) Relations section

If the bm CLI is available, bm orphans lists notes with no relations in one call.

What to do with orphans:

• Suggest relations based on content similarity
• Ask whether they should connect to existing topics
• Propose hub notes to gather related orphans (see capability 6)

2. Suggest Typed Relations

Analyze a note's content and propose meaningful connections.

read_note(identifier="note-to-analyze")
# Pull out key terms, then search for related notes
search_notes(query="key terms from the note")

Suggest relations based on shared topics, complementary content (problem/solution, question/answer), sequence (part 1 → part 2), or hierarchy (parent concept → detail).

Relation-type vocabulary:

• relates_to — general topical connection
• extends — builds upon or elaborates
• implements — realizes a concept or spec
• depends_on — requires understanding of
• part_of — hierarchy or composition
• contrasts_with — presents an alternative view
• inspired_by — source of insight
• enables — makes something possible

Custom relation types are fine — use whatever verb is descriptive.

Add a confirmed relation with edit_note:

edit_note(
    identifier="API Design Decisions",
    operation="insert_after_section",
    section="Relations",
    content="- depends_on [[Rate Limiter]]",
)

3. Identify Similar / Duplicate Notes

Find notes that may cover the same ground.

search_notes(query="topic keywords")
# Compare results for: similar titles, overlapping observations,
# shared tags, close-together timestamps

Actions for duplicates:

• Merge into a single comprehensive note, then redirect the loser with a relation
• Link with supersedes / updates when one revises the other
• Differentiate by adding context that clarifies each note's distinct focus

# Point an older note at the one that replaces it
edit_note(
    identifier="DB Schema v1",
    operation="insert_after_section",
    section="Relations",
    content="- updates [[DB Schema v2]]",
)

4. Folder Organization Review

list_directory(dir_name="/", depth=3)

Look for overcrowded folders, single-note folders, inconsistent naming, and notes that belong elsewhere. Suggest grouping related notes into topic folders, adding subfolders for large categories, and a consistent naming convention. Move misplaced notes with move_note. By default the permalink stays the same after a move, so links keep resolving. Projects with update_permalinks_on_move enabled rewrite it from the new path.

move_note(
    identifier="API Design Decisions",
    destination_path="architecture/api-design-decisions.md",
)

5. Tag Consistency

search_notes(query="*", page_size=100)
# Inspect tag patterns across results

Look for:

• Variant tags — architecture vs arch; pick one and standardize
• Unused tags — present on a single note, no longer carrying weight
• Over-used generic tags — so broad they don't aid discovery
• Missing tags — relevant notes lacking an obvious tag

6. Create Index / Hub Notes

After finding a cluster of related notes, build a navigation hub.

write_note(
    title="Architecture Decisions Index",
    directory="indexes",
    tags=["architecture", "index"],
    note_type="index",
    content="""# Architecture Decisions Index

A hub linking architecture-related decisions and patterns.

## Decisions
- [[Database Selection Decision]]
- [[API Design Patterns]]
- [[Authentication Architecture]]

## Patterns
- [[Repository Pattern]]
- [[Async Client Pattern]]

## Observations
- [index] Central hub for architecture knowledge #navigation

## Relations
- indexes [[Architecture]]""",
)