plugins/powerups/skills/bug-fix/SKILL.md
Use when fixing a bug — enforces reproduce-first-then-fix discipline with a strict step-by-step protocol. Prevents wrong-approach loops by gating each step on success criteria.
npx skillsauth add jackyliang/powerups bug-fixInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
A strict, sequential protocol for fixing bugs. Each step has a success criteria that MUST be met before proceeding to the next step. This prevents the common failure mode of guessing at fixes without understanding the bug, or breaking other things while fixing one thing.
This skill invokes powerups:best-practices — branching, investigation, TDD, and all other practices apply. This skill adds bug-specific discipline on top.
git checkout -b fix/{short-description}
Never fix bugs on main.
Read the relevant source files and understand the current behavior. Don't guess — read the actual code paths involved.
git log --oneline -10 -- path/to/file.pySuccess criteria: You can explain what the code currently does and why it produces the wrong result.
Write a minimal test that reproduces the exact bug. Run it and confirm it fails for the right reason.
test_returns_error_when_input_is_empty, not test_bug_fix# Run just the reproduction test
pytest tests/test_file.py::TestClass::test_name -v
Success criteria: The test fails, and the failure message clearly demonstrates the bug.
Now that you have a reproduction, investigate why it happens.
logger.debug or print) to narrow down the issuemcp__claude-in-chrome__*) to debug. If available, use them to:
Success criteria: You can point to the exact line(s) of code causing the bug and explain the root cause.
Fix the root cause identified in Step 4. Keep the fix minimal — don't refactor, don't "improve" adjacent code, don't add features.
Success criteria: The fix addresses the root cause and nothing else.
Run the test from Step 3. If it still fails, go back to Step 5.
pytest tests/test_file.py::TestClass::test_name -v
Success criteria: The reproduction test passes.
Run all tests to check for regressions.
# Python
pytest tests/
# JavaScript/TypeScript
npm test
If any other test broke, fix the regression without breaking the original fix. If fixing the regression requires changing the approach, go back to Step 5 with the new understanding.
Success criteria: All tests pass — both the new reproduction test and all existing tests.
print statementsgit diff should show only the fix and the testSuccess criteria: No debug artifacts remain in the diff.
Run /simplify — review changed code for reuse, quality, and efficiency. Fix issues found.
Success criteria: No duplicate code, N+1 queries, or anti-patterns in the diff.
Run powerups:change-log — add an entry to CHANGELOG.md describing the fix in plain, business-user-friendly language. Skip this step only if the fix is purely internal (not user-facing).
Success criteria: CHANGELOG.md has a new entry for today's date.
git add <specific files>
git commit -m "fix: <description of what was fixed and why>"
Create a PR. The PR description should include:
Success criteria: Commit is clean, PR is created.
| Don't | Do |
|-------|-----|
| Guess at the fix without reading the code | Read and trace the code path first (Step 2) |
| Fix without a reproduction test | Write a failing test first (Step 3) |
| Make a large fix that changes multiple behaviors | Make the smallest possible fix (Step 5) |
| Leave print or debug logging in the commit | Clean up before committing (Step 8) |
| Refactor adjacent code while fixing the bug | Only fix the bug — refactors are separate PRs |
| Skip the full test suite ("I only changed one file") | Always run all tests (Step 7) |
| Retry the same fix when the test still fails | Investigate deeper — re-read the root cause (Step 4) |
data-ai
Use for ultra-short replies. Three modes based on what the user is asking, answer a quick question, draft a short text/message, or draft a short email. Defaults to brevity over completeness. No preamble, no summaries, no offers to elaborate. Drafted messages and emails fit under 480 characters. Never use em-dashes.
development
Run before the post-completion audit (PDD M9) on any feature that used `powerups:plan-driven-development`. Reconciles the shipped artifact with the plan in BOTH directions — additive drift (what landed that wasn't planned) and subtractive drift (what's still in the code or plan but shouldn't be — dead files from replaced features, completed deferred items, stale TODOs, orphaned redirect stubs). Almost every shipped feature drifts on both axes; without this step the plan file lies and the repo accumulates stragglers.
development
Run before the post-completion audit (PDD M9) on any feature that used `powerups:plan-driven-development`. Reconciles the shipped artifact with the plan in BOTH directions — additive drift (what landed that wasn't planned) and subtractive drift (what's still in the code or plan but shouldn't be — dead files from replaced features, completed deferred items, stale TODOs, orphaned redirect stubs). Almost every shipped feature drifts on both axes; without this step the plan file lies and the repo accumulates stragglers.
data-ai
Use when the user wants to compare multiple UI/UX design directions side by side before choosing. Generates 5 meaningfully distinct variants of the same screen/component in parallel (one subagent per variant), each reachable via ?style=1...5 in the URL. Supports iteration — calling again on a chosen style produces 5 refined variants within that direction.