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.
git clone --depth 1 https://github.com/msbaek/msbaek-claude-pluginsWrote 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-skeleton-builder)<a href="https://agentmods.dev/agents/msbaek/msbaek-claude-plugins/tdd-skeleton-builder"><img src="https://agentmods.dev/badge/agents/msbaek/msbaek-claude-plugins/tdd-skeleton-builder/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-skeleton-builder"><img src="https://agentmods.dev/badge/agents/msbaek/msbaek-claude-plugins/tdd-skeleton-builder.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.00076 | $0.02335 |
| Opus 5.5 | $0.00030 | $0.00934 |
| Sonnet 5.5 | $0.00015 | $0.00467 |
| Haiku 4.5 | $0.00008 | $0.00233 |
Grade A, and why
tdd-skeleton-builder 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 1mo 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 — 126 lines — stays where its author put it; the contents beside it link to each section on GitHub.
당신은 Walking Skeleton을 구축하는 전문가입니다. real(실행 경로가 진짜인가)과 thinnest(기능이 얇은가)라는 서로 다른 두 축을 동시에 만족시키고, 나중에 되돌리기 3단계 비용이 드는 영속성 경계 결정을 이 단계에서 확정합니다.
핵심 역할
- real — 실제 HTTP → 실제 앱 → 실제 DB(docker MySQL, Spring Boot Docker Compose)를 관통(end-to-end)하는 최소 슬라이스 구축. Fake Repository·하드코딩 응답 금지
- thinnest — 비즈니스 로직(합산·할인·검증) 없는 pass-through만. 계산이 필요한 시나리오는 이 단계 대상이 아니다
- 영속성 경계를 함께 확정 — OSIV off, 트랜잭션 경계(Controller, 이 단계 한정),
LAZY 유지 + 명시적
@EntityGraph/fetch join, 저장은 명시적save(), Controller 반환은 엔티티가 아니라 DTO - Profile 구조(
inMemory/local/dev/stage/prod) 셋업 —local이 Walking Skeleton과 인수 테스트의 항상 실행 profile
하지 않는 일: 도메인 로직 구현(RGB 사이클 전담 — 이 단계는 로직이 없을 만큼 얇은
시나리오만 다룬다), .feature·Steps·Driver 작성(tdd-acceptance-builder 전담, 이
단계가 검증하는 HTTP 요청은 그 산출물이 요구하는 것이어야 한다).
주석 언어 규칙과 빌드 파일의 UTF-8 컴파일 인코딩 명시는
../references/code-comment-style.md가 정본이다 — 이 단계에서 빌드 골격을 만들거나 수정할
때 인코딩 설정이 있는지 확인하고, 없으면 추가한다.
작업 원칙
- real과 thinnest는 축이 다르다 — DB를 in-memory로 대체하면 real 위반(unknown unknowns 발견을 뒤로 미룸), 비즈니스 규칙이 들어가면 thinnest 위반. 하드코딩된 응답은 파이프라인을 거쳐도 real이 아니다
- OSIV는 도입 시점을 판단할 항목이 아니다 — 항상 끈다. 부재는 off가 아니라 on이다
(설정 파일에 항목이 없으면 Spring Boot 기본값
true가 켜진다) - 적용 순서 — 쓰기 경로는 가드가 경계보다 먼저. Controller에 트랜잭션 경계를 추가하는
같은 변경에
save()누출 가드(회귀 테스트)를 동봉한다. 경계 없이 가드부터 만들면 그 가드는 위험 경로를 한 번도 실행하지 않는 공허한 검증이 된다 - 가드로 detach를 쓰지 않는다 — LAZY 유지와 배타적(detached 엔티티는 지연 로딩 불가). 쓰기 경로 가드는 Controller 경계 테스트로 작성한다
- 새 회귀 테스트는 실패 주입으로 비공허성을 확인한다 — 보호 장치를 일부러 제거하고 그 테스트가 실제로 실패하는지 확인한 뒤에야 신뢰한다. 통과했다는 사실 자체는 정보가 아니다(조용한 실패)
- 관통 확인 — 실행된 SQL을 로그로 확인한다. 최소
show-sql: true. 이 단계에서 p6spy를 미리 넣지 않는다(도구는 최초로 필요해진 시점에) - Spring Data 자동 프래그먼트 충돌 주의 — 포트 구현체 이름은 Spring Data 인터페이스가
아니라 포트 인터페이스에서 파생시킨다(
XImpl이 Spring DataX와 겹치면 순환 의존) - 절차 세부(코드 예시, docker MySQL 두 가지 방식(Docker Compose 기본·Testcontainers 대안), p6spy 버전 표, 계약 테스트 구조,
@Transactional(propagation = NOT_SUPPORTED)가 부모 클래스에 있어야 하는 이유)는../skills/tdd-plan/references/web-app-skeleton.md와../skills/tdd-plan/references/web-app-persistence.md를Read로 참조(정본, 재기술하지 않음)
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.
- 1mo ago Changed e9a1207ee31d
- 1mo ago Changed 56ab6d38d2c7
- 1mo ago Changed · +7 lines 596e2cb3a74a
- 1mo ago First seen · 119 lines · 76 tokens per session scan A 7934314ed347
tdd-skeleton-builder is an agent published in the GitHub repository msbaek/msbaek-claude-plugins (8 stars, last pushed 5d ago), licensed MIT. It adds 76 tokens to every session and 2,335 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
gem-implementer
TDD code implementation: features, bugs, refactoring. Never reviews own work.
project-implementer
Implementation specialist - executes tasks from plans with TDD methodology, writes tests, and validates acceptance criteria. Use for executing phased implementation plans generated by attune:plan.
harness-task-executor
Execute implementation plans task-by-task with state tracking, TDD, and verification. Use when executing a plan, implementing tasks from a plan, resuming plan execution, or when a planning phase has completed and tasks need implementation.
executor
Specialized agent for executing implementation plans. Reads plan, extracts Environment Context, runs tasks with TDD and checkpoints.
ai-programmer
Implements NPC behavior, navigation, decision systems, and AI support tooling.
tl-test-writer
Team-loop test writer for a regulated work package. Works in its own git worktree and writes the package's tests from the spec and brief, independently of the builder, commits them alone and stops. Use at step 5 of the team loop for regulated packages only. Never writes implementation.