retro

レトロスペクティブ

直前に行った作業を振り返ります。

このスキルは、次の点を把握するためのものです。

• 何がうまくいかなかったか
• 何に時間がかかりすぎたか
• 何がトークンや労力の無駄になったか
• どのような行き詰まりがあったか
• 実際にうまくいったことは何か
• 次回は何を変えるべきか

目的は、単にミスを列挙することではありません。

根本原因を見つけ、今後のパフォーマンスを向上させる変更を提案することが目的です。

使用するタイミング

ユーザーから次のような依頼があった場合に、このスキルを有効にします。

• レトロスペクティブを行う
• 何がうまくいかなかったかを振り返る
• タスクに時間がかかりすぎた理由を特定する
• 非効率な点や無駄な労力を見つける
• 繰り返し起きている失敗のパターンを把握する
• 次回に向けてワークフローを改善する

振り返る入力

結果に影響した全体的な文脈を確認します。

• チャット履歴
• ユーザーの指示
• 使用したスキル
• リポジトリやタスクの文脈
• ツールの挙動
• 行った判断の順序

関連する場合は、次の点も確認します。

• エラー出力
• 再試行
• 断念したアプローチ
• 不明確な引き継ぎ
• タスク中のユーザーの意図の変化

対話モード

すべてのレトロスペクティブを一度で完了させる必要があるとは限りません。

状況に応じて判断します。

• 失敗のパターンが文脈から明らかな場合は、すぐにレトロスペクティブを作成します。
• 原因が曖昧、意見が分かれている、感情が絡んでいる、または運用担当者からより詳しい情報を得ることで改善が見込める場合は、まず短い対話形式のレトロスペクティブを行います。

対話形式の場合：

• 焦点を絞った質問を少数尋ねます
• 回答を使って根本原因の分析を深めます
• その後、最終的なレトロスペクティブを作成します

よい質問は、次のような点を尋ねるものです。

• エージェントが見落とし、ユーザーが気づいたこと
• 最も影響が大きかった問題
• 問題の原因がスキル、プロンプト、ツール、ワークフロー、判断のどれにあったか
• システムにどのような永続的な修正を望むか

レトロスペクティブを長引かせるためだけに、広範な質問や重複する質問をしてはいけません。 永続的な変更の質を実質的に高める場合に限って質問します。

確認する点

1. エラーとミス

次の点を見つけます。

• 誤った前提
• 不適切なツールの使用
• 指示の見落とし
• 事実やプロセスに関する誤り

2. 非効率な点

次の点を見つけます。

• トークンを多く消費する調査の無駄
• 重複作業
• 不必要な再試行
• 回避できたブラウジングや検索
• 簡単なツールやスクリプトを使うほうがよかった場面

3. 行き詰まり

次の点を見つけます。

• 役に立たなかった調査の方向性
• 文脈が不明確だったことで生じたループ
• もっと早く断念すべきだった繰り返しの試行

4. うまくいった点

よかった点を維持します。

次の点を見つけます。

• ユーザーによる有益な枠組みの提示
• 効果的なスキル
• 効果的なワークフローの手順
• うまくいった迅速な方法
• 維持すべき有用な経験則

こうした強みを損なうような変更を提案してはいけません。

根本原因分析

表面的な症状だけで終わらせてはいけません。

重要な問題ごとに、次の点を確認します。

1. 何が起きたか
2. なぜ起きたか
3. 何がそれを可能にしたか
4. その背景にある、より深いパターンは何か

根本原因として多いのは、次のようなものです。

• ユーザーの依頼の枠組みが不明確
• スキルの指示が不足している、または不十分
• スキルの適用範囲が不適切
• 共通の用語が不足している
• リポジトリや文脈の把握が不十分
• 繰り返し行う作業に適した軽量なツールがない
• ワークフローの順序が不適切
• チェックポイントやレビューのゲートがない

表面的な不満を長々と列挙するより、実質的な原因を少数に絞ります。

対話形式の場合は、ユーザーの回答を踏まえて、最終化する前に原因の仮説を検証します。

出力

次のセクションでレトロスペクティブを作成します。

レトロスペクティブの概要

• タスクの内容
• 全体としてうまくいったかどうか
• 主な問題点
• 主な強み

うまくいかなかった点

• 具体的な失敗、ミス、遅延、行き詰まり

根本原因

• 問題の背後にある根本原因
• 症状と原因を分けて記載

うまくいった点

• 維持すべきよいパターン
• それがうまくいった理由

推奨する変更

次回に向けた具体的な改善案を提示してください。

「もっと注意する」「もっとうまくやる」といったリマインダーではなく、実用的で継続的な変更にしてください。

振り返りで得た学びをメモリに保存してはいけません。 有効な成果物は次のものだけです。

• スキル - 既存のスキルを更新するか、新しいスキルを作成する（SKILL.md ファイル）
• ドキュメント - リポジトリにコミットする Markdown ファイル（運用手順書、チェックリスト、リファレンスドキュメント）
• スクリプト - リポジトリにコミットする決定論的なヘルパー

振り返りの結果を保存する場所として、メモリは無効です。スキル、スクリプト、リポジトリのドキュメントに記録する価値がない学びは、保存する価値もありません。

有効な変更の例：

• 既存のスキルの指示やチェックリストを更新する
• 新しいスキルを作成する
• リポジトリに Markdown ファイルとしてチェックリストや運用手順書を追加する
• リポジトリにコミットする CLI スクリプトを作成する
• スキル、スクリプト、運用手順書にレビューゲートを追加する
• スキルやリポジトリのドキュメントでワークフローの順序を変更する

提案ごとに、次の点を説明してください。

• 何を変更すべきか
• 変更によってどのような効果があるか
• 優先度が高いか、任意か
• どの成果物を更新するか（スキル、スクリプト、リポジトリのドキュメント）
• 変更を加える正確なファイルパス

最も効果の高い次のステップ

最初に行うべき、最も価値の高い変更を1つだけ挙げてください。

次のような、スキル、スクリプト、リポジトリのドキュメントへの具体的な変更にしてください。

• 特定のスキルの SKILL.md を更新する
• リポジトリにヘルパースクリプトを作成する
• スキルや運用手順書にレビューゲートまたは検証ゲートを追加する
• リポジトリに運用手順書またはチェックリストの Markdown ファイルを作成、または更新する

次のような曖昧な助言で締めくくらないでください。

• 「もっと注意する」
• 「もっと頻繁に確認する」
• 「もっとよくコミュニケーションを取る」
• 「次回はもっとうまくやる」

選んだ次のステップは、スキル、スクリプト、リポジトリのドキュメントのいずれかを変更するものにしてください。メモリは絶対に使わないでください。

反復モードを使用した場合は、ユーザーへの質問後に何が変わったのかを出力に反映し、ユーザーが追加した情報を無視しないでください。

良い対応

• 正直に、必要以上に騒ぎ立てずに伝える
• 非難ではなく、今後の改善に焦点を当てる
• すでにうまく機能していることは維持する
• その場しのぎではなく、仕組みとして解決する
• 担当者が実際に実装できるほど具体的にする
• すべての提案を、スキル、スクリプト、リポジトリのドキュメントへの変更につなげる。メモリは使わない
• ユーザーの所見によって振り返りの質が大きく向上する場合は、最終回答の前に簡潔に意見を尋ねる