Menu
Generate a structured bug report for GitHub issues based on conversation context about bugs, errors, or broken functionality
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Validate review findings about an implementation plan against the codebase and repo rules, fix the valid ones in the plan, and write a feedback file noting what changed and what was rejected (and why). For plan-review findings, not code-review findings.
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).
Manually review a feedback file produced after implementation-plan review findings were addressed. Use when the user asks to read a findings-feedback file and verify that the plan changes correctly close, correctly reject, or fail to close the original implementation-plan-review findings, while checking for newly introduced or newly exposed plan problems. Writes only new findings to the plan-id findings directory and replies with the output file path or a concise no-new-findings status.
Use this skill whenever the agent needs to deploy a smart contract to Sepolia testnet via Foundry (`forge create` or `forge script --broadcast`), routed through the Blockscout PRO API's JSON-RPC gateway instead of a third-party RPC provider. Trigger on requests like "deploy this contract to Sepolia", "deploy via Foundry", "broadcast this Foundry deployment script", or any `forge create`/`forge script` invocation that needs a signer and an RPC endpoint for Sepolia (chain id 11155111) in this project. Also consult it to find which local Foundry keystore to sign with — this project stores test signing keys as encrypted keystores under `.ai/wallet/`, never as a plain private key in `.env`. Do not use this for reads (balances, transaction history, contract info) — use the connected Blockscout MCP tools for those directly; this skill is specifically about broadcasting a deployment.
Enter the worktree of a GitHub PR, validate the code-review comments raised on it against what the code actually does and the repo rules, fix the valid ones directly in the PR's source/tests, and report in chat — a brief note per closed comment and a detailed plain-language explanation of every comment left unclosed and why. For code-review comments on a PR. Invoke manually.
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.
| 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.md