tdd

Name: tdd
Author: testdouble

122stars12forks

How to install tdd?

testdouble/han/tdd

$npx -y skills add testdouble/han --skill tdd

Installs into the current project.

Summary

Write code through a disciplined, BDD-framed Test-Driven Development loop: build a behavior test list, then drive each behavior through red-green-refactor with an enforced observed-failure gate. Use when the user wants to implement, build, or write code test-first, "do TDD", foll

Files · 1

View on GitHub

SKILL.md

1	## Project Context
2
3	- git installed: !`which git 2>/dev/null \|\| echo "not installed"`
4	- current branch: !`git branch --show-current 2>/dev/null \|\| echo unknown`
5	- CLAUDE.md: !`find . -maxdepth 1 -name "CLAUDE.md" -type f`
6	- project-discovery.md: !`find . -maxdepth 3 -name "project-discovery.md" -type f`
7
8	## Constraints (read before anything else)
9
10	This skill writes production and test code in your working tree. It is an
11	execution skill, not a document generator. These constraints shape every step
12	and override any instinct to move faster.
13
14	- The observed-failure gate is load-bearing. No production-code change
15	until a test has been run and observed to fail for the intended reason in
16	this loop. A test that passes on first run is a stop-and-diagnose signal,
17	not progress. This single rule is what separates real TDD from TDD-flavored
18	code. The verbatim Three Laws and Canon TDD steps it derives from are in
19	[references/tdd-loop.md](./references/tdd-loop.md); pull that reference when a
20	step needs the canon or the implementation gears.
21	- Two hats. Never refactor while any test is red. See
22	[references/tdd-loop.md](./references/tdd-loop.md) for the canonical statement.
23	- One behavior at a time. Exactly one test list item becomes one runnable
24	test per loop. Newly discovered scenarios are written to the list and
25	deferred, never implemented in the current loop.
26	- BDD framing. Tests describe observable behavior, named in the project's
27	existing test-naming convention, asserting outcomes through the public
28	interface — never private state. The behavior-naming and Given/When/Then
29	protocol is in [references/bdd-framing.md](./references/bdd-framing.md); pull
30	it when Step 2 needs it.
31	- You will be tempted to fake this. The specific ways an agent fakes TDD,
32	and the discipline that catches each, are in
33	[references/failure-modes.md](./references/failure-modes.md); pull it when a
34	loop feels off (a test passes on first run, no red is shown, the
35	implementation has outrun the test, refactor is being skipped).
36	- YAGNI governs the refactor step and the test list. Apply the rule in
37	[../../references/yagni-rule.md](../../references/yagni-rule.md): remove
38	duplication, but do not add abstractions, configuration, or indirection
39	without evidence. Speculative structure added "for flexibility" during
40	refactor is a YAGNI candidate. Speculative scenarios on the test list are
41	deferred with a reopen trigger, never silently added.
42
43	# Test-Driven Development
44
45	## Step 1: Resolve Project Config and Confirm Scope
46
47	Resolve commands. Read CLAUDE.md's `## Project Discovery` section for the
48	test command (under `### Commands and Tests`, not `### Frameworks and
49	Tooling`), the lint command, the build command, language, and framework. If
50	absent, fall back to `project-discovery.md`. If still absent, run
51	`${CLAUDE_SKILL_DIR}/scripts/detect-tdd-context.sh` and parse its output for
52	git state and manifest-inferred commands. Store the resolved test, lint, and
53	build commands for use in every later step.
54
55	Resolve standards and decisions. Resolve the coding-standards directory and
56	ADR directory the same way: read CLAUDE.md's `## Project Discovery` section;
57	fall back to `project-discovery.md`; fall back to Glob defaults (`docs/`,
58	`docs/adr/`, `docs/coding-standards/`, `docs/decisions/`). Also check
59	`CLAUDE.md` and `AGENTS.md` for inline standards. **Read the standards and
60	ADRs whose titles, paths, or one-line summaries indicate they govern the area
61	being built. Cap at five documents; if more than five look relevant, list them
62	and read only the five with the strongest apparent relevance — defer the rest
63	until refactor surfaces a need.** These govern the green and refactor steps.
64	If none exist, state that plainly and plan to infer conventions from the
65	surroundin

