retro

ユーザーが retrospective を求めています。今後の実行結果を改善するため、コーディングエージェントの environment に対する改善案を提案してください。

手順

1. Skill ツールを呼び出し、writing-for-agents を指定して、ライティングスタイルガイドを取得します。

2. ユーザーが指定したセッションの primary sources を読みます。ローカルで session logs を検索する必要がある場合があります。ユーザーがセッションを指定していない場合は、現在のセッションを使用します。

3. 次のカテゴリから改善候補を探します。

• Navigation：エージェントは正しい files をどれだけ簡単に見つけられましたか？files 間に隠れた依存関係はありますか？navigation pointer があれば、場所を見つけやすくなりますか？エージェントが特定の情報を見つけるまでに長い時間がかかった場合に使用します。
• Automated checks：エージェントのミスを検出できる automated checks はありますか？例：lint、typing、tests、filesystem linters など。まず repo 自身のチェックコマンド（package.json/build-tool にある lint/check scripts と CI workflow）を確認します。チェックがすでに存在するのにプロセスに組み込まれていない、またはひそかに機能しなくなっている場合、真の発見は新たなチェックを考案することではなく、その問題です。repo に guardrail がまったくない場合（pre-commit hook がなく、lint/typecheck/test command を実行する CI job もない場合）、それ自体が発見事項です。lint が導入されていない repo は、当然の初期状態ではなく、継続的に対処すべき改善の不足です。エージェントが automated check で検出できたはずのミスをした場合、または repo に guardrail がまったくない場合に使用します。
• Coding standards：reviewer agent に新しいルールを適用させるべきですか？既存のルールを削除または明確化すべきですか？まず違反の種類を分類します。mechanical な違反（固定された構文パターン、使用禁止の API、import 形式、ファイル配置規則）は deterministic check で処理する必要があります。repo が使用する言語と既存の guardrail に応じて、最もコストの低い方法を選びます。repo 自身の linter へのカスタムルールの追加、新しい pre-commit hook の追加、または新しい CI job の追加です。デフォルトでは、ルールを書くのではなくチェックを構築することを優先します。CODING_STANDARDS.md は、真の judgement calls（複数ファイルにまたがる一貫性、「周囲のスタイルに合っている」こと、およびいかなる guardrail でも代替できない判断）に限って使用します。reviewer agent がミスを見つけられなかった場合に使用します。
• Global AGENTS.md：steering instructions のうち、coding standards または automated checks に移すべきものはありますか？repo またはユーザーの global scope にある AGENTS.md が特に大きい場合に使用します。
• Tool economy：エージェントは、簡略化できる高コストな tool calls を実行しましたか？特に多くの tokens を消費するカスタム tooling（CLI、MCP など）はありますか？エージェントが高コストな tool call を実行した場合に使用します。
• No-ops：steering files に、エージェントの動作を変えない instructions はありますか？steering files が大きく、保守しにくい場合に使用します。
• Information access：エージェントがより多くの情報を得られるようにする方法はありますか？たとえば、dev server logs を tee で出力したり、third-party services への read-only access を提供したりする方法です。エージェントが重要な情報にアクセスできなかった場合に使用します。

4. これらの候補を、重大度の高い順にユーザーへ提示します。

参考

Implementation と Review

すべての作業は、implementation と review の 2 つのフェーズを経ることを覚えておいてください。implementation agent は最も大きな context pressure を受け、調査、コードの作成、失敗のデバッグを担当します。

review agent が受ける context pressure は最小です。diff を受け取るため、調査は不要です。通常、コードの作成やデバッグも必要ありません。

したがって、coding standards の適用は implementation agent ではなく、review agent が担当するべきです。

ファイル

repo 内のいくつかの files にアクセスできます。

• CLAUDE.md/AGENTS.md：これらの files は、この repo で作業するすべてのエージェントの context window に読み込まれます。使用は極めて控えめにし、通常は他の files を指す navigation pointers のみを記載します。
• CODING_STANDARDS.md：この file は review 時に読み込まれ、implementation 時には読み込まれません。standards file が 1,000 行を超える場合は、docs folders を指す navigation pointers を追加します。
• Docs：docs は reference files として扱い、他の files から pointers で参照します。新しい docs を書く前に、既存の docs を探します。
• Skills：docs の内容を skills に含めます（description がエージェントの context window に読み込まれるため）。または、ユーザーが呼び出すコマンドに使用します。writing-for-agents skill の推奨事項に従います。