// Generate a structured bug report for GitHub issues based on conversation context about bugs, errors, or broken functionality
| name | gh-issue-bug |
| description | Generate a structured bug report for GitHub issues based on conversation context about bugs, errors, or broken functionality |
| disable-model-invocation | true |
This skill generates a well-structured bug report for GitHub issues based on the conversation context and saves it to .ai/gh_issues/YYMMDD-<short-issue-name>.md. This skill is specifically designed for bug reports - not for feature requests, enhancements, or improvements.
When invoked, this skill extracts bug information from the current conversation and creates a standardized GitHub bug report document.
Use this skill for:
Do NOT use this skill for:
Review the conversation to identify:
Create a filename using the pattern:
.ai/gh_issues/YYMMDD-<short-issue-name-with-dashes>.md
Where:
YYMMDD: Current date in 2-digit year, month, day format (e.g., 260127 for January 27, 2026)<short-issue-name-with-dashes>: A brief, descriptive name using lowercase letters and dashes (e.g., nft-pagination-bug, timeout-error-in-ens-lookup)Example: .ai/gh_issues/260127-nft-pagination-bug.md
Write a Markdown document with the following sections:
# [Brief Title of the Issue]
## Description
[Short description of the bug - 2-3 sentences summarizing the problem]
## Steps to Reproduce
1. [First step]
2. [Second step]
3. [Third step]
...
## Expected Behavior
[Clear description of what should happen]
## Actual Behavior
[Clear description of what actually happens, including any error messages]
## Root Cause
[Technical explanation of why the bug occurs - reference specific code, logic, or system behavior]
## Suggested Fix
[Concise description of the proposed solution without code snippets - describe the approach at a high level]
MUST INCLUDE:
MUST NOT INCLUDE:
After creating the file, confirm:
When the user says:
/gh-issue-bug
You should:
.ai/gh_issues/260127-transaction-logs-timeout.mdUse this skill whenever you are about to run any write `gh` CLI command — `gh pr edit`, `gh pr create`, `gh issue edit`, `gh issue create`, `gh pr comment`, `gh issue comment`, `gh pr close`, `gh pr merge`, `gh release create`, or similar. High-level `gh` commands sometimes fail with "missing required scopes" auth errors even though the underlying GitHub REST API works fine with the same token. This skill makes you automatically fall back to `gh api` instead of stopping to ask the user to re-authenticate. Always invoke before running any mutating `gh` command.
Expert review of an implementation plan against a GitHub issue/enhancement description (provided as a local file or a GitHub issue URL) and the current repository codebase. Use when asked to critique a plan for correctness, completeness, codebase alignment, risks, and test/rollout readiness (do not implement).
Export a detailed phased implementation plan for a GitHub issue to a file, reading all applicable rules from .cursor/rules before planning
Use to implement a structured implementation plan (e.g. temp/impl_plans/issue-*.md) phase by phase. Trigger when the user asks to implement, execute, realize, or "do" an implementation-plan file. Orchestrates a phase-developer subagent and a plan-correspondence-verifier subagent for each phase, commits each verified phase, then walks the Final Checklist. Invoke explicitly — it makes commits and spawns many subagents.
TRIGGER CONDITIONS - invoke this skill when ANY of these apply: User-triggered (explicit request): - User mentions "specification", "SPEC", "SPEC.md", "spec requirements" - User asks to "verify with spec", "confirm with specification", "check requirements" - User requests "authoritative requirements" or "source of truth" Agent self-triggered (during reasoning): - Before implementing any feature or making code changes - When verifying technical requirements or constraints - When making architectural or design decisions - When you need unbiased guidance not influenced by current implementation - When encountering conflicting information and need ground truth PURPOSE: Consults SPEC.md through an isolated subagent that ONLY reads the specification, never implementation code. This ensures guidance is based on authoritative requirements, not potentially incorrect existing code.
Describe very high level changes required to implement discussed functionality (functionality, test, docs)