デブリーフ（振り返り）

デブリーフ（振り返り） は何をしますか？

デブリーフとは、プロセスを改善するためのプロセスという、常に存在するメタ目標を達成するための手段です。人間とエージェントがどのように協力したかを証拠とともに検証し、その結果を3種類のアウトプットに変換します。すなわち、エージェントへの教訓（指示、スキル、ワークフロー、フック）、人間への教訓（エージェントをよりうまく導く方法）、そしてプロジェクト設定の変更点です。双方向に正直であり、批判を捏造することはありません。うまくいったセッションは短いレポートになります。

構造とルールは、MITライセンスの2つのスキルから適応しました。感謝を込めて：debrief by Wavez（4つのチェックグループ、「すべての発見は瞬間を引用する」、「承認なしには何も適用しない」）およびretrospective by florianbuetow（レポートを履歴として保持、以前の推奨事項を確認し、再発する問題をエスカレーション、発見ごとに根本原因と提案）。コーチングセクション、5回のなぜ（Five Whys）の習慣、および使用状況スクリプトは、このスキル独自のものです。

インプット

1. 会話。 主要な情報源：ツールコール、質問とそのタイミング、ユーザーによる修正と確認、サブエージェントレポート、エラーとリトライ。セッションがコンパクト化された場合は、その旨をレポートに記載し、要約を信頼性の低い証拠として扱います。見えない部分の瞬間を捏造してはいけません。

2. 数値。 セッションの使用状況について、バンドルされたスクリプトを実行します：ターン数、ツールコール（名前別）、サブエージェントとワークフロー（トークン数を含む）、使用モデル、モデル別出力トークン、経過時間、コンパクション数。~/.claude/projects/<project-slug>/ 以下のセッション転写と、その隣の subagents/ ディレクトリを読み取ります。ユーザーが別のセッションについて尋ねる場合は、そのIDを渡します。

   python3 ${CLAUDE_PLUGIN_ROOT}/scripts/usage.py            # 現在のセッション（このプロジェクトの最新の転写）
   python3 ${CLAUDE_PLUGIN_ROOT}/scripts/usage.py <session-id>
   

3. プロジェクトの記録。 指示ファイル（CLAUDE.md、AGENTS.md）、プロジェクトが保持している場合はバックログと決定ログ、およびこのプロジェクトのエージェントのフィードバックメモリ（~/.claude/projects/<project-slug>/memory/）。これにより、繰り返されるミスを繰り返しとして認識できます。

4. 過去のデブリーフ。 レポートディレクトリ（後述）にある直近3件のレポート。それぞれの推奨事項について、実行されたか、再発しているか、不明かを記録します。再発する問題は重要度がエスカレーションされます。

労力は作業範囲に合わせます。短くてクリーンなセッションには簡単なパスで十分です。数週間におよぶセッションには本格的な処理を行い、大きなパターンには5回のなぜ（Five Whys）を適用します。

調査項目

以下の4つのグループを順に確認します。各発見について、その瞬間（何が言われ、行われたか、およそのタイミング）を引用し、なぜそれが重要だったかを説明し、「なぜ」をインスタンスを超えて、プロセスの原因または原則に到達するか、答えがプロジェクトの制御範囲外になるまで問い続けます。観察と処方は分けて保持します。観察が正しくても、提案された修正が間違っている可能性があります。

1. 効率性。 冗長または繰り返されるツールコール、スクリプトやスキルで処理すべきだった手書きロジック、余分なビルドやテストサイクル、バッチ処理できたはずの作業、見逃されたり効果を発揮したサブエージェント、コンパクション後のやり直し、セッションとともに消えたバックグラウンド作業。
2. 協調性。 早すぎる、遅すぎる、またはまったく行われなかった質問；守られなかった常設指示；ルールが意図されていたのに文字通りに受け取られた例；冗長性；エージェントがあいまいなリクエストのどの解釈を採用したかを述べたか；ブロッキングな質問が実際にブロックしたか。
3. 正確性と規律。 証拠なしになされた主張；後で発見された制約；確認なしに行われた破壊的または不可逆的なアクション；見落とされたプロジェクトの慣習；「これはどのシナリオを要求するのか」「何がこれを捕捉できたか」という質問の省略。
4. 将来への継承。 メモリやプロジェクトドキュメントとして保存する価値のある好みや決定；スキル、ワークフロー、フック、常設ルール、またはバックログ項目となる提案；作業範囲を容易にしたであろうツール；次回自動化できるステップ。2回の手書き繰り返しは、再利用可能なアセットが欠けていることを示します。

