If It Moved
You’ll Know

Issue Metadata

Fetch state, labels, comment count, timestamps:

gh api repos/OWNER/REPO/issues/NUMBER --jq '{state: .state, labels: [.labels[].name], comments: .comments, updated: .updated_at, created: .created_at}'

Issue Comments

Last 3 comments with author, date, full body:

gh api repos/OWNER/REPO/issues/NUMBER/comments --jq '.[-3:] | .[] | {author: .user.login, date: (.created_at | split("T")[0]), body: .body}'

All comments (for drafting — verify claims before posting):

gh api repos/OWNER/REPO/issues/NUMBER/comments --jq '.[] | {author: .user.login, date: .created_at, body: .body}'

Comments since a date:

gh api repos/OWNER/REPO/issues/NUMBER/comments --jq '[.[] | select(.created_at > "DATE")] | .[] | {author: .user.login, date: (.created_at | split("T")[0]), body: .body}'

Truncation rules: Never truncate comments on the primary issue being reviewed — technical

details (addresses, error codes, test counts) get lost. For secondary fetches (known

duplicates, upstream), [0:1500] is acceptable to manage context size.

Issue Body

Full issue body (read before commenting on unfamiliar issues):

gh api repos/OWNER/REPO/issues/NUMBER --jq '.body'

Search: Issues Involving User

Open issues with recent activity:

gh api "search/issues?q=involves:USERNAME+updated:>DATE+is:open" --jq '.items[] | "#\(.number) \(.repository_url | split("/") | .[-2:] | join("/")) — \(.title) [updated: \(.updated_at)]"'

Search: Issues by Author

gh api "search/issues?q=author:USERNAME+is:open&per_page=100&sort=updated" --jq '.items[] | "#\(.number) \(.repository_url | split("/") | .[-2:] | join("/")) — \(.title) [updated: \(.updated_at | split("T")[0])]"'

Search: Issues by Commenter (excluding authored)

gh api "search/issues?q=commenter:USERNAME+is:open+-author:USERNAME&per_page=100&sort=updated" --jq '.items[] | "#\(.number) \(.repository_url | split("/") | .[-2:] | join("/")) — \(.title) [updated: \(.updated_at | split("T")[0])]"'

Search: Keyword Search for Duplicates

Search for issues matching keywords, created after a specific date:

gh api "search/issues?q=repo:OWNER/REPO+is:open+created:>DATE+KEYWORD1+KEYWORD2&per_page=10" --jq '.items[] | "#\(.number) — \(.title) [\(.created_at | split("T")[0])] @\(.user.login)"'

Use multiple keyword variations per search to catch different phrasings. Example for an OAuth issue:

• —Search 1: OAuth redirect MCP
• —Search 2: clientId mcp add
• —Search 3: Slack plugin authentication

Search: Recently Closed Issues

gh api "search/issues?q=involves:USERNAME+is:closed+closed:>DATE&per_page=50&sort=updated" --jq '.items[] | "#\(.number) \(.repository_url | split("/") | .[-2:] | join("/")) — \(.title) [closed: \(.closed_at | split("T")[0])]"'

Post Comment

gh issue comment NUMBER --repo OWNER/REPO --body "$(cat <<'EOF'
Comment body here.
Supports **markdown**.
EOF
)"

Always use heredoc (<<'EOF') for comment bodies to handle special characters and newlines.

Quick State Check

Check if an issue is still open (fast, minimal data):

gh api repos/OWNER/REPO/issues/NUMBER --jq '.state'

PR Status Check

gh api repos/OWNER/REPO/pulls/NUMBER --jq '{state: .state, merged: .merged, title: .title, updated: .updated_at}'

PR Health (run when the tracked item is a PR)

Merge-readiness, review decision, and CI status in one call:

gh pr view NUMBER --repo OWNER/REPO \
  --json state,mergeStateStatus,mergeable,reviewDecision,statusCheckRollup,reviews

gh pr view --json resolves reviewDecision and statusCheckRollup via GraphQL under the

hood — the REST issues endpoint cannot. Use this template (not the issues endpoint) whenever

you need merge/CI/review state.

Reading the result:

• —mergeStateStatus — DIRTY means merge conflict; BLOCKED means a required check or review

is failing/missing; CLEAN/UNSTABLE means mergeable (UNSTABLE = non-required checks failing).

• —mergeable — CONFLICTING confirms a conflict; MERGEABLE is clean; UNKNOWN means GitHub

is still computing it.

• —reviewDecision — APPROVED, CHANGES_REQUESTED, or REVIEW_REQUIRED.
• —statusCheckRollup — array of checks; surface any with conclusion of FAILURE/TIMED_OUT/CANCELLED.

Review interpretation (do not misread):

• —A review with state: COMMENTED is not an approval. Only state: APPROVED counts.
• —Reviewers whose login ends in [bot] do not satisfy a human-review requirement — record

them separately from human reviews.

Rate Limiting

GitHub API has rate limits. If running many parallel requests:

• —Authenticated requests: 5000/hour
• —Search API: 30 requests/minute
• —If you hit limits, batch searches and add short delays between search batches
• —Metadata fetches (repos/OWNER/REPO/issues/NUMBER) don't count against search limits

Parallel Execution Strategy

To maximize speed, batch API calls by type:

Batch 1 (parallel): All active issue metadata + comments (these are REST calls, not search)

Batch 2 (parallel): All known duplicate/related issue checks (REST calls)

Batch 3 (parallel): All keyword searches for new duplicates (search API — respect 30/min limit)

Batch 4 (parallel): User involvement search + closed issue checks + upstream checks

Batches 1 and 2 can run simultaneously. Batch 3 should start after a brief pause if Batch 1+2 included many calls. Batch 4 can run with Batch 1.