よくある質問

GitHub を接続し、リポジトリを選んでから、レビューを依頼します。

• GitHub でサインインし、リポジトリがあるアカウントを選ぶで個人アカウントまたは組織を選びます。一覧にない場合は、GitHub でインストールを選択して GitHub 側で選びます。
• GitHub で Only select repositories を選び、レビューするリポジトリを指定して確定します。組織では、あなたがオーナーでない限り、GitHub がオーナーに承認を求めます。
• HeyDeer に自動でレビューさせるかを決めます。プルリクエストを自動でレビューをオンのままにするとプッシュのたびにレビューし（1 つのプルリクエストにつき最大 5 回）、オフにすると依頼したときだけレビューします。
• オープン中のプルリクエストに @heydeer review とコメントします。

リポジトリへの書き込み権限が必要です。新しいワークスペースはクレジットカード不要の無料プランで始まり、指摘事項はプルリクエストのレビューコメントとして届きます。

接続したらすぐにレビューを依頼できます。HeyDeer はプルリクエストの変更をリポジトリ全体の文脈の中で読み、PR のタイトル、説明、議論もあわせて確認します。どのレビューも最初からバグとセキュリティの問題を探します。

最初のレビューで足りない点が見えたら、適切な場所にガイダンスを追加します。

• AGENTS.md：コードの仕組みと、従っている規約。コーディングエージェントもこのファイルに従います。
• REVIEW.md：レビューで探すべきこと、触れずにおくこと、問題の深刻度。
• リポジトリのチェック：特定のファイルを変更するすべてのプルリクエストで、HeyDeer が必ず検証すべき要件。
• レビューへの指示：プルリクエストで変更されては困るガイダンスや、すべてのリポジトリに適用するガイダンス。

誰かが依頼すればすぐに始まります。プルリクエストに @heydeer review とコメントするか、レビュー履歴ページでレビューを開始を選択するか、HeyDeer Review チェックで Re-run を選択します。新しいワークスペースは手動のみで始まり、セットアップの直後に HeyDeer が自動でレビューするかどうかを尋ねます。

ワークスペース管理者は、ワークスペース設定 → レビュールール → レビューのタイミングでいつでもスケジュールを変更できます。

• PR ごとに 1 回：条件に合うプルリクエストを、レビューが 1 回成功するまでレビューします。
• プッシュごと：プルリクエストが初めてフィルターに一致したときと、その後コミットを追加するプッシュのたびにレビューします。デフォルトでは最大 5 回です。

自動レビューは、デフォルトでドラフト、フォーク、依存関係の更新をスキップします。

段階的に導入し、チームが結果を信頼できるようになったら、HeyDeer の結果をマージの条件にしましょう。

• いくつかのプルリクエストで試す：自動レビューをオフにしたまま、種類の異なるプルリクエストいくつかに @heydeer review とコメントし、指摘事項をチームのレビュアーの指摘と比べます。
• そのレビューで見えた不足を埋める：規約は AGENTS.md、要件はリポジトリのチェック、優先事項はレビューへの指示に書きます。
• 1〜2 個のリポジトリで自動レビューをオンにし（リポジトリで選択してからタイミングを変更）、その後ワークスペース全体に広げます。
• HeyDeer Review チェックを必須にし、自動承認を使うかどうかを決め、有料プランなら自動チャージと使用量の上限を設定します。

チームが大半の指摘事項に対応し、レビューが注意事項なしで完了するようになったら、次の段階に進みます。設定を変更するのはワークスペース管理者で、書き込み権限があれば誰でもレビューを依頼できます。

次のいずれかの方法で、プルリクエストの最新コミットをレビューできます。

• プルリクエストに @heydeer review とコメントする。
• HeyDeer Review チェックで Re-run を選択する。
• HeyDeer のレビュー履歴ページでレビューを開始を選択する。ここでは別の深さやフィードバックの範囲も選べます。

新しい変更のみレビューがオンの場合、レビューの対象は前回以降の変更です。プルリクエスト全体をもう一度レビューするには、@heydeer full review とコメントします。レビューの依頼には書き込み権限が必要です。依頼したレビューもほかのレビューと同じように課金されますが、PR ごとの自動レビュー上限にはカウントされません。

