remember

【必須】ユーザーが記憶を依頼した。以下のフローで保存先を判定し、確認の規定（下表）に従って実行する。新規保存専用のスキルであり、保存済みの記録そのものの訂正・撤回は forget skillの担当。

この判定木は rule-placement skillの4軸評価（契機/型/リスク/改訂見込み）から導出された高速表である。日常の「覚えて」はこの判定木で足りる。判定木の末端で迷う場合、1つの依頼に性質の異なる複数ルールが混ざっている場合は、rule-placementのfull評価へ切り替える。本判定木を改訂するときは、rule-placement側の評価体系から導出できる形を保つこと（片側だけの改訂は禁止。導出関係が崩れていたら矛盾として扱う）。

発動契機

以下のいずれかで発動する。

• ユーザーが何かを覚えておくこと・保存すること・記憶に残すことを依頼した（「覚えて」「保存して」「これ残して」「忘れないで」「メモって」「記録して」など。表現のバリエーションは問わない）
• ユーザーの発言に既視感がある（下の「既視感による自律発動」。雑談レベルの繰り返しは対象外）
• ユーザーがこのセッションでのClaudeの行動・判断・出力を誤りとして直した（同じ指摘の繰り返し、「〜しないで」等。表現は問わない。人間の発話に限る）。まず直してから、本フローで教訓の置き場（フィードバックエントリを含む）を判定する

以下では発動しない（decision-record・forgetとの線引きは「## 注意」を参照）。

• 経緯・成果物の記録（recording skillの担当）
• メタask裁定の発効に伴う配置（rule-placement skillの担当）

確認の規定

書き先	扱い
rules・habits・CLAUDE.md・判例decision・新しいdecision	候補ごとに承認を得てから書く
フィードバックのエントリとノート・auto-memory・tag-notes・pin	書いたあと1行で報告する

既視感による自律発動

ユーザーが明示的に記憶を依頼していなくても、発言に既視感を感じたら(雑談レベルの繰り返しは対象外)、判定フローの前処理3「既存を必ず引く」から始める（CALM searchだけで判定しない。get_feedback_entries、文脈内のauto-memory/habits/rulesの本文、触れたタグならtag-notesも見る）。

• どこにも見つからない → 勘違いとして扱い、以降の判定フローには進まず通常の応答に戻る
• 見つかったのが経緯（decision/log等）だけで、置き場所（フィードバックエントリ・auto-memory・habits・rules・tag-notes）には記録が無い → 新規保存として判定フローへ進む
• 置き場所に記録がある → 再発の手順（下）に進む

型の前判定（あらかじめ答えを出しておく1問）

そのルールは「〜な状態なら〜してよい/すべき」という条件付き判断基準か？ （適用条件と適用外を書き分けられ、隣接文脈に誤適用したら害がある型。例外条項付きの禁止はこれではなく無条件規範）

• YES → 全文の正は判例decision（add_decisionsで記録。reasonに適用条件:/適用外:の定型節を含める。書式は本スキル同梱の references/precedent-format.md。承認を得てから書く）と決まる。続けて下の判定フローで契機を判定し、契機の置き場が決まった場合はそこへ要旨と判例への参照を書く（両方配置。実行時は判例decision作成→参照配置の順。参照側の承認/報告は、置き場ごとの確認の規定に従う）
• NO → そのまま判定フローへ

判定フロー

前処理として次を行う。

1. 人間の発話による訂正・依頼か？ 他セッションの中継だけなら発動しない
2. 訂正なら先に直す。指示なら指示に従う（作業を先に済ませる）
3. 既存を必ず引く
   • get_feedback_entries（数十件未満なら引数なしで全件）
   • CALM search（対象はdecision/log/material/topic/activityのみ）
   • auto-memoryは文脈内の索引、habits/rulesは注入済みの本文、tag-notesは触れたタグなら注入済み。searchでは出てこないので、文脈を見る

そのルール/情報は…