そして、このスキルをパーソナルにする2つの部分：

• 人間へのコーチング。 プロンプトを書く人間は、どのようにすればより効果的だったか？彼らのどの行動が最も役立ったか（名前を挙げて、繰り返されるようにする）そしてどれがコストになったか（あいまいな範囲、ラベルの欠落した例、エージェントが必要とした決定の保留、レビューの省略）？監督グループの仲間のように、具体的で、証拠に基づき、お世辞も軟化もなく、直接その人に書きなさい。
• モデルと労力。 数値から：モデルと労力レベルは作業に見合っていたか？トークンはどこに使われたか（メインループ、サブエージェント、ワークフロー）、そしてその一部により安価なモデルや低い労力で済んだか？高い労力がどこで報われたか？

レポート

レポートはレポートディレクトリに書き、返信には短い要約を表示します。ディレクトリは、リポジトリに docs/ ディレクトリがある場合はカレントリポジトリの docs/debriefs/、それ以外の場合は ~/.claude/debriefs/<project-slug>/ です。ユーザーは別の名前を指定できます。ファイル名は YYYY-MM-DD.md とし、既存のものがある場合は -2 サフィックスを付けます。

短く濃密に：読者はセッションを体験した本人なので、レポートは語るのではなく想起させます。ニュアンスは、それを取り巻く散文ではなく、証拠と原因に宿ります。以下のテンプレートを使用します：

# デブリーフ <日付>: <作業範囲の概要>

カバレッジ: <デブリーフが見えた範囲；コンパクションに注意>。過去のデブリーフ: <日付、またはなし>。

## 5行で
- <作業範囲が達成したこと>
- <それを機能させたもの>
- <コストになったもの>
- <コーチングを1行で>
- <提案数、および小さくないもののうち1つ>

## 数値
<スクリプトからの1段落：経過時間、ターン数、上位のツールコール、モデル別出力トークン、サブエージェント、コンパクション>

## うまくいったこと
- **<2語のラベル>.** <その瞬間> → <もたらしたもの>。

## コストになったこと
- 🔴 / 🟡 / 🟢 **<ラベル>.** <その瞬間、1行>。
  原因: <なぜを問うた後のプロセスの原因>。<修正済み、または残っているもの>。

## <その人>へのコーチング
継続すること: <役立った行動、1行でリスト>。
1. **<習慣>.** <証拠> と <代わりにすべきこと>、1〜2文。

## モデルと労力
<1段落：見合っていたかどうか、およびそれを示す数値>

## 提案
| # | 提案 | 宛先 | 労力 | 決定 |
|---|---|---|---|---|
宛先：AGENTS.md または CLAUDE.md のルール、メモリ、スキル、ワークフロー、フック、バックログ、共有ガイド、導入するツール。

## 過去の推奨事項
| 出典 | 推奨事項 | ステータス（実行済み / 再発中 / 不明） |

重要度：🔴 実際の作業コストまたは損害のリスクがあったもの；🟡 時間または注意のコストになったもの；🟢 小さな習慣。

ルール

• レポートのみ。ユーザーが提案を承認するまで、指示ファイル、メモリ、バックログには何も書き込まれません。承認された場合、その1つだけを適用します。
• すべての発見は瞬間を引用します。引用できない場合は、その発見を破棄します。
• 水増ししないでください：3つの本物の発見は、10の水増しされたものより優れており、「この作業範囲はうまくいった」というのも有効な結果です。
• コーチングはその人の利益のためのものであり、率直でなければなりません。また、デフォルトでは非公開であり、本人が共有を依頼しなかったものは一切外部に出さないでください。
• 平易で実行可能な言葉：すべての項目は、セッションに参加していなかった人やエージェントでも実行できるように書きます。習慣を行動として名前を付けます（誰が何をして何を達成するか：「解決策ではなく成果を指定する」）、セッションで作られたニックネーム（「保留された解決策」、「懐疑論者」、「目視」）では決して呼びません。略語が認識に役立つ場合は、正式な形の後に括弧で入れます。テスト：同僚がその行を自分のガイドにコピーして従えるか？
• 簡潔さ：ラベルを太字で、次に証拠の1行、次に原因。発見に段落が必要な場合、それは2つの発見であるか、まだ理解されていないかのどちらかです。セクションごとに1画面を目指します。
• 教訓と摩擦の区別：教訓とは、別のプロジェクトの別のエージェントにも伝えるもの。このセッションにのみ当てはまるものは摩擦であり、発見には含まれますが、常設ルールの提案には含めません。