Sync memory

sync-memory

このセッションの会話内容（transcript）を解析し、以下の記録・更新をすべて実行してください。

実行手順

sync_policyの確認

セッション開始時にアクティブコンテキストとして sync_policy が注入されている場合、そのポリシーに従って以降のステップを実行する。

• sync_policyあり: ポリシーの内容に従ってエージェントが自律的に判断する。ユーザーへの確認を省略してよい場面はポリシーの記述に従う
• sync_policyなし: 従来通りの手順で実行する（各ステップの指示に従う）

0. 既存データの確認（重複防止）

最初に必ず実行する。 前回のsync-memoryやセッション中の手動記録で既に記録されている可能性があるため、既存データを確認してから記録する。

アクション:

• セッション中に使ったトピックの get_decisions(topic_id=...) と get_logs(topic_id=...) を実行し、直近の決定事項・ログを取得
• get_activities(status="active", orch_managed=False) で未完了アクティビティを取得（pending + in_progress）
• 取得した既存データと会話内容を照合し、既に記録済みの内容は記録しない

重複の判定基準:

• 同じ意味・内容のdecisionが既にあれば記録しない（完全一致でなくても意味が同じならスキップ）
• 同じ意味・内容のlogが既にあれば記録しない
• 同じタイトル・目的のアクティビティが既にあれば記録しない
• 同じテーマのtopicが既にあれば記録しない

1. トピックの特定・作成 (add_topic)

transcriptを解析し、議論されたテーマを特定する。

チェック項目:

• 新しい議論テーマが出ていないか？
• 既存トピックの子トピックとして切り出すべきものはないか？
• トピックが広すぎて分割すべきものはないか？

アクション:

• 既存トピックにマッチするものがあればそれを使う
• 新しいテーマがあり、かつ記録（decision/log）が必要な場合のみ add_topic で作成
• 作成時は tags に domain: タグ（必須）＋内容を表すタグを付ける

2. アクティビティの特定・登録 (add_activity)

実装予定・作業予定をすべて登録する。ここで登録したアクティビティは、後続の資材保存（Step 3）の紐づけ先になる。

アクティビティの判定基準:

• 「〜を実装する」「〜を作る」「〜を追加する」
• 「〜が必要」「〜をやる」
• 決定事項から派生する実装作業

チェック項目:

• 記録漏れのアクティビティはないか？
• アクティビティの粒度は適切か？（1つのPRで完結する程度）
• description に十分な情報があるか？

アクティビティ完了判定（確信度3段階）:

既存アクティビティの完了状態を以下の確信度で判定する:

• 高（自動クローズ）: エージェントが update_activity(status="completed") を実行する。ユーザー確認不要
  • PRマージ済み（transcript内でマージ確認済み）
  • フェーズ遷移済み（後続のdesign/implementアクティビティがin_progress以降）
  • セッション内でゴール達成が明確
• 中（自動判定）: Step 10aの棚卸しで自動的に処理する
  • 前回セッションであと一歩だったもの（残タスクが軽微）
  • 外部で完了した可能性が高いもの（transcript外の状況変化を示唆する情報がある）
• 低（自動判定）: Step 10aの棚卸しで自動的に処理する
  • 7日以上放置されているもの
  • 重複しているもの
  • 状況変化で不要になったもの

アクション:

• 未登録のアクティビティがあれば add_activity で登録
• tags に domain: タグ（必須）＋内容を表すタグを付ける
• 関連する仕様書があれば description に参照を含める
• 確信度「高」のアクティビティは update_activity で completed にする（自動クローズしたものはStep 10で事後報告する）
• 自動クローズしたアクティビティに次フェーズがあれば、アクティビティを作成する（例: [議論] 完了 → [設計] を作成）。既に存在すればスキップ。確信が持てなければ作成せず現状のまま残す

3. 資材の保存 (add_material)

セッション中に生成・確認された「静的な情報」を資材として保存する。資材はセッション終了とともに揮発するため、ここで永続化する。

materialに入れるもの（静的な情報 = 事実・成果物・スナップショット）:

• 分析結果・調査レポート
• 設計ドラフト・仕様案
• 調査で判明した事実（仕様、挙動、制約など）
• コード（生成したコード、差分、設定ファイルの内容など）
• 比較表、一覧表

