GitHub PR Auto-Detector Skill

GitHub PR Auto-Detector Skill

You have access to a skill that seamlessly integrates GitHub Pull Request context into conversations without polluting the main context window with huge PR payloads.

Mission

Enhance user conversations by:

1. Detecting GitHub PR mentions in user messages
2. Evaluating whether PR context is genuinely needed
3. Classifying user intent to fetch reviews, CI, or full context
4. Fetching concise summaries via context-isolated subagent
5. Integrating information naturally into your response

Pattern Recognition

Detect these GitHub PR patterns:

Full GitHub URLs:

• Format: https://github.com/[owner]/[repo]/​pull/[number]
• Examples:
  • https://github.com/​anthropics/​claude-code/​pull/​123
  • https://github.com/​owner/​repo/​pull/​456
• Common in: "Review https://github.com/owner/repo/pull/123"

Short Form (owner/​repo#number):

• Format: [owner]/[repo]#\d+
• Examples: anthropics/​claude-code#123, owner/​repo#456
• Common in: "Check anthropics/​claude-code#123"

Hash-only (#number):

• Format: #\d+
• Examples: #123, #456
• Common in: "What's the status of #123?"
• CAVEAT: Requires repository context from conversation or working directory

Explicit Mentions:

• "PR #123", "pull request 123", "PR 456"
• "the pull request #123"
• "review PR #456"

Multiple PRs:

• "Compare #123 and #456"
• "Review PRs #123, #124, #125"
• "Merged in anthropics/​claude-code#123 and owner/​repo#456"

Intelligence: When to Fetch

✅ FETCH when user needs context:

Direct questions:

• "What is #123 about?"
• "Tell me about anthropics/​claude-code#456"
• "What's in https://github.com/owner/repo/pull/789?"
• "Summarize PR #123"

Review requests:

• "Review #123"
• "Check the code in PR #456"
• "What do you think about anthropics/​claude-code#123?"
• "Analyze this PR: [URL]"

Status checks:

• "What's the CI status of #123?"
• "Did the tests pass on #456?"
• "Are there any review comments on #123?"
• "Is #456 approved?"

Implementation requests:

• "Apply the changes from #123"
• "Use the approach from anthropics/​claude-code#456"
• "Implement similar to #123"
• "Port #456 to our codebase"

Problem-solving:

• "Why did #123 fail CI?"
• "What are the review blockers on #456?"
• "How should I address feedback on #123?"

Comparisons:

• "Compare #123 and #456 approaches"
• "Which is better, #123 or anthropics/​claude-code#789?"

❌ DON'T FETCH when context not needed:

Past tense (already done):

• "I merged #123 yesterday"
• "PR #456 was released last week"
• "Closed #123 this morning"
• "Fixed in #456"

Passive listing:

• "Released with #123, #124, #125"
• "Changelog: #123, #456, #789"
• "Sprint delivered #100 through #150"

Technical identifiers:

• "The PR-123 endpoint" (endpoint name, not PR reference)
• "Variable pr_456_result"
• "Function handlePR123()"

Casual reference:

• "Similar to #123 but different"
• "Reminds me of that PR #456"
• "Like we did in #123"

Already fetched this session:

• Check transcript for previous gh-pr-analyzer subagent calls
• Don't re-fetch same PR in same conversation
• Reuse previously fetched context

Intent Classification: What to Fetch

Based on user's question, determine which PR aspects to fetch:

🔍 Full Context (default)

• User asks general questions: "What's #123 about?"
• Wants comprehensive review: "Review #456"
• Implementation planning: "Implement similar to #123"
• Options: include_reviews: true, include_ci: true

💬 Reviews Focus

• User asks specifically about feedback: "What are the review comments on #123?"
• Wants approval status: "Is #456 approved?"
• Addressing feedback: "How should I address review on #123?"
• Options: include_reviews: true, include_ci: false

✅ CI/​Checks Focus

• User asks about tests/​CI: "Did tests pass on #123?"
• CI failures: "Why did #456 fail CI?"
• Check status: "What's the CI status of #123?"
• Options: include_reviews: false, include_ci: true

📄 Minimal Context (rare)

• User only needs basic info: "Who authored #123?"
• Quick status check: "Is #456 merged?"
• Options: include_reviews: false, include_ci: false

How to Use This Skill

Step 1: Scan User Message

Look for GitHub PR patterns:

• Scan for full GitHub URLs
• Check for owner/​repo#number format
• Look for #number references
• Note explicit mentions ("PR #123")
• Identify all matches (can be multiple)

Step 2: Extract Repository Context

For full URLs:

• Parse owner and repo from URL
• Extract PR number
• Format: owner/​repo#number

For owner/​repo#number:

• Already has full context
• Use as-is

For #number only:

• Check conversation for repo context
• Check working directory (via git remote)
• If missing, ask user to clarify repository

Step 3: Evaluate Context Need

For each detected PR, ask yourself:

Does the user's request require understanding this PR?

• Will I need PR details to answer their question?
• Is this PR central to what they're asking?
• Are they asking me to work with this PR?

Is this just a passing mention?

• Is it in past tense (already merged/​closed)?
• Is it part of a list?
• Is it used as an identifier/​name?

Have I already fetched this PR?

• Check transcript for Task tool calls with "gh-pr-analyzer"
• Look for "GitHub PR Summary: owner/​repo#123" in conversation history
• If found, reuse that context

Step 4: Classify User Intent

Determine what aspects the user needs:

Full context signals:

• General questions ("What's #123 about?")
• Implementation ("Apply changes from #123")
• Comprehensive review ("Review #456")

Reviews focus signals:

• "review comments", "feedback", "approval"
• "What did reviewers say?"
• "Address review on #123"

CI focus signals:

• "CI", "tests", "checks", "build", "failed"
• "Did tests pass?"
• "Why did CI fail?"

Default: When unclear, fetch full context (reviews + CI)

Step 5: Fetch PR Summary (If Needed)

When you determine context IS needed:

First, acknowledge detection:

📋 **[PR Auto-Detector]** Detected PR reference: [owner/​repo#number or #number]
⏳ Fetching PR details...

Use the Task tool to spawn gh-pr-analyzer subagent:

Tool: Task
Parameters:
  prompt: "Fetch and summarize GitHub PR: [owner/​repo#number or URL]
           Options: include_reviews=[true/​false], include_ci=[true/​false]"
  subagent_type: "schovi:gh-pr-auto-detector:gh-pr-analyzer"
  description: "Fetching GitHub PR context"

Examples:

Full context (default):

prompt: "Fetch and summarize GitHub PR: anthropics/​claude-code#123"

Reviews only:

prompt: "Fetch and summarize GitHub PR: anthropics/​claude-code#123
         Options: include_reviews=true, include_ci=false"

CI only:

prompt: "Fetch and summarize GitHub PR: https://github.com/​owner/​repo/​pull/​456
         Options: include_reviews=false, include_ci=true"

CRITICAL formatting rules:

• Use full identifier format: owner/​repo#number OR full URL
• Specify options explicitly when not default
• Format must be parseable by gh-pr-analyzer subagent

What you'll receive:

The gh-pr-analyzer subagent will return a structured summary (~800-1000 tokens) with visual wrappers:

╭─────────────────────────────────────╮
│ 🔗 PR ANALYZER                      │
╰─────────────────────────────────────╯

# GitHub PR Summary: owner/​repo#123

## Core Information
- PR: #123 - Title
- Author: username
- Status: open | merged | closed
- Base: main ← Head: feature-branch
- URL: https://github.com/​owner/​repo/​pull/​123

## Description
[Condensed description, max 500 chars]

## Code Changes
- Files changed: 15 (+250, -100)
- Key files: [Top 5 files by changes]

## CI/​CD Status (if requested)
- Overall: ✅ passing | ❌ failing | ⏳ pending
- Failed checks: [Details if any]

## Reviews (if requested)
- Review decision: APPROVED | CHANGES_REQUESTED | PENDING
- Latest reviews: [Max 3 most recent]
- Key comments: [Max 5 significant comments]

## Analysis Notes
[Subagent's assessment]

Step 6: Use the Summary

After receiving the summary, acknowledge completion:

✅ **[PR Auto-Detector]** PR details fetched successfully

Integrate the summary information into your response:

Acknowledge you fetched it:

"I've fetched PR #123 details..." "Based on the pull request..." "Looking at anthropics/​claude-code#123..."

Use the context:

• Answer questions based on description/​changes
• Assess CI status and diagnose failures
• Summarize review feedback and approval state
• Analyze code changes based on diff summary
• Reference key comments if relevant

Stay concise:

• Don't regurgitate entire summary
• Extract relevant points for this response
• Focus on what user asked about

Step 7: Handle Multiple PRs

If user mentions multiple PRs (e.g., "Compare #123 and #456"):

Prioritize:

1. Primary PR: The one most central to their question
2. Secondary PRs: Only if needed for comparison/​context

Fetch sequentially:

1. Spawn subagent for #123
2. Wait for response
3. Spawn subagent for #456
4. Wait for response
5. Use both summaries for comparison

Limit:

• Don't fetch more than 3 PRs per response
• If user mentions 10 PRs in a list, don't fetch all
• Ask user to clarify which they want details on

Repository Context Detection

When #number is mentioned without owner/​repo:

Step 1: Check conversation history

• Look for previous PR mentions with full context
• See if user specified repository earlier
• Check for git remote context from previous commands

Step 2: Check current working directory

• If cwd is a git repository, use git remote get-url origin
• Parse owner/​repo from remote URL
• Format: owner/​repo#number

Step 3: Ask user if context unclear

"I see you mentioned #123. Which repository is this PR in? (e.g., owner/​repo#123)"

Example flow:

User: "What's #123 about?"

Your process:

1. ✅ Detect "#123" pattern
2. ❓ Missing owner/​repo context
3. ✅ Check cwd: /​Users/​schovi/​productboard/​frontend
4. ✅ Run: git remote get-url origin
5. ✅ Parse: https://github.com/​productboard/​frontend.git → productboard/​frontend
6. ✅ Format: productboard/​frontend#123
7. ✅ Spawn gh-pr-analyzer with full identifier

Session Memory

Track what you've fetched:

When you fetch a PR, remember it for this session:

• Note the PR identifier (owner/​repo#number)
• Note the summary content
• Note what options were used (reviews/​CI)
• Reuse this context if user mentions it again

How to check:

• Review conversation transcript
• Look for your previous Task tool calls
• Search for "GitHub PR Summary: owner/​repo#"

Benefits:

• Avoid redundant fetches
• Faster responses
• Cleaner context management

Re-fetch scenarios: When to fetch again even if already fetched:

• User asks for different aspects (was minimal, now wants reviews)
• User explicitly requests fresh data ("re-check CI on #123")
• Significant time has passed (CI might have updated)

Error Handling

If subagent returns "PR Not Found":

Respond to user:

"I couldn't fetch #123 - it might not exist or you may not have access. Can you verify the PR number and repository?"

Possible reasons:

• Typo in PR number
• Wrong repository
• PR doesn't exist
• User lacks permissions
• Private repository

If subagent returns "Repository context missing":

Respond to user:

"You mentioned #123, but I need the repository. Please specify as owner/​repo#123 or provide a full GitHub URL."

Your action:

• Ask for clarification
• Don't assume repository
• Wait for user to provide context

If subagent returns API error:

Respond to user:

"I encountered an error fetching the PR. Can you provide the key details about this pull request?"

Continue conversation:

• Ask user for context manually
• Don't block on PR fetch failure
• Use whatever information user provides

If gh CLI not authenticated:

Respond to user:

"GitHub CLI (gh) is not authenticated. Please run gh auth login to enable PR fetching."

Fallback:

• Ask user to provide PR details manually
• Suggest authentication command
• Continue with available information

If fetch times out:

Respond to user:

"Fetching PR #123 is taking longer than expected. While that completes, can you tell me what specific aspect you need help with?"

Proceed in parallel:

• Ask clarifying questions
• Start analysis with available context
• Incorporate PR summary when it arrives

Integration with Commands

If user explicitly runs a command that fetches PRs:

✅ Let the command handle PR fetching

• Commands may have their own PR fetch logic
• Don't duplicate effort
• Your skill doesn't need to activate

✅ The command will:

• Parse PR identifiers from arguments
• Delegate to gh-pr-analyzer subagent
• Perform its specific workflow

✅ Your role:

• Execute the command's instructions
• Don't interfere with its flow
• Trust the command's structured workflow

If user casually mentions PRs in other contexts:

✅ Your skill activates

• "What's #123 about?" → You fetch it
• "Review anthropics/​claude-code#456" → You fetch it
• "Why did #123 fail CI?" → You fetch it (CI focus)

Working with gh-pr-analyzer Subagent

Understand the architecture:

You (Main Claude with Skill)
  ↓ detect PR mention
  ↓ evaluate context need
  ↓ classify intent (reviews/​CI/​full)
  ↓ determine repository context
  ↓ spawn subagent via Task tool
  ↓
gh-pr-analyzer Subagent (Isolated Context)
  ↓ fetches huge PR payload via gh CLI
  ↓ analyzes and extracts essence
  ↓ burns tokens privately
  ↓ returns 800-1000 token summary
  ↓
You receive clean summary
  ↓ integrate into response
  ↓ main context stays clean!

Your responsibilities:

• WHEN to fetch (intelligence, context evaluation)
• WHAT to fetch (reviews, CI, full context)
• WHAT to do with summary (integration into response)

gh-pr-analyzer subagent's responsibilities:

• HOW to fetch (gh CLI commands, parsing)
• WHAT to extract (summarization, condensing)

Separation of concerns = clean architecture

Examples

Example 1: Direct Question (Full Context)

User: "What is anthropics/​claude-code#123 about?"

Your Process:

1. ✅ Detect "anthropics/​claude-code#123" pattern
2. ✅ Extract: owner=anthropics, repo=claude-code, number=123
3. ✅ Evaluate: Direct question → context needed
4. ✅ Classify: General question → full context (default)
5. ✅ Check transcript: Not fetched yet
6. ✅ Spawn gh-pr-analyzer subagent with full context
7. ✅ Receive summary
8. ✅ Respond with information

Your Response:

📋 [PR Auto-Detector] Detected PR reference: anthropics/​claude-code#123 ⏳ Fetching PR details...

[After subagent returns]

✅ [PR Auto-Detector] PR details fetched successfully

"I've fetched anthropics/​claude-code#123. This PR adds support for MCP servers in Claude Code. The PR includes 15 file changes (+250, -100 lines), primarily in the server integration layer. The CI is passing and the PR has been approved by 2 reviewers. Based on the description..."

Example 2: CI Status Check

User: "Did the tests pass on #456?"

Your Process:

1. ✅ Detect "#456" pattern
2. ❓ Missing owner/​repo → check cwd
3. ✅ Get git remote → productboard/​frontend
4. ✅ Format: productboard/​frontend#456
5. ✅ Evaluate: CI question → context needed
6. ✅ Classify: CI focus → include_reviews=false, include_ci=true
7. ✅ Spawn gh-pr-analyzer with CI focus
8. ✅ Receive CI summary
9. ✅ Respond about CI status

Your Response:

📋 [PR Auto-Detector] Detected PR reference: #456 ⏳ Resolving repository context and fetching CI status...

[After subagent returns]

✅ [PR Auto-Detector] CI status fetched successfully

"I've checked the CI status for productboard/​frontend#456. The build is currently failing - the 'test-suite' check failed with 3 test errors in the authentication module. The linter and type checks passed successfully. Here are the failing tests..."

Example 3: Review Request

User: "Review https://github.com/owner/repo/pull/789"

Your Process:

1. ✅ Detect full GitHub URL
2. ✅ Parse: owner=owner, repo=repo, number=789
3. ✅ Evaluate: Review request → context needed
4. ✅ Classify: Review request → full context (reviews + CI + code)
5. ✅ Spawn gh-pr-analyzer with full context
6. ✅ Receive comprehensive summary
7. ✅ Analyze and provide review feedback

Your Response:

📋 [PR Auto-Detector] Detected PR reference: https://github.com/owner/repo/pull/789 ⏳ Fetching full PR context for review...

[After subagent returns]

✅ [PR Auto-Detector] PR details fetched successfully

"I've reviewed owner/​repo#789. This PR refactors the authentication flow to use JWT tokens. Here's my analysis:

Code Changes: The PR modifies 8 files, primarily in the auth/ directory. The changes look well-structured and include comprehensive tests.

CI Status: All checks are passing ✅

Existing Reviews: One reviewer requested changes regarding error handling in the token refresh logic. I agree with that feedback.

Additional Observations: [detailed review feedback]..."

Example 4: Past Tense (Don't Fetch)

User: "I merged #123 yesterday, now working on #124"

Your Process:

1. ✅ Detect "#123" and "#124" patterns
2. ❌ Evaluate: Past tense (#123) → don't fetch
3. ✅ Evaluate: Current work (#124) → might need context
4. ❓ Check user intent: Are they asking for help with #124?

Your Response (if just informing):

"Great progress on #123! What would you like help with regarding #124?" [Don't fetch either PR yet - wait for user to ask specific question]

Your Response (if asking for help):

"Great! Now for #124, let me fetch the details..." [Fetch #124 only, with appropriate focus]

Example 5: Comparison Request

User: "Compare the approaches in #123 and anthropics/​claude-code#456"

Your Process:

1. ✅ Detect both PRs
2. ❓ #123 missing context → check cwd → productboard/​frontend
3. ✅ Format: productboard/​frontend#123 and anthropics/​claude-code#456
4. ✅ Evaluate: Comparison request → context needed for both
5. ✅ Classify: Approach comparison → full context
6. ✅ Spawn subagent for productboard/​frontend#123 first
7. ✅ Wait for summary
8. ✅ Spawn subagent for anthropics/​claude-code#456
9. ✅ Wait for summary
10. ✅ Compare based on both summaries

Your Response:

📋 [PR Auto-Detector] Detected PR references: #123, anthropics/​claude-code#456 ⏳ Fetching both PRs for comparison...

[After first subagent returns] ✅ productboard/​frontend#123 fetched ⏳ Fetching anthropics/​claude-code#456...

[After second subagent returns] ✅ anthropics/​claude-code#456 fetched

"productboard/​frontend#123 implements authentication using session cookies, while anthropics/​claude-code#456 uses JWT tokens. Key differences:

#123 (session cookies):

• Pros: [analysis]
• Cons: [analysis]

anthropics/​claude-code#456 (JWT):

• Pros: [analysis]
• Cons: [analysis]

For your use case, I'd recommend [recommendation with rationale]..."

Example 6: Technical Identifier (Don't Fetch)

User: "The PR-123 endpoint is returning 500 errors"

Your Process:

1. ✅ Detect "PR-123" pattern (looks like PR reference)
2. ❌ Evaluate: Used as endpoint name (technical identifier) → don't fetch
3. ✅ Respond about the endpoint issue

Your Response:

"Let me help debug the PR-123 endpoint. Can you share the error logs or stack trace?" [No PR fetch - "PR-123" is just an endpoint name here]

Example 7: Already Fetched (Reuse Context)

User (earlier): "Review #123" You: [Fetched anthropics/​claude-code#123, provided review]

User (later): "Can you also check if #123 affects the authentication flow?"

Your Process:

1. ✅ Detect "#123" pattern
2. ✅ Evaluate: Question about PR → context needed
3. ✅ Check transcript: Already fetched earlier in this conversation
4. ✅ Reuse previous summary from transcript
5. ✅ Answer based on already-known context

Your Response:

"Based on the #123 PR I reviewed earlier (adds MCP server support), let me analyze how it interacts with the authentication flow... [analysis based on previously fetched context]" [No redundant fetch - reused previous context]

Example 8: Missing Repository Context

User: "What's #123 about?"

Your Process (no git context available):

1. ✅ Detect "#123" pattern
2. ❓ Missing owner/​repo → check cwd → not a git repo
3. ❓ Check conversation → no previous repo mentions
4. ❌ Cannot determine repository
5. ✅ Ask user for clarification

Your Response:

"You mentioned #123 - which repository is this PR in? Please specify as owner/​repo#123 or provide the full GitHub URL." [Wait for user to clarify before fetching]

Quality Checks

Before fetching any PR:

• PR identifier matches valid format
• Repository context is clear (owner/​repo known)
• User's question genuinely requires PR context
• PR hasn't already been fetched this session (or needs refresh)
• Fetching will help (not hinder) the response
• User intent is clear (not ambiguous)
• Correct options selected (reviews/​CI/​full)

After receiving subagent summary:

• Summary was successfully returned (not error)
• Summary contains relevant information
• You understand the PR context
• You can now provide informed response
• You're ready to proceed

In your response:

• Acknowledged you fetched context
• Used summary information appropriately
• Didn't regurgitate entire summary
• Focused on user's specific question
• Response is actionable and helpful
• Integrated GitHub context naturally

Remember

Your goal: Seamlessly enhance conversations with GitHub PR context when needed.

Balance:

• ✅ Be proactive: Fetch when context genuinely helps
• ✅ Be respectful: Don't over-fetch or slow conversations
• ✅ Be intelligent: Understand nuance in how PRs are mentioned
• ✅ Be context-aware: Detect repository from environment
• ✅ Be specific: Fetch only what user needs (reviews/​CI/​full)
• ✅ Be transparent: Let users know you fetched context
• ✅ Be efficient: Reuse context, don't fetch redundantly

Trust the architecture:

• You decide WHEN (intelligence layer)
• You decide WHAT (intent classification)
• gh-pr-analyzer decides HOW (execution layer)
• User stays in flow (seamless experience)

Activation is automatic:

• No special invocation needed
• Just be aware of GitHub PR patterns
• Evaluate context intelligently
• Classify user intent appropriately
• Fetch when it genuinely helps

Good luck making GitHub PR integration seamless! 🚀