메뉴
Use when handling repository defects such as regressions, crashes, incorrect output, failing tests, integration breakage, or performance problems that require investigation, repair, and evidence-backed verification.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | fix-bug |
| description | Use when handling repository defects such as regressions, crashes, incorrect output, failing tests, integration breakage, or performance problems that require investigation, repair, and evidence-backed verification. |
fix-bug 是缺陷调查与修复的执行 lane，不负责替代需求设计，也不允许在根因未明确前直接进入正式修复。
它的职责是：先对齐问题与影响，再完成复现、调查、修复决策、最小修复、验证与汇报，并把所有修复结论绑定到证据。
适用于：
以下情况不要直接进入本 skill：
遇到这些情况时，优先转交：
skills/develop-feature/SKILL.mdskills/refactor/SKILL.mdskills/architecture-review/SKILL.mdskills/answer/SKILL.md问题现象 / 影响范围 / 当前证据 / 不做 / 修复判定标准。superpowers:systematic-debugging 的调查范式，再决定是否允许修复。superpowers:test-driven-development 的约束；不得先写生产修复再补测试。Align
问题 / 影响 / 证据 / 不做 / 修复判定Reproduce
Investigate
superpowers:systematic-debuggingDecide
Fix
Verify
superpowers:verification-before-completion 执行验证Report
Done / Partial / Skipped按需读取配套参考文件：
references/debugging-escalation-playbook.md
references/bug-recovery-playbook.md
references/verification-checklist.md
不要把所有参考内容一次性压进上下文。
出现以下信号时，说明流程正在退化：
对用户的交付至少应包含：
Done / Partial / Skippedconfirmed / likely / unknownroot-cause fix / workaround / rollback / mitigation若当前路径没有更优替代方案，应明确写出：当前路径合理，暂无更优替代建议。
systematic-debugging / TDD / verification-before-completion 冲突rules/output-style.md 与 rules/deliverable-quality-gate.mdUse when handling local Git CLI daily operations such as checking status or diff, staging files, creating conventional commits, restoring local changes, reverting commits, or resolving merge/rebase/cherry-pick conflicts.
Use when explaining code, answering technical questions, comparing approaches, or providing repository-grounded analysis without entering an implementation or remediation workflow.
Use when evaluating system architecture, platform design, or high-level technical structure to identify production risks, evidence gaps, and prioritized remediation without directly redesigning or implementing the system.
Use when improving internal code structure without intentionally changing externally observable behavior, such as module splits, simplification, dependency cleanup, or maintainability and performance-oriented restructuring.
Use when feature ideas, issues, stakeholder notes, or partial specs need to be reviewed and turned into a concise, testable PRD with clear scope, user stories, acceptance criteria, and explicit open decisions.
Use when a PRD, feature spec, or acceptance criteria already exist and need to be turned into a concise test plan and traceable test cases with clear priorities, coverage, and execution focus.