메뉴
Use when the user asks to fix a bug, investigate an error, debug a crash, explain a stack trace, or make a failing test pass. Enforces reproduce → isolate → smallest fix → verify, instead of guessing a cause and patching code.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Use when the user asks to review a pull request, review a diff, review changes on a branch, or audit code written by a teammate or AI agent. Reviews the diff (not the summary) for unrelated changes, missing verification, behavior risks, and over-engineering.
Use when the user asks to add a new feature, add a new API/endpoint/page/component, implement a new capability, or extend existing functionality with new behavior. Forces a plan-before-code loop, scoping non-goals, and verifying the new behavior end-to-end.
Use when the user asks to understand, explain, trace, audit, or explore code WITHOUT modifying it. Examples — "how does X work", "where is Y called", "why does this branch exist", "trace the request flow". Stays read-only and does not produce a fix.
Use when a request is large, ambiguous, or spans multiple files/components and the user has NOT yet approved an implementation approach. Produces a verifiable plan via Plan Mode and a TodoWrite breakdown, then hands off to a more specific skill (bug-fix, refactor, feature-add) for execution.
Use when the user asks to refactor, clean up, simplify, modularize, deduplicate, rename, or improve the structure of existing code WITHOUT changing behavior. If the user wants new behavior, do not use this skill. Enforces small reversible steps and behavior preservation.
Use before releasing, deploying, publishing, cutting a tag, or merging into a production-bound branch. Classifies risk level and audits verification evidence, rollback plan, and operational readiness — not just whether the code compiles.
| name | acp-bug-fix |
| description | Use when the user asks to fix a bug, investigate an error, debug a crash, explain a stack trace, or make a failing test pass. Enforces reproduce → isolate → smallest fix → verify, instead of guessing a cause and patching code. |
| version | 1.0.0 |
Use this skill when the user asks you to fix a bug, investigate an error, or explain why something is failing.
The goal is not to guess the cause quickly.
The goal is to reproduce, isolate, fix, and verify.
Before changing code, identify:
If the bug report is vague, ask for the missing reproduction details.
Do not fix a bug that has not been reproduced or clearly reasoned about.
Prefer one of these reproduction forms:
If reproduction is impossible in the current environment, state that clearly.
Before editing, explain the likely root cause.
For non-trivial bugs that span multiple files, use the Explore subagent to locate suspect call sites without polluting the main session, then read only the files actually implicated.
Good root cause statements look like:
The crash happens because `user.profile` can be null, but `renderAvatar` reads `user.profile.avatarUrl` without a null check.
Bad root cause statements look like:
This is probably a state issue.
Be specific.
Fix the bug with the smallest safe change.
Do not:
Every changed line must be related to the bug.
Run the most relevant checks available:
If checks cannot be run, explain why.
At the end, summarize:
Root cause:
- ...
Changed:
- ...
Verified:
- ...
Not verified:
- ...
Risk:
- ...
Stop and ask for human confirmation if the bug fix touches: