test-driven-development

Name: test-driven-development
Author: pimenov

20stars2forks

How to install test-driven-development?

pimenov/codex-first-skills-pack/test-driven-development

$npx -y skills add pimenov/codex-first-skills-pack --skill test-driven-development

Installs into the current project.

Summary

Drives behavior changes through tests or explicit focused checks before implementation. Use when implementing new logic, fixing a bug, changing behavior, adding edge-case handling, modifying validation, refactoring behavior-sensitive code, or after debugging identifies a root cau

Files · 1

View on GitHub

SKILL.md

1	# Test-Driven Development
2
3	## Overview
4
5	Use tests as executable proof of expected behavior. For bugs, first reproduce the bug with a failing test or focused check. For new behavior, define the expected behavior before writing implementation code.
6
7	This skill is not ceremony. It is a guard against "looks fixed" answers that cannot catch regressions.
8
9	## Do Not Use
10
11	- Pure documentation, copy, or static content changes with no behavior.
12	- Mechanical formatting, renames, or file moves.
13	- Configuration-only changes where the right proof is a config validation/build/smoke check rather than a unit test.
14	- One-off exploration before a behavior claim is made.
15	- Cases where the repo has no realistic test harness and the user explicitly chooses a manual smoke check.
16
17	## Core Loop
18
19	Use the smallest proof that matches the risk.
20
21	```text
22	RED -> GREEN -> REFACTOR -> VERIFY
23	```
24
25	### 1. RED: Define The Failing Behavior
26
27	Before implementation, create or identify a check that should fail before the fix.
28
29	Good RED targets:
30
31	- unit test for pure logic;
32	- integration test for service/API/database boundaries;
33	- component/browser test for UI behavior;
34	- CLI command or smoke script for operational behavior;
35	- minimal reproduction when no test harness exists.
36
37	For bugs, use the prove-it pattern:
38
39	```text
40	Bug report -> failing reproduction -> minimal fix -> passing reproduction -> broader check
41	```
42
43	If no failing test can be added, state why and name the substitute proof:
44
45	```text
46	No automated test added because <reason>.
47	Focused check: <command/manual smoke/repro script>.
48	Regression risk: <remaining gap>.
49	```
50
51	### 2. GREEN: Make The Smallest Fix
52
53	Write the minimum code that makes the RED check pass.
54
55	Do not mix in:
56
57	- broad refactors;
58	- unrelated cleanup;
59	- dependency upgrades;
60	- UI polish;
61	- new features not covered by the behavior check.
62
63	If the minimum fix needs a design decision, stop and surface the decision before coding through it.
64
65	### 3. REFACTOR: Improve Safely
66
67	Refactor only after the behavior check is green.
68
69	Keep refactors behavior-preserving. Run the focused check after meaningful refactor steps. If a refactor changes behavior, it needs its own RED check or a scope note.
70
71	### 4. VERIFY: Expand Confidence
72
73	Run checks in widening circles:
74
75	1. the focused failing test/check;
76	2. nearby tests for the touched module;
77	3. typecheck/lint/build if the stack uses them;
78	4. broader suite or browser/manual smoke when the touched surface warrants it.
79
80	Do not rerun expensive broad checks repeatedly on unchanged code. Say what was run and what remains unverified.
81
82	## Choosing Test Size
83
84	Prefer the smallest test that proves the behavior:
85
86	- `unit`: pure functions, validation rules, data transforms;
87	- `integration`: API handlers, database queries, service boundaries, auth checks;
88	- `component/browser`: user-visible UI behavior, routing, forms, rendering;
89	- `smoke`: deploy/runtime/CLI/config behavior where automated unit tests are not the right proof.
90
91	Avoid brittle tests that only assert implementation details unless the implementation detail is the contract.
92
93	## Working In Existing Repos
94
95	Before adding tests:
96
97	1. Read the existing test style and commands.
98	2. Find the closest similar test.
99	3. Use the repo's current runner and helpers.
100	4. Avoid adding a new test framework unless the user explicitly approves.
101	5. Keep test data small and deterministic.
102
103	If test commands or framework behavior are version-sensitive, use `source-driven-development` before inventing syntax.
104
105	## Working With Bugs
106
107	When `debugging-and-error-recovery` has identified a root cause, use this skill to add the guard.
108
109	Bugfix checklist:
110
111	- observed behavior is captured;
112	- expected behavior is explicit;
113	- failing reproduction exists or the no-test reason is stated;
114	- fix makes the reproduction pass;
115	- nearby regressions are checked.
116
117	Do not close a bug only because the code changed. Close it when the proof passes or the user explicitly accepts the remaining gap.
118
119	## Working With Production And External Systems
120
121	For production, data, auth, billing, routing, webhooks, email, CRM, Notion, Linear, GitHub, Directus, Cloudflare, VPS, or other live systems:
122
123	- keep the first pass read-only unless a bounded mutation is approved;
124	- prefer dry-runs, local fixtures, staging, or smoke checks over live writes;
125	- do not create synthetic production data without approval;
126	- record the exact check and rollback/evidence path when relevant.
127
128	Tests and smoke checks are evidence, not approval to deploy or mutate production.
129
130	## Common Rati

