| name | issue-analyzing |
| version | 1.0.1 |
| description | Use this skill when the user asks to analyze a specific GitHub issue, understand what area of code an issue affects, assess an issue's scope, or research the code context around an issue — example triggers like "analyze issue |
Issue Analyzing
Analyze a GitHub issue by combining authoritative issue data from GitHub with semantic code research from ChunkHound. Produces a structured analysis of problem scope, affected code area, and resolution status.
Do not activate for generic code questions that do not reference a specific issue.
Prerequisites
Requires the chunkhound-integration companion plugin. The skill calls mcp__plugin_chunkhound-integration_ChunkHound__code_research at Step 3 and stops with an error if that tool is not callable — see Errors.
Issue data is fetched from GitHub using whatever access the session has available (a GitHub MCP server, the gh CLI, or direct API calls).
Input
- Required: Issue number
- Optional: Repository as
owner/name — defaults to the current repository context
- Optional: Triage reasoning — context from the caller about why analysis was requested. Treat as a hint for research focus.
Workflow
Step 1 — Fetch issue data
Fetch the following from GitHub: issue metadata (title, body, author, labels, state) and all comments.
Use whatever GitHub access is available in the session. If a single call returns everything together, that's fine; if comments are returned separately, fetch them as part of this step. On error (issue not found, access denied, no GitHub access), stop and report to the user.
Step 2 — Identify the affected code area
From the issue description and comments, extract signals about what part of the codebase is affected:
- File paths or component names mentioned directly in the description
- Class or function names referenced in the text (often in backticks or stack traces)
- Error messages that can be traced back to specific components
- Area labels (e.g.,
area/checkout, area/admin) that indicate scope
- Linked PRs referenced as fixes — comments often contain "Fixed in #X" or "See PR #Y"
If the issue is a feature request, the "affected area" is the area that would need to change to implement it. If the body is too vague to identify a specific area, note this in the output and research at the area label's level instead.
Step 3 — Research the affected area
Use mcp__plugin_chunkhound-integration_ChunkHound__code_research with an incremental strategy — the same pattern as pr-analyzing, adapted for issues.
Stage 1 — Locate components. Run focused code_research queries to locate the components or areas referenced in the issue. Goal: find the concrete code that maps to the issue's problem space.
Examples:
- "What does the cart calculation logic do and where is it implemented?"
- "How is
LineItemCollection structured and used?"
Stage 2 — Understand the area. Based on Stage 1 findings, ask targeted questions about how the affected components work and what depends on them.
Examples:
- "What components depend on cart calculation? What invariants does it assume?"
- "How does the checkout flow handle empty line items currently?"
Stage 3 — Deep dive (optional). If Stage 2 reveals cross-component effects or unexpected complexity, run a follow-up query.
Example:
- "What happens throughout the order lifecycle when a cart contains zero-quantity line items?"
Budget. Issues differ from PRs: there is no diff to anchor on. Stage 1 (locating the affected code) is more important for issues than for PRs — if the description is vague, the skill must work harder to identify what to research. When an issue description is extremely thin (one sentence, no specifics), prefer to stop after Stage 1 and state what could not be determined rather than running expensive research that produces low-value output.
Track which stages ran.
Step 4 — Produce output
Return the analysis as structured text in the conversation, following Output Structure below.
Output Structure
Return these sections in order:
Summary — one-line description of what the issue is about.
Affected code area — which parts of the codebase the issue touches. Derive from direct references in the description, area labels, and Stage 1 research findings.
Code context — how the affected area works, based on ChunkHound research. Describe the component's role, its invariants, and its dependencies. This grounds the issue in architectural reality.
Scope assessment — is the problem localized or cross-cutting? Does fixing it require changes in multiple components?
Resolution status — resolved, in progress, or open? If linked PRs were referenced in comments, name them. If a fix is merged, summarize it in one line.
Key findings — specific observations from research worth calling out (e.g., unexpected consumers of the affected code, invariants the issue might violate, related components at risk).
Research method — brief note on which stages ran.
Errors
GitHub data unavailable. If issue data cannot be fetched at Step 1 — no GitHub access is configured, the issue is not found, or access is denied — stop and report the error to the user. Do not attempt analysis without issue data.
chunkhound-integration unavailable. If mcp__plugin_chunkhound-integration_ChunkHound__code_research is not callable at Step 3, stop and report to the user that the skill requires chunkhound-integration for code research. Do not produce partial analysis from GitHub data alone — code context is the substance of issue analysis, and keyword-only output would look like a complete result but silently omit the most valuable section.
