sync-memory

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

引数なしなら標準形（下記1〜6）を実行する。--minimal 引数（/sync-memory --minimal など）が渡された場合は最小形を実行する。

このセッションがorchタグの付いたアクティビティ（orch）の担い手で、ユーザーがこの窓口を閉じると言っているなら、以下の手順に入る前にorch skillの「空ける」を先に実行する。閉じないsync-memory（途中の記録など）では空けない。

実行手順（標準形）

1. 未記録区間の特定

まだ記録されていない区間（トピック・決定事項・ログ・資材・アクティビティ）を洗い出す。ここで洗い出した範囲を次のステップでまとめて記録する。同じ突き合わせをステップ4以降でやり直す必要はない。

アクション:

• セッション中に使ったトピックの get_decisions(entity_type="topic", entity_id=...) と get_logs(entity_type="topic", entity_id=...) を実行し、直近の決定事項・ログを取得
• get_activities(status="active") で未完了アクティビティを取得（pending + in_progress）
• 取得した既存データとtranscriptを照合し、まだ記録されていない議論・決定・成果物・アクティビティの範囲を特定する

重複防止の判定基準:

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

2. 未記録区間の記録

ステップ1で特定した範囲を、トピック・資材・決定事項・ログ・関連に振り分けて記録する。

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

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

チェック項目:

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

アクション:

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

資材の保存 (add_material)

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

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

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

logとの棲み分け:

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

アクション:

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

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

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

決定事項の判定基準:

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

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

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

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

チェック項目:

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

アクション:

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

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

reasonの定型節（任意）:

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

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

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

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

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

記録すべきもの:

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

チェック項目:

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

アクション:

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

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

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

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

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

判断基準:

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

チェック項目:

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

アクション:

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

3. アクティビティの始末（自セッションが触ったものに限る）

自セッションが触った（言及・着手・作業した）アクティビティに限り、次の3つを行う。全アクティビティを対象にした整理はステップ4a（棚卸し）の役割であり、ここでは扱わない。

未登録の作業を起票する

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

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

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

チェック項目:

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

アクション:

• 未登録のアクティビティがあれば add_activity で登録
• tags に domain: タグ（必須）＋内容を表すタグを付ける
• 関連する仕様書があれば description に参照を含める
• 起票するアクティビティについて、transcript中でこの作業の終了条件が明言されている、または推せるなら、起票と同じタイミングで確認なしに set_goal(activity_id, goal={"new": {...}}) をopenの条件として書く。候補が複数で定まらない、またはそもそも推せないときは書かない（事後の一括処理でユーザーに聞く相手がいないため、未定義のまま残す）

確信度「高」を自動クローズする

判定対象は、節見出しのとおり自セッションが触ったアクティビティに限る。以下の基準（フェーズ遷移済み等）はDB状態だけで機械的に真偽が付くが、それでも自セッションが触っていないアクティビティには適用しない。ステップ1で取得した全アクティブアクティビティのうち、自セッションが触っていないものは、基準に該当していてもここでは判定しない（該当すればステップ4aの棚卸しの対象になりうる）。

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

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

アクション:

• 確信度「高」のアクティビティは update_activity で completed にする（自動クローズしたものはステップ6で事後報告する）。ただし対象が goal に紐づいている場合は update_activity では completed にせず goal 機構側で扱う（get_goal(activity_id=...) で確認する）。外部の完了（PRのマージ状況など）を根拠にする条件は、gh など実際の手段で確かめられれば該当条件を update_goal で satisfied に書き、確かめた事実を add_material か add_logs に残す。確かめられないものは推測のまま satisfied にしない。確かめた結果で全条件が終端すれば judge_goal も呼んでよい（open_questions の扱いはcheck-inの「goalフィールドの扱い」節に従う）
• 自動クローズしたアクティビティに次フェーズがあれば、アクティビティを作成する（例: [議論] 完了 → [設計] を作成）。既に存在すればスキップ。確信が持てなければ作成せず現状のまま残す

