ai-memory-durable-pages

ai-memory 永続ページ

このスキルは、意図的に永続的な Wiki を変更する場合にのみ使用してください。通常のセッション記録は自動で行われ、永続的なメモにはユーザーからの明示的な依頼が必要です。

このクラスターのツール

• memory_write_page は、プロジェクトの恒久的な知識を記録する永続的な Wiki ページを書き込みます。
• memory_delete_page は、指定された正確なパスの永続的な Wiki ページを削除します。
• memory_restore_page は、ページのチェックポイントを一覧表示するか（rev なし）、以前のバージョンを書き戻します（rev あり）。削除済みのページも対象です。複数ユーザー対応サーバーでは管理者専用であり、scope: "profile" のページには適用されません。

永続メモリの書き込み

ユーザーから、何かを永続的に記憶する、メモを保存する、注釈を追加する、またはプロジェクトの知識を記録するよう明示的に依頼された場合にのみ、ページを書き込んでください。一時的な進捗、通常の状況報告、次回セッション用のコンテキストには永続ページを使用しないでください。

本文の1行目にページタイトルを # H1 として記載し、タイトル用の別引数は省略してください。ai-memory はこの H1 からタイトルを導出します。内容は簡潔で事実に基づくものとし、将来のエージェントがセッション全体を読み直さずに活用できるだけのコンテキストを含めてください。

任意のトップレベルメタデータ：kind（64文字）、entities（名前10件、各64文字。正規化後に重複を除去）、abstract（1,024文字）、relations（causes、fixes、contradicts をページのターゲット配列に対応付けるオブジェクト。ターゲットは合計32件、各1,024文字）。関連のターゲットには path、project:path、または workspace/project:path を使用します。拡張子のないページパスには .md が補われ、スコープの各要素はあらかじめトリミングされている必要があります。上限は、トリミング、正規化、重複除去の前の生の値に適用されます。任意の frontmatter および作成者フィールドは編集できません。 書き込みのたびに、ページ全体とメタデータが置き換えられます。省略されたフィールドはクリアされます。既存の内容を保持する必要がある場合は、先に現在のページを読み取ってください。パッチ機能や比較後に書き込むための事前条件はありません。

ユーザーがメモを一時的なものにしたいと明示した場合は、RFC3339形式の日時、または YYYY-MM-DD のみ（日付当日の終わり、UTC）を expires_at に指定してください。TTL の期限が切れると、通常の検索、最近の項目、ブリーフィングでページが表示されなくなり、次回の忘却処理で削除されます。TTL は pinned より優先されるため、ユーザーがその動作を明確に求めている場合を除き、両方を併用しないでください。

セッションのページを自分で書き込む場合

参加中のセッションをまとめるようユーザーから依頼された場合は、サーバーではなく自分のモデルを使ってページを書き込んでください。まずセッションの生の観測内容を読み取ります（取得スキルで読み取り方法を確認してください）。次に、memory_write_page に同じ session_id を渡して各ページを書き込みます。これによりセッションが証拠として記録され、キューに入っていた統合ジョブが完了します。サーバーの複数ページ構成に合わせ、ページは最大5件としてください。

• sessions/<session_id>.md：セッションの記録。tier: "episodic"、kind: "fact"。
• concepts/<slug>.md：長期的に有効な概念ページ。tier: "semantic"、kind: "fact"。
• decisions/<short>.md：選択内容を記録する ADR 形式のページ。tier: "semantic"、kind: "decision"。
• gotchas/<slug>.md：失敗のパターンや予想外の事象。tier: "semantic"、kind: "gotcha"。
• _rules/<slug>.md：独立した指示として記述する、永続的なプロジェクト規約。tier: "semantic"、kind: "rule"。

セッションで実際に明らかになったことだけを分けて記録してください。短いセッションなら、セッションページは1件にします。発言された内容と実行された内容を記録し、ユーザーの質問を確定した決定として扱わないでください。

プロジェクトのルールは、まず指示ファイルに記録する

常に特定の操作を行う、または特定の操作を決して行わないといった、永続的なプロジェクトルールの作成をユーザーから依頼された場合は、リポジトリに正規のエージェント指示ファイルが存在するなら、そのファイルを更新してください。ユーザーが Wiki にもルールを明示的に記録するよう求めた場合、または該当する正規の指示ファイルがない場合にのみ、永続ページを使用してください。

永続メモリの削除

