메뉴
Diagnose and fix a bug or GitHub issue with test-backed verification — reproduce, root-cause, fix, and guard with a red-green or regression test so it can't silently return. Use this skill whenever the user says "fix this bug", "there's a bug in", "this is broken", "fix issue
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Add beui-style loading animations (spinner, bouncing dots, bars, dot-matrix, dither, terminal/ascii spinners, shape morph, comet, scramble text, metaballs, newton's cradle, helix, percent counter) to any project as vanilla HTML/CSS/JS — no React, no build step, no dependency. Use this skill whenever the user wants a loader, spinner, loading indicator, progress animation, or "loading..." state in a non-React project — server-rendered templates (Go, Rails, Django, Flask/Jinja, PHP), HTMX, Web Components, static HTML, or plain JS apps — even if they don't mention beui by name. Also use it when the user asks to port or copy a beui motion component.
Audit a codebase for health issues — oversized files, duplicated logic, dead code, unused parameters, test coverage gaps, and documentation/config drift — and report findings ordered by severity. Use this skill whenever the user invokes "/check-code-health", asks about "code health", "tech debt", "code quality audit", "find dead code", "what needs cleanup", or wants a maintenance overview of the repo.
Update project dependencies safely — list outdated packages, upgrade minors/patches in bulk and majors individually with changelog review, verify with build and tests, and commit in clean chore(deps) commits. Use this skill whenever the user says "update dependencies", "upgrade deps", "bump packages", "are my dependencies outdated", "update to the latest version of X", or mentions dependabot/renovate-style maintenance. Not for adding a brand-new dependency.
Get a failing build back to green — run the project's build, test, and lint commands, then fix every reported compile error, test failure, and lint violation until all pass. Use this skill whenever the user invokes "/fix-build", says "the build is broken", "fix the build", "it doesn't compile", "CI is red", "make the tests pass", or pastes build/compiler errors asking for them to be resolved.
Generate or update CLAUDE.md for a codebase the thorough way — discover architecture, workflows, and project-specific conventions, merge with existing AI-agent instruction files, and iterate with the user. Use this skill whenever the user invokes "/initialise", says "set up CLAUDE.md", "update the CLAUDE.md", "initialise this repo for Claude", or wants AI-agent onboarding docs written for a project. Prefer this over the built-in /init when the user asks for the fancy/thorough version.
Analyze a GitHub issue and write an implementation plan into the issue itself — without implementing anything. Use this skill whenever the user invokes "/plan-github-issue", says "plan issue
| name | fix-bug |
| description | Diagnose and fix a bug or GitHub issue with test-backed verification — reproduce, root-cause, fix, and guard with a red-green or regression test so it can't silently return. Use this skill whenever the user says "fix this bug", "there's a bug in", "this is broken", "fix issue |
| version | 1.0.0 |
Fix a bug so it stays fixed. Every bugfix ships with a test that fails without the fix — otherwise the same bug can come back in six months with nothing to catch it. That test requirement is non-negotiable; how it's sequenced (red-green vs. after-the-fix) is flexible.
#123, an issue URL, or an argument to the skill): gh issue view <n> for the description, repro steps, and comments.Confirm the bug actually occurs before changing anything — run the failing case, hit the endpoint, run the snippet. A bug that can't be reproduced can't be verified fixed; if reproduction genuinely isn't possible (race condition, environment-specific), say so and reason from the code, but flag the lower confidence in the report.
Preferred — red-green: write the test first.
Red-first is preferred because it proves the test actually detects the bug; a test written after the fix might pass vacuously.
Fallback — regression test after the fix: when red-first is impractical (fix needed to even understand correct behavior, or test scaffolding must be built around the fixed code), fix first, then add the regression test. Then prove the test guards the fix: temporarily revert the fix (git stash the fix hunks or invert the change), run the test, confirm it fails, restore the fix. A regression test that passes both with and without the fix is decoration, not protection.
Either way: match the repo's existing test conventions (see neighboring test files), and never weaken an existing test to make the fix pass — a newly-failing existing test means the fix is wrong or the old test enshrined the bug; investigate and report which.
The fix is done only when build, full test suite, linting, and type checking all pass. Run whatever this repo uses (Makefile/justfile targets, CI config, go build ./... && go vet ./..., uv run pytest, etc.).
Local bug (no issue): commit fix + test together as one atomic commit (fix(<scope>): <what> with a body explaining the root cause). Stop there — do not push.
GitHub issue: follow the full flow:
git checkout -b fix/<issue-number>-<slug>fix(<scope>): <subject>, body references root cause, footer Fixes #<n>)gh pr create --title "..." --body "... Fixes #<n>"Commit signing may require the user to approve a TouchID prompt. On an SSH/agent signing error, stop and ask the user to be present — do not retry blindly or disable signing.
State: root cause (mechanism, one or two sentences), the fix, the guarding test and proof it guards (red-then-green, or revert-check result), and verification output. If confidence is reduced (couldn't reproduce, couldn't revert-check), say so explicitly.