bugfix

Diagnose and fix software bugs through a strict repro-cause-fix-regression workflow.

Updated Apr 27, 2024
One-click install
npx skills add https://github.com/IgorGribowsky/rts-sandbox --skill bugfix-igorgribowsky
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: bugfix
Source: https://github.com/IgorGribowsky/rts-sandbox/tree/main/rts-sandbox-src/.claude/skills/bugfix
Command: npx skills add https://github.com/IgorGribowsky/rts-sandbox --skill bugfix-igorgribowsky

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Developers often start editing code before reproducing a bug, which leads to fixing the wrong thing, shipping unverifiable changes, and letting silent bugs return. This Skill enforces a disciplined debugging order so every fix is grounded in a real reproduction and verified against regressions. ## Core Features & Use Cases - Strict four-step workflow: Repro → root cause → minimal fix → regression check, with no steps skipped. - Root-cause discipline: Inspect actual runtime values, serialized assets, subscriptions, and static state instead of reasoning about code in the abstract; check the checkpoint diff of the task that introduced the bug. - Scope guardrails: No drive-by refactoring, no silent mechanic changes, and clear rules for distinguishing bugs from balance tweaks or design changes. - Use Case: A user reports that units stutter after the last task. You reproduce the exact scenario, trace it to an unsubscribed event from the previous change, apply a minimal fix, rerun the repro, and add a line to the smoke-check list so the silent bug cannot return. ## Quick Start Use the bugfix skill to investigate why units stutter after the last task and produce a verified minimal fix.

Frequently Asked Questions about bugfix

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I debug a bug that I cannot reproduce?

Do not start fixing until you have a reproducible scenario. Ask for missing conditions such as elapsed time, restarts, editor versus build, and whether it happens on first run or after specific actions, then record the repro steps before touching code.

What is the correct order for fixing a software bug?

Follow the strict sequence: reproduce the issue, find the root cause from actual values, apply a minimal fix, then run a regression check. Skipping the repro step is the most common cause of fixing the wrong thing.

How do I find the root cause of a bug instead of the symptom?

Read actual runtime values such as field contents, active configs, pool sizes, and component states rather than reasoning about code. Check quiet failure spots like prefab overrides, stale serialized defaults, missing unsubscriptions, and static state carried across play sessions.

Should I refactor nearby code while fixing a bug?

No. A fix must be minimal and touch only what causes the bug, because bundled refactoring makes the change unverifiable and hides the source of any new problems. Log unrelated issues as separate backlog tasks instead.

How do I prevent silent bugs from coming back after a fix?

Rerun the original repro scenario and the related smoke-check items after every fix. For silent bugs that showed wrong behavior without errors, add a permanent line to the smoke-check list so regressions are caught.

When is a user complaint not actually a bug?

Requests like 'bullets are too slow' are balance tweaks, and 'I want it to work differently' is a design change, not a bug. Only broken behavior, especially regressions after a specific task, follows the bugfix workflow.