├─ 訂正でも依頼でもない（置くべきルール・情報が無い）／一回きりの指示・訂正で、
│   同じ型の再来が想定できない？
│   └─ YES → 記録しない（報告もしない）
│
├─ 引いた既存の記録が古い・誤っていて、消すか書き換える必要がある？
│   └─ YES → forget（新しい規範が要るなら、forgetの後にこの木へ戻る）
│
├─ 引いた既存の記録が今も正しく、それを踏んだ（再発）？
│   └─ YES → 再発の手順（下）
│
├─ 【型の前判定】条件付き判断基準か？
│   └─ YES → 全文の正本は判例decision（候補を出し、承認を得てから書く）。
│       続けて下の枝で契機の置き場を決め、そこに要旨と判例への参照を書く
│       （両方配置）
│
├─ 特定のactivity/topicに取り組んでいる間だけ必要？（終われば不要）
│   └─ YES → pin（内容をdecision/materialとして記録し、add_pinで対象へ
│       括り付ける。条件付き判断基準なら前判定で決めた判例decisionを
│       そのままpinで指す。指す先がmaterialか既存のdecisionなら書いたあと
│       報告、新しいdecisionが要るなら承認。pin元へのcheck_inのたびに本文
│       ごと再配達される。ただしpinned合計が全体予算の枠を超えると、小さい
│       ものから優先して残り本文は先頭を残して切られ、続きへのポインタが
│       付く縮退が起きる）
│
├─ 必要になる瞬間を字面で照合できる？
│   ├─ 人間の発話の字面 → エントリ（write_feedback_entry、strength=notify・
│   │    timing=utterance。書いたあと報告）
│   │    ※人間の発話に限る。SAの報告の中継・他セッションからのメッセージ・
│   │      バックグラウンドタスク通知・システム通知のターンは、hook側
│   │      （feedback_hook.py）が配達前に判定して止めるため、エントリ側に
│   │      除外条件を書く必要はない。SAの報告や他セッションのメッセージを
│   │      きっかけにする教訓は、この判定で届かないので下の枝へ
│   ├─ 踏む直前に自分が言いがちな言い回し → エントリ（strength=notify・
│   │    timing=output、conditionのfieldは'text'。書いたあと報告）
│   │    ※次の区切り（次のUserPromptSubmit）で届く。止めはしない。人間の
│   │      発話でないターン（bg・orchへの通知）にも届く
│   │    ※bodyは50字以内の一言。長い説明はrefに置く（拒否される）
│   ├─ ツール失敗のエラー文 → エントリ（strength=notify・timing=tool_fail。
│   │    書いたあと報告）
│   │    ※CALM自身のMCPツールはエラーを例外でなく戻り値で返すため、
│   │      PostToolUseFailureとして届かない（CALMツールの失敗を踏み跡に
│   │      したいならこの枝は使えない）
│   │    ※PreToolUse hookにdenyされた呼び出しは、ツール呼び出し自体が
│   │      実行されないためPostToolUseFailureが発火しない（公式hook
│   │      lifecycleの記述と、denyが多数発生した状況でも配達が一度も
│   │      発生していない実機観察の両方で確認済み）
│   │    ※サブエージェント発（agent_type付き）の呼び出しにはhook側
│   │      （feedback_hook.py）が配達前に判定して止める
│   └─ 実行直前の引数でしか照合できない → blockのエントリ
│        （strength=block・timing=pre_tool。書いたあと報告）
│        ・実行直前にはblock（1回止め）しか無い。「知らせるだけ」は作れない
│        ・1回止める価値があるときだけ使う（見逃すと不可逆、または同じ罠を
│          繰り返し踏む）。それ以外はエントリにせず、下の枝へ
│        ・tool名だけでallが空のblockは作らない（そのツールを毎回止めて
│          しまう）
│   ※エラーの前（設計時・着手時）に知っておくべきことなら、エントリは補助
│     にとどめ、下の枝を主にする
│
├─ 特定のファイルに触れる時だけ必要？
│   └─ YES → ~/.claude/rules/（パス付き。承認）
│       （条件付き判断基準なら、rulesには要旨+判例への参照を書く。
│         `cc-memory-habits.md`はhabits DBからの自動投影ファイルで手動編集
│         対象外。対象はそれ以外の手動管理rulesファイル）
│
├─ 特定のタグ文脈でだけ必要？
│   └─ YES → tag-notes（update_tagで記録。書いたあと報告。条件付き判断基準
│       なら、tag-notesには要旨+判例への参照を書く。型が手順・事実参照
│       （仕様スナップショット・運用手順・歴史記録）なら全文を書かず
│       1行ポインタに留め、正典はコード/docs/資材に置く（rule-placement
│       Step3のタグ文脈行参照）。追記後の見込み文字数が天井(4,000字)を
│       超えるなら（現在天井未満でも増加更新は超過時に拒否されるため）、
│       先に`demote_tag_notes`で縮めてから書き込む）
│
├─ どのプロジェクト・文脈でも常に適用される？
│   ├─ 条件付き判断基準（前判定YES）？
│   │   └─ 判例decisionのみで完結（承認。追加の置き場は作らない。契機を
│   │       名指しできない条件付きは実質「自覚的な迷い」が契機であり、
│   │       迷った瞬間のsearch/add_ask同梱のpullで届く判例が正しい置き場）
│   ├─ 「従え」系の無条件規範？（条件節なしの1文で書ける）
│   │   ├─ 毎回必ず守るべき（違反の実害が大きい）
│   │   │   ├─ 100字未満で書ける → habits（承認。add_habit後、
│   │   │   │    update_habitでtrigger_mode="always"へ昇格）
│   │   │   └─ 収まらない → ~/.claude/rules/（承認。横断ルール）
│   │   └─ 弱い行儀・好み → habits（承認。intelligently層のまま）
│   │       （intelligently層は実際には引かれにくい実測がある。
│   │         本当に守らせたいものをここに置かない）
│   └─ 「知っとけ」系の文脈・tips？
│       ├─ 重要度高い → ~/.claude/CLAUDE.md（承認）
│       └─ 重要度低い → auto-memory（書いたあと報告）
│           （同じ趣旨の記録が再発したら、再発の手順（下）に従う）
│
└─ 次のいずれかに該当 → [rule-placement](../rule-placement/SKILL.md) のfull評価へ
    ・どれにも当てはまらない / 複数に該当して迷う
    ・1つの依頼に性質の異なる複数ルールが混ざっている
    ・契機が「あるツールを呼ぶ瞬間」「ある定型手順（skill）の実行」にしか
      名指しできない（配置先がPR経路になり、fast pathの守備範囲外）