People who liked this also viewed

6 picks

Type

test-driven-development

20stars2forks

View on GitHub

How to install test-driven-development?

pimenov/codex-first-skills-pack/test-driven-development

$npx -y skills add pimenov/codex-first-skills-pack --skill test-driven-development

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Test-Driven Development
2
3	## Overview
4
5	Use tests as executable proof of expected behavior. For bugs, first reproduce the bug with a failing test or focused check. For new behavior, define the expected behavior before writing implementation code.
6
7	This skill is not ceremony. It is a guard against "looks fixed" answers that cannot catch regressions.
8
9	## Do Not Use
10
11	- Pure documentation, copy, or static content changes with no behavior.
12	- Mechanical formatting, renames, or file moves.
13	- Configuration-only changes where the right proof is a config validation/build/smoke check rather than a unit test.
14	- One-off exploration before a behavior claim is made.
15	- Cases where the repo has no realistic test harness and the user explicitly chooses a manual smoke check.
16
17	## Core Loop
18
19	Use the smallest proof that matches the risk.
20
21	```text
22	RED -> GREEN -> REFACTOR -> VERIFY
23	```
24
25	### 1. RED: Define The Failing Behavior
26
27	Before implementation, create or identify a check that should fail before the fix.
28
29	Good RED targets:
30
31	- unit test for pure logic;
32	- integration test for service/API/database boundaries;
33	- component/browser test for UI behavior;
34	- CLI command or smoke script for operational behavior;
35	- minimal reproduction when no test harness exists.
36
37	For bugs, use the prove-it pattern:
38
39	```text
40	Bug report -> failing reproduction -> minimal fix -> passing reproduction -> broader check
41	```
42
43	If no failing test can be added, state why and name the substitute proof:
44
45	```text
46	No automated test added because <reason>.
47	Focused check: <command/manual smoke/repro script>.
48	Regression risk: <remaining gap>.
49	```
50
51	### 2. GREEN: Make The Smallest Fix
52
53	Write the minimum code that makes the RED check pass.
54
55	Do not mix in:
56
57	- broad refactors;
58	- unrelated cleanup;
59	- dependency upgrades;
60	- UI polish;
61	- new features not covered by the behavior check.
62
63	If the minimum fix needs a design decision, stop and surface the decision before coding through it.
64
65	### 3. REFACTOR: Improve Safely
66
67	Refactor only after the behavior check is green.
68
69	Keep refactors behavior-preserving. Run the focused check after meaningful refactor steps. If a refactor changes behavior, it needs its own RED check or a scope note.
70
71	### 4. VERIFY: Expand Confidence
72
73	Run checks in widening circles:
74
75	1. the focused failing test/check;
76	2. nearby tests for the touched module;
77	3. typecheck/lint/build if the stack uses them;
78	4. broader suite or browser/manual smoke when the touched surface warrants it.
79
80	Do not rerun expensive broad checks repeatedly on unchanged code. Say what was run and what remains unverified.
81
82	## Choosing Test Size
83
84	Prefer the smallest test that proves the behavior:
85
86	- `unit`: pure functions, validation rules, data transforms;
87	- `integration`: API handlers, database queries, service boundaries, auth checks;
88	- `component/browser`: user-visible UI behavior, routing, forms, rendering;
89	- `smoke`: deploy/runtime/CLI/config behavior where automated unit tests are not the right proof.
90
91	Avoid brittle tests that only assert implementation details unless the implementation detail is the contract.
92
93	## Working In Existing Repos
94
95	Before adding tests:
96
97	1. Read the existing test style and commands.
98	2. Find the closest similar test.
99	3. Use the repo's current runner and helpers.
100	4. Avoid adding a new test framework unless the user explicitly approves.
101	5. Keep test data small and deterministic.
102
103	If test commands or framework behavior are version-sensitive, use `source-driven-development` before inventing syntax.
104
105	## Working With Bugs
106
107	When `debugging-and-error-recovery` has identified a root cause, use this skill to add the guard.
108
109	Bugfix checklist:
110
111	- observed behavior is captured;
112	- expected behavior is explicit;
113	- failing reproduction exists or the no-test reason is stated;
114	- fix makes the reproduction pass;
115	- nearby regressions are checked.
116
117	Do not close a bug only because the code changed. Close it when the proof passes or the user explicitly accepts the remaining gap.
118
119	## Working With Production And External Systems
120
121	For production, data, auth, billing, routing, webhooks, email, CRM, Notion, Linear, GitHub, Directus, Cloudflare, VPS, or other live systems:
122
123	- keep the first pass read-only unless a bounded mutation is approved;
124	- prefer dry-runs, local fixtures, staging, or smoke checks over live writes;
125	- do not create synthetic production data without approval;
126	- record the exact check and rollback/evidence path when relevant.
127
128	Tests and smoke checks are evidence, not approval to deploy or mutate production.
129
130	## Common Rati

People who liked this also viewed

6 picks

Type