bug-report
The bug-report skill generates structured bug reports from user descriptions or analyzes code files to identify potential bugs, ensuring comprehensive documentation with reproduction steps, severity classification, and technical context. Use this skill when documenting new issues, investigating code for defects, verifying bug fixes, or closing resolved issues in a game development workflow.
git clone --depth 1 https://github.com/Donchitos/Claude-Code-Game-Studios /tmp/bug-report && cp -r /tmp/bug-report/.claude/skills/bug-report ~/.claude/skills/bug-reportSKILL.md
## Phase 1: Parse Arguments Determine the mode from the argument: - No keyword → **Description Mode**: generate a structured bug report from the provided description - `analyze [path]` → **Analyze Mode**: read the target file(s) and identify potential bugs - `verify [BUG-ID]` → **Verify Mode**: confirm a reported fix actually resolved the bug - `close [BUG-ID]` → **Close Mode**: mark a verified bug as closed with resolution record If no argument is provided, ask the user for a bug description before proceeding. --- ## Phase 2A: Description Mode 1. **Parse the description** for key information: what broke, when, how to reproduce it, and what the expected behavior is. 2. **Search the codebase** for related files using Grep/Glob to add context (affected system, likely files). 3. **Draft the bug report**: ```markdown # Bug Report ## Summary **Title**: [Concise, descriptive title] **ID**: BUG-[NNNN] **Severity**: [S1-Critical / S2-Major / S3-Minor / S4-Trivial] **Priority**: [P1-Immediate / P2-Next Sprint / P3-Backlog / P4-Wishlist] **Status**: Open **Reported**: [Date] **Reporter**: [Name] ## Classification - **Category**: [Gameplay / UI / Audio / Visual / Performance / Crash / Network] - **System**: [Which game system is affected] - **Frequency**: [Always / Often (>50%) / Sometimes (10-50%) / Rare (<10%)] - **Regression**: [Yes/No/Unknown -- was this working before?] ## Environment - **Build**: [Version or commit hash] - **Platform**: [OS, hardware if relevant] - **Scene/Level**: [Where in the game] - **Game State**: [Relevant state -- inventory, quest progress, etc.] ## Reproduction Steps **Preconditions**: [Required state before starting] 1. [Exact step 1] 2. [Exact step 2] 3. [Exact step 3] **Expected Result**: [What should happen] **Actual Result**: [What actually happens] ## Technical Context - **Likely affected files**: [List of files based on codebase search] - **Related systems**: [What other systems might be involved] - **Possible root cause**: [If identifiable from the description] ## Evidence - **Logs**: [Relevant log output if available] - **Visual**: [Description of visual evidence] ## Related Issues - [Links to related bugs or design documents] ## Notes [Any additional context or observations] ``` --- ## Phase 2B: Analyze Mode 1. **Read the target file(s)** specified in the argument. 2. **Identify potential bugs**: null references, off-by-one errors, race conditions, unhandled edge cases, resource leaks, incorrect state transitions. 3. **For each potential bug**, generate a bug report using the template above, with the likely trigger scenario and recommended fix filled in. --- ## Phase 2C: Verify Mode Read `production/qa/bugs/[BUG-ID].md`. Extract the reproduction steps and expected result. 1. **Re-run reproduction steps** — use Grep/Glob to check whether the root cause code path still exists as described. If the fix removed or changed it, note the change. 2. **Run the related test** — if the bug's system has a test file in `tests/`, run it via Bash and report pass/fail. 3. **Check for regression** — grep the codebase for any new occurrence of the pattern that caused the bug. Produce a verification verdict: - **VERIFIED FIXED** — reproduction steps no longer produce the bug; related tests pass - **STILL PRESENT** — bug reproduces as described; fix did not resolve the issue - **CANNOT VERIFY** — automated checks inconclusive; manual playtest required Ask: "May I update `production/qa/bugs/[BUG-ID].md` to set Status: Verified Fixed / Still Present / Cannot Verify?" If STILL PRESENT: reopen the bug, set Status back to Open, and suggest re-running `/hotfix [BUG-ID]`. --- ## Phase 2D: Close Mode Read `production/qa/bugs/[BUG-ID].md`. Confirm Status is `Verified Fixed` before closing. If status is anything else, stop: "Bug [ID] must be Verified Fixed before it can be closed. Run `/bug-report verify [BUG-ID]` first." Append a closure record to the bug file: ```markdown ## Closure Record **Closed**: [date] **Resolution**: Fixed — [one-line description of what was changed] **Fix commit / PR**: [if known] **Verified by**: qa-tester **Closed by**: [user] **Regression test**: [test file path, or "Manual verification"] **Status**: Closed ``` Update the top-level `**Status**: Open` field to `**Status**: Closed`. Ask: "May I update `production/qa/bugs/[BUG-ID].md` to mark it Closed?" After closing, check `production/qa/bug-triage-*.md` — if the bug appears in an open triage report, note: "Bug [ID] is referenced in the triage report. Run `/bug-triage` to refresh the open bug count." --- ## Phase 3: Save Report Present the completed bug report(s) to the user. Ask: "May I write this to `production/qa/bugs/BUG-[NNNN].md`?" If yes, write the file, creating the directory if needed. Verdict: **COMPLETE** — bug report filed. If no, stop here. Verdict: **BLOCKED** — user declined write. --- ## Phase 4: Next Steps After saving, suggest based on mode: **After filing (Description/Analyze mode):** - Run `/bug-triage` to prioritize alongside existing open bugs - If S1 or S2: run `/hotfix [BUG-ID]` for emergency fix workflow **After fixing the bug (developer confirms fix is in):** - Run `/bug-report verify [BUG-ID]` — confirm the fix actually works before closing - Never mark a bug closed without verification — a fix that doesn't verify is still Open **After verify returns VERIFIED FIXED:** - Run `/bug-report close [BUG-ID]` — write the closure record and update status - Run `/bug-triage` to refresh the open bug count and remove it from the active list
The Accessibility Specialist ensures the game is playable by the widest possible audience. They enforce accessibility standards, review UI for compliance, and design assistive features including remapping, text scaling, colorblind modes, and screen reader support.
The AI Programmer implements game AI systems: behavior trees, state machines, pathfinding, perception systems, decision-making, and NPC behavior. Use this agent for AI system implementation, pathfinding optimization, enemy behavior programming, or AI debugging.
The Analytics Engineer designs telemetry systems, player behavior tracking, A/B test frameworks, and data analysis pipelines. Use this agent for event tracking design, dashboard specification, A/B test design, or player behavior analysis methodology.
The Art Director owns the visual identity of the game: style guides, art bible, asset standards, color palettes, UI/UX visual design, and the art production pipeline. Use this agent for visual consistency reviews, asset spec creation, art bible maintenance, or UI visual direction.
The Audio Director owns the sonic identity of the game: music direction, sound design philosophy, audio implementation strategy, and mix balance. Use this agent for audio direction decisions, sound palette definition, music cue planning, or audio system architecture.
The community manager owns player-facing communication: patch notes, social media posts, community updates, player feedback collection, bug report triage from players, and crisis communication. They translate between development team and player community.
The Creative Director is the highest-level creative authority for the project. This agent makes binding decisions on game vision, tone, aesthetic direction, and resolves conflicts between design, art, narrative, and audio pillars. Use this agent when a decision affects the fundamental identity of the game or when department leads cannot reach consensus.
The DevOps Engineer maintains build pipelines, CI/CD configuration, version control workflow, and deployment infrastructure. Use this agent for build script maintenance, CI configuration, branching strategy, or automated testing pipeline setup.