logとの棲み分け:

• material = それ自体は変化しない、ある時点での情報。要約せずそのまま保存する
• log = 議論の流れ・判断プロセス。material IDを参照して経緯を記録する

アクション:

• セッション中の生データを洗い出し、add_material でタグ付きで保存する（タグ必須）
• 既存 material（ガイド・設計仕様・一覧表など、更新されうる素材）の内容と矛盾・古い情報がある場合は、search() で対象 material を特定してから update_material(material_id, ...) で更新する
• related で関連するアクティビティやトピックとリレーションを張る
• 保存した material ID は Step 4 の log で参照する

4. 決定事項・ログの記録 (add_decision / add_log)

合意が成立した内容（decision）と、議論の経緯（log）を記録する。

決定事項の判定基準:

• ユーザーが「OK」「それでいこう」「了解」「いいね」等で承認した
• AIの提案に対して明示的な同意があった
• 「〜で決定」「〜に決めた」等の表現がある

（正本は decision-record skill の「合意判定基準」節。本ステップの記述と食い違う場合はそちらに従う）

ログの記録対象（議論の流れ・判断プロセス）:

• 議論の流れ（ユーザーの発言とAIの応答の要点）
• 検討した選択肢とその比較
• 採用しなかった案とその理由
• なぜその結論に至ったかの経緯

チェック項目:

• 記録漏れの決定事項はないか？
• 各決定事項は適切なトピックに紐づいているか？
• decision と reason が明確に分離されているか？
• 議論の経緯がlogとして残せているか？

アクション:

• 未記録の決定事項があれば add_decision で記録
• 議論の経緯があれば add_log で記録
• log には Step 3 で保存した material ID を参照として含める（例: 「分析結果（material #NNN）を踏まえてA案を採用」）
• topic_id は関連するトピックを指定
• tags で内容を表すタグを付ける（省略時はtopicのタグを継承）
• 記録したdecisionの中に、今後の作業や継続議論を伴うものがあれば、対応するアクティビティを add_activity で作成する（Step 2で未登録の場合）

CALM自身の不具合・使用感の違和感・既存記録との矛盾に気づいた場合は add_logs ではなく report_signal を使う（kind一覧は report_signal ツールの docstringを正とする）。

reasonの定型節（任意）:

議論の中で他案を検討して採らなかった・適用範囲が限定的・実測して確認した、といった 情報があれば、reason本文の末尾に定型節（却下案:/適用条件:/適用外:/検証:/隣接確認:）で書く。 書式の詳細は decision-record skillを参照する。将来のセッションが同じ案を再提案したり 射程外に誤適用したりすることを防ぐ。節はすべて任意で、該当なしなら書かない（空項目・ ダミー項目を作らない）。

add_decisions はこの節をパースして precedent としてレスポンスにechoする。書いたつもりの 節がechoに現れなければ書式ゆれの可能性がある（precedent_warnings を確認する）。

5. リレーションの確認・追加 (add_relation)

記録したトピック・アクティビティ間の関連を add_relation で追加する。ステップ1〜4でトピック・アクティビティの新規作成も既存エンティティへの記録もなかった場合はこのステップをスキップする。

判断基準:

• 「この2つは関連している」と思ったら張る（過剰 > 不足）
• 間違ったリレーションは remove_relation で消せるため、迷ったら張る

チェック項目:

• 同じテーマを扱うtopic同士にリレーションがあるか？
• アクティビティとその背景トピックにリレーションがあるか？
• 関連するアクティビティ同士にリレーションがあるか？

アクション:

• add_relation(source_type, source_id, targets=[{"type": "...", "ids": [...]}]) で追加
• 新規作成した topic / activity だけでなく、既存エンティティとの関連も確認する

6. 未決定の論点を記録 (add_decision)

議論が途中で終わった論点・アイデア・検討事項を記録する。決定していなくても記録する。

[議論中] の記録基準の正本は decision-record skill の「未決論点の記録: [議論中]」節であり、本ステップの記述と食い違う場合はそちらに従う。[未完] はアクティビティ側の関心事であり、Step 7 で扱う。

記録すべきもの:

