git diff 기준 변경 파일을 자동 탐지해 Composed Method 지향 Tidying Process를 TDD 사이클 없이 독립 실행. 완료 후 선택 기법 제안. "변경 파일 정리", "tidying만", "방금 바꾼 코드 정돈", "tidy first", "/tdd-tidy" 요청 시 사용. 단, 다른 클래스로 로직을 옮기는 구조 변경은 /system-wide-refactoring이 적합. /tdd-tidy [commit-ref]로 호출.
インストールする前に、エージェントに与えられる指示の中身を確認できます。
git diff로 최근 변경된 Java 파일을 자동 탐지하여, tdd-blue agent의 Local Tidying Process를 TDD 사이클 없이 독립 실행합니다.
refactor: 커밋 완료됨../../agents/references/tidying-process.md 정본)refactor: 커밋으로 완료됨 (변경이 있는 경우)인자가 전달된 경우 해당 commit ref와 비교, 없으면 unstaged + staged 변경 파일 수집:
# 인자 없음: unstaged + staged 변경 파일
git diff --name-only -- '*.java'
git diff --cached --name-only -- '*.java'
# 인자 있음: 특정 commit과 비교
git diff --name-only <commit-ref> -- '*.java'
*Test.java, *Tests.java, *Spec.java)은 제외수집된 파일 목록을 사용자에게 보여주고 확인:
다음 파일에 Tidying Process를 적용합니다:
- src/main/java/com/example/OrderService.java
- src/main/java/com/example/PaymentProcessor.java
진행할까요?
사용자 확인 후 tdd-blue agent를 standalone 모드로 호출:
[standalone] 다음 파일에 Local Tidying Process를 적용해주세요:
- src/main/java/com/example/OrderService.java
- src/main/java/com/example/PaymentProcessor.java
Local Tidying Process(단계·순서는 `../../agents/references/tidying-process.md` 정본)를 순서대로 적용하고,
One Pile 적용 시에는 항상 별도 커밋(refactor: one-pile [대상])으로 먼저 분리하고, 나머지 tidying은 별도 refactor: 커밋으로 완료해주세요.
Extract Method는 같은 클래스 내부(private 메서드 추출)로 한정한다. 다른 클래스로 옮기는 Domain Logic 이동(새 클래스가 생기는 분리 포함)은 수행하지 않는다 (system-wide-refactoring 스킬 전담).
tdd-blue agent 완료 후 사용자에게 결과 보고:
tidying 과정에서 발견된 징후에 따라 선택 기법 제안:
추가로 적용 가능한 기법이 발견되었습니다:
[발견 시에만 해당 항목 표시]
- /decompose-conditional — [파일명]의 if/then/else가 복잡합니다
- /replace-temp-with-query — [파일명]에서 임시 변수가 반복 계산됩니다
- /explicit-parameters — [파일명]에서 암묵적 필드 의존이 발견되었습니다
- /naming-process — 의도가 불분명한 이름이 [N]건 있습니다
- /intent-revealing-names — [파일명]에 긴 메서드가 남아 이름 주도 관통 리팩토링(grouping→comment→extract→6단계 rename)이 필요합니다
- /encapsulate-collection — [파일명]에서 컬렉션이 직접 노출됩니다
- /consolidate-conditional — [파일명]에서 동일 결과 조건문이 분산됩니다
- /introduce-assertion — [파일명]에서 암묵적 가정이 발견되었습니다
- /replace-loop-with-pipeline — [파일명]에서 명령형 루프를 Stream으로 변환 가능합니다
적용할 기법을 선택하세요 (slash command 또는 skip)
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
동일한 결과를 내는 여러 조건문(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]로 호출.
日本語の概要は準備中です。原文の説明を表示しています。