Tdd Agent Skill
Drive a change through a red-green-refactor loop - failing test first, minimal code to pass, then clean up. Use when implementing a feature or fixing a bug where correctness matters and a test can pin the behavior. Says "TDD", "test first", "red green refactor", "write the test first".
Install
one command, takes just this skill from the repositorynpx skills add https://github.com/rohitg00/pro-workflow --skill tddThe instruction itself
5 sections, as written by the authortdd
The agent codes better with a tight feedback loop than with a long
specification. A failing test is the tightest loop there is: it states the
target, and the target either goes green or it does not.
The loop
- Red. Write one failing test that states the next slice of behavior.
Run it. Confirm it fails for the right reason - a test that passes before
you write the code is testing nothing. If it errors instead of failing on
the assertion, fix the test setup first.
- Green. Write the least code that makes the test pass. Not the general
solution, not the abstraction - the minimal move. Run the test. Green.
- Refactor. Now clean up with the test as a net: remove duplication,
name things, simplify. Re-run after every edit. Behavior is frozen; only
the shape changes.
- Repeat for the next slice. Small slices. The rate of feedback is the
speed limit - never take on a step too big to hold a single test.
What makes a test worth writing
- Tests behavior, not implementation. Assert on the observable result,
not on which private method got called. A test that breaks on every
refactor is a liability.
- One reason to fail. Each test pins one behavior. When it goes red you
should know what broke without reading the body.
- Real seams, minimal mocks. Mock at the system boundary (network, clock,
filesystem), not internal collaborators. A test that mocks the thing under
test asserts nothing.
- No tautologies. A test that restates the implementation (
expect(x).toBe(x)
after setting x) verifies nothing. Assert the value the behavior should produce.
When to reach for it
Reach for TDD when the behavior is specifiable and a test can pin it: business
logic, parsers, state machines, bug fixes (write the failing case first, then
fix). Skip it for pure exploration, throwaway spikes, and layout-only UI where
a test asserts nothing a human would not eyeball.
Output contract
Show each red-green transition, not just the final green. If a test is hard to
write, say what the difficulty reveals about the design - untestable code is
usually badly-seamed code, and that is a finding, not an obstacle.
Other skills for the same job
different authors, same section of the catalogue
Toolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser logs.
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup
Use when implementing any feature or bugfix, before writing implementation code
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes
Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always
Expert guidance for systematic backtesting of trading strategies. Use when developing, testing, stress-testing, or validating quantitative trading strategies. Covers "beating ideas to death" methodology, parameter robustness testing, slippage modeling, bias prevention, and interpreting backtest results. Applicable when user asks about backtesting, strategy validation, robustness testing, avoiding overfitting, or systematic trading development.
Cloud laboratory platform for automated protein testing and validation. Use when designing proteins and needing experimental validation including binding assays, expression testing, thermostability measurements, enzyme activity assays, or protein sequence optimization. Also use for submitting experiments via API, tracking experiment status, downloading results, optimizing protein sequences for better expression using computational tools (NetSolP, SoluProt, SolubleMPNN, ESM), or managing protein design workflows with wet-lab validation.
This skill should be used for time series machine learning tasks including classification, regression, clustering, forecasting, anomaly detection, segmentation, and similarity search. Use when working with temporal data, sequential patterns, or time-indexed observations requiring specialized algorithms beyond standard ML approaches. Particularly suited for univariate and multivariate time series analysis with scikit-learn compatible APIs.
How to use it
Take rohitg00/tdd from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.