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 agents/co-native-ab/graphdo-ts/tdd-redgit clone --depth 1 https://github.com/co-native-ab/graphdo-tsWhat 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 | $0.00038 | $0.01460 |
| Opus 5 | $0.00019 | $0.00730 |
| Sonnet 5 | $0.00008 | $0.00292 |
| Haiku 4.5 | $0.00004 | $0.00146 |
Grade A, and why
TDD Red Phase - Write Failing Tests First 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 2d 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 — 165 lines — stays where its author put it; the contents beside it link to each section on GitHub.
TDD Red Phase - Write Failing Tests First (graphdo-ts)
Focus on writing clear, specific failing tests that describe the desired behaviour before any implementation exists.
Always read AGENTS.md before writing tests — it documents the three-layer test architecture and all testing patterns for this project.
Test Architecture
This project has three test layers. Choose the right layer before writing:
| Layer | Location | When to Use | Setup |
|---|---|---|---|
| Graph layer | test/graph/*.test.ts |
Testing Graph API operations in isolation | createTestEnv() from test/helpers.ts |
| Component | test/picker.test.ts, test/loopback.test.ts, test/config.test.ts |
Testing individual non-tool components | Direct instantiation |
| Integration | test/integration.test.ts |
Testing full MCP tool round-trips | InMemoryTransport + Client.callTool() |
GitHub Issue Integration
- Extract issue number from branch name or context
- Fetch issue details to understand requirements and acceptance criteria
- Extract edge cases from issue discussion comments
Core Principles
- Write the test before the code — never write production code without a failing test
- One test at a time — focus on a single behaviour
- Fail for the right reason — tests must fail due to missing implementation, not syntax/import errors
- Use the right test layer — most new tool behaviour should be an integration test
Test Patterns
Graph Layer Test Pattern
import { describe, it, expect } from "vitest";
import { createTestEnv } from "../helpers.js";
import { GraphClient } from "../../src/graph/client.js";
import { someGraphOp } from "../../src/graph/some.js";
describe("someGraphOp", () => {
it("returns expected data when resource exists", async () => {
const { graphState, graphBaseUrl, cleanup } = await createTestEnv();
// Arrange — seed mock state
graphState.someResource = { id: "test-id", name: "Test" };
// Act
const client = new GraphClient(graphBaseUrl, "test-token");
const result = await someGraphOp(client, "test-id");
// Assert
expect(result.id).toBe("test-id");
expect(result.name).toBe("Test");
await cleanup();
});
it("throws GraphRequestError when resource not found", async () => {
const { graphBaseUrl, cleanup } = await createTestEnv();
const client = new GraphClient(graphBaseUrl, "test-token");
await expect(someGraphOp(client, "nonexistent")).rejects.toThrow("not found");
await cleanup();
});
});
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.
- 2d ago First seen · 165 lines · 38 tokens per session scan A 3c0f42568687
TDD Red Phase - Write Failing Tests First is an agent published in the GitHub repository co-native-ab/graphdo-ts (1 stars, last pushed 11d ago), licensed MIT. It adds 38 tokens to every session and 1,460 once invoked, about $0.0002 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-31.
Other agents, from other repositories
tdd-guide
Red-Green-Refactor TDD 사이클 강제. 테스트 먼저 작성 → 최소 코드 구현 → 리팩토링. 커버리지 80%+ 엣지 케이스 분석 포함. Use proactively when 새 기능 구현, 버그 수정, 리팩토링을 시작할 때 — 특히 "TDD로", "테스트 먼저", "테스트 작성"이 포함된 요청. 빌드 에러 수정은 build-error-resolver, E2E는 e2e-runner 사용.
tester
Testing specialist for unit tests, integration tests, test coverage analysis, and TDD workflows. Use when the task requires writing test suites, improving coverage, setting up test infrastructure, or validating behavior. For example: writing unit tests for a service class, setting up integration test fixtures, or…
test-automator-agent
Type: test-writer-agent Role: Test writing and coverage analysis Spawned By: Issue Orchestrator, Coder Agent Tools: Codebase read/write, test runner, test-coverage-rubric.
godmode-tester
Test writer — TDD, unit/integration/e2e test generation.
red-agent
TDD Red Phase specialist - writes failing tests that define requirements.
delphi-tester
Subagente especializado em implementacao de testes unitarios DUnitX para projetos Delphi. Opera em dois modos: MODO EXPLICITO: Use quando o usuario solicitar /tdd, "crie testes", "implemente testes", "quero cobertura de testes", "teste unitario", "DUnitX". Nesse modo, analisa o projeto completo e gera a suite de…