Bug Fix Skill

Diagnose a concrete bug, choose the safest repair path, implement within the bug boundary, and verify the changed behavior.

<output_language>

Default all user-facing deliverables, saved artifacts, reports, plans, generated docs, summaries, handoff notes, commit/message drafts, and validation notes to Korean, even when this canonical skill file is written in English.

Preserve source code identifiers, CLI commands, file paths, schema keys, JSON/YAML field names, API names, package names, proper nouns, and quoted source excerpts in their required or original language.

Use a different language only when the user explicitly requests it, an existing target artifact must stay in another language for consistency, or a machine-readable contract requires exact English tokens. If a localized template or reference exists, such as *.ko.md or *.ko.json, prefer it for user-facing artifacts.

</output_language>

Turn a concrete bug report into an evidence-backed diagnosis, scoped repair, and verified outcome.
Classify the bug before editing so simple bugs can be fixed directly and complex bugs are tracked through explicit phases.
Prevent speculative changes by requiring root-cause evidence, impact boundaries, and targeted validation.
Preserve investigation state for complex bugs with .hypercore/bug-fix/flow.json using references/flow-schema.md.

</purpose>

<routing_rule>

Use bug-fix when the user asks to fix, debug, investigate, or resolve a concrete failing behavior, for example a runtime error, failing test, regression, broken request, stale state, duplicate rendering, incorrect calculation, or reproducible UI/API mismatch.

Do not use bug-fix when:

the main task is repository-wide build, dependency, deployment, or CI repair; route to the relevant build/deploy skill instead
the main task is a security audit, exploit analysis, trust-boundary review, or vulnerability fix; route to the relevant security skill instead
the user asks for a new feature, broad refactor, style cleanup, performance optimization, or architecture redesign without a concrete bug symptom
the user asks only for documentation, planning, or summarization

If the request starts as a concrete bug but expands into repo-wide build failure, deployment failure, security risk, or product redesign, stop the bug-fix branch and hand off with the evidence already collected.

</routing_rule>

<instruction_contract>

| Field | Contract | |---|---| | Intent | Fix a specific bug by proving the failing boundary, applying the smallest safe repair, and validating the changed behavior. | | Trigger | Concrete symptom, error, failing test, regression, broken integration path, or reproducible expected-vs-actual mismatch. | | Scope | Own diagnosis, direct code/config edits needed for the bug, targeted tests/builds, and optional .hypercore/bug-fix/flow.json tracking for complex cases. | | Authority | User instructions and repo-local rules outrank this skill. Existing code/tests and reproducible evidence outrank guesses. Do not override safety gates or unrelated changes. | | Evidence | Use error text, reproduction steps, failing tests, logs, relevant source reads, recent local diffs, and validation output. Record uncertain assumptions explicitly. | | Tools | Use repository inspection, edits, and validation commands. Gate destructive actions, credential access, network calls, production side effects, and unrelated cleanup. | | Output | Korean user-facing diagnosis and final report with bug, root cause, fix applied, changed files, validation commands, key results, and unverified risks. | | Verification | Run targeted validation for changed paths, then broader typecheck/test/build when applicable or explain why it cannot run. Complex flows must update tracking state. | | Stop condition | Stop only after requested bug behavior is fixed and verified, or after a diagnose-only request is answered, or when blocked by missing reproduction/user choice/unsafe side effect. |

</instruction_contract>

<activation_examples>

Positive examples

"Cannot read properties of undefined 에러가 /users 페이지에서 나는데 고쳐줘."
"최근 변경 뒤 로그인 버튼을 눌러도 세션이 저장되지 않아. 원인 찾고 수정해줘."
"이 failing test를 통과하게 실제 버그를 고쳐줘."
"API 응답은 오는데 화면에서 같은 카드가 두 번 렌더링돼."

Negative examples

"전체 CI가 깨졌는데 의존성/빌드 설정을 전부 정리해줘." Use a build/CI repair skill.
"이 인증 흐름의 보안 취약점을 감사해줘." Use a security review/fix skill.
"이 컴포넌트를 새 디자인으로 리팩터링해줘." Use design/refactor implementation, not bug-fix.
"버그 수정 방법에 대한 일반 가이드를 써줘." Use docs/planning, not bug-fix.

Boundary examples

"원인만 분석하고 수정하지 마." Stay in diagnose-only mode and stop before edits.
"배포 후 500 에러가 나는데 로그와 앱 코드 중 어디 문제인지 봐줘." Start as bug-fix; hand off if the primary issue is deployment/platform configuration.
"이 버그 고치고 커밋까지 해줘." Use bug-fix for diagnosis/fix/verification, then use a commit workflow only after the fix is complete.

</activation_examples>

<argument_validation>

If no concrete bug is provided, ask one concise question and stop:

어떤 버그를 고쳐야 하나요? 에러 메시지, 예상/실제 동작, 재현 단계, 관련 파일 중 아는 정보를 알려주세요.

If partial information is provided, proceed with reasonable local investigation when safe. Ask only when missing information prevents reproduction, risks destructive action, or creates multiple incompatible repair paths.

</argument_validation>

<support_file_read_order>

Read support files only when their condition applies:

Read rules/diagnosis-and-routing.md before classifying a bug, choosing diagnose-only/fix-now/option-first/handoff, or deciding whether user confirmation is required.
Read references/flow-schema.md only for complex bugs that need .hypercore/bug-fix/flow.json, or when resuming an existing tracked flow.
Read rules/validation-and-reporting.md before declaring completion, reporting blocked state, or deciding which validation evidence is sufficient.
Use Korean mirrors (*.ko.md) for user-facing reports or handoff notes when helpful; keep machine-readable flow fields in English.

</support_file_read_order>

| Phase | Simple / Fix-now path | Complex / Option-first path | |---|---|---| | 1. Intake | Confirm symptom and expected behavior from the prompt or local evidence. | Same, then check for existing .hypercore/bug-fix/flow.json. | | 2. Classify | Announce Complexity: simple with one-line evidence. | Announce Complexity: complex and initialize/update flow tracking. | | 3. Diagnose | Reproduce or narrow the failing boundary; identify root cause. | Reproduce, compare hypotheses, collect evidence, update diagnose. | | 4. Choose path | If one low-risk fix is clear and user asked to fix, announce the fix path. | Present 2-3 repair options with pros, cons, risk, files, and recommendation; wait for selection. | | 5. Implement | Make the smallest direct edit needed for the bug. | Implement only the selected option and update fix. | | 6. Verify | Run targeted validation and broader checks when applicable. | Run selected-path validation, retry within scope if needed, update verify. | | 7. Report | Report bug, root cause, changed files, validation, and residual risk. | Report the same and set flow status to completed when all phases pass. |

</workflow>

<execution_modes>

Diagnose-only: Use when the user asks for analysis only. Reproduce or narrow the failure, explain root cause and options, and stop before edits.
Fix-now: Use for simple bugs where the user requested a fix, the root cause is evidenced, one low-risk path is clearly safest, and validation can be run.
Option-first: Use for complex bugs with multiple plausible causes, cross-cutting effects, risky tradeoffs, or more than one valid repair strategy. Track via .hypercore/bug-fix/flow.json and wait for user selection.
Handoff: Use when the primary issue is outside the bug-fix scope. Include collected evidence and the recommended next skill/workflow.

</execution_modes>

<option_presentation>

Use this format for complex option-first cases:

## 버그 분석 결과
**원인**: ...
**근거**: ...
**영향 범위**: ...
**복잡도**: complex

### 옵션 1: ... (추천)
- **장점**:
- **단점**:
- **리스크**:
- **수정 파일**:

### 옵션 2: ...
- **장점**:
- **단점**:
- **리스크**:
- **수정 파일**:

추천: 옵션 N (... 때문에)
어떤 옵션으로 진행할까요? (1/2)

Include a third option only when there is a genuinely distinct fallback or temporary mitigation.

</option_presentation>

<implementation_rules>

Do not edit before root-cause evidence is collected.
Do not edit before user selection in option-first mode.
Keep changes limited to the requested bug and direct impact; do not perform opportunistic cleanup.
Prefer failing tests or a reproduction command before the fix, then rerun after the fix when practical.
Do not weaken tests, delete failing tests, suppress type errors, or hide diagnostics to make validation pass.
If validation fails after the fix, keep debugging within scope; do not report success until the failure is resolved or clearly pre-existing/out of scope.
If validation cannot run, state the exact blocker and what remains unverified.

</implementation_rules>

Before completion, satisfy this checklist:

[ ] Request has a concrete bug symptom, or a concise clarifying question was asked.
[ ] Mode selected: diagnose-only, fix-now, option-first, or handoff.
[ ] Complexity announced with one-line evidence.
[ ] Root-cause evidence collected before edits.
[ ] Complex path has .hypercore/bug-fix/flow.json created/resumed and updated using references/flow-schema.md.
[ ] Complex path presented options and recorded user selection before implementation.
[ ] Changed files are limited to the bug boundary.
[ ] Targeted validation ran for the changed path, plus broader typecheck/test/build when applicable.
[ ] Final report includes bug, root cause, fix, changed files, validation commands/results, unverified risks, and flow status if tracked.
[ ] Safety gates from rules/validation-and-reporting.md passed.

Forbidden completion states:

[ ] Fix claimed without reproduction, root-cause evidence, or targeted validation.
[ ] Complex fix implemented before user option selection.
[ ] Flow tracking omitted for a complex bug.
[ ] Unrelated cleanup mixed into the bug fix.
[ ] Failing validation hidden, weakened, or misreported.

</validation>