• 議論に出たが結論が出ていない論点
• 「〜かも」「〜という案もある」「〜どうしようかな」
• 提案されたが承認/却下がまだのアイデア
• 次のセッションで継続すべき検討事項

チェック項目:

• 議論が途中で終わっている論点はないか？
• 出てきたアイデアが記録されずに消えていないか？

アクション:

• add_decision で記録（決定事項と同じテーブルで管理）
• プレフィックスをつける: [議論中] または [未完]
• tags で内容を表すタグを付ける
• フォーマット例:

  decision: "[議論中] Skillの発動条件をどう改善するか（選択肢: A案, B案, C案）"
  reason: "議論は出たが結論未定。次セッションで継続"
  

• 論点が大きい場合は子トピックとして切り出す

7. 未完の作業をアクティビティとして登録 (add_activity)

セッション中に途中で終わった話・作業がある場合、次のセッションでこのアクティビティだけ見れば文脈が取れるレベルでアクティビティを登録する。

対象:

• 議論が途中で終わった話題（設計の途中、要件の詰めが途中など）
• 実装に着手したが完了していない作業
• ユーザーから依頼されたが未着手のもの

アクティビティの書き方:

• title: [未完] 〜 のプレフィックスをつける
• tags に domain: タグ（必須）＋内容を表すタグを付ける
• description に文脈を多めに記載する。具体的には：
  • 何について話していたか
  • どこまで進んだか・何が決まったか
  • 何が残っているか・次に何をすべきか
  • 関連するトピック名・決定事項の概要

フォーマット例:

title: "[未完] sync-memoryに未完アクティビティ自動作成機能を追加"
description: "「sync-memory改善」トピックで議論中。ステップ4のdecision記録はそのまま残し、追加でadd_activityでも登録する方針で合意済み（decision A案）。残作業：SKILL.mdへのステップ追加と動作確認。"

注意:

• ステップ6の [未完] decision とは別に、アクティビティとしても登録する（役割が異なる：decisionは「何が未決定か」、アクティビティは「次に何をすべきか」）
• 未完の話がなければこのステップはスキップする

8. 抜け漏れチェック

ステップ1〜7で記録した内容とtranscriptを突き合わせ、記録漏れがないか確認する。

アクション:

• transcriptを見直し、記録済みの内容と照合する
• 落ちているトピック・アクティビティ・資材・決定事項・ログがあれば、その場で追加記録する

9. 聞き返しの後追い検出

セッション中にClaudeがユーザーへ聞き返した質問と、ユーザーからの訂正発話を機械抽出し、既存記録との類似照合を経て「既存記録で答えられたはずだったか」を判定する。yesと判定した候補は report_signal(kind="precedent_miss") で計測台帳に積む。

前提スキップ: 候補が0件のときはこのステップ全体をサイレントスキップする。ユーザーへ「該当なし」と報告する必要はない。

手順:

1. SessionStart時にコンテキストへ注入された「このセッションのtranscript path: ...」の行からtranscript pathを取り出す。無ければこのステップをスキップし、完了報告に一行残す
2. 取り出したtranscript pathを渡して detect_reask_candidates(transcript_path=<path>) を1回呼ぶ。旧来の抽出スクリプト（scripts/detect_reask_candidates.py相当）・excluded_reason が付いた候補の除外・残候補のうち先頭N件（上限あり。Nを超える候補は判定対象外とし、超過した旨を完了報告に一行残す）への search バッチ実行までを内部で行い、各候補に既存記録top-3（top_hits。閾値は本ステップ末尾の実装ノート参照）が付いた candidates を返す
3. 個別の search 呼び出しは発生しない（手順2に集約済み）
4. 候補ごとの candidate.degraded（内部で行われた search バッチ呼び出しの degraded を候補単位に反映したもの）で degraded=true のときは判定を保守側に倒す（該当候補についてはprecedent_miss記録を行わない。skipした事実はStep 11の完了報告に一行残す）
5. 候補ごとの top_hits（閾値は本ステップ末尾の実装ノート参照。detect_reask_candidatesが内部で閾値判定済み）を「高類似ヒット」として扱う。高類似ヒットが1件もない候補は判定・記録の対象外とする。高類似ヒットがある候補についてのみ、Claudeが「この既存記録があれば、この聞き返しはそもそも不要だったか」を判定する。この判定はClaudeの主観判断であり、同じ候補・同じ既存記録でも判定がぶれうる
6. yes判定のみ report_signal(kind="precedent_miss", summary=..., detail=..., refs=[高類似ヒットの各id], context={"missed_ids": [...]}) を呼ぶ。summaryのフォーマットは下記参照（dedup fingerprintの安定性のため決定論的な文字列に固定する）
7. 判定ログ（候補text・ヒットid・判定結果）は本ステップ内では保存しない（signal_events側のcontextに集約される）

