コードレビューのないチーム

リスク

CI が検出できるのは、テストでカバーしている範囲だけです。レビューがないと、次の 2 つの問題が見逃されます：

• モデルのバイアス。コードを書いたモデルは、自分の作業を確認するよう指示しても、自身の推論をそのまま受け入れ、自身のミスを見落としがちです。
• 繰り返しの編集によるエラー。エージェントが同じコードを何度も修正すると、変更のたびに、以前の変更で正しくできていた部分が気づかないうちに壊れることがあります。

HeyDeer が加えるもの

• 独立した視点。HeyDeer はコードを書いたエージェントとは切り離して各プルリクエストをレビューし、投稿前にすべての指摘事項をコードと照合して検証します。
• 専用のレビュープロセス。プッシュごとにレビューが行われ、フォローアップレビューが以前の問題を再確認し、HeyDeer Review チェックが各コミットに結果を記録します。

推奨構成

1. すべての変更でプルリクエストを作成する。エージェントには main に直接コミットさせず、ブランチにプッシュしてプルリクエストを作成させます。
2. プッシュごとにレビューする。「ワークスペース設定」→「レビュールール」で、「レビューのタイミング」を「プッシュごと」に設定します。自動レビューを参照してください。
3. 問題があればチェックを失敗にする。「結果の公開」で「問題が見つかった場合はチェックを失敗にする」をオンにします。HeyDeer Review チェックを参照してください。
4. 自動承認をオンにする。「結果の公開」で「自動承認」をオンにします。HeyDeer は、完全なレビューの結果、問題が残っていなければプルリクエストを承認します。重大なアーキテクチャ変更と重要な動作変更は引き続き人の承認を待ちます。これらも承認するには、「人による承認が必要な変更」を「変更の種類による追加制限なし」に設定します。自動承認を参照してください。
5. GitHub で main を保護する。main のブランチルールで、Require a pull request before merging を必須の承認数 1 でオンにし、Dismiss stale pull request approvals when new commits are pushed もオンにします。続いて Require status checks to pass before merging をオンにし、CI のチェックに加えて HeyDeer Review を追加します。
6. 自動でマージする。リポジトリの GitHub 設定で Allow auto-merge をオンにします。次に、各プルリクエストで自動マージを有効にするか、プルリクエストの作成後にエージェントに gh pr merge --auto --squash を実行させます。

チームの基準をチェックとして書く

レビューでルールを徹底すると、エージェントはそのルールをより確実に守ります。ルールごとに .agents/checks/ に Markdown ファイルを追加すると、HeyDeer は該当するファイルを変更するすべてのプルリクエストにそのルールを適用します。リポジトリのチェックを参照してください。

.agents/checks/tenant-scope.md

---
files:
  - "src/db/**/*.ts"
  - "!**/*.test.ts"
---
Every query that reads or writes customer data must be
scoped to one tenant, taken from the request context and
never from request parameters.