HeyDeer からレビューを開始すると、そのレビューに限って深さとフィードバックの範囲を選べます。

• レビュー履歴を開き、レビューを開始を選択します。
• リポジトリとプルリクエストを選びます。一覧には、書き込み権限のあるリポジトリが表示されます。
• レビューの深さやフィードバックの範囲を変えるには、レビューのオプションを開きます。どちらもリポジトリのデフォルトが初期値です。
• レビューを実行するを選択します。

あとは GitHub で依頼したレビューと同じように実行され、公開されます。

最初のレビューのあと、HeyDeer は新しい部分に集中します。デフォルトの新しい変更のみレビューがオンの場合、以降のレビューでは、前回成功したレビュー以降にプルリクエスト自身のコミットが変更した部分でだけ新しい指摘事項を探し、以前の指摘事項を再確認します。ベースブランチからマージされたコミットは対象外ですが、コンフリクトの解消はレビューされます。

次の場合、HeyDeer はプルリクエスト全体をレビューします。

• 誰かが @heydeer full review とコメントした場合、またはこの設定がオフの場合。
• 前回のレビュー以降にベースブランチが変わった場合。
• 前回のレビューに注意事項があった場合、または確認を求めていた場合。

レビューの対象が新しい変更とPR 全体のどちらだったかは、チェックの概要に表示されます。

以降のレビューでは毎回、HeyDeer が未解決の以前の問題を現在のコードと照らし合わせて再確認します。

• まだ当てはまる問題は、対応が必要な以前の問題に表示されます。
• HeyDeer が検証できない問題は、必要な情報とともに確認が必要な以前の問題に表示されます。
• デフォルトの対応済みの HeyDeer の会話を解決済みにするがオンの場合、コードで問題が修正されたか誤りだったと示されたとき、または問題が見送られたときに、HeyDeer がその会話を解決済みにします。

修正はコードで示す必要があり、修正したという返信だけでは不十分です。未解決または未確認の問題は自動承認をブロックし、問題が見つかった場合はチェックを失敗にするがオンならチェックを失敗にします。

HeyDeer はフィードバックの範囲内の指摘事項を投稿します。この設定は、深刻度（緊急、高、中、低）ごとに、HeyDeer がどの程度の確信を持てば指摘事項を報告するかを決めます。

• 簡潔：「緊急」は可能性が高ければ、「高」と「中」は確信がある場合だけ報告し、「低」はリポジトリのチェックによるものだけを報告します。すべてのコメントに目を通すチームに向いています。
• バランス（デフォルト）：「緊急」は疑いの段階で、「高」は可能性が高ければ、「中」と「低」は確信がある場合に報告します。
• 網羅的：「緊急」と「高」は疑いの段階で、「中」と「低」は可能性が高ければ報告します。修正前にコーディングエージェントが各指摘事項を検証するチームに向いています。

範囲外の指摘事項は報告されず、チェックを失敗にすることも、自動承認をブロックすることもありません。範囲を比較するには、切り替える前に HeyDeer で完了したレビューを使ってプレビューしてください。

はい。「HeyDeer で修正」を使うと、選んだ指摘事項が、内容を確認してマージできるプルリクエストになります。

• レビューコメントのHeyDeer で修正、または HeyDeer のレビューページの指摘事項を修正を選択します。
• 指摘事項を選び、取るべきアプローチや維持すべき動作など、コンテキストが必要なものには指示を追加を使います。
• 2 件の指摘事項を修正のように、選択数が表示されたボタンを選択します。

HeyDeer が変更を行い、サンドボックスでテストを実行して、あなたの PR のブランチを対象とする別の PR を作成します。それをマージすると、次の PR のレビューでそれらの指摘事項が再確認されます。「HeyDeer で修正」はすべてのプランに含まれています。

Autopilot は、プルリクエストがマージできる状態になるか、あなたの対応が必要になるまで、HeyDeer に任せる機能です。各ラウンドで HeyDeer は未対応の項目を修正し、PR 自身のブランチにプッシュして、新しいコミットをレビューします。これをラウンドの上限まで繰り返します（既定は 5 ラウンドで、ワークスペースやリポジトリごとに変更できます）。対象は次のとおりです。

