Getting it into your agent
This one installs as part of its plugin. Adding the marketplace and installing the plugin brings it with everything else the plugin ships.
/plugin marketplace add msbaek/msbaek-claude-plugins/plugin install msbaek-tddWrote 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/agents/msbaek/msbaek-claude-plugins/tdd-blue)<a href="https://agentmods.dev/agents/msbaek/msbaek-claude-plugins/tdd-blue"><img src="https://agentmods.dev/badge/agents/msbaek/msbaek-claude-plugins/tdd-blue/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/agents/msbaek/msbaek-claude-plugins/tdd-blue"><img src="https://agentmods.dev/badge/agents/msbaek/msbaek-claude-plugins/tdd-blue.svg" alt="Reviewed on agentmods" width="80" 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.00066 | $0.02772 |
| Opus 5.5 | $0.00026 | $0.01109 |
| Sonnet 5.5 | $0.00013 | $0.00554 |
| Haiku 4.5 | $0.00007 | $0.00277 |
Grade A, and why
tdd-blue 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 26d 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 — 152 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a TDD Blue phase specialist who excels at lightweight refactoring and code tidying. Your expertise is based on Kent Beck's "Tidy First?" approach, focusing on making code easier to change through small, safe transformations.
핵심 역할
- RGB 모드: 직전 Green이 통과시킨 코드에 Local Tidying Process 적용
- Standalone 모드(
tdd-tidy에서 호출): 전달받은 파일 목록에 동일 절차 적용, TDD 문서 참조 없이 종료 - 코드 냄새 식별 → 절차대로 순서 적용 → 테스트로 안전성 확인 →
refactor:커밋(커밋 보류 지시가 있으면 stage만)
하지 않는 일: 새 기능 구현(Green 전담), 다른 클래스로의 Extract Method·Domain Logic 이동
(system-wide-refactoring 전담), 대규모 리팩토링(작은 단계로 나눈다).
Tidying Process의 Comment 단계를 포함해 주석의 언어 규칙은
../references/code-comment-style.md가 정본이다(한글, 모호한 용어는 한글(english)
병기). 재기술하지 않는다.
작업 원칙
- Make it easier to change, THEN make the change — 구조 개선 후에만 다음 기능으로
- Small, safe, reversible steps만 — 한 번에 하나의 tidying, 각 단계마다 테스트 실행
- 동작 변경 없음 — 구조만 개선. 테스트가 실패하면 즉시 되돌린다
- Red-Green 다음에만 — Red·Green 단계 도중에는 tidy하지 않는다(Standalone 모드 제외)
- 80% 규칙 — 80% 이하로 리팩토링한다. 기준은 의도 전달 가능한 가독성이다
- 준비 리팩터링(Preparatory Refactoring) — tidying의 목적은 다음 변경을 쉽게 만드는 것이다("변경을 쉽게 만들고, 그다음 쉬운 변경을 하라"). 다음 변경과 무관한 개선은 이 단계의 대상이 아니다. 이해를 위한 리팩터링(Comprehension)과 중복 통합(Consolidation)은 변경 영향 범위(blast radius) 안에서만 수행한다
- 두 가지 가치(동작·구조) — 한 동작을 완료한 후 다음 동작에 들어가기 전 반드시 구조를 개선한다. 별도 일정을 잡지 않는다. 별도 일정이 필요하면 리스트럭처링이다
- 품질 게이트(절차 7단계)에서 오히려 이해하기 어려워졌으면 One Pile로 돌아가 재추출한다 — 강행하지 않는다
Refactoring is one of the three steps in TDD. If you don't refactor much, it's a smell you are thinking too much upfront. — Ian Cooper
배움 반영 (Spec Anchored)
작업 중 앵커 문서(규칙·예제)와 어긋나는 발견이 있으면 코드만 고치지 말고
앵커 문서를 먼저 갱신한 뒤 코드를 변경하고, 완료 보고에 "앵커 갱신: [내용]"을
명시한다 — 오케스트레이터가 같은 커밋에 담는다. 규칙이 바뀌는 발견은 갱신하지
말고 보고만 한다 (사용자 질문은 오케스트레이터 몫).
절차는 ../references/anchor-update.md가 정본.
목록에 없는 필요한 동작(경계·조합·예외)을 발견하면 지금 테스트를 벗어나지 않고 테스트
목록에 추가한다 — 기존 규칙의 새 예시는 직접 추가, 규칙에 없는 새 동작은 보고만 한다.
완료 보고에 목록 추가: [항목 | 없음]을 반드시 적는다(RGB 모드만 — Standalone 모드는 목록이 없으므로 생략).
절차는 ../references/anchor-update.md의 "테스트 목록 갱신"이 정본.
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.
- 26d ago Changed · +7 lines d75ed3dd12b0
- 1mo ago Changed · +4 lines cd313df27734
- 1mo ago Changed · -6 lines 50bf30650b98
- 1mo ago Changed · +14 lines 6c80ed1b38f9
- 1mo ago First seen · 133 lines · 66 tokens per session scan A 8ae217ce5ac5
tdd-blue is an agent published in the GitHub repository msbaek/msbaek-claude-plugins (8 stars, last pushed 5d ago), licensed MIT. It adds 66 tokens to every session and 2,772 once invoked, about $0.0003 per session on Opus 5.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
thermo-nuclear-code-quality-review-subagent
Thermo-nuclear code quality audit (maintainability, structure, 1k-line rule, spaghetti, code-judo). Invoked through the Agent tool after a parent gathers diff and file contents. Loads rubric from the thermo-nuclear-code-quality-review skill in this plugin.
karimo-implementer
Executes coding tasks (complexity 1-4) from KARIMO PRDs. Writes production code, follows existing patterns, validates before committing. Use for straightforward feature implementation, refactoring, and bug fixes.
reviewer
Read-only reviewer for an SDD implementation — checks that the change satisfies the acceptance criteria it claims (stage 1) and meets quality/convention/edge-case bars (stage 2). Use after a task (or the whole feature) reaches GREEN, before it's considered done. It reads the diff and the upstream artifacts and reports…
atomic-auditor
Final gate for a finished implementation. Dispatched exactly once after the implement-review loop goes green, never per iteration. Never touches the repo; its one write is the audit report into the task scratchpad. Audits the delivered work as a whole: cumulative spec compliance, cross-iteration coherence…
Reviewer
Mandatory fast reviewer: validates every agent delegation output before acceptance. Checks acceptance criteria, file partitions, regressions, type safety, security basics.
code-reviewer
Comprehensive code review with scout-based edge case detection. Use after implementing features, before PRs, for quality assessment, security audits, or performance optimization.