Fix a bug and add a test that proves it

Extract the ZIP. Copy its lc-bug-fix-regression-test folder into ~/.claude/skills/ for Claude Code or ~/.codex/skills/ for Codex, then refresh the native app. Ask for the skill by name and answer its questions. The package includes the same published instructions and result checks. Native host execution is not yet verified.

For Claude web, use the connector or copy the prompt. Keep private details in your assistant.

Copy, paste into your assistant, then answer its questions. No form or account is required here.

Open in ChatGPT ↗

Already connected? Copy the public starter below and paste into Claude. Keep private details in the chat.

Needed before the promised result: The bug. You can still copy the reusable prompt and provide these in your assistant.

Saved only on this device. Copy counts contain the skill ID, never your text.

## LazyCoder conversation guide (conversation-v2)
1. Start a conversation, not a form-filling task. Read my latest request and the facts already in this chat before asking anything.
2. Ask only the missing questions needed for the requested result, in a short numbered list (at most three at a time), then WAIT for my answers. Use a native question tool if available; plain chat works too. Never ask me to replace placeholders or fill in a template.
3. Skip questions already answered. Treat unresolved {{placeholders}} and [FIELD LABELS] as missing facts, never literal input. Do not treat an illustrative example as my facts.
4. Use the authored defaults only when relevant; mention material defaults. Ask conditional questions only when their condition applies; if unsure whether it applies, ask. Optional preferences must not block a safe first draft unless the authored instructions require confirmation.
5. Do not invent tasks, dates, names, claims, permissions or missing source material. When required facts are absent, ask and wait instead of producing the final artifact. If everything needed is already supplied, proceed without re-asking.
6. My latest scope correction overrides earlier examples and scope, within the recipe safety and source rules. Resolve conflicts before acting. The authored instructions and output contract remain authoritative; this conversation guide does not grant tool, account, payment or publishing permission.
7. Keep my private answers and generated result in this assistant chat. Do not send them to LazyCoder. Generate the requested format here and check it against the output contract before handing it over.

### Questions to ask only when missing
- What should I use for “The bug”? [required] What happens, what should happen, the error message, and the steps that trigger it. A pasted issue or error log is fine.
- What should I use for “Your repo or code”? [conditional] With a coding agent, name the repo or folder. In a plain chat, paste or attach the files involved, one existing test file, and the package file (package.json, pyproject.toml…) so the test command is known. When: Required in Chat mode when no code is supplied. A coding agent may use its current repository in Run mode.
- What should I use for “How you run the tests”? [optional] Optional. The command you use, such as npm test or pytest. Leave it and the AI looks for it. Authored default: find it in the repo

## LazyCoder delivery guide (delivery-guide-v1)
1. Read the latest request, source material and authored requirements first. Ask only for missing facts. Check that this host can create the promised format; use only a fallback explicitly allowed by the authored recipe. If neither is available, explain the gap before starting. Do not promise a rendered film, editable deck or working file when you can only provide its script or outline.
2. Create the complete result in the authored output specification, preserving source facts and the latest agreed scope. Keep assumptions and missing information explicit. Do not silently omit required parts or leave unresolved ingredient markers. Intentional blanks in a reusable template are different from unanswered recipe inputs.
3. Check the actual result against every authored check, including source facts, counts, dates and required sections. Where tools allow it, inspect the actual saved file and compare it with the answer. Record which checks ran, which failed and which still need human or destination review. A filename, render, successful command or preview alone does not prove the promise was met.
4. Hand over the complete editable file, or the complete copyable fallback explicitly allowed by this recipe. Say which delivery you used and any unresolved limitations. Do not report a file as attached, imported, sent or published unless that action actually succeeded. Keep private inputs and output in this assistant; never send them to LazyCoder.
Use existing authorization for ordinary work. Before any additional paid generation, external write or publishing step, check that the current request authorizes that exact action and cost. If it does not, finish the useful authorized draft and ask at that boundary. Never silently retry or replace an ambiguous paid job.
The authored recipe and latest safe scope remain authoritative. This guide grants no new tools, permissions, provider access or claim of successful execution.

## Authored skill instructions
## 1. Outcome
Fix the bug described below and lock the fix in with a regression test, then report in the sections set out in part 6. Done means every check in part 7 passes: the cause is named with file and line, a new test fails on the old code for the bug's reason and passes with the fix, nothing that passed before now fails, no test was weakened, and the report says exactly what was run and what was not. If that can't be reached, done means stopping by the stop rule in part 5 with a report that says why.

