agentleFS
Sign inStart free
DevolutionsDevolutions/IronRDP/.agents/skills/tdd/SKILL.md

tdd

Skill3.3k starsChanged 2 days agoApache-2.0View on GitHub

Red-green loop for one behaviour at an agreed seam - failing test first, the least code that passes, refactoring outside the loop. Use for test-first bug fixes and small features, or whenever the user says TDD or red-green.

We split this skill into the rules it gives an agent

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

  • 0

    Common

    Most of the 185 edited versions we read keep these.

  • 6

    Distinctive

    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
  • could be automatic: a setting could enforce it
  1. Distinctive:

    Ask the user only when choosing between seams would create or change a design decision, saying what each catches and misses.

    line 11
  2. Distinctive:

    No test goes below the seam, because a test against internals passes on wrong behaviour and fails on a harmless refactor.

    line 12
  3. Distinctive:

    Write one test for one behaviour, run it, and read the failure: the assertion on the behaviour must be what fails.

    line 16
  4. Distinctive:

    Write the least code that passes this test and nothing for the test you expect next.

    line 23
  5. Distinctive:

    Run the one test while iterating and the unit's suite before each commit, so the loop leaves only green commits.

    line 24
  6. Distinctive:

    Do not write all the tests first: tests written in bulk check the shape you imagined, go insensitive to what the code does, and fix the …

    line 29

“Common” is measured: kept by at least 6 in 10 of the 185 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

test-writer decides what a good test is and test-oracle-reviewer where its expected value may come from; this skill is the loop around them.

Seam

Name the seam before the first test: the public boundary where the behaviour is observed, taken from the intent or contract file, the bug report, or the existing public interface. Ask the user only when choosing between seams would create or change a design decision, saying what each catches and misses. No test goes below the seam, because a test against internals passes on wrong behaviour and fails on a harmless refactor.

Red

Write one test for one behaviour, run it, and read the failure: the assertion on the behaviour must be what fails. A compile error, missing fixture, or setup panic is not red (unless compilation failure is the behaviour under test), since it goes away once that other problem is fixed and proves nothing. For a bug, the expected value is one test-oracle-reviewer would class as independent, never the output of the fixed code, which only shows the fix did what it did. A behaviour that needs a decision no intent, contract, or report states stops the loop: ask, or run grill-intent, before writing the assertion, because the test becomes the specification the code is bent to.

Green

Write the least code that passes this test and nothing for the test you expect next; a plainly stubbed answer is the signal for the next test, not a reason to write more code now. Run the one test while iterating and the unit's suite before each commit, so the loop leaves only green commits.

One slice at a time

One test, one change, repeat; each test responds to what the last cycle showed. Do not write all the tests first: tests written in bulk check the shape you imagined, go insensitive to what the code does, and fix the test structure before you understand the implementation.

Refactor outside the loop

Refactoring is its own commit after green, suite green before and after; a design finding from implementation or code-review is acted on there, so a refactor never hides behind a behaviour change.

Download now (ZIP)

Trending

More talk lately.about the whole repository

Dec 2025: 0 mentionsJan 2026: 0 mentionsFeb 2026: 1 mentionMar 2026: 0 mentionsApr 2026: 0 mentionsMay 2026: 0 mentionsJun 2026: 1 mentionJul 2026: 16 mentionsAug 2026: 1 mentionSep 2026: 15 mentionsOct 2026: 14 mentionsNov 2026: 0 mentions
Dec 2025Jun 2026Nov 2026
Mentions a month of the Devolutions/IronRDP repository that our weekly crawl found. There is no adoption data for this file yet.

Who's talking about Devolutions/IronRDP

The biggest 5 of 60 mentions linking to the repository that our crawl found. Each line is their own headline.

See all 60

Talked about on GitHub, Bluesky and Hacker News (60 times).

On GitHub · 50

45 more on GitHub

On Bluesky · 9

4 more on Bluesky

On Hacker News · 1

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