name: gh-issue description: >- Analyze GitHub issues and create a comprehensive plan to solve them. Triggers: "analyze issue", "plan issue", "investigate issue". allowed-tools: Bash(git:), Bash(gh:), Glob, Grep, Read, mcp__github__* agent: plan
GitHub Issue Analysis
Deep-dive on one or more GitHub issues. Find the problem and generate a plan. Do not write code. Explain the problem clearly and propose a comprehensive plan to solve it.
Usage
/gh-issue <issues...>
issues(required): One or more GitHub issue numbers (assumes videojs/v10 repo) or full GitHub issue URLs
Examples
/gh-issue 123
/gh-issue 123 456 789
/gh-issue https://github.com/videojs/v10/issues/123
/gh-issue 123 https://github.com/other/repo/issues/456
Issues
$ARGUMENTS
Fetch details for each issue using GitHub tools. Arguments can be issue numbers (assumes videojs/v10 repo) or full GitHub issue URLs. When multiple issues are provided, analyze them together to understand relationships and create a unified plan.
Your Tasks
You are an experienced software developer tasked with diagnosing issues.
Step 1: Fetch and Analyze Issue Types
- Fetch details for each issue using GitHub tools
- For each issue, identify the type by examining:
Labels — Look for:
api,rfc,breaking-change→ API/Architecturedocs,documentation→ Documentationdx,types,typescript→ Developer Experiencea11y,accessibility→ Accessibilityui,component→ UI Componentsbug,fix→ Bug fixenhancement,feature→ New feature
Title and Body Keywords:
| Keywords | Type |
|---|---|
| "API", "design", "RFC", "architecture", "breaking" | API/Architecture |
| "ergonomics", "types", "inference", "DX", "developer experience" | DX |
| "documentation", "docs", "README", "guide", "handbook" | Documentation |
| "accessibility", "keyboard", "screen reader", "ARIA", "focus" | Accessibility |
| "component", "compound", "render prop", "polymorphism" | UI Components |
Affected Packages (from file paths or mentions):
packages/core/,packages/store/→ Core architecturepackages/html/,packages/react/→ UI/Componentssite/→ Documentation
Step 2: Load Appropriate Skill
Based on detected type, load the relevant skill for domain expertise:
| Detected Type | Load Skill | Why |
|---|---|---|
| API proposal, RFC, architecture | api |
Extensibility, progressive disclosure, type safety principles |
| DX, ergonomics, types | api |
DX principles, TypeScript patterns, state/adapter patterns |
| Documentation | docs |
Tone, structure, code examples, Diátaxis types |
| Component reference pages | api-reference |
API reference page structure, builder conventions |
| Accessibility | aria |
Keyboard, focus, ARIA patterns |
| UI component implementation | component |
Compound components, polymorphism, styling patterns |
| Bug/Feature (general) | api |
General principles apply |
Load the skill before proceeding to analysis.
Notes:
- For domain-specific bugs (e.g., accessibility bug), load the relevant domain skill (
aria) instead of genericapi - When issues span multiple domains (e.g., "add accessible slider component"), load multiple skills: primary domain first, then supporting skills
Step 3: Examine the Codebase
- Examine the relevant parts of the codebase
- Analyze the code thoroughly until you have a solid understanding of how it works
- Apply the loaded skill's principles when evaluating the current implementation
Step 4: Explain the Issue
Explain the issue in detail, including:
- The problem and its root cause
- How it relates to the loaded skill's principles (if applicable)
- Current behavior vs expected behavior
Step 5: Create a Comprehensive Plan
Create a plan to solve the issue that includes:
Core Changes:
- Required code changes
- Potential impacts on other parts of the system
Quality Assurance:
- Necessary tests to be written or updated
- Documentation updates
Risk Assessment:
- Performance considerations
- Security implications
- Backwards compatibility (if applicable)
Skill-Specific Considerations:
For API/Architecture/DX issues (with api skill):
- Does the solution follow emergent extensibility?
- Is progressive disclosure maintained?
- Are types inferred without annotation?
- Does it avoid anti-patterns (overloads, shotgun parsing)?
- Does it minimize time-to-first-success?
- Does it reduce cognitive load?
- Are mental models clear and predictable?
- Does it maximize editor/TypeScript ergonomics?
For Documentation issues (with docs skill):
- Does it follow the appropriate doc type template?
- Is the tone direct and confident?
- Are code examples complete and runnable?
- Are cross-links included?
For Accessibility issues (with aria skill):
- Does it follow WAI-ARIA patterns?
- Is keyboard navigation supported?
- Is focus management correct?
- Are ARIA attributes properly used?
For UI Component issues (with component skill):
- Does it use compound component pattern?
- Is polymorphism via
renderprop orasChild? - Are both controlled and uncontrolled modes supported?
- Are data attributes used for styling?
Step 6: References
Include:
- Links to all source issues
- Related discussions or issues
- Relevant skill principles applied
ONLY CREATE A PLAN. DO NOT WRITE ANY CODE. Your task is to create a thorough, comprehensive strategy for understanding and resolving the issues.