People who liked this also viewed

6 picks

Type

tdd

122stars12forks

View on GitHub

How to install tdd?

testdouble/han/tdd

$npx -y skills add testdouble/han --skill tdd

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	## Project Context
2
3	- git installed: !`which git 2>/dev/null \|\| echo "not installed"`
4	- current branch: !`git branch --show-current 2>/dev/null \|\| echo unknown`
5	- CLAUDE.md: !`find . -maxdepth 1 -name "CLAUDE.md" -type f`
6	- project-discovery.md: !`find . -maxdepth 3 -name "project-discovery.md" -type f`
7
8	## Constraints (read before anything else)
9
10	This skill writes production and test code in your working tree. It is an
11	execution skill, not a document generator. These constraints shape every step
12	and override any instinct to move faster.
13
14	- The observed-failure gate is load-bearing. No production-code change
15	until a test has been run and observed to fail for the intended reason in
16	this loop. A test that passes on first run is a stop-and-diagnose signal,
17	not progress. This single rule is what separates real TDD from TDD-flavored
18	code. The verbatim Three Laws and Canon TDD steps it derives from are in
19	[references/tdd-loop.md](./references/tdd-loop.md); pull that reference when a
20	step needs the canon or the implementation gears.
21	- Two hats. Never refactor while any test is red. See
22	[references/tdd-loop.md](./references/tdd-loop.md) for the canonical statement.
23	- One behavior at a time. Exactly one test list item becomes one runnable
24	test per loop. Newly discovered scenarios are written to the list and
25	deferred, never implemented in the current loop.
26	- BDD framing. Tests describe observable behavior, named in the project's
27	existing test-naming convention, asserting outcomes through the public
28	interface — never private state. The behavior-naming and Given/When/Then
29	protocol is in [references/bdd-framing.md](./references/bdd-framing.md); pull
30	it when Step 2 needs it.
31	- You will be tempted to fake this. The specific ways an agent fakes TDD,
32	and the discipline that catches each, are in
33	[references/failure-modes.md](./references/failure-modes.md); pull it when a
34	loop feels off (a test passes on first run, no red is shown, the
35	implementation has outrun the test, refactor is being skipped).
36	- YAGNI governs the refactor step and the test list. Apply the rule in
37	[../../references/yagni-rule.md](../../references/yagni-rule.md): remove
38	duplication, but do not add abstractions, configuration, or indirection
39	without evidence. Speculative structure added "for flexibility" during
40	refactor is a YAGNI candidate. Speculative scenarios on the test list are
41	deferred with a reopen trigger, never silently added.
42
43	# Test-Driven Development
44
45	## Step 1: Resolve Project Config and Confirm Scope
46
47	Resolve commands. Read CLAUDE.md's `## Project Discovery` section for the
48	test command (under `### Commands and Tests`, not `### Frameworks and
49	Tooling`), the lint command, the build command, language, and framework. If
50	absent, fall back to `project-discovery.md`. If still absent, run
51	`${CLAUDE_SKILL_DIR}/scripts/detect-tdd-context.sh` and parse its output for
52	git state and manifest-inferred commands. Store the resolved test, lint, and
53	build commands for use in every later step.
54
55	Resolve standards and decisions. Resolve the coding-standards directory and
56	ADR directory the same way: read CLAUDE.md's `## Project Discovery` section;
57	fall back to `project-discovery.md`; fall back to Glob defaults (`docs/`,
58	`docs/adr/`, `docs/coding-standards/`, `docs/decisions/`). Also check
59	`CLAUDE.md` and `AGENTS.md` for inline standards. **Read the standards and
60	ADRs whose titles, paths, or one-line summaries indicate they govern the area
61	being built. Cap at five documents; if more than five look relevant, list them
62	and read only the five with the strongest apparent relevance — defer the rest
63	until refactor surfaces a need.** These govern the green and refactor steps.
64	If none exist, state that plainly and plan to infer conventions from the
65	surroundin

People who liked this also viewed

6 picks

Type