run-retro

振り返りの実施

完了した作業ストリームを、デリバリー速度、プロセス、コードベースの健全性という観点から評価し、根拠に基づく改善策についてユーザーと合意します。 意思決定のループは、実際の grilling スキルが担います。振り返りは会話内で提示します。

承認

振り返りの実施依頼で承認されるのは分析のみです。ファイルの編集やその他の変更には、grilling を通じたユーザーの最終選択が必要です。この選択で承認されるのは、選択されたドキュメントの編集、create-issue を通じて選択されたチケットへの対応、および明示的に選択された即時実装を通常の /deliver ワークフローで実行することに限られます。このスキルが直接実装することはありません。無関係なコミット、プッシュ、PR、issue、ファイル編集は承認されません。振り返りの実施を求める元の依頼は、この最終選択には該当しません。

ゲート

• 現在の会話、引き継ぎ、差分、コミット、issue、PR、レビュー、チェック、結果、手戻りから作業ストリームの範囲を定めます。確認できない証拠を記録して確信度を下げ、経緯を捏造したり、リポジトリ全体の監査に範囲を広げたりしないでください。
• プロセスまたは設計の修正を提案する前に、その起点となった意思決定、現在の実装または実行可能な設定、現在のドキュメントを追跡します。設計の欠落、実装の逸脱、ドキュメントの逸脱を区別します。現在の矛盾する証拠が新たな意思決定を必要としない限り、確定済みの選択は維持します。実装や説明文が逸脱したというだけで、再度検討を求めないでください。
• コーディネーターとサブエージェントの完全な記録を、プロセスイベントや引き継ぎを含めて確認します。繰り返された推論、再構築または破棄された証拠、読み込まれたものの使われなかったスキルや迂回されたスキル、手動での再開、能力に応じた振り分けの誤り、価値を生まなかったその他のコンテキスト消費を特定します。このような価値のないコンテキスト消費は、ほかの所見とは分けて報告し、確認できない会話やプロセスの証拠を明記します。
• タイミングの台帳を作成する前に、references/timing-analysis.md を読みます。完了した Milestone Rush については、そこに記載された無視対象の .agent/milestone-rush-events.jsonl も読みます。テレメトリーを現在のリポジトリ、issue、プルリクエスト、CI の証拠と照合します。テレメトリーが部分的または欠落している場合は確信度の制約として扱い、値を推測する根拠にしないでください。
• 証拠と候補を添えて grilling を呼び出します。場当たり的な質問で代用しないでください。利用できない場合は中止します。推奨事項を添えて、一度に1つずつ判断を促すようにします。共通認識に達し、正確なアクションの内容が確認された後にのみ実行してください。
• 3つすべての観点を評価します。永続的な所見がない観点があっても評価を省略しないでください。
  • **デリバリー速度：**品質を損なわずに、待ち時間、手戻り、引き継ぎの摩擦、不要な範囲、認知負荷を減らせるか。
  • **プロセス：**計画、意思決定、引き継ぎ、ゲート、ツール、協働。
  • **コードベース：**アーキテクチャ、保守性、テスト、開発者体験、信頼性、蓄積した摩擦。
• 証拠に裏付けられた、プロジェクト全体に適用できる教訓だけを採用します。時系列の説明、単発のミス、個人の好み、重複、既存のルール、憶測は除外します。
• 作業ストリーム内で重複を排除します。過去の調査や決定を再利用し、複数の証拠システムが示す同じ事象をまとめ、原因とアクションが同じ候補の教訓を出所を保持したまま統合します。繰り返された実装や見つけやすさに関する証拠が作業ストリームの摩擦を引き起こした場合は報告します。ただし、振り返りをリポジトリ全体の重複や見つけやすさの監査にしないでください。それは codebase-audit の対象です。

各教訓の振り分け

