agentleFS
Sign inStart free
epicsagasepicsagas/epic-harness/skills/tdd/SKILL.md

tdd

Skill20 starsChanged 2 months agoApache-2.0View on GitHub

Test-Driven Development enforcer. Red→Green→Refactor cycle with no production code without a failing test first. Use for new features and bug fixes.

194 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use capture-learning-tools, design-frontend-dev and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • The-Vibe-CompanySkill

    capture-learning-tools

    Turn technical conversations, bugs, CI failures, review comments,

    Also in 5 projects that use this

  • The-Vibe-CompanySkill

    design-frontend-dev

    Clean Impeccable frontend design skill. Use when the user wants to

    Also in 5 projects that use this

  • tristanphvnSkill

    ketchup-video

    Catch the user up like /keel:ketchup, with a short silent video of slides for what happened and the waiting calls as text under it. Use for /keel:ketchup-video.

    Also in 14 projects that use this

  • jaydubya818Skill

    figure-it-out

    Use when novel or multi-phase work needs an auditable workflow and no narrower playbook fits.

    Also in 54 projects that use this

  • jaydubya818Skill

    principle-laziness-protocol

    Apply when a refactor is adding wrappers or abstractions instead of simplifying.

    Also in 45 projects that use this

  • +2 more from The-Vibe-Company
  • +5 more from jaydubya818

The file

We split this skill into the rules it gives an agent

11 rules. 0 are common, 10 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 186 edited versions we read keep these.

  • 10

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST.

    line 11
  2. Distinctive:

    Red: Write a failing test that describes the desired behavior

    line 17
  3. Very specific:

    Test name should read like a spec: it("returns 401 when token is expired") (reason: the test name IS your specification — it must …

    line 18
  4. Distinctive:

    Run the test — confirm it fails for the right reason (reason: a test that fails for the wrong reason gives false confidence)

    line 19
  5. Distinctive:

    Green: Write the minimum code to make the test pass

    line 21
  6. Distinctive:

    Do not write more than needed — because premature optimization is the root of all evil.

    line 22
  7. Distinctive:

    Do not optimize yet — because optimization without a passing test is speculation, not engineering

    line 23
  8. Distinctive:

    Run the test — confirm it passes (reason: a passing test is the only proof the code works)

    line 24
  9. Distinctive:

    Run tests again — must still pass (reason: refactoring without re-running tests is just renaming bugs)

    line 28
  10. Distinctive:

    Before claiming TDD is done, show ALL of these:

    line 51
  11. Distinctive:

    Test that tests implementation details instead of behavior

    line 62

“Common” is measured: kept by at least 6 in 10 of the 186 edited versions of this file we could read. “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

TDD — Test-Driven Development

Iron Law

NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST. Violating the letter of this process is violating the spirit of this process.

Process

Red → Green → Refactor

  1. Red: Write a failing test that describes the desired behavior
    • Test name should read like a spec: it("returns 401 when token is expired") (reason: the test name IS your specification — it must communicate intent to future readers)
    • Run the test — confirm it fails for the right reason (reason: a test that fails for the wrong reason gives false confidence)
  2. Green: Write the minimum code to make the test pass
    • Do not write more than needed — because premature optimization is the root of all evil; make it work first
    • Do not optimize yet — because optimization without a passing test is speculation, not engineering
    • Run the test — confirm it passes (reason: a passing test is the only proof the code works)
  3. Refactor: Clean up without changing behavior
    • Extract duplicates, rename for clarity, simplify — because readability matters more than cleverness
    • Run tests again — must still pass (reason: refactoring without re-running tests is just renaming bugs)

Cycle

Repeat for each behavior. One test, one behavior, one cycle — because scope creep in a single test cycle leads to unverified code.

When to Trigger

  • /go subagents: always — because autonomous agents without TDD produce unverified code
  • New function or method being written
  • Bug fix (write regression test first — because a bug that happened once will happen again without a guard)

Anti-Rationalization

ExcuseRebuttalWhat to do instead
"This is too simple for tests"Simple code still breaks. The Beyonce Rule applies: if you liked it, you should have put a test on it.Write the test anyway — it takes 30 seconds and catches edge cases.
"I'll write tests after"That's documentation, not specification. Tests written after confirm what you built; tests written before define what you should build.Write the test first. If you can't describe the behavior, you don't understand the requirement.
"Tests slow me down"15 minutes of TDD saves hours of debugging regression bugs later.Time the cycle — Red-Green-Refactor is usually faster than debug-after-deploy.
"I'll just test manually"Manual tests don't catch regressions. Automate it once, save hours forever.Write an automated test that runs on every commit.
"The types guarantee correctness"Types check shape, not logic. add(a,b) can still return a-b.Write a test that verifies the actual business rule, not just the type signature.
"I need to see the API shape first"Spike freely, then delete and rebuild test-first. A throwaway spike is research, not implementation.Spike, discard, then TDD the real implementation from what you learned.

Evidence Required

Before claiming TDD is done, show ALL of these:

  • Failing test output (Red phase): the test name and failure message
  • Passing test output (Green phase): ✓ with the same test name
  • Test covers behavior, not implementation (no mocking internals)
  • Refactor step completed OR explicitly noted as unnecessary with reason

No evidence = not done. "I wrote tests" without showing output is not TDD.

Red Flags

  • Writing implementation before any test exists
  • Test that tests implementation details instead of behavior
  • Skipping the refactor step
  • Multiple behaviors in one test

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