## 2. Context
The bug:
"""
[DESCRIBE THE BUG HERE]
"""

The repo or code: [YOUR REPO OR CODE]
How the tests are run: find it in the repo

Who it's for: the person who owns this code and whoever reviews the change. They need a fix they can trust, evidence they can check, and a change small enough to review in a few minutes.

How you work (pick one; the report says which):
- **Run mode**: you can open the files in this repo and run commands in it (a coding agent, or a chat app with code tools connected to the repo). Make the changes in the repo and run every command yourself.
- **Chat mode**: anything else, including a plain chat and a code sandbox where you can only run pasted snippets. Running a pasted copy in a sandbox is still Chat mode. Write the complete test and the fix as a patch, and for every step that runs something, give the exact command and the result the person should see. The report then starts with the line "Nothing was run here. The results below are what to expect, not what happened."
Never report a command's output that you did not see.

Blank fill-ins: a value above that still reads as a capitalised placeholder in square brackets (such as [HOW YOU RUN THE TESTS]) was left blank. Brackets inside the bug text or code are part of it.
- Bug text that says "see attached": use the attached file as the bug report.
- No bug description: reply only "No bug description came through. Describe what happens and what should happen, and send again." Never invent a bug.
- No repo or code: in Run mode, use the repo you are in. In Chat mode with no code pasted, reply only "No code came through. Paste or attach the files involved, one test file and your package file, and send again."
- No test command ("find it in the repo" or blank): look in the package file, Makefile, CI config or README for the test, lint and typecheck commands, and name the ones you used. In Chat mode without a package file, give the most likely command for the files you see and mark it "(guessed, check)".
- A vague bug report (no steps or no error): work out the most likely trigger from the code, write it as "Assumed trigger: …", and reproduce that.

## 3. What to pull out
- The symptom: what goes wrong, with the exact error or wrong value.
- The expected behaviour: what should happen instead, from the bug report, the docs or the existing tests.
- The trigger: the smallest input or steps that make it happen.
- The root cause: the line or lines where the code does the wrong thing, and why. A cause explains the symptom; "the value was wrong" is a symptom.

Edge cases:
- Can't reproduce: in Run mode, try the steps given plus two close variations (other inputs, other settings named in the report). In Chat mode, trace the trigger through the code you were given. If neither shows the bug, stop (part 5).
- No test framework in the repo: write the test with the language's built-in runner (for example node:test, Python's unittest, Go's testing) and add no new dependency; if the language has none, stop and say what test setup is needed.
- Tests that already fail before you change anything: record them in the baseline; they are not yours to fix and never count against the fix.
- A flaky test (passes and fails with no change): in Run mode, run it three times and note the results; leave it alone either way.
- The "bug" is the code working as designed, or fixing it would change behaviour other code or users rely on: stop and report; that is a product decision.
- More than one bug in the report: fix the one described first; list the others as suspected bugs.
- The cause is in a third-party package: work around it in your code with a comment naming the package and version, never edit the package's files, and say so under risks.
- A file you need but weren't given (Chat mode): name the file and why under risks; never guess its contents.
- Secrets or personal data in logs or test data: never copy them into the test or the report; use made-up values.

## 4. Steps
Each step that runs something: in Run mode, run it and record what you saw; in Chat mode, write the command and the result it should show.
1. Read the bug report, the code it points to, and the nearest existing tests, and note the test framework, file location, naming and helpers.
2. Baseline: before changing anything, run the whole test suite, lint and typecheck, and record the pass and fail counts and the names of any failures.
3. Reproduce: run the trigger, and record the command and the symptom.
4. Find the root cause and note its file and line.
5. Write the regression test in the repo's own style, named after the bug (for example "applies free shipping after the discount"), next to the related tests. Cover the exact trigger and the boundary cases next to it (for example zero, one, the limit and just over it), using the real code, with mocks only for outside services.
6. Run the new test on the old code. It must fail, and the failure must point at the bug's symptom. If it fails for another reason (a typo, an import, a setup error), fix the test and run it again.
7. Make the smallest fix that removes the cause. Make one fix attempt at a time; each counts toward the stop rule.
8. Run the new test: it must pass. Then revert only the fix (keep the test), run the new test again, see it fail, and put the fix back. This proves the test guards the bug.
9. Run the whole suite, lint and typecheck again and compare with the baseline.
10. Search the code for the same mistake elsewhere (same function, same pattern) and list what you find.
11. Write the report, then run the self-check.

