القائمة
Use when implementing features/fixes. Iron law: ¬∃ production code without failing test.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف 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.