zhongwei/gh-schovi-claude-schovi-schovi
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial commit

Browse Source
This commit is contained in:
Zhongwei Li
2025-11-30 08:54:26 +08:00
commit 3562b3d6a4
27 changed files with 16593 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

362
skills/datadog-auto-detector/SKILL.md Normal file
View File

@@ -0,0 +1,362 @@
---
name: datadog-auto-detector
description: Automatically detects Datadog resource mentions (URLs, service queries, natural language) and intelligently fetches condensed context via datadog-analyzer subagent when needed for the conversation (plugin:schovi@schovi-workflows)
---
# Datadog Auto-Detector Skill
**Purpose**: Detect when user mentions Datadog resources and intelligently fetch relevant observability data.
**Architecture**: Three-tier pattern (Skill → Command → Subagent) for context isolation.
## Detection Patterns
### Pattern 1: Datadog URLs
Detect full Datadog URLs across all resource types:
**Logs**:
- `https://app.datadoghq.com/.../logs?query=...`
- `https://app.datadoghq.com/.../logs?...`
**APM / Traces**:
- `https://app.datadoghq.com/.../apm/traces?query=...`
- `https://app.datadoghq.com/.../apm/trace/[trace-id]`
- `https://app.datadoghq.com/.../apm/services/[service-name]`
**Metrics**:
- `https://app.datadoghq.com/.../metric/explorer?query=...`
- `https://app.datadoghq.com/.../metric/summary?metric=...`
**Dashboards**:
- `https://app.datadoghq.com/.../dashboard/[dashboard-id]`
**Monitors**:
- `https://app.datadoghq.com/.../monitors/[monitor-id]`
- `https://app.datadoghq.com/.../monitors?query=...`
**Incidents**:
- `https://app.datadoghq.com/.../incidents/[incident-id]`
- `https://app.datadoghq.com/.../incidents?...`
**Services**:
- `https://app.datadoghq.com/.../services/[service-name]`
**Events**:
- `https://app.datadoghq.com/.../event/stream?query=...`
**RUM**:
- `https://app.datadoghq.com/.../rum/...`
**Infrastructure/Hosts**:
- `https://app.datadoghq.com/.../infrastructure/...`
### Pattern 2: Natural Language Queries
Detect observability-related requests:
**Metrics Queries**:
- "error rate of [service]"
- "check metrics for [service]"
- "CPU usage of [service]"
- "latency of [service]"
- "throughput for [service]"
- "request rate"
- "response time"
**Log Queries**:
- "logs for [service]"
- "log errors in [service]"
- "show logs from [service]"
- "check [service] logs"
- "error logs"
**Trace Queries**:
- "traces for [service]"
- "trace [trace-id]"
- "slow requests in [service]"
- "APM data for [service]"
**Incident Queries**:
- "active incidents"
- "show incidents"
- "SEV-1 incidents"
- "current incidents for [team]"
**Monitor Queries**:
- "alerting monitors"
- "check monitors for [service]"
- "show triggered monitors"
**Service Queries**:
- "status of [service]"
- "health of [service]"
- "[service] dependencies"
### Pattern 3: Service Name References
Detect service names in context of observability:
- Common patterns: `pb-*`, `service-*`, microservice names
- Context keywords: "service", "application", "component", "backend", "frontend"
- Combined with observability verbs: "check", "show", "analyze", "investigate"
## Intelligence: When to Fetch
### ✅ DO Fetch When:
1. **Direct Request**: User explicitly asks for Datadog data
- "Can you check the error rate?"
- "Show me logs for pb-backend-web"
- "What's happening in Datadog?"
2. **Datadog URL Provided**: User shares Datadog link
- "Look at this: https://app.datadoghq.com/.../logs?..."
- "Here's the dashboard: [URL]"
3. **Investigation Context**: User is troubleshooting
- "I'm seeing errors in pb-backend-web, can you investigate?"
- "Something's wrong with the service, check Datadog"
4. **Proactive Analysis**: User asks for analysis that requires observability data
- "Analyze the performance of [service]"
- "Is there an outage?"
5. **Comparative Analysis**: User wants to compare or correlate
- "Compare error rates between services"
- "Check if logs match the incident"
### ❌ DON'T Fetch When:
1. **Past Tense Without URL**: User mentions resolved issues
- "I fixed the error rate yesterday"
- "The logs showed X" (without asking for current data)
2. **Already Fetched**: Datadog data already in conversation
- Check conversation history for recent Datadog summary
- Reuse existing data unless user requests refresh
3. **Informational Discussion**: User discussing concepts
- "Datadog is a monitoring tool"
- "We use Datadog for observability"
4. **Vague Reference**: Unclear what to fetch
- "Something in Datadog" (too vague)
- Ask for clarification instead
5. **Historical Context**: User providing background
- "Last week Datadog showed..."
- "According to Datadog docs..."
## Intent Classification
Before spawning subagent, classify the user's intent:
**Intent Type 1: Full Context** (default)
- User wants comprehensive analysis
- Fetch all relevant data for the resource
- Example: "Analyze error rate of pb-backend-web"
**Intent Type 2: Specific Query**
- User wants specific metric/log/trace
- Focus fetch on exact request
- Example: "Show me error logs for pb-backend-web in last hour"
**Intent Type 3: Quick Status Check**
- User wants high-level status
- Fetch summary data only
- Example: "Is pb-backend-web healthy?"
**Intent Type 4: Investigation**
- User is debugging an issue
- Fetch errors, incidents, traces
- Example: "Users report 500 errors, investigate pb-backend-web"
**Intent Type 5: Comparison**
- User wants to compare metrics/services
- Fetch data for multiple resources
- Example: "Compare error rates of pb-backend-web and pb-frontend"
## Workflow
### Step 1: Detect Mention
Scan user message for:
1. Datadog URLs (Pattern 1)
2. Natural language queries (Pattern 2)
3. Service names with observability context (Pattern 3)
If none detected, **do nothing**.
### Step 2: Check Conversation History
Before fetching, check if:
- Same resource already fetched in last 5 messages
- Recent Datadog summary covers this request
- User explicitly requests refresh ("latest data", "check again")
If already fetched and no refresh requested, **reuse existing data**.
### Step 3: Determine Intent
Analyze user message to classify intent (Full Context, Specific Query, Quick Status, Investigation, Comparison).
Extract:
- **Resource Type**: logs, metrics, traces, incidents, monitors, services, dashboards
- **Service Name**: If mentioned (e.g., "pb-backend-web")
- **Time Range**: If specified (e.g., "last hour", "today", "last 24h")
- **Filters**: Any additional filters (e.g., "status:error", "SEV-1")
### Step 4: Construct Subagent Prompt
Build prompt for `datadog-analyzer` subagent:
```
Fetch and summarize [resource type] for [context].
[If URL provided]:
Datadog URL: [url]
[If natural language query]:
Service: [service-name]
Query Type: [logs/metrics/traces/etc.]
Time Range: [from] to [to]
Additional Context: [user's request]
Intent: [classified intent]
Focus on: [specific aspects user cares about]
```
### Step 5: Spawn Subagent
Use Task tool with:
- **subagent_type**: `"schovi:datadog-auto-detector:datadog-analyzer"`
- **prompt**: Constructed prompt from Step 4
- **description**: Short description (e.g., "Fetching Datadog logs summary")
### Step 6: Present Summary
When subagent returns:
1. Present the summary to user
2. Offer to investigate further if issues found
3. Suggest related queries if relevant
## Examples
### Example 1: Datadog URL
**User**: "Look at this: https://app.datadoghq.com/.../logs?query=service:pb-backend-web%20status:error"
**Action**:
1. Detect: Datadog logs URL
2. Check: Not in recent conversation
3. Intent: Full Context (investigation)
4. Prompt: "Fetch and summarize logs from Datadog URL: [url]"
5. Spawn: datadog-analyzer subagent
6. Present: Summary of error logs
### Example 2: Natural Language Query
**User**: "Can you check the error rate of pb-backend-web service in the last hour?"
**Action**:
1. Detect: "error rate" + "pb-backend-web" + "last hour"
2. Check: Not in recent conversation
3. Intent: Specific Query (metrics)
4. Prompt: "Fetch and summarize metrics for error rate. Service: pb-backend-web, Time Range: last 1h"
5. Spawn: datadog-analyzer subagent
6. Present: Metrics summary with error rate trend
### Example 3: Investigation Context
**User**: "Users are reporting 500 errors on the checkout flow. Can you investigate?"
**Action**:
1. Detect: "500 errors" (observability issue)
2. Check: Not in recent conversation
3. Intent: Investigation
4. Prompt: "Investigate 500 errors in checkout flow. Query Type: logs and traces, Filters: status:500 OR status:error, Time Range: last 1h. Focus on: error patterns, affected endpoints, trace analysis"
5. Spawn: datadog-analyzer subagent
6. Present: Investigation summary with findings
### Example 4: Already Fetched
**User**: "Show me error rate for pb-backend-web"
[Datadog summary for pb-backend-web fetched 2 messages ago]
**Action**:
1. Detect: "error rate" + "pb-backend-web"
2. Check: Already fetched in message N-2
3. **Skip fetch**: "Based on the Datadog data fetched earlier, the error rate for pb-backend-web is [value]..."
### Example 5: Past Tense (No Fetch)
**User**: "Yesterday Datadog showed high error rates"
**Action**:
1. Detect: "Datadog" + "error rates"
2. Check: Past tense ("Yesterday", "showed")
3. **Skip fetch**: User is providing historical context, not requesting current data
### Example 6: Comparison
**User**: "Compare error rates of pb-backend-web and pb-frontend over the last 24 hours"
**Action**:
1. Detect: "error rates" + multiple services + "last 24 hours"
2. Check: Not in recent conversation
3. Intent: Comparison
4. Prompt: "Fetch and compare metrics for error rate. Services: pb-backend-web, pb-frontend. Time Range: last 24h. Focus on: comparative analysis, trends, spikes"
5. Spawn: datadog-analyzer subagent
6. Present: Comparative metrics summary
## Edge Cases
### Ambiguous Service Name
**User**: "Check the backend service error rate"
**Action**:
- Detect: "backend service" (ambiguous)
- Ask: "I can fetch error rate data from Datadog. Which specific service? (e.g., pb-backend-web, pb-backend-api)"
- Wait for clarification before spawning subagent
### URL Parsing Failure
**User**: Provides malformed or partial Datadog URL
**Action**:
- Detect: Datadog domain but unparseable
- Spawn: Subagent with URL and note parsing might fail
- Subagent will attempt to extract what it can or report error
### Multiple Resources in One Request
**User**: "Show me logs, metrics, and traces for pb-backend-web"
**Action**:
- Detect: Multiple resource types requested
- Intent: Full Context (investigation)
- Prompt: "Fetch comprehensive observability data for pb-backend-web: logs (errors), metrics (error rate, latency), traces (slow requests). Time Range: last 1h"
- Spawn: Single subagent call (let subagent handle multiple queries)
## Integration Notes
**Proactive Activation**: This skill should activate automatically when Datadog resources are mentioned.
**No User Prompt**: The skill should work silently - user doesn't need to explicitly invoke it.
**Commands Integration**: This skill can be used within commands like `/schovi:analyze` to fetch Datadog context automatically.
**Token Efficiency**: By using the subagent pattern, we reduce context pollution from 10k-50k tokens to ~800-1200 tokens.
## Quality Checklist
Before spawning subagent, verify:
- [ ] Clear detection of Datadog resource or query
- [ ] Not already fetched in recent conversation (unless refresh requested)
- [ ] Not past tense reference without current data request
- [ ] Intent classified correctly
- [ ] Prompt for subagent is clear and specific
- [ ] Fully qualified subagent name used: `schovi:datadog-auto-detector:datadog-analyzer`

