How do I install the Tdd Loop skill?

Run npx skillmds@latest add adityaarakeri/tdd-loop in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Tdd Loop safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Tdd Loop?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Tdd Loop free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Tdd Loop?

adityaarakeri (@adityaarakeri) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Tdd Loop by adityaarakeri — Agent Skill

Name: Tdd Loop
Author: adityaarakeri

Tdd Loop

Implement a known feature, behavior change, or diagnosed bug with a red-green-refactor loop. Use when the user asks to add, build, implement, or fix behavior and automated tests exist or should exist. For an unknown failure cause use debug-protocol first; for model, prompt, RAG, or agent quality use evaluate-ai-changes alongside deterministic tests.

File contents

TDD Loop

Use a failing behavior test as the executable specification.

Preserve Scope and State

Inspect existing tests, commands, conventions, and worktree state before editing.
Preserve unrelated changes. Do not create branches, stage, commit, sync remotes, or push unless the user explicitly requests that git workflow.
If no test framework exists, prefer an existing dependency-free mechanism. Ask before adding a new framework or dependency.

Red-Green-Refactor

Red: Write the smallest test that demonstrates one missing behavior. For a diagnosed bug, preserve the reproduction as a regression test.
Observe: Run the test and confirm it fails for the intended assertion, not setup, import, fixture, or environment noise. If it passes, determine whether the behavior already exists or the test is ineffective.
Green: Implement the minimum production change that satisfies the behavior.
Expand: Run the focused test, adjacent tests, and the relevant suite. Add contract or integration coverage when behavior crosses a process, network, database, filesystem, or public API boundary.
Refactor: Improve structure while all tests remain green. Use logical working-tree checkpoints; commit only when separately authorized.
Repeat for the next independently verifiable behavior.

Protect Test Integrity

Do not weaken, delete, skip, or broadly mock an assertion to manufacture green.
Mock expensive collaborators, not the unit or behavior under test.
Prefer observable outcomes over implementation-call assertions.
Add characterization tests before changing poorly understood legacy behavior.
Control time, randomness, concurrency, and external services where possible. For inherently stochastic AI behavior, use repeated evaluations through evaluate-ai-changes rather than pretending one unit test proves quality.
Treat a painful test as design feedback, not permission to skip coverage.

---name: tdd-loopdescription: Implement a known feature, behavior change, or diagnosed bug with a red-green-refactor loop. Use when the user asks to add, build, implement, or fix behavior and automated tests exist or should exist. For an unknown failure cause use debug-protocol first; for model, prompt, RAG, or agent quality use evaluate-ai-changes alongside deterministic tests.---# TDD LoopUse a failing behavior test as the executable specification.## Preserve Scope and State- Inspect existing tests, commands, conventions, and worktree state before editing.- Preserve unrelated changes. Do not create branches, stage, commit, sync remotes, or push unless the user explicitly requests that git workflow.- If no test framework exists, prefer an existing dependency-free mechanism. Ask before adding a new framework or dependency.## Red-Green-Refactor1. **Red:** Write the smallest test that demonstrates one missing behavior. For a diagnosed bug, preserve the reproduction as a regression test.2. **Observe:** Run the test and confirm it fails for the intended assertion, not setup, import, fixture, or environment noise. If it passes, determine whether the behavior already exists or the test is ineffective.3. **Green:** Implement the minimum production change that satisfies the behavior.4. **Expand:** Run the focused test, adjacent tests, and the relevant suite. Add contract or integration coverage when behavior crosses a process, network, database, filesystem, or public API boundary.5. **Refactor:** Improve structure while all tests remain green. Use logical working-tree checkpoints; commit only when separately authorized.6. Repeat for the next independently verifiable behavior.## Protect Test Integrity- Do not weaken, delete, skip, or broadly mock an assertion to manufacture green.- Mock expensive collaborators, not the unit or behavior under test.- Prefer observable outcomes over implementation-call assertions.- Add characterization tests before changing poorly understood legacy behavior.- Control time, randomness, concurrency, and external services where possible. For inherently stochastic AI behavior, use repeated evaluations through `evaluate-ai-changes` rather than pretending one unit test proves quality.- Treat a painful test as design feedback, not permission to skip coverage.

Frequently asked questions