test-driven-development

Original：🇺🇸 English

Translated

Use Red→Green→Refactor for product behavior changes (features, bug fixes, domain/API logic, regression guards). Not for declarative toolchain config, docs, or mechanical edits. Use when the user mentions TDD, test-first, failing test, feature, bug fix, or behavior change in app code.

5installs

Sourcemengtaoxin/agent-kit

Added on2026-10-23

NPX Install

npx skill4agent add mengtaoxin/agent-kit test-driven-development

SKILL.md Content

View Translation Comparison →

Test-driven development (for agents)

Prove intended product behavior with a failing test first, then make it pass with the smallest change. "Looks right" is not done.

Scope

In scope (full cycle): features and bug fixes in app code; domain rules, mapping, validation, non-trivial helpers; HTTP / persistence / CRUD contracts; regression guards for bugs with a meaningful automated hook.

Out of scope (no new test; never add one that only mirrors a literal you set):

Docs, comments, formatting.
Mechanical moves / renames with unchanged behavior (still run the suites when code changed).
Declarative toolchain, build or dev-server config that flips an upstream option (bundler flag, lint rule,
```
tsconfig
```
option).
Dependency bumps without logic changes; throwaway spikes (redo with the cycle before keeping them).

If unsure: in scope when the repo owns the logic or contract, out of scope when you only flip an upstream tool's switch.

Cycle (when in scope)

Red: state the behavior in one sentence; write or extend a test; run it and confirm it fails for the right reason (not a compile error, bad import or flaky setup).
Green: change production code just enough to pass. No drive-by refactors.
Refactor: clean up with tests green.

If no meaningful failing test can be written, clarify the requirement instead of writing code or a hollow test.

Layer

Discover the project's test docs (
```
docs/testing.md
```
,
```
AGENTS.md
```
) and copy a nearby test's style, naming and location.
Pick the lowest layer that locks the behavior; one focused test beats several overlapping ones. End-to-end only for user-visible integration.
Prefer real collaborators over mocks when a lower layer expresses the contract cleanly.
Verify behavior with automated tests. When the contract is page structure, assert it through the project's test runner. A check that only a person can judge by looking stays outside this cycle.

Running

Use the project's scripts (

package.json

,

Makefile

,

AGENTS.md

). Run focused tests on each Red / Green step; before finishing run the full suites (or the project's single finish / verify command) when product code changed, or the smallest relevant check for out-of-scope config. Not done until they pass.

Do not

Implement first, then write a test that mirrors the code.
Assert a config flag equals the value you just set.
Change a test to match buggy behavior without a product decision.
Churn unrelated tests or snapshots.
Use e2e as a substitute for a unit test of a pure helper.
Leave Red unobserved, tests failing, or finish on focused runs alone.