Menu
Use when implementing features/fixes. Iron law: ¬∃ production code without failing test.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
| name | test-driven-development |
| description | Use when implementing features/fixes. Iron law: ¬∃ production code without failing test. |
∀ features/fixes where TDD applies. Simple tasks may skip TDD.
¬∃ production_code without failing_test_first. If code ∃ before test -> DELETE IT ∧ start over. Sunk cost irrelevant — time gone regardless.
RED(write 1 test -> run -> observe FAIL) -> GREEN(minimal code to pass) -> REFACTOR(structure, tests stay green)
it('should validate email format', () => {
const result = validateEmail('not-an-email');
expect(isErr(result)).toBe(true);
});
Rules: 1 behavior/test | descriptive name | describe/it/expect (¬test()) | MUST run ∧ watch FAIL
∀ test: fails for right reason (missing feature ¬syntax error). GREEN before impl -> feature ∃ ∨ test wrong — investigate.
export const validateEmail = (email: string): Result<string, Error> => {
if (!email.includes('@')) return Err(new Error('Invalid email'));
return Ok(email);
};
Only enough code to pass. No more.
Improve structure, ¬change behavior, tests stay green.
Deleting hours of work to start test-first is correct. Time gone regardless. Starting over w/ proper TDD produces better code faster than retrofitting tests.
3+ test fixes attempted -> question the design, ¬ the test. Test probably right; impl approach wrong.
| Pattern | Problem | Fix |
|---|---|---|
| Tests after impl | Never verified test catches failures | Write test first -> watch fail -> implement |
| Mock behavior testing | expect(mock).toHaveBeenCalled() tests mock, ¬code | Use ∈-memory adapters implementing real interface |
| Over-mocking | Mock everything, test nothing real | ∈-memory adapters: real interface, ¬I/O |
| "Too simple for TDD" | Simple code is where hidden bugs live | Follow the cycle regardless |
Vitest: describe/it/expect/beforeEach/afterEach | ¬test() | colocated .spec.ts | globals: true
Use when making git commits. Conventional commit format and rules.
Use when running security review on a diff/PR/file. Research-vs-Reporting discipline, three-tier confidence gate, attacker-controllable taxonomy.
Use when invoking plannotator for approval review of generated .tff-cc milestone artifacts (plan, verification, spec).
Use when starting design or discovery work. MUST use before any creative work.
Use when the user wants to report a bug, file an issue, or send feedback about tff-cc. Triggers on phrases like 'report issue', 'file a bug', 'tff-cc broke', 'something is wrong with tff-cc', 'open an issue', '/report-issue'.
Use when creating, refining, or composing skills. Evidence-driven pattern analysis.