削除は正確なパスを指定して行ってください。ユーザーが曖昧なタイトルやトピックを指定した場合は、読み取り専用の検索で先にページのパスを特定します。ユーザーが明示的に指定しない限り、関連する別プロジェクトは保持してください。

プロジェクトのスコープ

MCP クライアントの ID サポートに応じて、スコープを選択します。

• セッションを認識する MCP クライアント（実際のライフサイクルフックのセッション ID をすべてのリクエストに転送するもの）は、自動的な現在のプロジェクトへのルーティングを使用してください。現在のリポジトリについては workspace、project、cwd を省略し、ユーザーが別のプロジェクトを指定した場合にのみ明示的なスコープを渡してください。
• 静的な MCP クライアント（ライフサイクルフックがあっても、そのフックのセッション ID を MCP リクエストに結び付けるブリッジがないクライアントを含む）は、このプロジェクト、自分たちの作業、またはここに関するリクエストも含め、プロジェクトをスコープとするすべての呼び出しで workspace と project をセットで渡す必要があります。最も近い .ai-memory.toml に両方が定義されている場合は、正確な名前を読み取ってください。マーカーによる上書きがない場合は、正規化した upstream、次に origin からプロジェクトを導き出し、ホストを除いた完全なリポジトリパスを使用してください（github.com/acme/api → acme-api）。有効なリモートがない場合に限り、フォルダーのベース名を使用してください。サーバーで最後にアクティブだったプロジェクトには決して依存しないでください。

このルールは、プロジェクトをスコープとする呼び出しにのみ適用されます。プロジェクト横断検索では、global=true の場合に workspace、project、scopes を省略してください。scope: "global" を指定して恒常的な設定を記録する場合は、workspace と project を省略してください。

アーキテクチャ上の決定には ADR の構成とピン留めを適用します

ユーザーからアーキテクチャ上の決定（選択したアプローチ、却下した代替案、恒常的なトレードオフ）の記録を求められたら、decisions/<short-slug>.md の下に pinned: true を設定した永続的なページとして、本文を次の構成で記録してください。

# <Decision title>

**Status:** accepted   

## Context
What situation forced a decision; the constraints that mattered.

## Decision
What was decided, stated as a fact.

## Consequences
What becomes easier, what becomes harder, what was given up.
Rejected alternatives and WHY, so future sessions don't re-propose them.

ピン留めされたページは保持期間による減衰とキュレーションの対象外であり、自動改善の処理による書き換えも拒否されます。人がピン留めを解除しない限り、記録は変更されません。決定を置き換えるには、新しいページを作成し、古いページのステータス行を superseded by [[decisions/<new>]] に設定してください。古い決定の内容は決して編集しないでください。注：ai-memory はプロジェクトリポジトリ内のファイルには一切触れません。リポジトリ内で管理される docs/adr/ ディレクトリ（手作業または別のツールによるもの）は ai-memory の対象外です。これらの wiki ADR は、セッションをまたいだ検索のために既存の ADR を補完します。

恒常的なユーザー／チーム設定はプロジェクト横断プロファイルに保存します

すべてのプロジェクトに適用する恒常的な設定（技術の選択（「常に pnpm workspaces を使用する」）、コードスタイル（「継承より合成を優先する」）、個人の規約（「確認せずに --force を使わない」）など）は、現在のプロジェクトではなく scope: "profile" を指定して memory_write_page を呼び出してください。このページは profile/ のプロジェクト横断プロファイルに追加されます（tools/pnpm.md のようなパスを渡すと、profile/tools/pnpm.md として保存されます）。すべてのプロジェクトのセッション開始時にデフォルトとして一覧表示され、デフォルトのメモリ読み取りでは global_scope_hits として表示されます。本文は # Title と命令形の一文で始めてください。対象スタックのプロジェクトに限定するには applies_to（例：["rust"]）を渡し、すでに何かによって強制されている場合（例："pre-push hook"）は enforced_by を渡してください。これにより、セッション開始時のダイジェストから除外されます。これらの引数はプロファイルのエントリーでのみ受け付けられ、書き換え時に省略するとクリアされます。削除するには、scope: "profile" を指定して memory_delete_page を呼び出してください。scope: "global" は引き続き、共有の _global スコープに直接書き込みます。どちらのスコープも workspace／project 引数と組み合わせることはできません。プロジェクト横断で適用する設定に限って使用してください。プロジェクト固有のルールは、プロジェクト内（または上記のセクションに従い、その指示ファイル内）に残してください。ルールファイルは常にプロファイルより優先されます。プロファイルは、リポジトリに記載がない場合に適用するデフォルトです。