記録で答えられない性質の候補は除外する:

• Claudeの意見・選好を求める質問（「A案とB案どっちがいい?」等）
• ユーザー自身の選好・状況を尋ねる質問（「今日どこまでやりたい?」等）
• セッション外の環境事実（OS状態・CI状態・PR状態など、記録に載せる対象ではないもの）

report_signalのsummaryフォーマット:

summaryは決定論的な文字列 missed: <最上位ヒットの既存記録type>#<id> に固定する（自由記述の要約はdetailに書く）。高類似ヒットが複数件ある場合は、refsのうち最もscoreが高いものを代表として使う。summaryはfingerprint計算にそのまま使われるため、自由記述にすると同じ既存記録を別セッションで踏み直したときに文言が実行ごとに揺れ、fingerprintが一致せずdedupが発火しない。

実装ノート（初期値、観察後に確定値へ差し替え）:

• 判定に回す候補上限N: 5〜10件（detect_reask_candidatesのsearch_top_n引数、既定8件）
• 「高類似ヒット」の閾値: search score 0.4以上（detect_reask_candidatesのscore_threshold引数、既定0.4）
• 除外辞書: scripts/detect_reask_candidates.py の組み込み既定を使う（detect_reask_candidatesツールは辞書差し替え引数を持たない。差し替えが要る場合は従来通りスクリプトを直接呼ぶ）

10. 棚卸し・remember（自動実行）

ステップ10a〜10bの判定に基づき、ユーザーに確認せずClaudeが判断してその場で処理する。処理内容はステップ11の完了報告にまとめて記載する。10a〜10bが何も無ければステップ10全体をサイレントスキップする。

10a. アクティビティの棚卸し

まずスキップ判定: ステップ0で取得したアクティビティを以下のカテゴリに照合し、該当が1件もなければ即座にスキップする。 ユーザーにアクティビティ一覧を見せたり、「該当なし」と報告する必要はない。

判断基準 — いずれかに該当するアクティビティがある場合のみ処理対象とする:

（確信度「高」のアクティビティはStep 2で自動クローズ済みのため、ここでは扱わない）

確信度「中」（完了の可能性が高いがエージェント判断では確定できないもの）:

• 前回セッションであと一歩だったもの（残タスクが軽微）
• 外部で完了した可能性が高いもの（transcript外の状況変化を示唆する情報がある） → update_activity(status="completed") で自動的にcompletedにする（Step 2の確信度「高」と同様の扱い）

確信度「低」（整理・棚卸し対象）:

1. 重複: 同じ目的・内容のアクティビティが複数存在する場合の片方 → update_activity(status="completed") にする。判定優先順位: まず情報量（description・タグ・関連リレーションの充実度）が少ない方を選ぶ。情報量が同程度の場合のみ updated_at が古い方を選ぶ
2. 7日以上放置: updated_at から7日以上経過しているpendingアクティビティ → 前提が変わらずまだ必要と判断すれば update_activity(activity_id, status="snoozed") で寝かせる（snooze期間経過後に自動でpendingに復活する）、状況を見て不要と判断すれば completed にする
3. 状況変化で不要: 前提条件が変わり、もうやる意味がないアクティビティ → update_activity(status="completed") にする。description先頭に理由を追記する（例: 「YYYY-MM-DD sync-memoryで前提変更によりcompleted」）
4. フェーズ移行済み: in_progressの議論アクティビティ（intent:discuss）で、後続フェーズが既に動いているもの。以下のいずれかで検出する:
   • depends_onで下流アクティビティ（intent:design/implement）がin_progress以降
   • 同トピック内でintent:discussがin_progressかつ、intent:design/implementのアクティビティが存在する → update_activity(status="completed") にする