未完の作業を引き継ぐ（[未完]）

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

対象:

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

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

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

フォーマット例:

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

注意:

• 未決定の論点を記録する節の [議論中] decision とは別に、アクティビティとしても登録する（役割が異なる：decisionは「何が未決定か」、アクティビティは「次に何をすべきか」）
• 未完の話がなければこの節はスキップする
• transcript中でこの作業の終了条件が明言されている、または推せるなら、起票時に上記「未登録の作業を起票する」節の手順で確認なしに set_goal(new) を書く。候補が複数で定まらない、またはそもそも推せないときは書かない

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

ステップ4a〜4bの判定に基づき、ユーザーに確認せずClaudeが判断してその場で処理する。ただし4bでrememberの判定が承認を要求する置き場になったものは、承認なしに書ける置き場へ格下げしてその場で書く（下の4b参照）。処理内容はステップ6の完了報告にまとめて記載する。4aが何も無ければ4aは黙ってスキップしてよい。4bは省略せず必ず実行し、結果（訂正の件数）を完了報告に必ず書く。

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

（本節の判定基準が recompose-context skill の全体モードの「3. 処遇判定」節と食い違う場合は、そちらを正本とする）

goal付きアクティビティの扱い: 以下の判定でcompletedにする（または重複統合で閉じる側にする）前に、対象が goal に紐づいていないか get_goal(activity_id=...) で確認する。goal に紐づいている場合、この棚卸しの推定だけではcompletedにせず、judge_goal も呼ばない（このセッションに根拠のある充足だけが判定材料になり得るが、推定に基づくこのステップの判定はその根拠にならない）。ただし外部の完了を、ステップ3の確信度「高」と同じ基準（gh など実際の手段で確かめられれば update_goal で該当条件を satisfied に書き、終端すれば judge_goal も呼んでよい）で確認できた場合はその限りではない。重複判定（下記1）でも、goal付きのアクティビティは閉じる側にしない（残す側にする。両方がgoal付きなら、このステップでは統合せず現状のまま残す）。

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

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

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

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

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

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

1. 重複: 同じ目的・内容のアクティビティが複数存在する場合の片方 → update_activity(status="completed", closed_by="claude") にする。判定優先順位: まず情報量（description・タグ・関連リレーションの充実度）が少ない方を選ぶ。情報量が同程度の場合のみ updated_at が古い方を選ぶ
2. 放置: max(updated_at, last_heartbeat_at) から7日以上経過しているpendingアクティビティ → 前提が変わらずまだ必要と判断すれば update_activity(activity_id, status="snoozed") で寝かせる（snooze期間経過後に自動でpendingに復活する）、状況を見て不要と判断すれば update_activity(status="completed", closed_by="claude") にする
3. 状況変化で不要: 前提条件が変わり、もうやる意味がないアクティビティ → update_activity(status="completed", closed_by="claude") にする。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", closed_by="claude") にする

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

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

セッションのtranscriptを振り返り、記憶すべき知見を収集・判定する。最初に人間の訂正を拾う。 他の収集パターンはその後にする。

手順（この順で行う）:

1. 訂正を拾う: transcript中の人間の発話から、Claudeの言動を誤りとして直したもの（「〜じゃなくて」「〜しないで」「〜のほうがいい」「なんで〜したの」、同じ指摘の繰り返し）を全部リストにする。1件ずつ、何を直されたかを1行にする。0件なら0件と数える（SAの報告・他セッションのメッセージ・システム通知は含めない）
2. 既存の教訓の索引を1回で引く: get_feedback_entries() を1回呼ぶ（50件以下なら引数なしで全件、超えるなら訂正の語で絞り、絞ったときは完了報告の注意事項にそう書く）。文脈内のauto-memory索引・habits/rules・触れたタグのtag-notesも合わせて見る。リストの訂正をこの索引とまとめて突き合わせ、各訂正を「新規」か「再発（既存の教訓名）」に振り分ける。訂正ごとのCALM searchは回さない（判例decisionの要否判定が要るネタだけ、rememberの手順でsearchする）
3. 書く: 1件ずつ remember skillの判定フロー（前処理3のうちフィードバックエントリ・文脈内索引の確認は2で済んだものとして扱う）に従って置き場を決め、書く。再発はrememberの「再発の手順」でstumbleを書く
4. 訂正以外の収集パターンも拾う: エージェントのやらかし（コマンドミス、間違った前提での行動）、ハマりポイント、ユーザーの非自明な肯定、新発見（調査で判明した仕様・制約）。これらも3と同じく1件ずつremember経由で置き場を決める

置き場の決め方と書き込みの注意（承認の要る置き場の格下げ、tag notesの全文置換への注意など）はremember側の手順に従う。ただしsync-memoryは事後の一括処理でユーザーに聞く相手がいないため、次のとおり読み替える。

• 確認の規定で「承認を得てから書く」置き場（rules・habits・CLAUDE.md・判例decision・新しいdecision）になったネタは、承認不要の置き場のうち最も強いところへ格下げして、その場で書く。字面で照合できるもの（人間の発話・ツール失敗・実行直前の引数）はフィードバックエントリ、照合できないものはauto-memoryに書く。本来の置き場の候補は残す（エントリならrefに「本来の置き場の候補: habits」のように、auto-memoryなら本文に書く）
• 「書いたあと報告」の置き場は、その場で書き、報告はステップ6の完了報告に含める（個別の1行報告はしない）
• 「ユーザーに確認する」「判定に迷う」「rule-placementのfull評価でも決めきれない」ネタは書き込まない。完了報告の注意事項に、迷った点とともに記す（誤って書くより書かないほうが安全）
• rememberの発動契機のうち、ユーザーへの応答として先に直す手順（訂正なら先に直す）は、すでに済んだものとして扱う
• 再発として既存の記録に追記する場合は、追記（stumbleまたは再発の行）を書いたうえで、強い置き場への格上げが必要になったときはrememberの「格上げの承認の取り方」の人がいない場面に従い、メタaskを起票する

訂正が0件で、他にも記録すべきものがなければ、書き込みなしで終える（完了報告には「訂正: 0件」の行を書く）。

5. 聞き返しの後追い検出（条件付き）

セッション中にClaudeがユーザーへ聞き返した質問（AskUserQuestion）と、「これ前に決めなかったっけ」のような過去の議論を指す定型の発話を機械抽出し、既存記録との類似照合を経て「既存記録で答えられたはずだったか」を判定する。yesと判定した候補は report_signal(kind="precedent_miss") で計測台帳に積む。

注意: 抽出が拾うのはAskUserQuestionの呼び出しと数個の固定フレーズだけである。「〜しないで」のような通常の訂正は拾わない（それは4bの担当）。実績では抽出が0件のことが大半で、0件でも異常ではない。

前提スキップ: 候補が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した事実は完了報告に一行残す）
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ツールは辞書差し替え引数を持たない。差し替えが要る場合は従来通りスクリプトを直接呼ぶ）

6. 完了報告とふりかえり

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

## sync-memory 完了

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

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

### 記憶（フィードバックエントリ / auto memory / tag notes / pin）
- 訂正: N件（新規N・再発N。別軸で、書いたN・書かなかったN。どちらの軸も合計がN）。0件なら「訂正: 0件」の行を書く（この行は省略しない）。「書かなかった」は迷って書かなかったものと、書き込めなかったもので、理由を注意事項に1行ずつ書く
- (書いたものを置き場ごとに概要を列挙。既存エントリへの再発追記もここに書く)
- (格下げして書いたものは「格下げ」と明示し、本来の置き場の候補を添える)
- (格上げのために起票したメタaskがあれば、その旨を添える)

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

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

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