エントリを新しく書く手順

1. bodyだけで意味が通るように、100字以内で書く。refは配達されない
   • 長い手順は資材・skill・ファイルに置き、bodyに参照先を書く（例:「手順は資材〈名前〉をget_materialで読む」）
2. refには「踏み跡: 〜」と経緯を書く。手入れのときに読むためのメモである
3. 書いたら、名前と何をしたかを1行で報告する
4. エントリの変更・削除はforgetを通さない

再発の手順（軽い出口）

まず、そのエントリが「届いた」かどうかを決める。

• 「届いた」とみなすのは、そのエントリの配達文が、今の自分の文脈に見えているときだけである。配達文は次のどれかの形をとる。
  • 「過去の躓きから学んだ注意点」
  • 「直前のツール失敗に関連する過去の躓き」
  • 「直前の自分の発言に関連する過去の躓き」
  • ブロックの理由文
• 見えていなければ「出なかった」とする。圧縮のあとや別のセッションでは、見えないので「出なかった」になる
• 訂正の語彙そのものを条件にしたエントリは、踏んだあとにしか届かない。このため「届いた／出なかった」の欄は空でよい

既存の記録の種類ごとに、次のことをする。複数の種類に同じ記録があるとき（例: フィードバックエントリとrulesの両方に同じ教訓がある）は、フィードバックエントリの行を必ず実行してstumbleを書き、他の行はそのうえで追加として行う。

既存の記録	すること
フィードバックエントリ	add_feedback_note(kind="stumble")を書き、「届いた／出なかった」と「人に直されたか」を記す。<br>出なかった: get_feedback_entries(name=)でread_markを取り、write_feedback_entry(action="update")で条件を広げる。広げれば次は届く見込みならここまでにする。広げても字面で拾えない型なら、次の「届いたのに」と同じく格上げを検討する。<br>届いたのに踏んで人に直された: stumbleを1件書いた時点（再発1回）で、block化・rules/habits格上げ（要承認）・条件修正のいずれかを検討し、結果をnoteに残す。件数が溜まるのを待たない。
auto-memory / tag-notes	字面で照合できる: エントリを新しく作る（書いたあと報告）。bodyはその記録の要旨とし、「詳細は〈記録名〉」と書く。<br>照合できない: まず「それを踏む直前に、自分が言いがちな言い回しはあるか」を考える。あれば、その言い回しを条件にしたoutputのエントリを新しく作る（書いたあと報告。上の「字面で照合できる」と同じ作り方で、bodyは50字以内）。言い回しが思い当たらないときだけ、その記録に日付つきで再発の1行を追記する。書式は- 再発 YYYY-MM-DD: <何が起きたか1行>（書いたあと報告）。<br>再発の行を1行追記した時点（再発1回＝2回目に踏んだ時点）で、rule-placementのfull評価で格上げ先を決める。結論がrules・habits・CLAUDE.md・判例decision・新しいdecisionなら、下の「格上げの承認の取り方」に従う。tag-notes・pin・エントリなら書いたあと報告する。
rules / habits / CLAUDE.md	字面で照合できる: blockかnotifyのエントリで強制力を足す（書いたあと報告）。bodyは人間の規則への参照だけにし、規則の中身を言い換えない。<br>照合できない: auto-memoryに「〈規則名〉の再発」の記録を作るか追記して、上の行と同じく再発の行を1行書いた時点でfull評価に進む。<br>すでに常時push（always/rules）に置かれていて上げる先が無いときは、書き直しの候補を出し、下の「格上げの承認の取り方」に従う。

