retro

完了したサイクルを、次のサイクルで実際に活用できる教訓に変えます。

目標

retro は、成果物を生み出した作業サイクルを擁護することなく、長期的に役立つ学びを抽出します。サイクルが実行され、テストに合格しても、作るべきものを間違えていることがあります。出力は変更履歴でも、セラピーの記録でもありません。何がうまくいき、何がビルドを誤った方向へ導き、次の試行で何をクリアすべきかを、根拠に基づいてローカルに記録したものです。

成果物が完成した、失敗した、期待外れだった、あるいは曖昧で、次のエージェントが勢いよりもサイクルの教訓を必要としている場合に retro を使います。

ワークフロー

1. 当初の目標、最終成果物、QA の根拠、ユーザーからの不満、ローカルの計画メモを読みます。
2. 再利用に値する契約、スキーマ、テスト、サービス、用語、例と、進捗があるように見えただけの UI、パネル、スキャフォールド、抽象化を分けて、役立った資産と誤解を招く進捗を整理します。
3. それぞれの失敗を、気分ではなくアンチパターンとして明確にします。
4. 繰り返し発生する失敗や影響の大きい失敗を、次の試行で適用する品質ゲートに変えます。
5. 曖昧なユーザーの指示を、新しいエージェントが使えるアーキテクチャ用語に変換します。
6. サイクルのためのローカルドキュメントを作成、または更新します。教訓を記録する振り返りと、次のサイクルの契約、ゲート、用語を定める計画を用意します。
7. ゼロから始めるエージェントが、それらのドキュメントだけで同じ失敗を避けられることを確認します。

ルール

• 成果物を擁護しないでください。プロダクトとして期待されたものに届かなかったのであれば、何が届かなかったのかを記します。
• 変更履歴を書かないでください。ファイル一覧や作業量の要約は教訓ではありません。
• 否定的な記録も残してください。失敗した経路はトレーニングデータです。
• 助言よりも、明確なゲートを優先します。
• サイクルの根拠を示します。目標、ファイルに関する事実、QA の出力、スクリーンショット、トランスクリプト、差分、ユーザーからのフィードバックなどです。
• 次のエージェントが行動に移せないなら、それはまだ教訓ではありません。
• 来歴はローカルに残します。リリースする成果物に、その失敗の傷跡を語らせないでください。

検証

完了する前に、次の点を確認します。

1. すべての教訓が、観察されたサイクルの根拠に結び付いている。
2. すべてのアンチパターンが、具体的な失敗の形と、それを検知するゲートを明示している。
3. 新しいエージェントが、過去のセッション全体を読まずに、何を維持し、何を破棄し、何を最初にテストすべきか判断できる。