- **30**: ジャックポット。`jackpot.md` を読み、対応表の項目数を数えて `roll_dice(sides=<項目数>)` を振ってネタを決定する。ダイスには触れず、選ばれたネタをそのまま実行する。ネタ7（マルコフ連鎖）の場合は、書き出したコーパスの絶対パスを引数にして `uv run --directory "${CLAUDE_PLUGIN_ROOT}" python "${CLAUDE_SKILL_DIR}/scripts/markov.py" "<絶対パス>"` を実行する
- **1〜29**: セッション中の個別事実を俯瞰して見えた構造的パターン・矛盾・気づきを書く。事実の要約ではなく、事実から導かれる洞察。ユーザーが思ってるけど言語化してないことを代わりに言語化するイメージ。比喩OK。

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

最小形（--minimal）

bgセッションを止める前、複数のorchの窓口を同時に閉じるときなど、人がその場で読まない場面で使う。orchが複数のbgセッションを続けて止めるとき、または複数のorchの窓口を同時に閉じるときは、標準形の棚卸し（全アクティブアクティビティを対象にする）が並行して動く他セッションの作業に触れてしまうことと、rememberの全文置換書き込みが競合することを避けるため、最小形にする。1つの窓口だけを閉じるときは、この競合が起きないため標準形のままにする。

• ステップ1〜3を標準形と同じ基準で実行する（ステップ3の「自セッションが触ったものに限る」がそのまま効く）
• ステップ4aの棚卸しとステップ5（聞き返し検出）は実行しない。4bは訂正を拾う部分（手順1〜2）と、手順3のうちフィードバックエントリ・stumbleの書き込みだけ行う（手順4の訂正以外の収集は行わない。格上げのメタaskは起票せず、次回の標準形に任せる）（tag notesやauto-memoryの全文置換は競合するため書かない。それが置き場になった訂正は下の「訂正」行の「書かなかった」に数える）
• 完了報告は次の簡略形にする。ふりかえりは標準形と同じ手順を実行する（省略しない）

## sync-memory 完了（最小形）

- 記録: トピックN件・資材N件・決定事項N件・ログN件
- 訂正: N件（0件なら「訂正: 0件」と書く。フィードバックエントリに書いたN・書かなかったN。tag notes・auto-memoryが置き場になって書かなかったものはここに数え、理由を1行添える）
- アクティビティ: 登録N件・自動クローズN件・[未完]引き継ぎN件

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

- **30**: ジャックポット。`jackpot.md` を読み、対応表の項目数を数えて `roll_dice(sides=<項目数>)` を振ってネタを決定する。ダイスには触れず、選ばれたネタをそのまま実行する。ネタ7（マルコフ連鎖）の場合は、書き出したコーパスの絶対パスを引数にして `uv run --directory "${CLAUDE_PLUGIN_ROOT}" python "${CLAUDE_SKILL_DIR}/scripts/markov.py" "<絶対パス>"` を実行する
- **1〜29**: セッション中の個別事実を俯瞰して見えた構造的パターン・矛盾・気づきを書く。事実の要約ではなく、事実から導かれる洞察。比喩OK。

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

注意

• 未決定の論点は add_decision で記録する - プレフィックス [議論中] をつけて区別（[未完] はアクティビティのタイトル用）
• 判断に迷う場合は、記録する方向で進める（後で修正可能）
• 既に記録済みのものは重複して記録しない - ステップ1で取得した既存データと照合すること
• 現在進行中の作業がある場合は add_activity で登録し、update_activity で in_progress にする
• ステップ1〜5（棚卸し・rememberを含む）ではツール呼び出しの前後に判断理由・中間分析・進捗報告のテキストを出力しない。見せるのはステップ6の完了報告のみ（最小形も同様、簡略形の完了報告のみ）
• 個別の経緯・成果物のその場記録はrecording skillの担当