• フィードバックの範囲内の指摘事項と、未解決の以前の問題。
• 未解決のレビューの会話や新しいコメントでの、書き込み権限を持つ人からの依頼。
• 失敗したチェック：必須のチェック、または HeyDeer Review 以外のすべてのチェック。
• マージコンフリクト：ベースブランチをマージして解消し、リベースや強制プッシュは行いません。

レビューページまたは HeyDeer のレビューコメントにある Autopilot ボタンで開始するか、@heydeer autopilot とコメントします。停止すると、HeyDeer はレビューを公開し、まだ未対応の項目を一覧にします。Autopilot には有料プランが必要で、各ラウンドはほかの修正やレビューと同じようにクレジットを消費します。

HeyDeer の Autopilot のページでAutopilot を停止を選択するか、@heydeer autopilot stop とコメントします。書き込み権限があれば誰でも停止できます。次の場合も Autopilot は自動的に停止します。

• 修正するものが残っていない、または質問へのあなたの回答が必要になった。
• ほかの誰かがブランチにプッシュした（GitHub の Update branch ボタンによるものも含む）。
• ラウンドの上限に達した、またはラウンドを重ねても進展がなくなった。
• 1 時間たってもチェックが実行中だった、PR がマージキューに入っている、または GitHub がプッシュを拒否した。
• PR がクローズまたはマージされた、またはワークスペースのクレジットが尽きたか、有料プランではなくなった。

PR へのコメントで停止した理由とまだあなたの対応が必要なことを伝え、必要な場合は開始した人をメンションします。もう一度開始するとラウンド数がリセットされ、新しい回答やコメントも取り込まれます。

プルリクエストや Issue のコメント、インラインのレビューコメント、新しいプルリクエストや Issue の説明で @heydeer をメンションすると、質問したり作業を任せたりできます。例：

• @heydeer what does this function do? と書くと、返信でコードを説明します。
• @heydeer fix the first issue and open an issue for the second と書くと、修正を含むプルリクエストと新しい Issue を作成します。
• @heydeer do the latest Next.js docs recommend this? と書くと、Web 上のドキュメントを確認します。

HeyDeer は会話を読み、テストを実行できるサンドボックスで作業し、依頼された場所で回答します。特に指示がなければ、コードの変更は新しいプルリクエストになります。書き込み権限があれば誰でも依頼でき、各依頼はワークスペースのクレジットを消費して、HeyDeer のタスクに表示されます。

「HeyDeer で修正」は、無料プランを含むすべてのプランに含まれています。修正には次が必要です。

• ブランチがフォークではなく同じリポジトリにある、オープン中のプルリクエスト。
• リポジトリへの書き込み権限。
• HeyDeer による Contents、Pull requests、Workflows の読み取り・書き込み権限。HeyDeer が Workflows の権限を求める前にインストールされていた場合は、まずインストールの管理者が GitHub で更新された権限を承認します。

各プルリクエストで同時に実行できる修正は 1 つで、1 回の修正で最大 100 件の指摘事項を扱えます。

はい。リポジトリのルートにある AGENTS.md に書いておけば、HeyDeer はすべてのプルリクエストをその規約に照らしてレビューします。AGENTS.md に対応したコーディングエージェントも、コードを書くときに同じファイルに従います。コードの構成、命名、使うべきヘルパーやライブラリ、エラーとテストの扱いなど、新しく加わったチームメンバーが知っておくべきことを、1 つの箇条書きに 1 つの規約で、わかりにくい場合は理由も添えて書きます。

独自の規約が必要なディレクトリには、src/payments/AGENTS.md のように専用のファイルを置けます。このファイルは上位の規約に追加され、矛盾する場合は優先されます。AGENTS.md がないディレクトリでは、HeyDeer は CLAUDE.md を読みます。HeyDeer はインポートをたどらないので、規約はファイル自体に書いてください。

REVIEW.md に書きます。リポジトリのルート、または独自のガイダンスが必要な任意のディレクトリに置けます。用途は次のとおりです。