いずれも判断に迷う場合は、より安全な側（消さない・completedにしない、現状のまま残す）に倒す。

10b. 記憶すべき知見の判定（remember）

セッションのtranscriptを振り返り、記憶すべき知見を収集・判定する。

収集 — 以下のパターンに該当するものを洗い出す:

• ユーザーからの修正指示（「それじゃなくて」「〜しないで」「〜のほうがいい」）
• エージェントのやらかし（コマンドミス、間違った前提での行動、やり直し）
• ハマりポイント（デバッグや調査に時間がかかった箇所）
• ユーザーの非自明な肯定（意外なアプローチが通った「そうそう」「それでいい」）
• 新発見（調査で判明した仕様・制約・挙動）

振り分け — 収集したネタを2軸で保存先に判定する:

• 特定のタグ文脈でだけ必要 → tag notes（update_tagで記録）
• どの文脈でも常に適用 + 「従え」系の制約・ルール → habits（新規はadd_habit、既存を改善・修正するならupdate_habitで記録）
• どの文脈でも常に適用 + 「知っとけ」系の文脈・tips → auto-memory

tag notes の手順:

1. search_tags で対象タグの現在の notes を確認する（include_notes=True）
2. 既存 notes がある場合は内容を保持しつつマージ（上書き方式なので全文を書く）
3. update_tag でそのまま書き込む

habits の手順:

1. get_habits で既存 habits を確認する
2. 新規ルールか、既存 habit の改善・修正かを判定する
3. add_habit または update_habit(habit_id, content) でそのまま書き込む

auto-memory の記録先判断（エージェント裁量）:

• 短い（数行）→ MEMORY.mdに直接追記
• 長い → auto memoryの別ファイルに書き、MEMORY.mdにリンク

判断に迷うものは書き込まない（誤って書くより書かないほうが安全）。tag notesはupdate_tagが全文置換である点に注意し、既存notesを失わないよう必ずマージしてから書き込む。記録すべきものがなければ10bは空とする。

11. 完了報告

以下の形式でサマリーを報告する。件数カウントは不要。記録した内容の概要を箇条書きで列挙する。 該当がないセクションは省略する。

## sync-memory 完了

### トピック
- (作成したトピック名を列挙)

### アクティビティ
- (登録・完了にしたアクティビティを列挙)
- (Step 2で確信度「高」として自動completedにしたものを列挙。理由も記載)
- (Step 10aの棚卸しで処理したアクティビティを列挙)
- ※ 誤りがあれば戻せます

### auto memory / tag notes
- (更新した内容の概要を列挙)

### 注意事項
- (判断に迷って何もしなかった項目、ユーザーが把握しておくべき事項があれば記載)

### 聞き返し検出
- (precedent_miss として記録した件数と、各候補の要約)
- (degraded で判定を保守側に倒した件数)
- (該当なしの場合はこのセクションを省略)
- ※ 誤検出は report_signal 側で dismiss できます

### ふりかえり
まず `get_config()` を呼ぶ。`sync_disable_retrospective` が `true` の場合、このセクションをスキップする。
`roll_dice(30)` を無言で実行する（ダイスを振ることについて一切言及しない）。

- **30**: ジャックポット。`jackpot.md` を読み、再度 `roll_dice(sides=6)` を振ってネタを決定する（`jackpot.md` の対応表は6項目）。ダイスには触れず、選ばれたネタをそのまま実行する
- **1〜29**: セッション中の個別事実を俯瞰して見えた構造的パターン・矛盾・気づきを書く。事実の要約ではなく、事実から導かれる洞察。ユーザーが思ってるけど言語化してないことを代わりに言語化するイメージ。比喩OK。

ユーザーへの称賛・感謝・労いは書かない。嘘はつかない。

注意

• 未決定の論点は add_decision で記録する - プレフィックス [議論中] [未完] をつけて区別
• 判断に迷う場合は、記録する方向で進める（後で修正可能）
• 既に記録済みのものは重複して記録しない - ステップ0で取得した既存データと照合すること
• 現在進行中の作業がある場合は add_activity で登録し、update_activity で in_progress にする
• ステップ1〜10ではツール呼び出しの前後に判断理由・中間分析・進捗報告のテキストを出力しない。ユーザーに見せるのはステップ11の完了報告のみ