メニュー
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コマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
Drive a repository on autopilot through its GitHub issue tracker. Pick the next ordered epic/child issue, or seed a new epic only from a real code/spec/research gap, implement it on a branch, run an adversarial critic/fix loop until no actionable findings remain, verify with the repo's full gates, sync the issue tracker and roadmap, and merge only when authority is granted. Use when the user asks to autopilot a repo or epic, "run the loop", "go on" through issues, seed-and-ship work, or grind an epic to completion in your repos that follow repo AGENTS files and a shared canonical rule set.
Two Claude Code sessions coordinate via a shared JSONL chat file at ~/Downloads/claude-chat.jsonl, push-style via the Monitor tool. Lighter than /multi-claude:paired-branches; no branches, no worktrees, just a chat channel. Use when two sessions need to talk in real time and GH-issue polling is too slow / too expensive.
Spin up two Claude Code sessions on different branches of the same repo (typically main + develop), coordinating through a shared JSONL chat file in ~/Downloads. The human (U) types directives in plain English into either tab. This file is the canonical, self-contained recipe: clone-Mac, follow it top to bottom, you have the workflow running in under five minutes.
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>.