751
skills/gh-pr-auto-detector/SKILL.md Normal file
View 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! 🚀

500
skills/jira-auto-detector/SKILL.md Normal file
View File

@@ -0,0 +1,500 @@
---
name: jira-auto-detector
description: Automatically detects Jira issue mentions (EC-1234, IS-8046, URLs) and intelligently fetches context via jira-analyzer subagent when needed for the conversation
---
# Jira Issue Auto-Detector Skill
You have access to a skill that seamlessly integrates Jira issue context into conversations without polluting the main context window.
## Mission
Enhance user conversations by:
1. **Detecting** Jira issue mentions in user messages
2. **Evaluating** whether issue context is genuinely needed
3. **Fetching** concise summaries via context-isolated subagent
4. **Integrating** information naturally into your response
## Pattern Recognition
### Detect these Jira patterns:
**Issue Keys:**
- Format: `[A-Z]{2,10}-\d{1,6}`
- Examples: EC-1234, IS-8046, PROJ-567
- Common in: "Look at EC-1234", "Implement IS-8046"
**URLs:**
- Format: `https://productboard.atlassian.net/browse/[KEY]`
- Example: "Check https://productboard.atlassian.net/browse/EC-1234"
**Multiple mentions:**
- "Compare EC-1234 and IS-8046"
- "Fixed in EC-1234, EC-1235, IS-8046"
## Intelligence: When to Fetch
### ✅ FETCH when user needs context:
**Direct questions:**
- "What is EC-1234 about?"
- "Tell me about IS-8046"
- "Explain PROJ-567"
**Analysis requests:**
- "Analyze EC-1234"
- "Investigate IS-8046"
- "Review PROJ-567"
**Implementation requests:**
- "Implement EC-1234"
- "Fix IS-8046"
- "Work on PROJ-567"
**Problem-solving:**
- "How should I approach EC-1234?"
- "What's the best solution for IS-8046?"
- "Help me with PROJ-567"
**Comparisons:**
- "Compare EC-1234 and IS-8046"
- "Which is more urgent, EC-1234 or PROJ-567?"
### ❌ DON'T FETCH when context not needed:
**Past tense (already done):**
- "I fixed EC-1234 yesterday"
- "EC-1234 was released last week"
- "Completed IS-8046 this morning"
**Passive listing:**
- "Released with EC-1234, EC-1235, IS-8046"
- "Sprint includes EC-1234 through EC-1240"
- "Changelog: EC-1234, EC-1235"
**Technical identifiers:**
- "The EC-1234 endpoint returns JSON"
- "Call the IS-8046 service"
- "Database table PROJ_567_users"
**Casual reference:**
- "Similar to EC-1234 but different"
- "Reminds me of IS-8046"
- "Like we did in PROJ-567"
**Already fetched this session:**
- Check transcript for previous jira-analyzer subagent calls
- Don't re-fetch same issue in same conversation
- Reuse previously fetched context
## How to Use This Skill
### Step 1: Scan User Message
Look for Jira patterns in the user's input:
- Scan for issue key format
- Check for Atlassian URLs
- Note all matches (can be multiple)
### Step 2: Evaluate Context Need
For each detected issue, ask yourself:
**Does the user's request require understanding this issue?**
- Will I need issue details to answer their question?
- Is this issue central to what they're asking?
- Are they asking me to work with this issue?
**Is this just a passing mention?**
- Is it in past tense?
- Is it part of a list?
- Is it used as an identifier/name?
**Have I already fetched this issue?**
- Check transcript for `Task` tool calls with "jira-analyzer"
- Look for "Jira Issue Summary: [KEY]" in conversation history
- If found, reuse that context
### Step 3: Fetch Issue Summary (If Needed)
When you determine context IS needed:
**First, acknowledge detection:**
```markdown
🎯 **[Jira Auto-Detector]** Detected issue reference: [ISSUE-KEY]
⏳ Fetching issue details...
```
**Use the Task tool to spawn jira-analyzer subagent:**
```
Tool: Task
Parameters:
prompt: "Fetch and summarize https://productboard.atlassian.net/browse/[ISSUE-KEY]"
subagent_type: "schovi:jira-auto-detector:jira-analyzer"
description: "Fetching Jira issue context"
```
**CRITICAL formatting rules:**
- Always use FULL URL format (not just "EC-1234")
- Format: `https://productboard.atlassian.net/browse/EC-1234`
- This ensures the subagent can parse the issue key correctly
**What you'll receive:**
The jira-analyzer subagent will return a structured summary (~800 tokens) with visual wrappers:
```markdown
╭─────────────────────────────────────╮
│ 🔍 JIRA ANALYZER │
╰─────────────────────────────────────╯
# Jira Issue Summary: EC-1234
## Core Information
- Issue: EC-1234 - Title
- Type: Bug | Story | Task
- Status: To Do | In Progress | Done
- Priority: High | Medium | Low
## Description
[Condensed description, max 500 chars]
## Acceptance Criteria
1. [Criterion 1]
2. [Criterion 2]
...
## Key Comments
- **Author**: [Summary]
...
## Technical Context
- Affected: [Components]
- Environment: [If specified]
...
```
### Step 4: Use the Summary
**After receiving the summary, acknowledge completion:**
```markdown
✅ **[Jira Auto-Detector]** Issue details fetched successfully
```
Integrate the summary information into your response:
**Acknowledge you fetched it:**
> "I've fetched EC-1234 details..."
> "Based on the Jira issue..."
> "Looking at EC-1234..."
**Use the context:**
- Answer questions based on description/criteria
- Plan implementation based on requirements
- Analyze problem based on technical context
- 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 5: Handle Multiple Issues
If user mentions multiple issues (e.g., "Compare EC-1234 and IS-8046"):
**Prioritize:**
1. Primary issue: The one most central to their question
2. Secondary issues: Only if needed for comparison/context
**Fetch sequentially:**
```
1. Spawn subagent for EC-1234
2. Wait for response
3. Spawn subagent for IS-8046
4. Wait for response
5. Use both summaries for comparison
```
**Limit:**
- Don't fetch more than 3 issues per response
- If user mentions 10 issues in a list, don't fetch all
- Ask user to clarify which they want details on
## Session Memory
**Track what you've fetched:**
When you fetch an issue, remember it for this session:
- Note the issue key
- Note the summary content
- Reuse this context if user mentions it again
**How to check:**
- Review conversation transcript
- Look for your previous Task tool calls
- Search for "Jira Issue Summary: [KEY]"
**Benefits:**
- Avoid redundant fetches
- Faster responses
- Cleaner context management
## Error Handling
### If subagent returns "Issue Not Found":
**Respond to user:**
> "I couldn't fetch EC-1234 - it might not exist or you may not have access. Can you verify the issue key?"
**Possible reasons:**
- Typo in issue key
- Issue doesn't exist
- User lacks permissions
- Wrong cloud ID
### If subagent returns API error:
**Respond to user:**
> "I encountered an error fetching EC-1234. Can you provide the key details about this issue?"
**Continue conversation:**
- Ask user for context manually
- Don't block on Jira fetch failure
- Use whatever information user provides
### If fetch times out:
**Respond to user:**
> "Fetching EC-1234 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 Jira summary when it arrives
## Integration with /analyze-problem Command
**If user explicitly runs `/analyze-problem EC-1234`:**
✅ **Let the command handle Jira fetching**
- The command has its own Jira fetch logic
- Don't duplicate effort
- Your skill doesn't need to activate
✅ **The command will:**
- Parse the issue key from arguments
- Delegate to jira-analyzer subagent
- Perform full problem analysis workflow
✅ **Your role:**
- Execute the command's instructions
- Don't interfere with its flow
- Trust the command's structured workflow
**If user casually mentions Jira in other contexts:**
✅ **Your skill activates**
- "What's EC-1234 about?" → You fetch it
- "How should I approach IS-8046?" → You fetch it
- "Compare EC-1234 to previous solution" → You fetch it
## Working with jira-analyzer Subagent
**Understand the architecture:**
```
You (Main Claude with Skill)
↓ detect Jira mention
↓ evaluate context need
↓ spawn subagent via Task tool
↓
jira-analyzer Subagent (Isolated Context)
↓ fetches 10k token Jira payload
↓ analyzes and extracts essence
↓ burns tokens privately
↓ returns 800-token summary
↓
You receive clean summary
↓ integrate into response
↓ main context stays clean!
```
**Your responsibilities:**
- **WHEN** to fetch (intelligence, context evaluation)
- **WHAT** to do with summary (integration into response)
**Subagent's responsibilities:**
- **HOW** to fetch (API calls, MCP tools)
- **WHAT** to extract (summarization, condensing)
**Separation of concerns = clean architecture**
## Examples
### Example 1: Direct Question
**User:** "What is EC-1234 about?"
**Your Process:**
1. ✅ Detect "EC-1234" pattern
2. ✅ Evaluate: Direct question → context needed
3. ✅ Check transcript: Not fetched yet
4. ✅ Spawn jira-analyzer subagent
5. ✅ Receive summary
6. ✅ Respond with information
**Your Response:**
> 🎯 **[Jira Auto-Detector]** Detected issue reference: EC-1234
> ⏳ Fetching issue details...
>
> [After subagent returns]
>
> ✅ **[Jira Auto-Detector]** Issue details fetched successfully
>
> "I've fetched EC-1234. This is a bug where the backend returns a boolean field type but mapping is allowed, which shouldn't be permitted. The issue is currently in To Do status with Medium priority. Based on the acceptance criteria, the fix needs to..."
### Example 2: Implementation Request
**User:** "Implement IS-8046"
**Your Process:**
1. ✅ Detect "IS-8046" pattern
2. ✅ Evaluate: Implementation request → context needed
3. ✅ Spawn jira-analyzer subagent
4. ✅ Receive summary with acceptance criteria
5. ✅ Use summary to plan implementation
6. ✅ Proceed with codebase analysis and implementation
**Your Response:**
> 🎯 **[Jira Auto-Detector]** Detected issue reference: IS-8046
> ⏳ Fetching issue details...
>
> [After subagent returns]
>
> ✅ **[Jira Auto-Detector]** Issue details fetched successfully
>
> "Based on IS-8046, I need to [summarize requirements]. Let me analyze the codebase to identify the affected components..."
### Example 3: Past Tense (Don't Fetch)
**User:** "I finished EC-1234 yesterday, now working on EC-1235"
**Your Process:**
1. ✅ Detect "EC-1234" and "EC-1235" patterns
2. ❌ Evaluate: Past tense (EC-1234) → don't fetch
3. ✅ Evaluate: Current work (EC-1235) → might need context
4. ❓ Check user intent: Are they asking for help with EC-1235?
**Your Response (if just informing):**
> "Great progress on EC-1234! What would you like help with regarding EC-1235?"
> [Don't fetch either issue yet - wait for user to ask specific question]
**Your Response (if asking for help):**
> "Great! Now for EC-1235, let me fetch the details..."
> [Fetch EC-1235 only]
### Example 4: Comparison Request
**User:** "Compare EC-1234 and IS-8046 approaches"
**Your Process:**
1. ✅ Detect both issues
2. ✅ Evaluate: Comparison request → context needed for both
3. ✅ Spawn subagent for EC-1234 first
4. ✅ Wait for summary
5. ✅ Spawn subagent for IS-8046
6. ✅ Wait for summary
7. ✅ Compare based on both summaries
**Your Response:**
> 🎯 **[Jira Auto-Detector]** Detected issue references: EC-1234, IS-8046
> ⏳ Fetching issue details...
>
> [After first subagent returns]
> ✅ EC-1234 fetched
> ⏳ Fetching IS-8046...
>
> [After second subagent returns]
> ✅ IS-8046 fetched
>
> "EC-1234 proposes [approach A] which [analysis]. IS-8046 suggests [approach B] which [analysis]. Key differences: [comparison]..."
### Example 5: Technical Identifier (Don't Fetch)
**User:** "The EC-1234 endpoint is returning 500 errors"
**Your Process:**
1. ✅ Detect "EC-1234" pattern
2. ❌ Evaluate: Used as endpoint name (technical identifier) → don't fetch
3. ✅ Respond about the endpoint issue
**Your Response:**
> "Let me help debug the EC-1234 endpoint. Can you share the error logs or stack trace?"
> [No Jira fetch - EC-1234 is just an endpoint name here]
### Example 6: Already Fetched (Reuse Context)
**User:** "Can you also check if EC-1234 affects the login flow?"
**Your Process:**
1. ✅ Detect "EC-1234" pattern
2. ✅ Evaluate: Question about issue → 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 EC-1234 details I fetched earlier, the issue is about boolean field type mapping. Looking at the login flow... [analysis]"
> [No redundant fetch - reused previous context]
## Quality Checks
### Before fetching any issue:
- [ ] Issue key matches valid format (A-Z)+-\d+)?
- [ ] User's question genuinely requires issue context
- [ ] Issue hasn't already been fetched this session
- [ ] Fetching will help (not hinder) the response
- [ ] User intent is clear (not ambiguous)
### After receiving subagent summary:
- [ ] Summary was successfully returned (not error)
- [ ] Summary contains relevant information
- [ ] You understand the issue 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
## Remember
**Your goal:** Seamlessly enhance conversations with Jira 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 issues are mentioned
- ✅ Be transparent: Let users know you fetched context
- ✅ Be efficient: Reuse context, don't fetch redundantly
**Trust the architecture:**
- **You decide WHEN** (intelligence layer)
- **jira-analyzer decides HOW** (execution layer)
- **User stays in flow** (seamless experience)
**Activation is automatic:**
- No special invocation needed
- Just be aware of Jira patterns
- Evaluate context intelligently
- Fetch when it genuinely helps
Good luck making Jira integration seamless! 🎯