recompose-context

指定された入口（activity/topic/decisionどれでもOK）から関連する全情報（topics, decisions, logs, materials）を読み込み、統合material（anchor対応表付き）の生成・軽照合・リコンサイル・tag pin・tag-notes更新を行う。次のcheck-inだけで作業に必要な情報が全部揃っている状態を作ることがゴール。

anchorの新規作成・更新の対話手順は references/anchor-setup.md に従う。「anchor作って」「検証先決めたい」など、anchorだけを決めたい依頼でもこの手順だけを使う。

モード

• 局所モード（既定）: 入口から辿れる整理単位を対象に、以下の手順1〜9をすべて行う。アクティビティのメンテ（ステップ5）は整理範囲に出てきたアクティビティだけに回す
• 全体モード（--all）: アクティビティ(active/shelved/snoozed)全域の棚卸しを行う。手順は references/full-inventory.md に従い、この本文の手順1〜9は回さない。アクティビティのメンテは全域に適用する

整理単位

整理単位は「2-3個のtopicを囲む形で増殖した関連A/D群」。入口がactivity/decisionでも、関連relationを辿ってtopicまで遡って整理する。

発動契機

実行は手動（ユーザーが「やるか」と言って初めて走る）。check-in時のナッジhint（tagスコープ内のdecision増分検知、全体モードは放置アクティビティ件数の検知）から誘導されることもある。実行コンテキストは限定しない: 別セッションで単独実行しても、sync-memoryの延長でやってもよい。

発話の例: 「/recompose」「recompose」「情報整理して」「まとめて」「リコンサイル」。全体モードは「/recompose --all」「アクティビティ棚卸しして」「activity棚卸し」「アクティビティの整理して」など。

次には発動しない: sync-memory標準形のStep 4a（セッション終了時の軽い自己完結処理）の自動棚卸し、単一アクティビティの完了・中断（activity-finish）、タグの共起分析・整理（tag-cleanup）。

手順

1. 入口の特定とスコープ提示

引数で entity_type + entity_id が指定されていればそのまま使う。指定されていなければ、文脈（check-in済みactivity・直近の話題・ナッジhintの対象tag）からエージェントが自律判断で決める。activity/topic/decisionどれでも可。

エージェントがスコープを切ったら、実行前にユーザーへ一行で規模感を提示してOK確認を取る。背景: CALMの記録内容はユーザー自身も把握していない前提なので、スコープの中身を見せる代わりに作業規模だけ示す。

提示フォーマット例:

「ざっと N activities + M decisions ぶん、SA X 人で並列整理する。これで進める？」 「整理単位が大きいので 2 cluster に分けて並走させる。SA Y 人。これで進める？」

提示する内容:

• 関連エンティティの概数（activities + decisions + materials の合計件数感）
• 並列起動する SA の人数（cluster 数で決まる、目安: 各 SA が 1 cluster を担当）
• 分割した場合はその数を明示

提示しないこと:

• どの activity/decision がどの cluster に入るかの内訳（ユーザーは記録を把握していない）
• 関連エンティティの個別 ID 一覧

OK が出たら自走モードに入り、以降ステップ2-8はユーザーへの追加確認なしで進める。OK が出るまでは記録 read のみで write はしない。

判断材料が本当にないとき（入口候補がゼロ）だけ「どこから整理する？」を聞く。

2. 全情報の収集

入口から関連エンティティを総ざらいする:

1. 入口に応じた取得: activityなら check_in、topicなら get_decisions/get_logs、decisionなら get_by_ids などで起点情報取得
2. get_map(entity_type, entity_id, max_depth=3) で関連エンティティを辿る（depthが足りなければ運用で上げる）
3. search で言及されているが正式relationが張られていないentityを補完探索
4. 各エンティティのget系で全文取得（ページネーション、retract済みは除外）

フィルタ方針: retract済みdecision/logのみ除外。completedなactivityも収集対象に含める（間引き対象として扱うため）。

3. 統合materialの生成（anchor対応表付き）