• HeyDeer がコードからは知り得ない確認事項（どのログフィールドが個人データにあたるかなど）。
• 触れずにおくこと。範囲を絞り、対象のパスを明記します。
• ある種類の問題の深刻度。緊急、高、中、低で表します。
• ある種類の指摘事項が誤りだと判明することが続くときに、その種類に必要な根拠。

Claude Code Review 向けに書いた REVIEW.md はそのまま使えます。REVIEW.md はプルリクエストで編集できるため、変更されては困るガイダンスはレビューへの指示に置いてください。

リポジトリ内の .agents/checks/ に Markdown ファイルとして保存する要件で、対象のファイルはフロントマターの files に列挙します。HeyDeer は、それらのファイルを変更するすべてのプルリクエストで、その要件専用のレビュアーを使って検証します。そのため、チェックは一般的なガイダンスより徹底的で、クレジットも多く消費します。

見落とすと代償が大きく、見過ごされやすい要件（API ルートのアクセス制御など）にチェックを使いましょう。チェックによる指摘事項にはそのファイル名が示され、HeyDeer Review チェックと自動承認に反映されます。チェックを自動で書いてもらうには、ダッシュボードでリポジトリのチェックを設定を選びます。HeyDeer がリポジトリと過去のプルリクエストを読み、チェックを追加するプルリクエストを作成します。クレジットは消費しません。

多くの場合、ガイダンスが変更されたファイルをカバーしていません。当てはまる原因を確認してください。

• リポジトリのチェックは .agents/checks/ の直下にある .md ファイルで、files のパターンが変更されたファイルに一致している必要があります。
• AGENTS.md や REVIEW.md は、変更されたファイルをカバーするディレクトリに置く必要があります。
• レビューへの指示は保存後に依頼したレビューから適用され、リポジトリの指示はワークスペースの指示と矛盾する場合に優先されます。
• 指摘事項がフィードバックの範囲外かもしれません。「バランス」または「網羅的」を試してください。
• コードを読むだけでは HeyDeer が検証できない要件は、コードに関する条件として書き直す必要があります。
• 生成ファイルと、ベースブランチにすでにあるロックファイルはスキップされます。

原因を直したら、@heydeer review とコメントしてください。

次のリストを上から順に試してください。少ない手間で大きな効果が出る変更から並んでいます。

• HeyDeer で最近のレビューを使ってプレビューしたうえで、フィードバックの範囲を簡潔に切り替える。
• 生成コードに .gitattributes で linguist-generated を付ける。
• skip-review ラベルなどの自動レビューのフィルターで、ボットや使い捨てのプルリクエストをスキップする。
• 修正しないと決めた指摘事項は見送り、再び指摘されないようにする。
• 誰も対応しない種類のコメントには、理由を添えた範囲の狭いレビューへの指示を追加する。
• リポジトリのチェックが関係のないファイルについて報告する場合は、その files パターンを絞り込む。

リモートの MCP サーバーで、コードだけではわからないこと（機能の使われ方、ログの内容、テーブル内のデータ、ライブラリのドキュメントなど）をレビューやタスクで確認できるようにします。有料プランに含まれており、GitHub の組織または個人アカウントのオーナーが管理します。

追加するには、ワークスペース設定 → コネクタを開き、コネクタを追加を選択して、サーバーの HTTPS エンドポイントと必要なヘッダーを入力し、ツールを読み込むを選択します。許可するツールとリポジトリを選び、コネクタを保存を選択します。最初は読み取り専用ツールだけが許可され、コネクタはデフォルトで非公開リポジトリでのみ使われます。ツールの呼び出しは、その作業のクレジットに加算されます。

ワークスペース設定 → レビュールールのレビューのタイミングにある自動レビューのフィルター、またはリポジトリのレビュールールタブを使います。各行では、ラベル、作成者、作成者のチーム、関係やアカウントの種類、ドラフトの状態、ソースで絞り込み、プルリクエストはすべての行に一致した場合にだけ対象になります。よく使う行の例：

