agentleFS
Sign inStart free
GuiMoraesDevGuiMoraesDev/taskflow/skills/bug-red-test/SKILL.md

bug-red-test

Skill1 starsChanged 24 days agoMITView on GitHub

Prove a regression test actually catches the bug by watching it fail against the old behaviour before the fix ships. Use for any change that claims to fix a defect, and when the user says "add a regression test" or "verify the test fails first".

The file

We split this skill into the rules it gives an agent

2 rules. About 0 are common, 2 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈2

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Restore the fix: Run the suite again, green.

    line 24
  2. Distinctive:

    Leave the revert in place.

    line 32

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

bug-red-test

A test written from a bug's description rather than its mechanism tends to pass either way. This procedure is what separates the two.

Procedure

  1. Name the mechanism. One sentence: the exact state and input under which the wrong behaviour occurs. If you cannot write that sentence, you do not yet understand the bug - go read, do not go write.
  2. Write the test against the mechanism, not the symptom. It asserts on the observable outcome the mechanism corrupts.
  3. Make it red. Either write the test before the fix, or - when the fix is already applied - revert the fix (git stash the fix hunk, or flip the changed line back), run the suite, and watch the new test fail.
  4. Read the failure. It must fail for the bug's reason. A failure from a missing import, a bad fixture or an unrelated assertion proves nothing - fix the test and repeat step 3.
  5. Restore the fix. Run the suite again, green.
  6. Record it in the session log: what the defect actually was, and that the test was verified failing against the old behaviour.

Do not

  • Skip step 3 because the test "obviously" covers it. That belief is what this step exists to check.
  • Leave the revert in place. Verify the tree is back to the fixed state before the gates run.
  • Name the test after the plan or the ticket. It states the behaviour: it("appends the username on a drop"), not it("fixes TASK-3").

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free