人のレビュアーがいるチーム

HeyDeer が引き受けること

• 細部とエッジケース。HeyDeer はすべてのプルリクエストで、エラー処理、境界値、並行処理、変更によって壊れる呼び出し元をチェックします。
• レビュアーの負担を軽減。レビュアーはミスを探して 1 行ずつ追う必要がなくなり、その時間と注意力を、人にしかできない判断に使えます。
• 細部まで正確。社内の 1,000 件のプルリクエストで、HeyDeer は細部の正しさを人のレビュアーよりも正確にレビューしました。

推奨構成

1. プッシュごとにレビューする。「ワークスペース設定」→「レビュールール」で、「レビューのタイミング」を「プッシュごと」に設定します。自動レビューを参照してください。
2. 問題があればチェックを失敗にする。「結果の公開」で「問題が見つかった場合はチェックを失敗にする」をオンにします。HeyDeer Review チェックを参照してください。
3. GitHub でチェックを必須にする。main のブランチルールで Require status checks to pass before merging をオンにし、HeyDeer Review を追加します。これで、プルリクエストは指摘事項が修正されるか見送られた場合にのみマージされます。
4. 人のレビューは HeyDeer の結果を起点にする。レビュアーには、チェックが成功したプルリクエストを開いてもらい、設計、プロダクトの動作、そして HeyDeer が人の判断が必要だと示した点に時間を使ってもらいます。

オプション：定型的な変更を自動承認する

自動承認をオンにし、「人による承認が必要な変更」は「重大なアーキテクチャ変更と重要な動作変更」のままにします。これで HeyDeer は、問題が残っていない定型的なプルリクエストを承認し、重大な変更は人に任せて、人が下すべき判断を示します。

ブランチルールで必須の承認数を 1 にしておけば、定型的なプルリクエストはレビュアーを待たずにマージできます。すべての承認が最新のコードを対象とするよう、Dismiss stale pull request approvals when new commits are pushed をオンにしてください。

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

レビュアーがコメントで何度も繰り返しているルールは、チェックにしましょう。ルールごとに .agents/checks/ に Markdown ファイルを追加すると、HeyDeer は該当するファイルを変更するすべてのプルリクエストにそのルールを適用します。リポジトリのチェックを参照してください。

.agents/checks/migrations.md

---
files: "migrations/**/*.sql"
---
The previous release keeps running while a migration
deploys. Report a migration that:

- drops or renames a table or column that code on the
  base branch still uses;
- adds a NOT NULL column without a default;
- creates an index on an existing table without
  CONCURRENTLY.