• ボットをすべてスキップ：作成者のアカウント → 次のいずれでもない → ボット。
• ラベル付きのプルリクエストだけをレビュー：PR ラベル → 次のいずれか → ai-review。
• 作成者がオプトアウトできるようにする：PR ラベル → 次のいずれでもない → skip-review。

デフォルトでは、フィルターはドラフト、フォーク、依存関係の更新をスキップします。フィルターは自動レビューにだけ適用されるので、どのプルリクエストでも引き続きレビューを依頼できます。

クレジットで、各レビューや修正が行った作業量に応じて支払います。そのため、大きな変更や「詳細」レビューは、小さな「標準」レビューより多くのクレジットを消費します。ワークスペース全体で 1 つのプランとクレジット残高を共有し、開発者数もリポジトリ数も無制限で人数課金もないので、チームメンバーを追加しても料金は変わりません。

• どのプランにも月次クレジットが含まれます。無料プランは最初の月が 1,000 クレジット、その後は毎月 300 クレジットです。
• 無料プランを含むどのプランでも、1,000 クレジットあたり $10 の基本料金でクレジットを追加でき、まとめて購入すると割引があります。
• 公開リポジトリのレビューは、適正利用の上限まで無料です。

有料プランでは、月次クレジットと並列レビュー数が増え、「詳細」レビュー、Autopilot、コネクタも使えます。

ワークスペースにクレジットが補充されるまで、HeyDeer は新しいレビューを開始しません。すでに実行中のレビューは最後まで完了し、未払い分の使用量は HeyDeer が負担します。一方、実行中の修正は停止します。自動レビューを開始できない場合は HeyDeer Review チェックに理由が表示され、HeyDeer は各リポジトリで最初に該当したプルリクエストに、プランとクレジットの選択肢へのリンク付きで 1 日 1 回コメントします。

続けるには、使用量と請求 → 概要でクレジットを追加するか、翌月のクレジット付与を待つか、有料プランを選んでから、もう一度レビューを依頼します。以降の自動レビューは通常どおり始まります。有料プランでは、クレジットが少なくなったときと尽きたときに HeyDeer がワークスペースにメールを送り、自動チャージを使えばその前にクレジットを追加できます。

ワークスペースがプランを選んだあと、ワークスペース管理者が使用量と請求 → 概要 → 支出の管理で両方を設定します。

• 自動チャージはデフォルトでオフです。残高が設定したしきい値を下回るたびに、一定量の追加クレジットをボリュームディスカウント適用の価格で購入し、レビューが止まらないようにします。有効な有料プランが必要で、サブスクリプションのカードに請求されます。
• 使用量の上限は、暦週または暦月にレビューと修正が合計で使うクレジットに上限を設けます。上限に達すると、上限がリセットされるか引き上げるまで新しいレビューと修正は始まりませんが、実行中のものは完了します。

週ごとの上限は毎週月曜日、月ごとの上限は毎月 1 日に、いずれも 00:00 UTC にリセットされます。クレジットを追加しても、使用量の上限は解除されません。

ワークスペース管理者が使用量と請求 → 概要でプランを管理します。

• アップグレードするにはプランを変更を使います。支払った時点で適用され、期間の残りについて差額を支払い、増える月次クレジットのうち相応の分を受け取ります。更新日は変わりません。
• ダウングレードもプランを変更で行います。次回の更新時に適用され、現在のプランを維持で取り消せます。
• 解約するには請求ポータルを開きます。支払い済みの期間の終わりまでプランは続き、その後ワークスペースは無料プランに戻ります。プランを続けたい場合は、それまでにサブスクリプションを再開を選択します。

実行するレビューの数と深さをコントロールします。

• デフォルトのレビューの深さは標準のままにし、「詳細」はコードが必要とする場所だけで使う。
• レビューのタイミングをPR ごとに 1 回にするか、PR ごとの自動レビュー上限を下げる。
• 新しい変更のみレビューをオンのままにする。
• レビューの不要なプルリクエストは自動レビューのフィルターでスキップし、生成ファイルにはマークを付ける。

有料プランでは、週ごとまたは月ごとの使用量の上限で支出に上限を設けられます。使用量と請求 → 使用量で、リポジトリ、プルリクエスト、レビュー、タスクごとの使用クレジットを確認できます。

各メンバーには、GitHub でアクセスできるリポジトリのレビューが表示され、書き込み権限のあるリポジトリではレビューを開始・キャンセルできます。管理者はさらに次のことができます。

• レビュールールとスケジュールの変更（メンバーも閲覧はできます）。
• ワークスペース設定と使用量と請求の管理。
• メンバーのロールの変更。

コネクタを管理できるのは、GitHub オーナーまたはアカウントオーナーと表示された管理者だけです。また、手動レビューの権限で、レビューを依頼できる人を絞り込めます。

インサイトは、選んだ期間とリポジトリについて、レビューで何が見つかり、チームがそれにどう対応したかをまとめます。

• レビューした PR 数、指摘事項数、PR あたりの指摘事項数、見送り率。
• 深刻度別の指摘事項数の推移と、それぞれが後のレビューで修正済み、コードに残存、見送りのどれと判定されたか。
• 同じ集計のリポジトリ別の内訳と、ワークスペース管理者にはプルリクエストの作成者別の内訳。

後のレビューで繰り返し報告されても、各指摘事項は 1 回だけカウントされます。あるリポジトリで見送り率が高い場合、多くは HeyDeer にそのリポジトリのコンテキストが不足しています。それはレビューへの指示、REVIEW.md、リポジトリのチェックで補えます。

ワークスペースのクレジット、支払い、GitHub へのアクセスに関するメールで、マーケティングメールは送られません。

• クレジット残量の低下（自動チャージがオフの有料プランで、プランの月次クレジットの 20% になったとき）と、クレジットの枯渇。
• サブスクリプションの支払いの失敗、銀行から確認を求められた支払い、猶予期間後も未払いの更新。
• 自動チャージの失敗や購入上限による一時停止、請求の問題の解決中の支払いの一時停止。
• GitHub の組織オーナーによる、HeyDeer の接続リクエストの承認。

HeyDeer は GitHub App としてインストールされ、Only select repositories を選ぶと、レビューしてほしいリポジトリだけにアクセスを限定できます。主な権限は次のとおりです。

• Contents の読み取り・書き込み：コードと履歴を読み、修正と @heydeer への依頼のためにコミットをプッシュします。ブランチ上のコミットを上書きすることはありません。
• Pull requests の読み取り・書き込み：レビューとコメントを公開し、依頼に応じてプルリクエストを作成、更新、マージします。
• Checks の読み取り・書き込み：HeyDeer Review チェックを表示します。
• Workflows：修正で GitHub Actions のワークフローファイルが変わる場合に、そのファイルを更新します。

そのほか、コマンド、Autopilot 用の Actions のログ、フィルター用の組織メンバー、請求通知用のメールアドレスに、範囲の小さい権限を使います。HeyDeer は Administration の権限を要求せず、各トークンは 1 つのリポジトリと、そのステップに必要な権限だけに限定されます。

レビュー履歴を残し、ワークスペースを運用するのに必要なものです。

• レビューと修正の結果、選択された指摘事項と指示。コメント対象の行が引用されることがあります。
• リポジトリと PR の識別子。
• アカウントとワークスペースの情報、設定。
• 請求の記録。

リポジトリ自体は一時的なクローンで処理され、作業が終わると破棄されます。コネクタの呼び出しについては、ツール、時刻、所要時間、結果を記録しますが、送受信した内容は保存しません。

最新コミットの HeyDeer Review チェックのタイトルに理由が表示されます。よくある原因を多い順に挙げます。

• スケジュールが、新しいワークスペースのデフォルトである手動のみになっている：PR ごとに 1 回またはプッシュごとを選びます。
• フィルターでスキップされている（デフォルトではドラフト、フォーク、依存関係の更新がスキップされます）：レビュー可能な状態にするか、フィルターを変更するか、@heydeer review とコメントします。
• 処理枠が埋まっているため、レビューがキューで待機している：枠が空くと始まります。
• PR ごとに 1 回ですでにレビューが成功している、または PR がPR ごとの自動レビュー上限に達した：@heydeer review とコメントします。
• ワークスペースのクレジットが尽きたか、使用量の上限に達した：クレジットを追加するか上限を引き上げてから、レビューを依頼します。
• その PR で自動レビューが一時停止されている：@heydeer resume とコメントします。

