メニュー
Use when the user reports a LOGIC bug — wrong behavior, incorrect output, or a feature not working as designed. Triggers on "fix the bug where", "it's broken", "not sending", "not saving", "wrong result", "something broke".
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Scans a real codebase and writes coding-conventions.md from what it actually finds — variable style, SQL patterns, error handling, INSERT strategy, naming. Run once on any new project to bootstrap the convention system. Triggers on "scan conventions", "generate conventions", "bootstrap conventions", "extract conventions from code", "what are the conventions".
Security audit — checks auth, SQL injection, exposed endpoints, and sensitive data. Triggers on "security check", "is this secure", "check for vulnerabilities", "check auth", "audit security", "security audit".
Use when switching environments, updating config values, or verifying URLs/settings. Triggers on "check environment", "switch to production", "update URLs", "check config", "is this prod-ready".
Use when verifying a feature works, after making changes, or before shipping. Triggers on "verify this works", "test this", "does this work", "run the checklist", "before I ship", "check this end to end".
Use when cleaning up, simplifying, or restructuring existing code without changing behavior. Triggers on "refactor", "clean up", "simplify this", "this is getting messy", "too long", "hard to read", "extract this".
Use when the user wants to review a file for bugs, antipatterns, or quality issues. Triggers on "review", "check for issues", "look for problems", "audit", "before I ship".
| name | fix-bug |
| description | Use when the user reports a LOGIC bug — wrong behavior, incorrect output, or a feature not working as designed. Triggers on "fix the bug where", "it's broken", "not sending", "not saving", "wrong result", "something broke". |
| allowed-tools | Read, Edit, Grep, Glob, Bash |
| effort | high |
| keep-coding-instructions | true |
Locate the failure layer — ask: is it frontend, API/backend, database, scheduler, or email?
Read the relevant file — don't guess; read it with offset+limit if large
Hypothesize one root cause — state it before touching anything:
"I think the issue is X because Y"
Check common silent failure modes first:
Fix only the confirmed root cause — minimum code change
Verify — re-test the exact failing case, confirm nothing adjacent broke
Log it — add one line to tasks/error-lookup.md:
[date] | error description | root cause | fix applied
Report: "Bug fixed. Root cause was: [X]. Changed: [file:line]. Verified: [how]."
After step 8 — automatically run the following WITHOUT waiting for user to ask:
Step A — Verification:
Step B — Guard (always, after any fix):
guard skill on the changed file(s)