github-scanning

GitHub スキャン

意図別の検索クエリパターン

Issue

意図	クエリパターン	範囲
自分に割り当てられている	is:open assignee:USERNAME	すべてのリポジトリ
自分が @メンションされている	is:open mentions:USERNAME	すべてのリポジトリ
自分が作成した	is:open author:USERNAME	すべてのリポジトリ
特定のリポジトリ	repo:owner/repo is:open	単一のリポジトリ
キーワードで検索	{keyword} is:open	すべてのリポジトリ
組織全体	org:ORGNAME is:open	組織のリポジトリ
クローズ済み（振り返り用）	is:closed author:USERNAME	すべてのリポジトリ

プルリクエスト

意図	クエリパターン	範囲
自分のレビュー待ち	review-requested:USERNAME state:open	すべてのリポジトリ
自分のオープンな PR	author:USERNAME state:open	すべてのリポジトリ
自分に割り当てられている	assignee:USERNAME state:open	すべてのリポジトリ
自分がレビュー済みで、更新を確認	reviewed-by:USERNAME state:open	すべてのリポジトリ
特定の PR	owner、repo、number を指定して直接取得	単一のリポジトリ
組織全体	org:ORGNAME state:open	組織のリポジトリ

ディスカッション

意図	操作
自分がメンションされている	mentions:USERNAME で検索
自分が参加している	自分がコメントしたディスカッションを検索
活動が活発	過去 24 時間に 10 件以上のコメントがあるものに絞り込む
自分の Issue に関連付けられている	Issue への参照を説明文／コメントからスキャン

リリース

• リポジトリごとに github_list_releases を使用し、最近のリリース、ドラフト、プレリリースを確認します。
• マージ済み PR とリリースノートを照合し、未リリースの作業を特定します。
• Issue のマイルストーンとリリース予定を比較し、期限が近い項目にフラグを立てます。

セキュリティ

• Dependabot アラート：監視対象のリポジトリ全体における、重大および高重大度のアラート。
• 依存関係に影響するセキュリティアドバイザリ。
• dependabot[bot] または renovate[bot] による保留中の依存関係更新 PR。

CI/CD

• 最近のワークフロー実行を取得し、失敗したワークフロー、時間のかかるジョブ、不安定なテストを特定します。
• ワークフローが失敗した場合：リポジトリ、ワークフロー名、ブランチ、失敗理由、実行へのリンクを記録します。
• ユーザーのオープンな PR と CI の結果を照合します。

---

日付範囲の処理

自然言語を GitHub のクエリ修飾子に変換します。

ユーザーの指定	GitHub の修飾子
"last week"	created:>YYYY-MM-DD（7 日前）
"this month"	created:>YYYY-MM-01
"today"	closed:YYYY-MM-DD
"this week"	closed:>YYYY-MM-DD（7 日前）
"between X and Y"	created:X..Y
指定なし	設定の search.default_window を使用します（デフォルト：updated:>YYYY-MM-DD、30 日間）。この前提を明記します
"for current month"（a11y トラッカー）	milestone:"{Month} {Year}"

---

範囲の絞り込み

ユーザーが範囲を指定した場合、修飾子を追加して検索範囲を絞り込みます。

範囲	修飾子
単一のリポジトリ	repo:owner/name
組織のすべてのリポジトリ	org:orgname
ユーザーが所有するすべてのリポジトリ	user:username
すべて（デフォルト）	修飾子なし：アクセス可能なすべてのリポジトリを検索

---

設定ファイルの統合

.github/agents/preferences.md を読み込み、検索の前後に次のフィルターを適用します。

1. repos.discovery - デフォルトの検索範囲（all / starred / owned / configured / workspace）を決定します。
2. repos.include - 制限モードでも、これらのリポジトリを常に含めます。
3. repos.exclude - すべての検索で、これらのリポジトリを除外します。
4. repos.overrides - リポジトリごとの設定です。
   • track.issues: false -> このリポジトリのイシュー検索をスキップします
   • track.pull_requests: false -> このリポジトリの PR 検索をスキップします
   • track.discussions: false -> このリポジトリのディスカッション検索をスキップします
   • track.releases: false -> このリポジトリのリリース確認をスキップします
   • track.security: false -> このリポジトリのセキュリティアラートをスキップします
   • track.ci: false -> このリポジトリの CI ステータスをスキップします
   • labels.include / labels.exclude -> ラベルで結果を絞り込みます
   • paths -> これらのファイルパスに変更がある場合のみ実行します（PR/CI 向け）
   • assignees -> 指定した担当者に絞り込みます（空の場合はすべて）
