菜单
End-to-end workflow for fixing a tracked bug. Issue-first, branch, implement, push, PR, then a critic-fix loop that does NOT stop until the critic surfaces literally nothing new AND tests pass. Use when the user says "start on
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/mihaelamj/skills --skill fix-bug命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
正在显示 SKILL.md
| name | fix-bug |
| description | End-to-end workflow for fixing a tracked bug. Issue-first, branch, implement, push, PR, then a critic-fix loop that does NOT stop until the critic surfaces literally nothing new AND tests pass. Use when the user says "start on |
Follow the shared conventions in ../conventions.md.
The full bug-fix workflow. Each phase is a hard gate; do not advance until its checks pass.
Before touching anything:
CLAUDE.md and AGENTS.md (the project may add rules on top of canon).The issue is the audit trail. The issue must exist BEFORE the fix work begins. No exceptions. (See conventions.md § Issue-first for the shared issue shape; this skill uses the fuller template below.)
If the bug already has a GH issue: open it; verify the body follows the canon. If it doesn't, edit it into shape now.
If no issue exists yet, file one via gh issue create with this body shape:
## Status (YYYY-MM-DD)
Filed. No work started. Catalog source (if any): `path/to/audit-doc.md`.
## Symptom
What goes wrong, in plain prose. One or two paragraphs.
## Repro
Concrete shell commands or steps that demonstrate the failure on the current repo state. If static-only finding (no runtime trigger), say so explicitly.
## Severity / blast radius
Low / Medium / High, with one sentence on real-world impact and one on the trigger conditions.
## Affected sites
File references by SYMBOL name, never `file.swift:142`. Lines drift on every PR; symbols don't. Write `Foo.swift (the `searchSymbols` function)` not `Foo.swift:142`.
## Fix
The plan, in numbered steps. Reference the canonical pattern if one exists in the repo.
## Acceptance
Concrete observable conditions that prove the fix shipped. Test additions, command output, schema state.
## Out of scope
What this issue does NOT cover. Punt-to-follow-up items go here, named.
## Provenance
Where the bug was found (audit doc, user report, CI failure). If from a catalog, name the catalog letters.
Labels: pick from the 5-label canon ONLY (bug, enhancement, epic, priority: high, good first issue). Anything else is label sprawl.
Apply via gh issue create -R <owner>/<repo> --label "<comma,separated>". If the repo doesn't have the canonical labels yet, create them first, matching the shared label palette.
git fetch origin main
git checkout -b fix/<N>-<topic> origin/main
<topic> is two-to-four-word kebab. Issue-number-anchored prefix is mandatory when an issue exists.
Edit the issue's ## Status (YYYY-MM-DD) block in place:
## Status (YYYY-MM-DD)
In progress on `fix/<N>-<topic>`. Started YYYY-MM-DD. Scope: <one-line scope statement>.
Use gh issue edit <N> -R <owner>/<repo> --body-file <(...)> or the gh api variant.
Make the mechanical edits. Project-specific build + test commands run here:
# Adapt per project. Common shapes:
xcrun swift build # Swift packages
swift test # Swift packages
npm test # JS
pytest # Python
Plus live verification when applicable (run the actual binary against real data, exercise the failure mode, observe the failure is gone).
Commit with conventional format (see conventions.md § Branch + commits), anchored to the issue number:
<type>(<scope>): <summary under 70 chars> (#<N>)
<body wrapped at 80 chars; multiple paragraphs OK>
Allowed types: fix, feat, chore, docs, refactor, test, style. Scope is the package or area being changed.
Style rules at commit boundary: apply conventions.md § Output discipline to every commit message (human-authored, no em dashes). Plus, specific to this skill: if a pre-commit hook fires, fix the underlying issue and create a NEW commit. Don't --amend to dodge the hook; don't --no-verify.
git push -u origin fix/<N>-<topic>
Open the PR with gh pr create. PR title under 70 chars. Body opens with ## Status (YYYY-MM-DD), mirrors the issue body shape (Symptom, Repro, Severity, Affected sites, Fix, Acceptance, Out of scope), and ends with Closes #<N>.
This is the heart of the workflow. Do not exit early. (See conventions.md § The critic / fix loop for the base mechanic; this phase adds the finding categories and the out-of-scope ladder.)
The loop:
Read the full PR diff (git diff main..HEAD) as if you were a reviewer who didn't write it.
List every concrete issue you can find. Categories:
DO UPDATE SET; tests that assert the wrong thing; missing null-guards; missed edge cases.gh issue create) and reference it in the PR body's "Out of scope" section.For each issue, fix it with a new commit on the same branch:
critic-fix(<scope>): <what was wrong>
Re-run build + tests + live verification. ALL must pass.
Go to step 1.
Exit condition (and only this exit condition): step 1 surfaces zero new findings AND step 4 is fully green.
Do NOT exit because:
Two consecutive empty critic passes is the minimum signal of convergence. Three is comfort.
gh pr merge <N> --squash --delete-branch
Verify the auto-close:
gh issue view <N> --json state # expect "CLOSED"
Local cleanup:
git checkout main
git pull --ff-only
git branch -D fix/<N>-<topic>
The shared checks from conventions.md (output discipline and remote policy) still apply. Plus, specific to this skill:
Foo.swift:142 in any committed text (issue body, PR body, commit messages, code comments). Symbols only.question / wontfix / help wanted etc.#NNN is OPEN at write time, OR the surrounding sentence describes the dep as already-shipped.release/v<X.Y.Z> instead of fix/<N>-<topic>.