TDD 오케스트레이터 — 대상 클래스(FQCN)의 템플릿 문서·테스트 클래스를 생성하고 tdd-plan→tdd-rgb 워크플로우를 안내. "TDD 시작", "TDD로 새 클래스 만들자", "테스트 주도로 시작", "/tdd" 요청 시 사용. 단, 템플릿이 이미 있는 상태에서 사이클만 돌리는 것은 /tdd-rgb, 요구사항 정리부터는 /tdd-plan-input이 적합. /tdd <general|web-app> <FQCN>으로 호출.
インストール方法を見るインストールする前に、エージェントに与えられる指示の中身を確認できます。
TDD 프로젝트 생성 및 진행 상황을 관리하는 진입점입니다.
[피드백 요청]
- 대상: [테스트/구현/설계/리팩토링]
- 초점: [특정 관심 영역]
- 맥락: [현재까지의 작업 요약]
- 구체적 질문: [구체적인 피드백 요청 사항]
/tdd $1 $2
$1 = general | web-app (TDD 유형)$2 = FQCN (예: com.example.bowling.BowlingGame)FQCN에서 패키지명과 클래스명을 자동 파싱합니다. 패키지명 없이 입력 시 예시를 보여주며 재입력 요청합니다.
예: /tdd general com.example.bowling.BowlingGame
예: /tdd web-app com.example.basket.CreateShoppingBasket
build.gradle, build.gradle.kts) 또는 Maven(pom.xml) 프로젝트 루트 탐색FQCN을 기반으로 다음 경로를 결정합니다:
src/test/java/{package_path}/{ClassName}.mdsrc/test/java/{package_path}/{ClassName}Test.java예: com.example.bowling.BowlingGame →
src/test/java/com/example/bowling/BowlingGame.mdsrc/test/java/com/example/bowling/BowlingGameTest.java../../references/code-comment-style.md를 따른다../../references/commit-style.md를 따른다/tdd-plan --full로 3 에이전트 + critic 풀 플로우를 안내)기어(검토 밀도)는 이론에 대한 확신이 정한다. 확신이 낮으면 low, 상용구 수준으로 명확하면 high다(상세는 tdd-rgb의 "기어(Gears)" 섹션).
| 상황 | 기어 | 호출 |
|---|---|---|
| 낯선 도메인·기술, 학습 목적, 설계 미확정 | low | /tdd-rgb --gear=low (매 R/G/B 검토) |
| 유사 문제 경험 있음, 설계가 안정되어 감 | mid | /tdd-rgb --gear=mid (테스트 1개 사이클마다 검토) |
| 이론이 명확, 테스트 목록 전체를 자율로 | high | /tdd-rgb --gear=high (완료 + 적대적 리뷰 후 최종 검토) |
| 이론이 명확, feature 하나를 plan 합의 후 자율로 | high | /tdd-feature (Phase B = feature 범위 high) |
폭발 반경(blast radius)이 큰 영역(인증·인가, 결제·금액 계산, 데이터 삭제·변경, 외부 API, 동시성)은
기어와 무관하게 완료 시 적대적 리뷰를 1회 실행한다
(../tdd-rgb/references/gears.md의 "폭발 반경(blast radius)" 참조).
--gear 없이 /tdd-rgb만 호출해도 그 기어로 복원된다/tdd-feature는 --gear를 받지 않는다 — Phase B 자율 진행이 곧 high다# {ClassName} TDD 구현
## 절차
- [ ] 1. 앵커 작성 (규칙 + 예제 검산표 + 미확정)
- [ ] 2. 테스트 구현 (RGB 사이클)
## 규칙
## 예제 (검산표)
## 미확정
## 진행 기록
기어: low
## 배움 로그
# AI와 Pair로 {ClassName}을 TDD로 구현하기 (Web App)
## 전체적인 절차
- [ ] 1. 앵커 작성 (규칙 + 예제 검산표 + 미확정)
- [ ] 2. 인수 테스트 셋업 (.feature + Runner, 미구현은 @pending — .feature가 시나리오의 실행되는 정본)
- [ ] 3. Walking Skeleton 구현
- [ ] 4. 테스트 구현 (RGB 사이클 — 각 Green이 자기 시나리오 @pending 해제)
- [ ] 5. JPA Repository 완성 (계약 테스트로 InMemory와 동등성 검증)
- [ ] 6. DSL 개선 (Steps·Protocol Driver·Test Data Builder)
- [ ] 7. 적대적 리뷰 (high 기어 또는 폭발 반경(blast radius) high-stakes 시 — 5·6을 마친 뒤 실행, diff가 전체 구현을 포함해야 함)
- [ ] 8. 하드닝 게이트 (① CRAP·DRY 분석 → ② /system-wide-refactoring → ③ mutation 대표 파일 1개 — 제안만, 실행은 사용자 결정)
## 규칙
## 예제 (검산표)
## 미확정
## 진행 기록
기어: low
## 배움 로그
Web App은
/cucumber-acceptance가 필수다 — 1단계 앵커 작성에서 승인된 Gherkin이 2단계에서.feature로 실행되어 인수 계층을 담당한다. 별도 High Level Test(JUnit)를 두지 않는다(같은 검증이 두 계층에 중복되면 안 됨). 프로젝트 제약으로 Cucumber를 도입할 수 없는 경우에만 대표 시나리오 1개를 JUnit 인수 테스트로 작성해 대체한다.
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
동일한 결과를 내는 여러 조건문(OR 나열·중첩 AND)을 하나로 통합하고 의미 있는 boolean 메서드로 추출. "조건문 합쳐", "같은 결과 반환하는 if 정리", "중첩 if 평탄화", "/consolidate-conditional" 요청 시 사용. 단, 여러 메서드에 흩어진 동일 조건을 호출자 쪽으로 올리는 것은 /lift-up-conditional, 복잡한 조건식·분기를 메서드로 쪼개는 것은 /decompose-conditional이 적합. /consolidate-conditional [commit-ref]로 호출.
日本語の概要は準備中です。原文の説明を表示しています。
기능의 external behavior를 Cucumber 인수 테스트(주 검증층)로 구축 — .feature 실행으로 문서↔코드 드리프트를 구조적으로 차단, Four Layer(Steps→Protocol Driver→SUT), 태그 기반 가역 제외, 기존 JUnit 인수 테스트 이관. "인수 테스트 도입", "Gherkin을 실행 가능하게", "cucumber 셋업" 요청 시 사용. /cucumber-acceptance로 호출.
日本語の概要は準備中です。原文の説明を表示しています。
복잡한 if/then/else의 조건식과 각 분기를 의미 있는 메서드로 추출하여 가독성 향상. "조건문 분해", "if 가독성", "복잡한 조건식에 이름 붙여", "/decompose-conditional" 요청 시 사용. 단, 같은 결과를 내는 조건문들을 하나로 합치는 것은 /consolidate-conditional, 타입별 분기를 클래스로 바꾸는 것은 /replace-conditional-with-poly가 적합. /decompose-conditional [commit-ref]로 호출.
日本語の概要は準備中です。原文の説明を表示しています。
Primitive Obsession 제거 — 검증·연산이 따라다니는 primitive 필드(금액+통화, 이메일 문자열 등)를 도메인 개념을 담은 Value Object로 치환. "값 객체 도입", "primitive obsession", "Money 클래스로", "/discover-value-object" 요청 시 사용. 단, 함께 전달되는 파라미터 묶음을 객체로 바꾸는 것은 /introduce-parameter-object, 컬렉션을 감싸는 것은 /first-class-collection이 적합. /discover-value-object [commit-ref]로 호출.
日本語の概要は準備中です。原文の説明を表示しています。
컬렉션 getter가 내부 List/Set을 직접 노출하는 것을 방지 — unmodifiable 반환 + add/remove 메서드 제공. "컬렉션 캡슐화", "getter가 List 그대로 노출", "unmodifiable로", "/encapsulate-collection" 요청 시 사용. 단, 컬렉션과 관련 로직을 전용 클래스로 뽑는 것은 /first-class-collection이 적합. /encapsulate-collection [commit-ref]로 호출.
日本語の概要は準備中です。原文の説明を表示しています。
암묵적 의존성(전역 변수·클래스 필드·싱글턴 접근)을 명시적 파라미터로 전환하여 메서드 투명성 향상. "숨은 의존성 드러내", "필드 대신 파라미터로", "전역 참조 제거", "/explicit-parameters" 요청 시 사용. 단, 파라미터가 많아져 묶어야 하면 /introduce-parameter-object, I/O와 계산 분리는 /segregate-functional-core가 적합. /explicit-parameters [commit-ref]로 호출.
日本語の概要は準備中です。原文の説明を表示しています。