capture

/capture

その場で単一の記憶をキャプチャします。能動的な動詞です。エージェントがひらめいた瞬間を写真のように捉えます。

呼び出し方

origin MCP サーバーの capture ツールを呼び出し、ユーザーの内容を完結した独立の文として渡します。topic は cwd または会話から設定します。ユーザーに入力させないでください。

capture(content="<args, written as a full sentence with WHY>",
        memory_type="<picked from the 6 types>",
        entity="<primary entity name, if any>",
        space=<inferred>)

memory_type — エージェントが6種類から選択

ローカルモデルまたは API キーが設定されている場合、デーモンが分類します。ローカルメモリモードでは分類しないため、エージェントが内容からタイプを選びます。次の対応表を使用してください。

タイプ	用途
identity	ユーザーに関する長期的な事実（役割、会社、言語の設定）
preference	「Y なので X を好む」——習慣、訂正、文体上の選択
decision	「C なので B ではなく A を選ぶ」——理由を伴う具体的な選択
lesson	特定した根本原因、見つけた回避策、得られた技術的な知見
gotcha	見落としやすい点、意外な挙動、注意すべきこと
fact	人物、プロジェクト、ツールに関する長期的な情報——可能であれば entity に紐付ける

2つのタイプが当てはまる場合は、その記憶が重要である理由に最も近いタイプを選んでください。decision は preference も含意しますが、decision のほうがより具体的です。

entity — 紐付け先を抽出

内容に含まれる最も重要な名前付きの対象を1つ選びます。人物、プロジェクト、ツール、場所などです。正式な名前をそのまま使います。例：「Alice は TDD を好む。なぜなら…」→ entity="Alice"。内容に名前付きの対象がない場合は、entity を省略します。

topic / space の推定

• cwd がリポジトリ内にある場合 → リポジトリ名（例：~/Repos/origin/... → "origin"）。
• リポジトリ外の場合 → 会話内の直近のトピックを使うか、省略します。
• スコープが分かっている場合は必ず space を渡します。不確かな場合は後で list_spaces を実行するか（post-PR-C）、省略します。

複数のエンティティや関係

MCP の capture ツールで指定できる主要な entity は1つです。追加のエンティティや関係には、専用の MCP ツールを使用します。内容に複数のエンティティが含まれている場合は、まず記憶をキャプチャし、その後、追加のエンティティごとに次を実行します。

create_entity(name="<entity>", entity_type="<person|project|tool|place>")

2つのエンティティ間の関係には、次を実行します。

create_relation(from_entity="<a>", to_entity="<b>", relation_type="<verb>")

デーモンに LLM がある場合は、後続の取り込み時の補完処理で抽出されるため、これらの呼び出しは省略します。

キャプチャする内容

• 決定：「B なのでアプローチ A を選ぶ」
• 好み：「早期にリグレッションを検出できるので TDD を好む」
• 訂正：「実際は D ではなく C」
• アイデンティティ／プロジェクトに関する事実：「AI ツール向けのローカルメモリデーモンである Origin に取り組んでいる」

キャプチャしない内容

• システムプロンプト、起動ログ、ハートビート
• 一時的なタスクの状態（「現在作業中…」）
• ツールの出力、コマンドの結果、アーキテクチャのダンプ
• 一語だけの相づち
• ユーザーが簡単に再確認できる内容（ファイルパス、最近の Git 履歴）

原子的なアイデア

1回のキャプチャにつき、アイデアは1つです。「TDD を好む」と「pytest を使う」は、1つではなく2回のキャプチャです。

使用するタイミング

• ユーザーが「これを覚えておいて」「それを保存して」「これをキャプチャして」と明示的に依頼したとき。
• ユーザーが、長期的な好み／決定／訂正を自発的に述べたとき（確認は不要です。これが最低条件であり、実行のきっかけではありません）。

使用しないタイミング

• セッション終了時にまとめて保存する場合 → /handoff を使用します（複数項目の一括処理）。
• 記憶を取り出す場合 → /recall を使用します。

キャプチャ後の矛盾シグナル

capture の戻り値を受け取った後、response.triggered_revisions と response.auto_superseded を確認します。

auto_superseded（対応不要）

auto_superseded が空でない場合、デーモンはすでに矛盾を解決しています。次のように情報として提示します。

Note: auto-superseded mem_X. Origin replaced a prior protected memory because
trust=high and similarity > 0.9. No action needed.

承認／却下の呼び出しは不要です。修正は自動的に適用されています。

triggered_revisions (人によるレビューが必要)

triggered_revisions が空でない場合 (かつ auto_superseded が空の場合)、ユーザーにインラインブロックを表示します。

Stored mem_new.

This capture topic-matches a protected memory now flagged for revision:
  - mem_target_abc

Action: accept (replace original content) | dismiss (drop the revision) | leave (decide later)

インライン動詞マップ:

• accept: accept_revision(target_source_id="mem_target_abc")
• dismiss: dismiss_revision(target_source_id="mem_target_abc")
• leave: 呼び出しなし。次回の /brief で再び表示されます

技術的には、1 つのレスポンスで両方のフィールドが空でない状態になり得ます (複数の保護された一致)。しかし実際には、1 回のキャプチャにつきどちらか一方だけが発火します。auto_superseded は trust=full かつ類似度 > 0.9 の場合に発火し、triggered_revisions はそれ以外の場合に発火します。

どちらのフィールドも空でない状態でなければ、そのキャプチャは競合なく正常に保存されました。