サイズ予算

2,000〜3,000字を目安、最大5,000字まで許容（参考値、実運用で調整）。このmaterialはcheck-inのたびに全文注入されるため、予算超過は継続コストになる。check-in応答全体が予算を超えると、pin枠を超えた分から途中で切られる・スタブ化される（応答のnextフィールドにget_materialへのポインタが残る）ため、超えそうなら要約の密度を上げるか、整理単位の分割を検討する。

tagスコープとの対応

tagスコープとmaterialは原則1対1。1つのtagに複数のmaterialが必要になった場合は、materialを分けるのではなく1 material内にインデックスセクションを作り、深掘りは search / get_material へ誘導する（更新責務を曖昧にしないため）。

セクション構成

## 現状
（どこまで進んでいるか、今どのフェーズか。経緯の概観を含む）

## 合意事項
（有効なdecisionsの要約。各項目はWHAT + WHYで書く。
  supersedes済みは除外。[議論中]タグのものは「残論点」に分類する。
  次のエージェントがget_decisionsしに行かなくても判断の背景を
  理解できる粒度で書く）

## anchor対応表
| 合意事項参照 | anchor型 | 検証先 |
|---|---|---|
| D#xxxx の要約 | 実装済 | src/services/foo.py:bar |
| D#yyyy の要約 | 未実装 | bar.py周辺 + D#zzzz の前後関係 |

## 注意事項
（検討して却下された代替案、議論中の制約条件、暗黙の関連 など）

## 残論点
（未解決の議論、次にやるべきこと、軽照合で見つかったズレ）

3-a. anchor自動推測

各合意事項について、エージェントが anchor型と検証先を推測する。型と書き方:

型	検証先
実装済	該当コードのファイル+関数
外部仕様準拠	doc URL
未実装	周辺の実装済みコード＋関連decisionの前後関係
事実調査	material内の一次ソース

「最新decisionを静的参照」は採用しない。

推測できた合意事項は anchor対応表 に直接追加。推測できない / 確証が低いものは buffer に溜める。

3-b. anchor確定の対話

buffer が空でなければ references/anchor-setup.md の手順で、ユーザーと対話してanchor確定する。結果（mode=created）は anchor対応表 に merge する。

3-c. anchor対応表の統合

完成した anchor対応表 を material.content の「## anchor対応表」セクションに書き込む。

4. 軽照合

各合意事項について、anchorに対してSAに指示出ししてズレを確認する:

• 実装済 → 「このコード（パス）が、この合意（テキスト）と整合しているか確認して」
• 外部仕様 → 「このdoc（URL）が、この合意の根拠として通用するか確認して」
• 未実装 → 「周辺コード＋関連decisionの前後関係から、この合意の方向で進めて問題ないか確認して」
• 事実調査 → 「このmaterialの一次ソースが、この合意の根拠として通用するか確認して」

SA（run_in_background）で並行実行。結果はマトリクス化して、合意との一致/ズレを記録。

• 一致 → そのまま維持
• ズレ → 「残論点」に追加。ズレが「anchor側が古い」起因なら anchor-setup.md の更新モードに回す候補としてマーク

5. リコンサイル（無効化・再編）

軽照合や情報棚卸しで「無効化・再編すべき」と判断したエンティティを、自律度ルールに従って処理する。

無効化・再編アクション（種別別）

• decision/log → retract
  • 頻繁に参照される decision を無効化する場合は、単純な retract より定型節 （書式は本スキル同梱の references/precedent-format.md）付きの新 decision で supersede し直すことを検討する。 retract は却下理由・射程の情報を残さないため、頻出参照の decision ほど supersede の価値が高い
• material → update_material で上書き
• topic/activity → retract非対応のため「直す」: status調整・合流・relation張り・新規作成

アクティビティのメンテ

整理範囲のアクティビティ（ステップ2で収集したもののうちcompleted以外。全体モードでは全域）について、goalと親への結びつけを整える。未定義や結びつけ漏れを一度に遡及せず、recomposeが呼ばれるたびにその範囲の分だけ直していく。

読み出しは get_goal(activity_id=...) と get_by_ids で行い、入口以外のアクティビティに check_in しない（statusがin_progressに変わり、作業中のセッションとしての記録も付くため）。

• goalが未定義（labelがundefined）: 記録（description・log・関連decision）から真偽の付く終了条件が推せるなら、set_goal(activity_id, goal={"new": {"handle": ..., "statement": ..., "conditions": [...]}}) で書く。条件にはClaudeが自力で到達できるもの（actor: "claude"）を最低1本含める。既存の未判定goalの続きの作業だと分かるなら、新規作成せず set_goal(activity_id, goal={"goal_id": <そのgoalのgoal_id_raw>}) で紐づける。推せない、または候補が複数で1つに絞れないときは何も書かない。未定義のまま残すのは正当な状態であり、雛形で埋めない

• 不要印（labelがnot_needed）: 触らない

• 条件の充足と判定: 記録からの推定だけで条件を satisfied にせず、judge_goal も呼ばない。外部の完了（PRのマージ等）は gh など実際の手段で確かめられた場合に限り satisfied に書く。goal付きアクティビティを閉じるのは update_activity ではなく judge_goal 経由で行う

• 親への結びつけ: 記録から、このアクティビティを子として振ったまとめ役のアクティビティが推せるなら、候補を提示せずそのまま結ぶ。結び先は直近の親のgoalにする（子の中で切り出された孫なら、まとめ役ではなく子のgoalに結ぶ）

  1. get_goal(activity_id=<親のid>) で親のgoalを読む。未定義・不要印・判定済み（labelがclosed）なら結ばない
  2. 親goalの conditions[].bound にこのアクティビティが既にあれば何もしない
  3. update_goal(goal_id=<親のgoal_id_raw>, changes=[{"op": "add", "statement": "子「<子のtitle>」のgoalがachievedで閉じた（済にする前にget_goalで判定を確かめる）", "actor": "claude", "bound": {"type": "activity", "id": <子のid>}}]) で条件を足す

  誤った結びつけは条件をwaivedにして結び直せるので、ユーザーに確認しない。親が推せないときは何もしない

• 束ね役の親の提案（上の「親が推せないときは何もしない」の例外）: どの親にも結べない未完了のアクティビティが、共通する素タグ（domain:とintent:以外）で見て同じテーマで3本以上溜まっているときは、確認レーンに「常設の領域orchを立てて結ぶ」案を積む（子の候補とテーマを添える）。同じテーマかの判定に迷うものは提案に含めない。先に、そのテーマを束ねるorchが既にあるかをorch skillの「一覧」と同じ取り方で探す。同じ範囲に空席のorchがあれば新設せず、そこへ結ぶ（上の「親への結びつけ」に戻る）。無いときだけ提案し、了承を得たら、orch skillの「担い手空席の常設orchとして起票する」手順で立てて子を結ぶ。了承なしには立てない

自律度ルール（暫定・運用後見直し前提）

ゾーン	アクション例
🟢 自律	relation張り / status・title調整 / material上書き / アクティビティのメンテ（推せたgoalの作成・親goalへの条件追加）
🟡 確証あれば自律	decision/log retract / activity合流
🔴 確認	新規entity作成（material・アクティビティのメンテで作るgoalを除く）

怪しき発火条件（全レーン共通で🔴に格上げ）

以下のいずれかに該当する場合は確認レーンに格上げする:

• 矛盾で新旧不明
• [議論中]タグ
• log に懸念明記
• 推測でしか判定不可

確認はバッファに溜めて最後に一括提示・ジャッジ。重大な矛盾だけはその場で確認（ハイブリッド）。アクティビティのメンテで終了条件や親が推せないものは、確認に回さず何もしない（束ね役の親の提案を除く）。

6. material の保存と tag pin

