Initial commit
This commit is contained in:
751
skills/gh-pr-auto-detector/SKILL.md
Normal file
751
skills/gh-pr-auto-detector/SKILL.md
Normal file
@@ -0,0 +1,751 @@
|
||||
---
|
||||
name: gh-pr-auto-detector
|
||||
description: Automatically detects GitHub PR mentions (URLs, #123, owner/repo#123) and intelligently fetches condensed context via gh-pr-analyzer subagent when needed for the conversation
|
||||
---
|
||||
|
||||
# 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:**
|
||||
```markdown
|
||||
📋 **[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:
|
||||
|
||||
```markdown
|
||||
╭─────────────────────────────────────╮
|
||||
│ 🔗 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:**
|
||||
```markdown
|
||||
✅ **[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! 🚀
|
||||
Reference in New Issue
Block a user