メニュー
Use this skill when the user asks to diagnose and fix a concrete bug with a symptom, error, failing test, regression, or reproducible wrong behavior. Do not use for broad build/CI repair, security review, new features, or speculative cleanup.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
[Hyper] Commit and push in one action, including from linked Git worktrees. Use when the user asks to commit and push together, save and push changes, or run `/git-maker`; it performs safe commit grouping first, then automatically pushes without a second confirmation.
[Hyper] Optimize an existing codebase through baseline-first experiments, binary evaluation, and one-mutation-at-a-time iteration. Use for codebase autoresearch, measured bottleneck reduction, benchmarked code optimization, and evidence-backed refactors.
[Hyper] Use this skill when optimizing an existing Codex skill through baseline-first experiments, binary evals, Guard checks, and one-mutation-at-a-time iteration. Use for skill autoresearch, measured trigger/workflow improvement, self-optimizing a skill, benchmarking skill changes, or resuming skill experiment artifacts. If invoked without a target, ask for the target skill and eval intent before creating artifacts or mutating files. Do not use for one-off skill creation/refactor, generic docs polish, app QA, commit-only, or push-only requests.
[Hyper] Use when the user explicitly wants Anthropic Claude Code CLI (`claude`) for an isolated session, non-interactive (`-p`) run, session resume by ID or name, or a CI-friendly `--bare` invocation. Trigger phrases: "use claude code", "ask claude", "run claude", "continue the last claude session", "resume the auth-refactor claude session", or "use Anthropic's CLI to inspect or fix this repo".
[Hyper] Use when the user explicitly wants OpenAI Codex CLI (`codex`) for an isolated session, non-interactive run, code review, or session resume. Trigger phrases: 'use codex', 'ask codex', 'run codex', 'codex exec', 'codex review', 'continue the last codex session', or 'use OpenAI CLI to inspect or fix this repo'.
[Hyper] Convert colors between hex, rgb, and oklch using @kood/color-cli. Use when the user asks to convert colors, transform CSS file colors, or needs accurate oklch values. Trigger phrases — "color convert", "hex to oklch", "oklch to hex", "rgb to oklch", "CSS color conversion", "color conversion", "tell me the oklch value".
| name | bug-fix |
| description | Use this skill when the user asks to diagnose and fix a concrete bug with a symptom, error, failing test, regression, or reproducible wrong behavior. Do not use for broad build/CI repair, security review, new features, or speculative cleanup. |
| compatibility | Use in environments with code exploration, editing, and validation commands; complex investigations may write `.hypercore/bug-fix/flow.json`. |
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>
.hypercore/bug-fix/flow.json using references/flow-schema.md.<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:
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>
Cannot read properties of undefined 에러가 /users 페이지에서 나는데 고쳐줘."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:
rules/diagnosis-and-routing.md before classifying a bug, choosing diagnose-only/fix-now/option-first/handoff, or deciding whether user confirmation is required.references/flow-schema.md only for complex bugs that need .hypercore/bug-fix/flow.json, or when resuming an existing tracked flow.rules/validation-and-reporting.md before declaring completion, reporting blocked state, or deciding which validation evidence is sufficient.*.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. |
<execution_modes>
.hypercore/bug-fix/flow.json and wait for user selection.</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>
</implementation_rules>
Before completion, satisfy this checklist:
.hypercore/bug-fix/flow.json created/resumed and updated using references/flow-schema.md.rules/validation-and-reporting.md passed.Forbidden completion states: