| name | episode-retrospective |
| description | Episode の closure 時に構造化振り返りを適用する。closure gate checklist（消費者明示・routing・status 確定）、出力型×消費チャネルの内容プロンプト、tier 判定（opt-out / standard / heavy）を含む。Episode を閉じるとき、Decision/ADR への昇格を検討するときに使用する。 |
Episode Retrospective — closure 時の構造化振り返り
いつ使うか
- Episode を closure する（作業を畳み、status を確定する）とき
- Episode から Decision / ADR への昇格を検討するとき
- branch-finish / PR 作成の直前で「episode を閉じたか」を確認するとき
いつ使わないか
- Episode 本文（追記ログ）の書き方 — 本文はフリーフォーム + 性質ガイドのまま（
document-format.md §7）。本スキルは本文に構造を課さない（書きアンカー保護、design-principles §5）
- frontmatter / ULID / 命名規則 —
spec-card が担う（本スキルは重複させない）
- kickoff / plan / discussion の closure — 対象は episode のみ
設計根拠（要約）
episode 品質監査（52 件全数採点、docs/research/2026-06-10-episode-quality-audit.md）の主要結果:
- 最大の穴は closure 軸（平均 1.12/2、満点率 19%）。振り返り枠組み（KPT/YWT）の選択は主要因ではない
- closure は「次の消費者」が存在するときだけ書かれる（法則 L1）。明示ゲートで代替可能
- 「後で追記」型の先送りは観測範囲で 100% 不履行（法則 L4）
- テンプレートは過去向き軸の床を上げるが、未来向き軸を作らない（法則 L2）。構造の足しすぎは蒸留を下げる
よって本スキルの重心は「枠組みの精緻さ」ではなく closure gate（消費者明示 + routing + status 確定）に置く。セクションは感想カテゴリでなく「何を出力し、誰が消費するか」で定義する（Issue #113 オーナー設計判断、2026-06-10）。
Step 1: tier 判定
closure 開始時にまず tier を判定する。判定は印象でなく下のトリガ列で行い、heavy → opt-out → standard の順で評価する（heavy トリガに 1 つでも該当すれば、失格条件や消費者の有無にかかわらず heavy。opt-out に到達するのは heavy トリガゼロのときだけ）。
heavy トリガ（1 つでも該当すれば heavy）
opt-out 失格条件（1 つでも該当すれば opt-out 不可）
判定結果:
| tier | 条件 | 要求 |
|---|
| heavy | heavy トリガ 1 つ以上 | Step 2 + Step 3 + Step 4（外部チェック・条件付き辞退可） |
| opt-out | heavy トリガなし + 失格条件ゼロ + 消費者なし | 下記の opt-out 定型 1 行のみ |
| standard | 上記以外（失格条件への該当は opt-out を塞ぐだけで heavy にはしない） | Step 2 + Step 3（自己申告で可） |
opt-out 定型
opt-out は「書かない」ではなく「消費者ゲート判断を明示した正当な closure」。次の 1 行を episode 末尾（episode 未作成なら PR 本文）に残し、status を確定する:
振り返り不要: <理由> / 次の消費者: なし / follow-up: なし / status: <stable または deprecated>
Step 2: closure gate checklist（standard / heavy で必須。opt-out は Step 1 の定型 1 行が本 checklist を代替）
手段指示の構造化セクション（design-principles §4）。4 項目 + 条件付き 2 項目。これを満たさない closure は不完全。
Step 3: 内容セクション — 出力型 × 消費チャネル
該当する出力型だけ書く（全部埋める義務はない。空欄の機械的穴埋めは蒸留を下げる — 監査 L2）。各型は「誰が消費するか」で定義されている。書く前に「この episode から何が出たか」を型に照らして確認する目的のチェックリストであり、空でも見出しを立てる必要はない。
| 出力型 | 消費チャネル | 書く内容 |
|---|
| 事実・失敗 | 失敗分類・再発防止（→ #60） | 何が起き、何が失敗したか。実行ログに残る失敗を選択的に省略しない |
| 決定と根拠 | 判断の再利用・Decision 昇格 | 選択肢・採否・棄却した案と棄却理由。コードや diff から復元できない「なぜ」 |
| わかったこと（W） | ナレッジ・次タスク参照 | 検証で判明した事実・技術的知見 |
| 原則（Pattern / Anti-pattern 対) | negative knowledge 注入（→ #62） | 転用可能な対構造。NG/OK ペア形式可 |
| 行動変更 | hook / skill / チェックリスト化 | トリガ・機構・着地先アーティファクト名を必須。機構未確定の「検討する」は残課題（routing 対象）へ降格 |
| 蒸留シグナル | 昇格パイプライン | 昇格候補の明示: Decision / skill / rule / #62 / なし（「なし」も明示する） |
| 残課題 | routing（Step 2 で行き先付与） | 未解決・未検証。証明できなかったことは証明できなかったと書く（対称な honesty） |
任意の皮: KPT / YWT
人間レビュー用の読み物として、上記の内容を KPT（Keep / Problem / Try）+ Open Questions や YWT で再構成してもよい。皮は骨格の代替ではない — Keep に「わかったこと」を仮装させない、Problem の空欄/形骸化は皮では検知できない（自己検出率 0 の実証あり）ことに注意。
Step 4: heavy tier の外部チェック
自己評価は甘い（別リポ実証: Problem 自己検出率 0、選択的省略あり）。heavy では外部チェックを 1 回入れるのを既定とする（下記の客観条件を満たす場合のみ辞退可）。
-
既定: so-compare で振り返りの focused check。確認対象は 失敗セクションの選択的省略 / routing の網羅 / evidence anchor / back-propagation のみに絞る（全文レビューにしない — 摩擦が高いと skip される）
-
委譲採点 + spot-check は監査級の規模（多数 episode の横断評価）に限定
-
SO 出力パスを episode にリンクする（Step 2 の条件付き項目。証跡の有無が PR レビューで機械的に確認できる）
-
条件付き辞退（advisory）: Step4 の確認対象は closure 品質（失敗の選択的省略 / routing 網羅 / evidence anchor / back-propagation）であり、コードや設計の SO はこれを代替しない（検証対象が別）。この 4 観点が既存レビューで既に覆われている、または低リスクで該当しないと示せる場合に限り辞退可。「追加価値が低い」だけでは辞退不可（= skip の別名になる）。辞退時は opt-out 同様、closure に定型を残す（機械確認可能にする）:
Step4 辞退: <理由> / 既存チェックで覆った観点: <routing / evidence anchor / 省略チェック / back-propagation のうち> / 未実施観点と判断: <なし or 理由>
プロンプト例
so-compare -w "$(pwd)" "episode <path> の closure 振り返りを検証: (1) 実行ログにある失敗・撤回・指摘が事実・失敗セクションから選択的に省略されていないか (2) 全 follow-up に行き先があるか (3) 揮発パス参照が残っていないか (4) 他文書の欠陥への back-propagation 漏れはないか"
制約と既知の限界
- 本スキルは助言であり同期ゲートではない。「skill があっても closure を忘れる」問題（監査 R4）は branch-finish / PR フロー側の同期ゲートで対処する（別 Issue）。本スキルの遵守はトリガされたときのみ機能する
- 実行ログマーカー（つまずき / 指摘 / 撤回）× 失敗セクションの機械突合は将来機構（書き込み時ガイドラインとセットで成立。#149 B 検証の defer 解除後）。現時点では Step 1 失格条件・Step 4 SO が代替
- 後追い再構成の episode（リアルタイム追記でないもの）は冒頭に
reconstructed と明示する。リアルタイム追記ログと同じ証拠価値を持たないため、形式比較のデータとして同列に扱わない
- 本修正のスコープ外（別途検討）: heavy トリガ
非自明な設計判断 が広く、選択肢比較を含む実装 episode の大半が heavy 化しうる → Step4 摩擦の主因になりうる（SO 指摘）。トリガ較正、または「episode 内で既に意図的 SO 済みなら Step4 をトリガ連動で免除」の重複排除ルールは別途。本修正は Copilot 混載の是正＋Step4 辞退の客観化 に限定
効果測定（#113 完了条件のデータ取得経路）
「KPT で十分か別形式か」は 2 事例 + オーナー判断（出力型×消費チャネル骨格の採用、KPT は皮へ）で回答済み。以後の測定経路:
- 監査 rubric の軸5（closure）・軸3（証拠接続）で導入前後の episode を比較（before 値: 軸5 = 1.12 / 軸3 = 1.35）
- opt-out 率を追跡（乱用の可視化。opt-out が多数派になったら失格条件を再設計）
- Step4 実施率 / 辞退率を追跡（辞退の濫用＝R4 再誘発の可視化）。tier 定義変更（本修正）以降は opt-out 率・closure 軸の before/after にベースライン汚染が入るため、変更時点を記録して比較する
- 実適用 episode に形式メモを 3〜4 行残す: チャネル骨格で拾えたもの / 拾えなかったもの / 皮（KPT/YWT）を使ったか / 摩擦
既存スキル・ドキュメントとの関係
spec-card: frontmatter / ULID / 命名 / status enum の正本。本スキルは closure の中身を担い、形式は spec-card に従うdocument-format.md §7 Episode: 本文フリーフォーム + 性質ガイドの定義。本スキルは末尾の構造化 FB セクションの実装branch-finish: ブランチ完了判定フローの一部として closure 確認に使える（同期ゲート化は別 Issue）evidence-verification-rule: 自己確認は検証ではない — Step 4 外部チェックの根拠- Issue #60 / #62: 出力型の消費チャネル先（失敗分類 / negative knowledge 注入）。注入側フォーマットは #62 で設計