1. 整理単位の代表tagを1つ選ぶ（例: 対象topicのdomainタグ、recompose-context, anchor, reconciliation などその整理単位を表すtag）
2. 既存material（同じtag + 対象エンティティへのrelation を持つ）を探す
3. 既存あり: 上書き前のcontentを add_logs で退避してから（履歴保全、バージョニング機構の代わり）、update_material でcontent/title/tags/sourceを上書き
4. 既存なし: add_material で新規生成
   • タイトル: recompose: {対象エンティティのtitle}（YYYY-MM-DD）
   • tags: 代表tag + recompose-context を含める
   • related で対象エンティティに紐づける
5. add_pin(source_type='tag', source_ref=<代表tag>, target_type='material', target_ref=<material_id>) で代表tagにmaterialをpinする
6. 複数ヒットした場合は警告を出してabort（正常系は1件のみ）

7. tag-notes更新

対象entityに紐づく全タグについて、以下を自問する:

• 追加型: 既存tag-noteに書かれていない横断知見はないか？同じタグを持つ他entityにも適用される教訓・運用ルールはないか？
• 改訂型: 既存tag-noteと矛盾する新しい合意はないか？→書き換え / 前提が覆った記述はないか？→削除or書き換え

書かないもの: 一過性の話題 / entity固有の文脈（→material行き）/ 既存記述と重複する内容

判定が出たタグは update_tag で上書きする。追記前に内容の種別を判定する: 教訓・落とし穴（行動を変える注意）と環境知識のみ全文で書ける。仕様スナップショット・運用手順・歴史記録は1行ポインタ（正典はコード/docs/decision/資材）に留め、状態・進行ジャーナル（「YYYY-MM-DD時点で〜中」等）は書かない。

既存notesの整理、または追記後（マージ後のドラフト）が天井(4,000字)を超える場合は、update_tagで書き込む前に demote_tag_notes(tag=..., sections=["見出しテキスト", ...]) で該当セクションを資材へ退避する（天井は「新しい長さが4,000字を超え、かつ既存より増加している」書き込みのみを拒否するため、現在は天井未満のタグでも追記で超える見込みなら先に縮める必要がある）。sections はnotes中の ## 見出しテキストで指定する（前文は退避不可）。mode は状態ジャーナル型のセクションのみ drop、それ以外は既定の pointer（退避後に1行ポインタを残す）を使う。整理の終了条件はdemoteの実行回数ではなく、返り値の notes_length.over_budget が false になったことで判定する。1タグ失敗でも他タグ処理は継続。該当なければスキップ。

8. relation補完

logs・decisionsの中で言及されているが正式relationが張られていないtopic/activity/materialを発見したら add_relation で補完する。

該当なければスキップ。

9. ユーザーへの報告

## recompose-context 完了: {対象エンティティのtitle}

### 統合material
- M#xxx（tag pin: <代表tag>）

### anchor対応表
- 合計N件（推測のみ N件 / 対話確定 N件 / 更新 N件）

### 軽照合
- 一致 N件 / ズレ N件（→残論点）

### リコンサイル
- 自律実行: N件
- 確認待ち: N件（バッファ提示）

### tag-notes更新
- （更新したタグ。なければ「なし」）

### relation補完
- （追加したrelation。なければ「なし」）

### アクティビティのメンテ
- goalを書いた N件 / 親に結んだ N件

確認待ちがあれば、報告後にユーザーと一括ジャッジする。

注意

• 鵜呑み防止ガード: 確証なく判断できないもの（矛盾で新旧不明 / [議論中] / log懸念 / 推測でしか判定不可）は自律retractせず確認レーンへ。重大な矛盾は手動運用ならその場で確認
• anchor推測の枠: anchorは「正解を当てる」のではなく「判断ができる場所を指す」だけで十分。「最新decisionを静的参照」は採用しない
• 情報を要約しすぎない。check-inだけで完結する密度が必要
• ステップ2〜8ではユーザーへのテキスト出力を最小限にする。最終報告（ステップ9）でまとめて伝える
• 自律度ルールは暫定。一度運用してから見直す前提