Bug fix protocol
Skill CodeAlive-AI/ai-driven-development/skills/bug-fix-protocol
8-step disciplined bug-fix protocol that treats every production bug as two failures — the code defect itself and the testing system that allowed it through. Use when fixing a production bug, investigating a regression, writing a post-mortem, or auditing a missed defect. Triggers on "fix this bug", "production bug", "regression test", "post-mortem", "test gap", "why did the tests miss this".From its SKILL.md
npx -y skills add CodeAlive-AI/ai-driven-development --skill bug-fix-protocolAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
SKILL.md
2.5 KB, 489 tokens by cl100k_base, as published. Nobody here has run it
Bug Fix Protocol
A bug fix is two fixes in one: fix the code, and fix the testing system that let the bug through. Skipping the second step means the same class of bug ships again.
The full protocol (philosophy, eight steps with examples, audit checklist, anti-patterns) lives in PROTOCOL.md. Read it before applying.
When to apply
Use this protocol whenever a defect reaches production, staging, or a customer environment. Do not use it for bugs caught locally during normal development — those are part of the writing process, not testing-system failures.
The eight steps (summary)
- Analyze and reproduce requirements. Understand exact actual vs expected behaviour; identify minimal repro path; ask the user before guessing on ambiguities.
- Write a failing test (red). Encode the bug as a test that fails for the right reason. No code change yet.
- Trace root cause. Walk the failing test back through the system. Stop at the smallest place that, if changed, makes the test pass.
- Apply the minimal fix. Smallest possible change. No drive-by refactors.
- Verify green locally. Failing test now passes; no other tests regressed.
- Run the full suite + lints + types. Catch indirect regressions.
- Document the fix. Commit message and PR description name the symptom, the root cause, and the fix in one sentence each.
- Audit the testing system (the most important step). Ask: which layer should have caught this, and why didn't it? Then change that layer so it would catch the next instance — new test type, new fixture, new lint rule, new property test, new contract assertion. A fix without step 8 is incomplete.
Output expectations
When applying the protocol, return:
- The repro test (red, then green).
- The minimal code fix.
- A one-paragraph step-8 audit naming the missed coverage layer and the change made to close the gap.
If step 8 produces "we couldn't have caught this," investigate further — that answer is almost always wrong, and accepting it is how the testing system stagnates.
Reference
Full text: PROTOCOL.md.
What ships with it: 1 file
6.9 KB alongside SKILL.md
- PROTOCOL.md6.9 KB
Gives 1 of the 12 instructions most test skills give in 489 tokens
Counted across 1,201 of the 2,096 authors here whose files we hold, read 2026-09-06
- Write a failing test before writing codein 43 of 1201, across 36 files
- Run the full test suitehere, and in 36 of 1201, across 35 files
- Test only one variable per experimentin 34 of 1201, across 17 files
- Read product marketing context before asking questionsin 34 of 1201, across 14 files
- Mock external dependenciesin 34 of 1201, across 30 files
- Define primary, secondary, and guardrail metricsin 33 of 1201, across 16 files
- Pre-determine sample size before startingin 31 of 1201, across 14 files
- Test behavior rather than implementationin 31 of 1201, across 29 files
- Formulate a hypothesis before designing a testin 30 of 1201, across 13 files
- Document every test hypothesis, variant, and resultin 29 of 1201, across 11 files
- Use descriptive test function namesin 25 of 1201, across 21 files
- Commit to the methodology without stopping earlyin 24 of 1201, across 8 files
Said here and by no other author read
- Read the protocol before applying
- Verify the fix locally
- Audit the testing system for gaps
- Improve testing to catch future instances
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.