5. search.default_window - ユーザーが期間を指定しない場合のデフォルトの期間です。
6. briefing.sections - デイリーブリーフィングに含めるセクションを指定します。
7. accessibility_tracking - a11y トラッカーの設定です（リポジトリ、ラベル、チャンネル）。

---

リポジトリ横断インテリジェンス

異なるリポジトリから結果が届いた場合は、次のパターンを探して提示します。

パターン	アクション
リポジトリ横断の参照	イシュー A に owner/repo#N が含まれている場合、項目 N を取得して提示します
共通するラベルのパターン	異なるリポジトリで P0 タグが付いた項目を、トリアージでまとめます
異なるリポジトリの関連 PR	次のように示します："このイシューは、まだオープンの repo-B の PR #N に依存しています"
マージ済みだが未リリースの PR	次のように記載します："PR #N はマージされていますが、まだどのリリースにも含まれていません"
マージ済みの修正 PR があるイシュー	次のように示します："解決済みの可能性があります - このイシューをクローズする PR #N は {date} にマージされました"
ブランチ名のパターン	異なるリポジトリで同じブランチ命名規則を使用している PR をまとめます

---

並列ストリーム収集モデル

複数のデータストリームから収集するエージェントは、独立したストリームを同時に実行します。依存関係のない処理を順番に実行しないでください。

例：デイリーブリーフィング - 3 つの並列バッチ

バッチ 1 - 完全に独立しており、同時に実行します：

• イシュー（割り当て済み、メンション済み、作成者）
• プルリクエスト（レビュー依頼済み、作成者）
• リリースとデプロイ
• アクセシビリティの更新

バッチ 2 - バッチ 1 の後に実行します（CI はバッチ 1 の PR リストを必要とします）：

• GitHub ディスカッション
• CI/CD の健全性（PR リストを相互参照）
• セキュリティアラート

バッチ 3 - バッチ 2 と並行して実行できます：

• プロジェクトボードのステータス
• 最近クローズ/マージされた作業

例：分析 - 2 つの並列バッチ

バッチ 1 - 収集（すべて独立）：

• 期間内にクローズ/マージされた PR
• 期間内に作成されたイシュー
• 期間内の CI ワークフローの実行
• 期間内のセキュリティアラート

バッチ 2 - 分析（バッチ 1 のデータに依存）：

• 健全性スコアの算出
• ベロシティ指標の計算
• ボトルネックの検出

並列作業の告知テンプレート

 Running {N} searches in parallel... ({scope})
 Batch 1 complete - {X} items found

 Running {N} additional searches...
 Batch 2 complete - {Y} items found

 Scoring and prioritizing...
 Done - {Z} items need action, {W} to monitor

---

結果が空の場合の自動リカバリー

検索結果が 0 件の場合：

1. 自動的に範囲を広げます。日付フィルターを削除する、範囲を all に広げる、またはラベルフィルターを削除します。
2. 変更内容をユーザーに正確に伝えます："過去 7 日間の結果はありません。過去 30 日間に範囲を広げたところ、3 件見つかりました。"
3. 少なくとも 1 回、より広い条件で検索する前に、結果が 0 件だと返してはいけません。

リカバリーの順序：

1. 1 回目：日付条件を削除
2. 2 回目：範囲を広げる（org: を追加するか、repo: 条件を削除）
3. 3 回目：ラベルフィルターを削除
4. 3 回すべてで結果がなかった場合に限り、結果が 0 件だと報告します

---

ページネーション

• 大量の結果は 10 件ずつページネーションします。
• 続きを読み込む前に確認します："47 件中 10 件を表示しています。続きを読み込みますか？"
• 結果を黙って切り詰めてはいけません。必ず合計件数を明示します。

---

結果の重複排除

同じ項目が複数の検索結果に表示される場合（たとえば、自分が担当していて、さらにメンションもされている Issue）：

• コンテキストをすべてまとめて、一度だけ表示します。
• Signal 列には、シグナルをまとめて「Assigned, @mentioned」のように記載します。
• 優先度の計算では、スコアの高いシグナルを適用し、加算しません。

---

レート制限

• レート制限（403/429）が発生した場合は、リセット時刻を1文でユーザーに伝えます。
• 同じクエリを再試行しないでください。リセットまで60秒未満の場合は待機し、それ以外の場合は状況を報告して次に進みます。
• 複数のストリームから収集する場合は、レート制限されたストリームをスキップし、フォローアップで完了します。