多くの場合、リポジトリがまだレビューされていないか、チェックの公開がオフになっています。次の順に確認してください。

• リポジトリが手動のみで、一度もレビューされていない：レビューを依頼すれば、以降のリビジョンにチェックが付きます。
• GitHub チェックを公開がオフになっている：レビュールールの結果の公開でオンにします。
• HeyDeer に Checks の権限またはリポジトリへのアクセス権がない：GitHub オーナーがワークスペース設定 → GitHub 接続で権限リクエストを確認またはリポジトリを追加を選択します。
• プルリクエストがクローズされている：再オープンします。

HeyDeer があるリポジトリでチェックを公開するようになると、プルリクエストが更新されるたびにチェック結果が付くので、必須チェックがいつまでも待ち続けることはありません。

HeyDeer は受け付けたコマンドすべてに 👀 を付けます。付かない場合は次を確認してください。

• コマンドは、コード、引用、HTML コメント、編集ではなく、新しい PR コメントまたはインラインのレビューコメントにプレーンテキストで、ボットではなく個人アカウントから投稿します。
• 書き込み権限が必要です。手動レビューの権限が制限されている場合は、そこに登録されている必要があります。
• ワークスペースのクレジットが尽きているか、使用量の上限に達している可能性があります。
• HeyDeer に Issues または Pull requests の権限が必要な場合があります：GitHub オーナーがワークスペース設定 → GitHub 接続で権限リクエストを確認を選択します。
• pause と resume は、オープン中のプルリクエストでのみ機能します。

原因を直したら、新しいコメントでもう一度コマンドを投稿してください。

HeyDeer Review チェックを必須にし、指摘事項があればチェックが失敗するようにします。

• チェックが存在するよう、リポジトリで少なくとも 1 つのプルリクエストを HeyDeer にレビューさせます。
• ベースブランチの GitHub のブランチ保護ルールまたはルールセットで必須ステータスチェックをオンにし、HeyDeer Review を追加して、ソースとして HeyDeer を選択します。
• HeyDeer で、ワークスペース設定 → レビュールール → 結果の公開の問題が見つかった場合はチェックを失敗にするをオンにします。

これで、プルリクエストは指摘事項と以前の問題が修正または見送られたあとでしかマージできなくなります。HeyDeer が自動でレビューしないコミット（PR ごとの自動レビュー上限に達したあとなど）も、誰かがレビューを依頼するまでマージをブロックします。

チェックの概要には、結果の根拠となった指摘事項、未解決の以前の問題、失敗したリポジトリのチェックの数が表示されます。チェックが失敗するのは次の場合です。

• 問題が見つかった場合はチェックを失敗にするがオンで、レビューにフィードバックの範囲内の指摘事項、未解決または未確認の以前の問題、またはレビューの注意事項がある場合。
• 設定にかかわらず、リポジトリのチェックが実行されなかった、以前の問題が再確認されなかった、または HeyDeer がレビューを開始または完了できなかった場合。

指摘事項を修正してプッシュするか、それぞれの会話で見送ってから @heydeer review とコメントします。レビューが不完全な場合は、もう一度依頼してください。コネクタを呼び出していなければ、HeyDeer は失敗したレビューのクレジットを返還します。

自動承認はデフォルトでオフです。レビュールールの結果の公開でオンにします。オンの場合、HeyDeer のレビューページに自動承認されませんでしたと理由が表示されます。たとえば次のような理由です。

• 指摘事項または以前の問題が残っている：修正するか見送ります。または深刻度「低」の問題を許可を選ぶと、「低」だけが残った状態で承認されます。
• PR のリスクレベルがHeyDeer が承認できる PRの設定を超えているため、人が承認します。
• 要確認に質問が残っている、またはレビューに注意事項がある。
• AGENTS.md やリポジトリのチェックなど、HeyDeer が PR から読み込むガイダンスを PR が変更している、または HeyDeer が作成した PR である。
• レビュー後に新しいコミットが追加された、またはベースブランチが進んだ。