• ドキュメントの編集： 既存の契約、README、 docs/、ADR、AGENTS、スキル、テンプレート、ポリシー、または貢献者向けガイダンスに記載する、長期的に有効なガイダンスです。 既存の文章を明確にするか、既存の文章と組み合わせることを優先してください。直接編集できるのは ドキュメントに限られます。
• フォローアップチケット： ソース、実行可能な設定、またはその他の実装が必要です。詳細の追加、 さらなるヒアリング、create-issue（ユーザーが希望する場合は、まず草案を作成）、またはスキップを提案できます。委任されたワークフローでは、独自のゲートが維持されます。
• 次のサイクルの前に実装： 選択された改善を次のサイクル開始前に提供すべき場合は、このルートを推奨してください。推奨だけでは、何も実施する権限は与えられません。ユーザーが明示的に選択した後、create-issue を使って可視化用の課題を再利用または作成し、通常の /deliver ワークフローに進み、そのアクションが提供されるか、実際にブロックされるまで、このレトロスペクティブを有効な状態に保ってください。委任されたワークフローでは、すべてのゲートが維持されます。
• 報告のみ： 有用な根拠はありますが、編集もチケットも必要ありません。

ガイダンスとその実装がそれぞれ別個に必要な場合に限り、編集とチケットの両方を使用してください。 ユーザーが提案された内容を正確に選択した場合に限り、不足しているドキュメントを作成できます。

ワークフロー

1. 作業ストリームの境界を確定し、関連するプロジェクトドキュメントを読みます。
2. 上記のゲートに従って、起点とコーディネーター／サブエージェントの記録をたどります。 その後、成果、摩擦、手戻り、予想外の事象、有効だったゲートまたは見逃されたゲート、成功したプラクティス、および価値のないコンテキストとして分類した情報を、3つすべての観点から個別に記録するエビデンス台帳を作成します。タイミングのリファレンスから1つ以上のタイミングプロファイルを選び、ハイレベルなライフサイクルフェーズと、利用可能なグラウンドレベルの操作の両方を対応付けます。
3. 二重計上を避けながら、クリティカルパスへの排他的な寄与、重複または隠れていた作業、リソース消費の合計を再構成します。排他的な経過時間への影響に基づいてボトルネックを順位付けし、確信度と不足している帰属情報を報告します。
4. 裏付けのない候補、セッション固有の候補、重複する候補、すでに扱われている候補を除外し、残りを上記のルートで分類します。
5. 主な提供済みの変更と重要な成果を、エビデンスに基づく Before と After の状態、不確実性、ソースへのリンクとともに、会話形式で要約します。仕組みや判断の明確化に役立つ場合は、図や比較表を使用します。
6. 境界、エビデンス、現在のドキュメント、不足情報、候補を示しながら、grilling を使って一度に1つずつ判断を検討します。アクションを選ぶ前に、どの調査結果についても詳しく掘り下げられることを提示し、新たなエビデンスを比較に反映します。
7. 詳細な要約を提示します。
   • 調査結果なしの場合も含め、すべての観点についての調査結果；
   • ライフサイクルおよび選択したサーフェスのプロファイル、排他的なクリティカルパスの順位、隠れていた作業や重複していた作業、グラウンドレベルでのビルド／テスト／ツールの所要時間、リソース消費の合計、エビデンスの出所、確信度の不足；
   • 主な成果、Before／After の状態、実施可能な詳細調査；
   • ファイルごとに、提案するドキュメントへの追加、置換、削除の正確な内容；
   • 利用可能なすべての対応経路を含む、簡潔なチケットの概要；
   • 報告のみの所見、裏付けとなるエビデンス、確信度、不足情報。
8. grilling を通じて、ユーザーから正確な選択を得ます。詳細化や追加の検討が必要な場合は、そのループに戻って要約を再生成します。
9. 上記の承認範囲内で、選択されたアクションのみを実施し、ドキュメントの構造を維持して重複を避けます。選択された実装優先の次サイクル向けアクションごとに、可視化用のイシューを再利用または作成し、通常の /deliver を実行して、完了するか、実際にブロックされるまでレトロスペクティブを続けます。
10. 結果を確定済みのアクション一式と比較し、宣言されたドキュメントチェックを実行します。
11. 変更したドキュメント、作成したイシューへのリンク、即時アクションの実施またはブロックを示すエビデンス、報告のみの所見、確信度の限界、確認できた検証結果を報告します。作業ストリームの履歴はチャット内に保持し、どの調査結果についても詳細を依頼できることをユーザーに伝えます。