GitHub Scanning
Search Query Patterns by Intent
Issues
| Intent | Query Pattern | Scope |
|---|
| Assigned to you | is:open assignee:USERNAME
| All repos |
| You were @mentioned | is:open mentions:USERNAME
| All repos |
| Authored by you | | All repos |
| Specific repo | | Single repo |
| By keyword | | All repos |
| Org-wide | | Org repos |
| Closed (for recap) | is:closed author:USERNAME
| All repos |
Pull Requests
| Intent | Query Pattern | Scope |
|---|
| Awaiting your review | review-requested:USERNAME state:open
| All repos |
| Your open PRs | author:USERNAME state:open
| All repos |
| Assigned to you | assignee:USERNAME state:open
| All repos |
| You reviewed, check for updates | reviewed-by:USERNAME state:open
| All repos |
| Specific PR | Fetch directly with owner, repo, number | Single repo |
| Org-wide | | Org repos |
Discussions
| Intent | Action |
|---|
| You're mentioned | Search with |
| You're participating | Search discussions you've commented on |
| High activity | Filter for 10+ comments in last 24h |
| Linked to your issues | Scan description/comments for issue references |
Releases
- Use per repo - check for recent, draft, and pre-releases.
- Cross-reference merged PRs against release notes to identify unreleased work.
- Compare issue milestones against release schedules to flag upcoming deadline items.
Security
- Dependabot alerts: critical and high severity across monitored repos.
- Security advisories affecting dependencies.
- Pending dependency update PRs from or .
CI/CD
- Fetch recent workflow runs - identify failing workflows, long jobs, and flaky tests.
- For failing workflows: note repo, workflow name, branch, failure reason, and link to run.
- Cross-reference user's open PRs against CI results.
Date Range Handling
Convert natural language to GitHub query qualifiers:
| User Says | GitHub Qualifier |
|---|
| "last week" | (7 days ago) |
| "this month" | |
| "today" | |
| "this week" | (7 days ago) |
| "between X and Y" | |
| Not specified | Use from preferences (default: 30 days) - mention this assumption |
| "for current month" (a11y tracker) | milestone:"{Month} {Year}"
|
Scope Narrowing
Add qualifiers to narrow by scope when the user specifies one:
| Scope | Qualifier |
|---|
| Single repo | |
| All org repos | |
| All repos by user | |
| Everything (default) | No qualifier - searches all accessible repos |
Preferences File Integration
Read
.github/agents/preferences.md
and apply these filters before and after searching:
- - determines the default search scope (all / starred / owned / configured / workspace).
- - always include these repos even in restricted modes.
- - skip these repos in all searches.
- - per-repo settings:
- -> skip issue searches for this repo
track.pull_requests: false
-> skip PR searches for this repo
- -> skip discussions for this repo
- -> skip release checks for this repo
- -> skip security alerts for this repo
- -> skip CI status for this repo
- / -> filter results by label
- -> only trigger for changes touching these file paths (for PRs/CI)
- -> filter to specific assignees (empty = all)
- - default time range if the user doesn't specify one.
- - which sections to include in the daily briefing.
- - config for the a11y tracker (repos, labels, channels).
Cross-Repo Intelligence
When results arrive from different repos, look for and surface these patterns:
| Pattern | Action |
|---|
| Cross-repo references | When issue A contains , fetch and surface item N |
| Shared label patterns | Group items in different repos tagged together in triage |
| Related PRs in different repos | Flag: "This issue depends on PR #N in repo-B which is still open" |
| Merged PR not yet released | Note: "Your PR #N is merged but not in any release yet" |
| Issue with merged fix PR | Flag: "This may be resolved - PR #N that closes it was merged on {date}" |
| Branch naming patterns | Group PRs in different repos using the same branch naming convention |
Parallel Stream Collection Model
For agents that collect from multiple data streams, run independent streams simultaneously. Don't serialize operations with no dependencies.
Example: Daily Briefing - 3 Parallel Batches
Batch 1 - fully independent, run simultaneously:
- Issues (assigned, mentioned, authored)
- Pull requests (review-requested, authored)
- Releases & deployments
- Accessibility updates
Batch 2 - run after Batch 1 (CI needs PR list from Batch 1):
- GitHub Discussions
- CI/CD health (cross-references PR list)
- Security alerts
Batch 3 - can overlap with Batch 2:
- Project board status
- Recently closed/merged work
Example: Analytics - 2 Parallel Batches
Batch 1 - collection (all independent):
- Closed/merged PRs in period
- Opened issues in period
- CI workflow runs in period
- Security alerts in period
Batch 2 - analysis (depends on Batch 1 data):
- Health score computation
- Velocity metrics calculation
- Bottleneck detection
Announcement Template for Parallel Work
text
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
Auto-Recovery for Empty Results
If a search returns 0 results:
- Automatically broaden: remove date filter, expand scope to , or remove label filters.
- Tell the user exactly what changed: "No results in last 7 days - broadened to last 30 days and found 3 items."
- Never return 0 results without trying at least one broader query first.
Recovery cascade:
- First try: Remove date qualifier
- Second try: Expand scope (add org: or remove repo: qualifier)
- Third try: Remove label filters
- Report 0 results only if all three attempts return nothing
Pagination
- Paginate large result sets in batches of 10.
- Ask before loading more: "Showing 10 of 47. Load more?"
- Never silently truncate results - always disclose the total count.
Result Deduplication
When the same item appears in multiple searches (e.g., an issue you're both assigned to AND mentioned in):
- Show it once, with all context combined.
- In the Signal column, combine signals: "Assigned, @mentioned".
- In priority calculations, apply the highest-scoring signal, not additive.
Rate Limiting
- If rate-limited (403/429), tell the user the reset time in one sentence.
- Do not retry the same query - wait if reset is <60 seconds; otherwise report and move on.
- For multi-stream collection, skip rate-limited streams and complete them in a follow-up.