| name | issue-retro |
| description | issue-loop の Step 9 (振り返り) 単体 skill。対象 PR のレビュー/メタレビュー/E2E findings を「事前 (Step 0-pre) に検出可能だったか」で分類し、プロジェクト側チェックリスト skill への追加提案を出力する。Use when the user asks for a retrospective of a completed PR / issue loop, or to feed findings back into a Step 0-pre checklist. |
| user-invocable | true |
| disable-model-invocation | false |
Purpose
issue 対応ループの品質を次の issue に複利で効かせるためのフィードバック工程。Step 4 (敵対的レビュー) / Step 5 (メタレビュー) / Step 7 (E2E) が surfacing した finding を分類し、「事前に見つけられたはずのもの」の検出条件をプロジェクトの Step 0-pre チェックリスト skill (例: artgraph の artgraph-graph-primitive-impact) に還元する。
引数
対象 PR (URL or 番号)。loop の各 Step ログ (findings 一覧) があれば併せて渡す。
手順
1. findings の収集
対象 PR のレビューコメント / loop の Step 4・5・7 成果物から finding を列挙する (誤検知と判定されたものは除外)。
未起票の finding を監査するときは、起票ゲート (issue-loop SKILL.md) を通した結果を書く。 「未起票だから起票せよ」ではない — C (このリポジトリの開発しか困らない) / D (挙動の欠陥でない) は起票しないことが正しい処理であり、振り返りはそれを「漏れ」として数えない。振り返りが未起票を一律に起票へ回すと、ループごとの起票数が構造的に 1 を超える。
2. 事前検出可能性の分類
各 finding を 3 値で分類し、表にする:
| 分類 | 基準 |
|---|
| 可能 | 現行の Step 0-pre チェックリストのいずれかのチェックを正しく実行していれば検出できた |
| 条件付き | チェックリストに新しい観点を足せば検出できた (その観点を明文化する) |
| 不可能 | 実装が存在して初めて観測できる (実行時挙動・環境依存など)。Step 4/5/7 が正当な検出層 |
分類表の各行: finding 概要 / ランク / 分類 / 根拠 (どのチェックで・なぜ引っかかる or かからないか)。
3. チェックリスト更新提案の判定
「条件付き」の finding について、検出条件をチェックリストへ追加すべきかを判定する:
- 追加する: 同型の欠陥が今後も出うる一般性がある (例: hub-node パターン監査、CLI フラグ parse 意味論監査)
- 追加しない: 一回性が高い / チェックのコストが検出価値を上回る (理由を記録)
提案は「可能 : 条件付き」の比を先に見てから出す
チェックリストが長くなること自体が、実行漏れを増やす。 提案を書く前に、直近 3 ループ分の分類集計を並べて比を出すこと:
| ループ | チェックリスト行数 | 可能 (実行漏れ) | 条件付き (新観点) |
|---|
- 「条件付き」が横ばい〜減少なら、カバレッジは足りている。そこへ新観点を足しても効かない。
- 「可能」が増えているなら、壊れているのは実行。必要なのは追加ではなく、トリアージ・再入場トリガー・実行主体の規律。
- 両方が増えているときだけ、新観点の追加が正当化される。
実測 (2026-08): チェックリストが 370 → 540 行になったループで、「条件付き」12 → 8 に対し「可能」3 → 9 と 3 倍になり、うち 6 件が新設したばかりの 1 チェックの未実行だった。追加が効かなくなる兆候はこの比に出る。
提案 1 件ごとに予算を書く
各提案に 「何を置き換えるか」または「なぜ純増でなければならないか」 を 1 行で書く。書けない提案は出さない。純増を選ぶ場合は、その提案がカバーする finding 数と追加する語数を併記する。
出力の末尾に「今回の提案による増減 (行数・語数) の合計」を書くこと。振り返り自身が、自分の出力量に責任を持つ。
4. 出力
- 振り返りサマリ — 分類表 + プロセス上の学び (brief の改善点、有効だった指示など)
- 更新提案 — 追加すべき検出条件がある場合:
- プロジェクト側チェックリスト skill の SKILL.md にチェック項目を追加する PR を作成する (チェック番号は既存の末尾に追記。出所・経緯は SKILL.md には書かず PR 本文に記載する — 成果物には実行に効く情報のみ残す)
- PR を作らない場合 (プロジェクト外・権限なし) は、チェックリスト skill の管理 issue にコメントとして提案を残す
運用メモ
- 分類はクリーンな Opus 5 (
claude-opus-5) サブエージェントに委譲してよい (メイン loop が実装・レビューに関与しているため、自己評価バイアスを避ける)。
- 「可能」に分類された finding が出た場合はチェックリストの問題ではなく実行の問題 — Step 0-pre の brief が正しくチェックを回せていたかを見直し、brief テンプレ側を直す。
