Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/jh941213/codex-lattice/tddnpx skills add jh941213/codex-lattice --skill tddgit clone --depth 1 https://github.com/jh941213/codex-latticeWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/jh941213/codex-lattice/tdd)<a href="https://agentmods.dev/skills/jh941213/codex-lattice/tdd"><img src="https://agentmods.dev/badge/skills/jh941213/codex-lattice/tdd.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00062 | $0.00908 |
| Opus 5 | $0.00031 | $0.00454 |
| Sonnet 5 | $0.00012 | $0.00182 |
| Haiku 4.5 | $0.00006 | $0.00091 |
Grade A, and why
tdd scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 5d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 118 lines — stays where its author put it; the contents beside it link to each section on GitHub.
TDD (테스트 주도 개발)
테스트를 먼저 작성하고, 코드를 구현하는 TDD 방식을 적용합니다.
TDD 사이클
RED → GREEN → REFACTOR → REPEAT
RED: 실패하는 테스트 작성
GREEN: 테스트 통과하는 최소 코드 작성
REFACTOR: 코드 개선 (테스트 유지)
REPEAT: 다음 기능/시나리오
Step 1: 인터페이스 정의 (SCAFFOLD)
// 타입 먼저 정의
interface CreateUserInput {
name: string;
email: string;
}
// 빈 구현체
export function createUser(input: CreateUserInput): User {
throw new Error('Not implemented');
}
Step 2: 테스트 작성 (RED)
테스트 순서: 정상 → 엣지 → 에러
describe('createUser', () => {
// 정상 케이스 먼저
it('유효한 입력으로 사용자를 생성해야 한다', () => {
const input = { name: '홍길동', email: '[email protected]' };
const result = createUser(input);
expect(result).toMatchObject({ name: '홍길동', email: '[email protected]' });
expect(result.id).toBeDefined();
});
// 엣지 케이스
it('이름 앞뒤 공백을 제거해야 한다', () => {
const result = createUser({ name: ' 홍길동 ', email: '[email protected]' });
expect(result.name).toBe('홍길동');
});
// 에러 케이스
it('이메일이 없으면 ValidationError를 던져야 한다', () => {
expect(() => createUser({ name: '홍길동', email: '' })).toThrow(ValidationError);
});
});
Step 3: 실패 확인 (중요!)
# 반드시 실패하는지 확인 — 바로 통과하면 테스트가 잘못된 것
npm test -- path/to/file.test.ts
# 또는
pytest path/to/test_file.py -v
실패 안 하면 STOP — 테스트를 다시 검토.
Step 4: 최소 구현 (GREEN)
- 테스트만 통과하는 최소한의 코드
- 하드코딩도 OK (리팩토링에서 개선)
- 우아함보다 정확성
Step 5: 리팩토링 (REFACTOR)
- 중복 제거, 네이밍 개선
- 테스트 재실행하여 깨지지 않는지 확인
- 새 기능 추가 금지 — 리팩토링만
Step 6: 반복 (REPEAT)
다음 테스트 케이스 추가 → RED부터 다시.
프레임워크별 명령어
| 프레임워크 | 실행 | 워치 | 커버리지 |
|---|---|---|---|
| Vitest | npx vitest run |
npx vitest |
npx vitest --coverage |
| Jest | npx jest |
npx jest --watch |
npx jest --coverage |
| pytest | pytest -v |
ptw |
pytest --cov=src |
테스트 파일 위치
| 패턴 | 위치 |
|---|---|
| 코로케이션 | src/user.ts → src/user.test.ts |
| tests | src/user.ts → src/__tests__/user.test.ts |
| Python | src/user.py → tests/test_user.py |
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 5d ago First seen · 118 lines · 62 tokens per session scan A 16203080c9b7
tdd is a skill published in the GitHub repository jh941213/codex-lattice (19 stars, last pushed 3mo ago), licensed MIT. It adds 62 tokens to every session and 908 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
engram-testing-coverage
TDD and coverage standards for Engram. Trigger: When implementing behavior changes in any package.
nunit-testing
Use when writing or modifying tests in NUnit's own test projects, or when making a behavioral change to production code that needs test coverage. Covers test structure, attribute choice, helper visibility, platform guards, and which test projects are real.
tdd
Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.
strict-tdd
Strict RED->GREEN->REFACTOR test-driven development with enforcement. Never write production code before a failing test. Atomic commits per TDD cycle.
tdd
This skill should be used when the user wants to implement features or fix bugs using test-driven development. Enforces the RED-GREEN-REFACTOR cycle with vertical slicing, context isolation between test writing and implementation, human checkpoints, and auto-test feedback loops. Uses multi-agent orchestration with the…
conductor-implement
Execute tasks from a track's implementation plan following TDD workflow.