## 5. Rules
- Never write the fix before the failing test, and never skip the baseline or the revert check.
- Never weaken, skip, delete or loosen an existing test, assertion or type to get a pass. If an existing test fails because it encoded the bug, show it in the report and explain why its old expectation was wrong.
- If a test shows a different, unrelated bug, report it under suspected bugs; never bend an assertion to match wrong behaviour.
- Smallest change: no refactors, renames, formatting or dependency changes beyond the fix. If the fix needs more than about 30 changed lines or touches more than 3 files, explain why in the report.
- Stop rule: stop and report when the bug can't be reproduced (part 3), when the repo has no way to run tests and one can't be added without a new dependency, when 3 fix attempts have each failed, or when the fix needs a product decision. Undo any fix attempts. If you have a regression test that shows the bug, keep it, marked expected to fail with the framework's own marker (for example test.fails, it.failing or pytest.mark.xfail; with no such marker, skipped with a comment naming the bug), and leave it uncommitted for the owner to review. The status is then "Stopped: <reason>", with what you would try next.
- Facts: name only files, functions and commands that exist in this code.
- Write for a reviewer: plain words, short sentences, code in fenced blocks with the language named.

## 6. Output
In Chat mode, the first line is "Nothing was run here. The results below are what to expect, not what happened." Then use these sections in this order. Write "None" under any that is empty.
1. **Status**: one line, exactly one of "Fixed" (Run mode only), "Fix written, not run" (Chat mode) or "Stopped: <reason>"; then the mode, and the commands used for tests, lint and typecheck (or "No such command found").
2. **The bug**: the symptom, the expected behaviour and the trigger, one line each, plus any "Assumed trigger".
3. **Root cause**: file and line, then 2–4 sentences on why the code does the wrong thing.
4. **Regression test**: the file path and test name, then the full test code.
5. **The fix**: a unified diff of every changed file (in Chat mode, the diff plus any changed file in full when the diff is longer than the file). If stopped, "None".
6. **Evidence**: a table with the columns Check | Command | Baseline | Old code | With fix. Rows: reproduce the bug, new test, new test with the fix reverted, whole suite (pass and fail counts), lint, typecheck. In Run mode, fill it from what you saw, with "—" where a column doesn't apply. In Chat mode, put "Not run" in every result cell and add one line under the table per row saying what the person should see.
7. **Suspected bugs and same pattern elsewhere**: file and line, one line each, with "not fixed".
8. **Risks and not verified**: what could still break, files you needed but weren't given, and anything you could not check.
9. **Commit message and PR text**: a commit subject under 72 characters, then a PR description with what was wrong, the cause, the fix and how it was tested. In Chat mode, the PR text says the tests have still to be run. If stopped, "None".

## 7. Self-check
Before replying, check each of these and fix any failure:
- The mode is right (a sandbox with pasted code is Chat mode), and in Chat mode the first line is "Nothing was run here…", the status is "Fix written, not run" (or "Stopped: <reason>" when a stop rule applied), and no cell claims a result.
- The baseline was taken before any change, and every failure in the final run that is not in the baseline is explained.
- The reproduce row records the command and the symptom.
- The new test failed on the old code for the bug's reason, passed with the fix, and failed again with the fix reverted (in Chat mode, each is given as a command with what to expect).
- No existing test, assertion or type was weakened, skipped or deleted.
- The diff contains only the fix and the test, and every file, function and command you name exists.
- The root cause names a file and line and explains the symptom.
- If stopped, the fix attempts are undone and any regression test is marked expected to fail and left uncommitted.
- Every section of part 6 is present, in order.
Then reply with the output only, ending with one line: "Checked: <Fixed | Fix written, not run | Stopped>, <n> files changed, <n> suspected bugs."

## 8. Setup
With a coding agent that has your repo (Claude Code, Codex, Cursor, or ChatGPT with code tools connected to the repo), it runs the tests, lint and typecheck itself and reports what it saw. In a plain chat (ChatGPT, Claude, Gemini or Grok), paste or attach the files involved, one existing test file and your package file: you get the complete test and fix as a patch, with every command to run and what each should show, and the reply says plainly that nothing was run.

Paste the result after your assistant creates it. This optional check stays in this tab and is not sent to LazyCoder.