obsidian-project-memory

Obsidian プロジェクトメモリー

研究プロジェクト向けに、ファイルシステムを中心とし、エージェントが駆動する Obsidian ナレッジベースを維持します。

ノートの出力言語は、プロジェクトで設定された note_language に従います。ノートの言語が設定されていない場合は、デフォルトで英語を使用します。技術用語、論文タイトル、定着したフォルダー名は、そのほうが明確であれば原文のままにします。ユーザーが明示的に求めた場合に限り、ノートの本文を別の言語に切り替えます。

次の条件に当てはまるリポジトリ内では、このスキルを優先してください。

• .claude/project-memory/registry.yaml がすでに存在する
• 明らかに研究プロジェクトであり、Obsidian ボルトとの紐付けが必要である

基本原則

• プロジェクトの状態管理にはスクリプトを使用します。
• プロジェクトの理解と知見の統合にはエージェントを使用します。
• 永続的な研究知識のみを、小規模なボルト構成に書き込みます。
• MCP、API キー、REST プラグイン、.base アーティファクトは必須としません。
• .canvas に全般的に依存しないでください。ただし、文献ワークフローではデフォルトの文献グラフアーティファクトとして Maps/literature.canvas を維持できます。
• 内部向けの実験サマリーレポートは、Writing/ のノートではなく、Results/Reports/ に保存する永続的な結果関連ノートとして扱います。

デフォルトのボルト構成

このプロジェクトレイアウト内にのみ書き込みます。

Research/{project-slug}/
  00-Hub.md
  01-Plan.md
  Knowledge/
  Papers/
  Experiments/
  Results/
    Reports/
  Writing/
  Daily/
  Archive/

正確な構成とノートの役割については、references/SCHEMA.md をお読みください。

決定論的なヘルパースクリプト

scripts/project_kb.py は、検出、初期化、同期、ライフサイクル管理など、自由度の低い操作にのみ使用します。

python3 scripts/project_kb.py detect --cwd "$PWD"
python3 scripts/project_kb.py bootstrap --cwd "$PWD" --vault-path "$OBSIDIAN_VAULT_PATH"
python3 scripts/project_kb.py sync --cwd "$PWD" --scope auto
python3 scripts/project_kb.py lifecycle --cwd "$PWD" --mode archive
python3 scripts/project_kb.py query-context --cwd "$PWD" --kind broad
python3 scripts/project_kb.py query-context --cwd "$PWD" --kind experiment --query freezing
python3 scripts/project_kb.py find-canonical-note --cwd "$PWD" --kind experiment --query freezing
python3 scripts/project_kb.py note-lifecycle --cwd "$PWD" --mode archive --note "Results/Old-Result.md"

このスクリプトがプロジェクトの意味を理解すると期待しないでください。スクリプトは状態を管理するものであり、知見の統合に取って代わるものではありません。

タスクをスクリプトで処理するか、エージェント主導にするかを判断する際は、references/SCRIPT-VS-AGENT.md をお読みください。

デフォルトのワークフロー

1. 検出して紐付ける

1. scripts/project_kb.py detect --cwd "$PWD" を実行します。
2. リポジトリがすでに紐付けられている場合は、既存のプロジェクトで作業を続けます。
3. リポジトリがまだ紐付けられておらず、研究プロジェクトとして有力な候補である場合は、project_kb.py bootstrap で初期化します。

詳しいライフサイクルについては、references/WORKFLOW.md をお読みください。

2. 必要最小限のコンテキストを読む

何かを書き込む前に、必要最小限の安定したコンテキストのみを読みます。

• .claude/project-memory/<project_id>.md
• 00-Hub.md
• 01-Plan.md
• 今日の Daily/YYYY-MM-DD.md（存在する場合）

タスクがプロジェクトの理解、既存ドキュメント、または過去の結果に関するものである場合は、以下のリファレンスを使って、必要なコンテキストを選択的に読み込みます。

3. 知識の差分を分類する

現在のターンを、次のカテゴリの1つ以上に振り分けます。

• knowledge
• paper
• experiment
• result
• writing
• daily
• project-structure

書き込む前に、references/NOTE-ROUTING.md をお読みください。

4. デフォルトの永続的な研究プロセスに従う

実質的な研究作業のデフォルトの流れ：

• Papers/ -> 再利用可能なアイデア、ベースライン、プロジェクトとの関連性を抽出します
• Experiments/ -> それらを検証可能な仮説、実行手順、またはアブレーションに落とし込みます
• Results/ -> 安定した知見を、根拠と解釈を添えてまとめます
• Results/Reports/ -> 完全な振り返りを書き終えた段階で、1回分または1バッチ分の内部実験レポートを保存します
• Writing/ -> 永続的な主張をレビュー、提案書、草稿、スライド、または反論メモとして外部向けにまとめます

Daily/ は時系列の記録と作業の仮置きに使用し、永続的な研究知識の最終的な保存先にはしません。

この流れに沿ってターンを進める方法を判断する際は、references/PAPERS-TO-WRITING.md をお読みください。

5. エージェントによる先行統合が必要かどうかを判断する

次の場合は、エージェントによる先行インポート／統合を使用します。

• 既存のリポジトリを初めてインポートするとき
• ナレッジベースが空、または背景情報が不足しているとユーザーが伝えたとき
• 複数のソース文書を、安定したプロジェクト知識に統合する必要があるとき
• プロジェクトに、長期的に利用できる概要、研究課題、実験マップ、または結果の要約が必要なとき

この場合は、まずエージェントを使って主要なソースを読み、その後、統合した結果を Obsidian に書き戻します。

推奨されるソースの読み込み順序については、references/AGENT-FIRST-IMPORT.mdをお読みください。

6. 必要最小限の書き戻しを行う

書き戻しは常に慎重に行います。

少なくとも次の内容を書き戻します。

• このターンでプロジェクトの状態が変わった場合は、本日のDaily/YYYY-MM-DD.md
• 最近の進捗または全体状況に実際の変化があった場合に限り、00-Hub.md
• プロジェクトの状態が変わった場合は、.claude/project-memory/<project_id>.md

そのうえで、該当する分類の、長期的に有用なノートだけを書き込みます。

• knowledge → Knowledge/
• paper → Papers/
• experiment → Experiments/
• result → Results/
• writing → Writing/
• daily → Daily/
• project-structure → 通常はKnowledge/Project-Overview.mdまたはKnowledge/Source-Inventory.md

内部向けの実験ラウンドレポートは、原則として次の場所に保存します。

• Results/Reports/YYYY-MM-DD--{experiment-line}--r{round}--{purpose}.md

ノートの形式を統一する必要がある場合は、references/NOTE-TEMPLATES.mdをお読みください。

ナレッジの CRUD ルール

保管庫は、少数の正規ノートと、それを補足する日々の記録で構成されるものとして扱います。

作成

• 新しいナレッジは意図的に取り込みます。Markdown ファイルが新たに作成されるたびに、長期的に保持するノートにするわけではありません。
• 可能な限り、長期的に保持する対象ごとに正規ノートを1つ維持します。
  • 安定したプロジェクト概要を1つ
  • 実験系列ごとに、安定した実験ノートを1つ
  • 長期的に有用な知見ごとに、安定した結果ノートを1つ
  • 論文ごとに、安定した論文ノートを1つ
• 新しい Markdown ファイルは、まず要約し、その後に振り分けることを原則とします。
  • ファイルがすでに安定していて、それだけで内容が完結している場合に限り、直接昇格させます。
  • それ以外の場合は、既存の正規ノートに統合するか、Daily/に一時保存します。
• 新しい長期保存対象が内部向けの完全な実験レポートである場合は、Results/Reports/に保存し、対応するExperiments/および正規のResults/ノートへのリンクを追加します。

読み取り

• まず、対象を絞って照会します。
  • プロジェクト全般に関する質問 → 00-Hub.mdと主要なKnowledge/ノート
  • 進行中の作業に関する質問 → 01-Plan.md、本日のDaily/、プロジェクトメモリ
  • 特定の実験、結果、論文に関する質問 → まず対応する正規ノート
  • 特定の内部向け実験の振り返り → まずResults/Reports/内の対応するノート
• 回答が複数の長期保存ソースにまたがる場合、または正規ノートを読んでもリポジトリの資料が必要な場合に限り、エージェントによる統合を使用します。

更新

• 関連するノートを新たに作成するよりも、既存の正規ノートを更新することを優先します。
• 生の資料は入力として扱い、最終的な保管庫の対象とはみなしません。
• Daily/には追記のみの簡易な記録を認めますが、長期的なナレッジはKnowledge/、Papers/、Experiments/、Results/、Results/Reports/、またはWriting/に保持します。

削除

• 「削除する」「取り除く」「使用をやめる」は、デフォルトでアーカイブとして扱います。
• 完全削除は、ユーザーが明示的に依頼した場合に限ります。
• 長期保存ノートをアーカイブまたは完全削除する場合は、00-Hub.md、01-Plan.md、明示的なインデックスノートにある直接リンクを修正し、主要な作業画面から存在しないファイルへの参照が残らないようにします。

安全ルール

• リポジトリ全体を保管庫に複製しないでください。
• 実際の内容がない空のフォルダー分類やプレースホルダーのノートを生成しないでください。
• リポジトリの変更をすべて新しいノートに記録しないでください。
• すべてのコード変更をナレッジの更新として扱わないでください。
• ユーザーから明示的に依頼されない限り、.base ファイルを作成しないでください。
• 任意の .canvas ファイルをむやみに増やさないでください。主な例外は、文献ワークフロー向けの Maps/literature.canvas です。
• エンジニアリングのみを扱うやり取りでは、実験、結果、または計画に実質的な影響がない限り、プロジェクトのメモリーに加えて Daily/ を優先してください。
• 「プロジェクトの知識を削除する」は、デフォルトでアーカイブとして扱ってください。完全な削除は、ユーザーから明示的に依頼された場合に限ります。

参照ファイル

必要なものだけを読み込んでください。

• references/SCHEMA.md - 保管庫の構成とノートの役割
• references/WORKFLOW.md - 検出／初期設定／同期／アーカイブのワークフロー
• references/PAPERS-TO-WRITING.md - 文献から実験、結果、執筆へのデフォルトの引き継ぎ
• references/SCRIPT-VS-AGENT.md - 自由度の低いスクリプト操作とエージェントのみで行う推論の境界
• references/KNOWLEDGE-CRUD.md - 永続的な研究ナレッジの作成／読み取り／更新／削除のルール
• references/NOTE-ROUTING.md - ナレッジの種類ごとの保存先
• references/NEW-MD-INGESTION.md - 新規作成された Markdown ファイルの取り込み方法
• references/AGENT-FIRST-IMPORT.md - エージェントによる統合を用いて既存プロジェクトをインポートする方法
• references/NOTE-TEMPLATES.md - 一般的なノートの種類に使える簡潔な形式