memory-curate

Memory Curate

健全で相互につながったナレッジグラフを維持します。メモが蓄積してきたら、定期的に整理し、リンクを追加してナレッジベースをキュレーションすると、孤立したメモをつながりのあるグラフにできます。

このスキルは、ナレッジベースを構成するメモ、リレーション、タグからなるナレッジグラフをキュレーションします。（メモの内容については、肥大化したメモの分割、散在する情報の統合、古くなった項目の整理を扱うmemory-defragを参照してください。）

使用するタイミング

• ナレッジベースの整理、クリーンアップ、改善を依頼されたとき
• メモ間のつながりや、まだリンクされていない項目を探すよう依頼されたとき
• 孤立したメモやリンクされていないメモについて言及されたとき
• 重複または類似したメモについて尋ねられたとき
• フォルダー構成やタグの一貫性について支援を求められたとき
• 「整理を手伝って」「関連するメモを探して」「リンクされていないのはどれ」「メモを整理して」などの表現があったとき

キュレーション機能

1. 孤立したメモを見つける

孤立したメモは、他のメモとのリレーションがなく、グラフ内の島になっています。

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

query="*" は mode="text" の場合にのみ、すべての項目を一覧表示します。本文にウィキリンクまたは通常の Markdown リンクで他のメモへのリンクがあるメモは、Relations セクションがなくても孤立していません。

bm CLI が利用できる場合、bm orphans を実行すると、リレーションのないメモを一度に一覧表示できます。

孤立したメモへの対応:

• 内容の類似性に基づいてリレーションを提案します
• 既存のトピックとつなげるべきか尋ねます
• 関連する孤立メモをまとめるハブメモを提案します（機能 6 を参照）

2. 型付きリレーションを提案する

メモの内容を分析し、意味のあるつながりを提案します。

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

共通のトピック、相補的な内容（問題／解決策、質問／回答）、順序（パート 1 → パート 2）、階層（親概念 → 詳細）に基づいてリレーションを提案します。

リレーションタイプの語彙:

• relates_to — 一般的なトピック上のつながり
• extends — 発展または詳述する
• implements — 概念または仕様を実現する
• depends_on — 理解するために必要とする
• part_of — 階層または構成
• contrasts_with — 別の見解を示す
• inspired_by — 洞察の源
• enables — 何かを可能にする

カスタムのリレーションタイプも問題ありません。内容を適切に表す動詞を使ってください。

確認済みのリレーションを bm_edit で追加します。

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

insert_after_section を使うには、見出しが存在している必要があります。孤立したメモには ## Relations がないことが多いため、その場合は代わりにセクションを末尾に追加します。

bm_edit(
    identifier="API Design Decisions",
    command="append",
    content="\n## Relations\n- depends_on [[Rate Limiter]]",
)

3. 類似または重複したメモを特定する

同じ内容を扱っている可能性のあるメモを見つけます。

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

重複したメモへの対応:

• 統合して包括的なメモを 1 つ作成し、統合元のメモにはリレーションを追加して参照先を示します。統合元のメモを削除する場合、他のメモからのリンクは未解決リンクのまま残るため、先にリンク先を変更してください
• 一方のメモが他方を改訂している場合は、supersedes / updates でリンクします
• 各メモの異なる焦点が明確になるよう文脈を加えて、差別化します

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

4. フォルダー構成を見直す

bm_find(path="/", depth=3, project="<project>")

フォルダーが過密になっていないか、メモが 1 件だけのフォルダーがないか、命名に一貫性があるか、別の場所に置くべきメモがないかを確認します。関連するメモをトピック別フォルダーにまとめる、大きなカテゴリにサブフォルダーを追加する、一貫した命名規則を設ける、といった方法を提案します。配置が適切でないメモは bm_move で移動します。デフォルトでは、移動後もパーマリンクは変わらないため、リンクは引き続き解決されます。update_permalinks_on_move が有効なプロジェクトでは、新しいパスに基づいてパーマリンクが書き換えられます。

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

5. タグの一貫性を保つ

bm_search(query="*", mode="text", page_size=100)
# Inspect tag patterns across results

次の点を確認します。

• 表記揺れのあるタグ — architecture と arch のようなタグ。どちらかを選び、統一します
• 未使用のタグ — 1 件のメモにしか付いておらず、もはや役割を果たしていないタグ
• 過剰に使われている汎用タグ — 範囲が広すぎて、見つけやすさの向上に役立たないタグ
• 不足しているタグ — 関連性のあるメモに、適切と思われるタグが付いていない状態

6. インデックス／ハブメモを作成する

関連するメモのまとまりを見つけたら、ナビゲーション用のハブを作成します。

bm_write(
    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]]""",
)

7. 情報の少ないメモを充実させる

構成が整っていないメモを見つけて、内容を補いましょう。

bm_read(identifier="sparse-note")

メモに「観察」セクションがない場合は、カテゴリを提案します。「関連」がない場合は、リンクを提案します。タグがない場合は、関連するタグを提案します。背景情報が不足している場合は、その追加を提案します。bm_edit で適用します。

キュレーションのワークフロー

依頼に合わせて作業の範囲を調整します。ヘルスチェックでは、孤立したメモ、重複の可能性が高いメモ、最近のアクティビティ（bm_project(command="recent")）、フォルダーの分布を報告します。詳細なセッションでは、調査結果に応じた順序で、上記の機能を使って作業を進めます。トピック単位の作業では、bm_search と bm_context であるテーマを調査し、見つかった不足を補い、ハブとなるメモで締めくくります。

ベストプラクティス

1. 段階的に進めます。 一度にすべてを整理し直さないでください。
2. 変更前に確認します。 メモの移動、統合、編集を行う前に、必ず確認を求めてください。
3. パーマリンクを維持します。 パーマリンクを変更すると、受信する memory:// リンクが壊れます。プロジェクトで update_permalinks_on_move が有効になっていない限り、移動してもデフォルトでパーマリンクは維持されます。
4. 提案の理由を説明します。 関連付けや統合が妥当な理由を説明してください。
5. 既存の仕組みを尊重します。 ユーザーの整理方法を強化し、新しい分類体系を押し付けないでください。
6. グラフを表示します。 bm_context を使って、メモ同士のつながりをユーザーが把握できるようにします。

会話の例

ユーザー：「メモの整理を手伝ってください」

アシスタント：

1. ナレッジベースのヘルスチェックを実行します
2. 「メモは47件あります。孤立したメモが12件、重複の可能性があるメモが3件見つかりました」と報告します
3. 「孤立したメモの関連付けから始めますか？ それとも、先に重複を確認しますか？」と尋ねます

ユーザー：「API 設計のメモにリンクすべきメモを見つけてください」

アシスタント：

1. API 設計のメモを読みます
2. 関連する内容を検索します
3. 次のように提案します。「関連する可能性のあるメモが5件あります。
   • 『REST のベストプラクティス』→ relates_to
   • 『認証フロー』→ implements
   • 『レート制限の決定』→ extends これらの関連付けを追加しますか？」

ユーザー：「似たトピックのメモはありますか？」

アシスタント：

1. タイトルと内容を分析し、クラスターを特定します
2. 次のように報告します。「内容が重複している可能性があります。
   • 『認証フロー』と『認証設計』は、似た内容を扱っています
   • 『DB スキーマ v1』と『DB スキーマ v2』には、supersedes の関連付けが適切と思われます どちらかを確認しますか？」