照合できない再発は、この1本の道だけで扱う。full評価に進むのは、再発の行を追記して格上げを検討するときだけである。

格上げの承認の取り方

格上げ先が承認の要る置き場（rules・habits・CLAUDE.md・判例decision・新しいdecision）になったときは、次の2通りのどちらかで承認を取る。

• 生きたセッションでユーザーがいる: その場で候補を出して聞く
• 人がいない場面（sync-memoryなど、セッションを閉じる直前の一括処理）: add_askでメタask（kind="meta"、blocks不要）を起票する。questionは「教訓〈名前〉を〈候補の置き場〉へ格上げしてよいか」とし、contextには教訓の要旨・踏んだ経緯・候補の置き場とその理由を入れる。起票までが仕事で、承認なしに書かない

格上げ則（判定フローに優先する例外）

「見逃すと不可逆な事故になる（外部へのpush・データ消失・他セッション巻き込み）」かつ「踏む直前に迷いが発生しない（良かれと思って・ついでに踏む）」ルールは、pull系（判例decision・habits intelligently層・auto-memory）に置いてはいけない。契機を名指しできるならその契機のpush経路（tag-notes/pin）、できないなら常時push（habits always昇格 or ~/.claude/rules/）へ格上げする。pull経路は実際には引かれないことがある。

• 実行直前の引数で照合できるなら、blockのエントリを格上げ先の最上位にする
• 既存のエントリがあっても、それが不可逆で、しかも気づかずに踏む種類なら、blockのエントリを新しく作ることを同時に検討する

格上げ先の経路の判断に迷う場合は、fast pathで即決せずrule-placementのfull評価（Step 4の強度補正）で確定する。

判定の3軸（fast path版）

• 契機: 何が起きたらこのルールが要るのか。作業単位 → ファイル → タグの順（狭い契機から）に名指しを試し、名指しできないものだけを「常時」に落とす。複数の契機に該当したら、より狭い契機を採る。「重要だから常時」は契機の名指しの失敗（重要度はリスク軸で扱う）
• 型: 無条件規範（従え系）/ 条件付き判断基準（〜ならOK系）/ 事実・tips（知っとけ系）
• リスク: 見逃しコスト × 無自覚性。上記の格上げ則を参照

habits投影の仕組み

add_habitで記録したhabitは常にtrigger_mode='intelligently'（マニフェスト表示）で作成される。SessionStart時に~/.claude/rules/へ自動投影されるが、intelligently層はタイトルのみで、全文はget_habitsでのon-demand取得が必要になる。

「毎回必ず全文で見てほしい」レベルの制約は、記録後にupdate_habitでtrigger_mode="always"へ昇格する追加ステップが要る（新規作成と同時にalways指定はできない）。判定に迷う場合はユーザーに確認する。

注入の強度

強 ┃ habits（always層）        — 全文をSessionStartで常時投影。絶対守れ
   ┃ rules/                    — セッション起動時に全文注入。従え
   ┃ pin                       — pin元へのcheck_inのたび本文ごと再配達
   ┃                             （pinned合計が予算超過時は小さい順に優先、
   ┃                             溢れた分は先頭を残して切られポインタが付く）
   ┃ フィードバックエントリ    — 字面が一致した瞬間に配達、blockは実行を止める
   ┃ tag-notes                 — タグ文脈に触れた初回に全文注入
   ┃ CLAUDE.md                 — プロジェクト文脈として参照
   ┃ 判例decision              — search/pull_precedents/add_ask時にpullで届く
   ┃ auto-memory               — 見えてはいるけど、気づけば使え程度
   ┃ habits（intelligently層） — タイトルのみ常時投影、全文はget_habitsで取得
弱 ┃

注意

• 判定に迷ったらrule-placementのfull評価へ。それでも決めきれない場合はユーザーに確認する
• 「決めたことの事実記録」としてのdecision（decision-record skillの担当）は「覚えて」の対象外。ただし条件付き判断基準の配置先としての判例decisionは本フローの正規の出口であり、対象外ではない。記録時はdecision-recordの書式作法（定型節）に従う
• auto-memoryとCALMの二重記録はOK（異なる注入経路として機能する）
• 保存済みの記録そのものが古い・誤りで消す・書き換える必要がある場合は対象外。気づいたらforget skillへ