msbaek-tdd

Plugin msbaek-tdd from marketplace msbaek-claude-plugins in msbaek/msbaek-claude-plugins. Commands read from the repo's manifest — 16 days ago.

Skills (28)

• consolidate-conditional

  동일한 결과를 내는 여러 조건문(OR 나열·중첩 AND)을 하나로 통합하고 의미 있는 boolean 메서드로 추출. "조건문 합쳐", "같은 결과 반환하는 if 정리", "중첩 if 평탄화", "/consolidate-conditional" 요청 시 사용. 단, 여러 메서드에 흩어진 동일 조건을 호출자 쪽으로 올리는 것은 /lift-up-conditional, 복잡한 조건식·분기를 메서드로 쪼개는 것은 /decompose-conditional이 적합. /consolidate-conditional [commit-ref]로 호출.

• cucumber-acceptance

  기능의 external behavior를 Cucumber 인수 테스트(주 검증층)로 구축 — .feature 실행으로 문서↔코드 드리프트를 구조적으로 차단, Four Layer(Steps→Protocol Driver→SUT), 태그 기반 가역 제외, 기존 JUnit 인수 테스트 이관. "인수 테스트 도입", "Gherkin을 실행 가능하게", "cucumber 셋업" 요청 시 사용. /cucumber-acceptance로 호출.

• decompose-conditional

  복잡한 if/then/else의 조건식과 각 분기를 의미 있는 메서드로 추출하여 가독성 향상. "조건문 분해", "if 가독성", "복잡한 조건식에 이름 붙여", "/decompose-conditional" 요청 시 사용. 단, 같은 결과를 내는 조건문들을 하나로 합치는 것은 /consolidate-conditional, 타입별 분기를 클래스로 바꾸는 것은 /replace-conditional-with-poly가 적합. /decompose-conditional [commit-ref]로 호출.

• discover-value-object

  Primitive Obsession 제거 — 검증·연산이 따라다니는 primitive 필드(금액+통화, 이메일 문자열 등)를 도메인 개념을 담은 Value Object로 치환. "값 객체 도입", "primitive obsession", "Money 클래스로", "/discover-value-object" 요청 시 사용. 단, 함께 전달되는 파라미터 묶음을 객체로 바꾸는 것은 /introduce-parameter-object, 컬렉션을 감싸는 것은 /first-class-collection이 적합. /discover-value-ob

• encapsulate-collection

  컬렉션 getter가 내부 List/Set을 직접 노출하는 것을 방지 — unmodifiable 반환 + add/remove 메서드 제공. "컬렉션 캡슐화", "getter가 List 그대로 노출", "unmodifiable로", "/encapsulate-collection" 요청 시 사용. 단, 컬렉션과 관련 로직을 전용 클래스로 뽑는 것은 /first-class-collection이 적합. /encapsulate-collection [commit-ref]로 호출.

• explicit-parameters

  암묵적 의존성(전역 변수·클래스 필드·싱글턴 접근)을 명시적 파라미터로 전환하여 메서드 투명성 향상. "숨은 의존성 드러내", "필드 대신 파라미터로", "전역 참조 제거", "/explicit-parameters" 요청 시 사용. 단, 파라미터가 많아져 묶어야 하면 /introduce-parameter-object, I/O와 계산 분리는 /segregate-functional-core가 적합. /explicit-parameters [commit-ref]로 호출.

• extract-method-object

  지역 변수가 서로 얽혀 Extract Method가 불가능한 거대 메서드를 별도 클래스(Method Object)로 추출. "긴 메서드를 클래스로", "지역 변수 때문에 추출 불가", "method object", "/extract-method-object" 요청 시 사용. 단, 지역 변수 얽힘 없이 잘라낼 수 있는 긴 메서드는 /intent-revealing-names(grouping→extract)가 적합. /extract-method-object [commit-ref]로 호출.

• first-class-collection

  컬렉션과 그에 붙은 로직(필터·합계·검증)을 전용 클래스로 추출하여 First Class Collection 생성. "일급 컬렉션", "List<Order> 감싸는 클래스", "컬렉션 로직 모아", "/first-class-collection" 요청 시 사용. 단, getter 노출 방지만 필요하면 /encapsulate-collection, 단일 값 타입은 /discover-value-object가 적합. /first-class-collection [commit-ref]로 호출.

• intent-revealing-names

  하나의 긴 메서드를 grouping(Reorder/Chunk)·comment로 정돈해 책임을 드러낸 뒤 Arlo Belshee 6단계 네이밍(완전정직 이름 → Extract Method → Intent Revealing → Domain Abstraction)을 하나의 연속 흐름으로 관통하는 self-contained 워크플로우. "이 긴 메서드 이름이 하는 일을 안 드러낸다", "메서드 이름부터 정직하게 만들어서 쪼개줘", "이름 주도로 이 메서드 리팩토링" 요청 시 사용. 단, 여러 파일에 흩어진 개별 이름 스멜의 배치 교체는 /

• introduce-assertion

  암묵적 가정(null 아님·범위·상태)을 Assert/Validate로 명시하여 가정 위반 시 즉시 발견. "assertion 추가", "전제 조건 명시", "가정을 코드로", "/introduce-assertion" 요청 시 사용. 단, 반복되는 null 검사를 객체로 대체하는 것은 /introduce-special-case가 적합. /introduce-assertion [commit-ref]로 호출.

• introduce-parameter-object

  반복되는 파라미터 그룹을 객체로 치환(IPO)하거나, 객체에서 꺼낸 값 대신 객체 자체를 전달(Preserve Whole Object). "파라미터 객체", "인자가 너무 많아", "start·end 대신 Range로", "/introduce-parameter-object" 요청 시 사용. 단, 결과 객체가 검증·연산을 가진 도메인 값이면 /discover-value-object가 적합. /introduce-parameter-object [commit-ref]로 호출.

• introduce-special-case

  반복되는 null 검사를 Special Case(Null Object) 클래스로 대체하여 다형성으로 처리. "null 객체 패턴", "null 체크 반복 제거", "특수 케이스 클래스", "/introduce-special-case" 요청 시 사용. 단, 단순 전제 조건 명시는 /introduce-assertion, 타입별 분기 전반은 /replace-conditional-with-poly가 적합. /introduce-special-case [commit-ref]로 호출.

• lift-up-conditional

  여러 메서드·분기에 중복된 동일 조건문을 상위(호출자 또는 메서드 시작)로 끌어올려 중복 제거. "조건 위로 올려", "같은 if가 여러 메서드에", "lift up", "/lift-up-conditional" 요청 시 사용. 단, 한 메서드 안에서 동일 결과를 내는 조건문 통합은 /consolidate-conditional이 적합. /lift-up-conditional [commit-ref]로 호출.

• naming-process

  Arlo Belshee의 6단계 네이밍 프로세스와 Clean Code 네이밍 규칙을 적용해, 여러 파일에 흩어진 개별 이름 스멜(타입 반복·-er/-Utils·불용어·축약어 등)을 탐지하고 배치 교체하여 코드 가독성 향상. 단, 하나의 긴 메서드를 통째로 관통(grouping→extract→rename)하는 것은 /intent-revealing-names가 적합. /naming-process로 호출.

• replace-conditional-with-poly

  타입·상태별로 반복되는 switch/if-else 분기를 다형성(인터페이스 + 구현 클래스)으로 치환. "switch를 다형성으로", "타입 분기를 클래스로", "strategy 패턴", "/replace-conditional-with-poly" 요청 시 사용. 단, null 분기만이면 /introduce-special-case, 조건식 가독성만이면 /decompose-conditional이 적합. /replace-conditional-with-poly [commit-ref]로 호출.

• replace-loop-with-pipeline

  명령형 for/while 루프를 Stream API/Collection Pipeline으로 변환하여 데이터 흐름 의도 명확화. "스트림으로 바꿔", "루프를 파이프라인으로", "for문 stream", "/replace-loop-with-pipeline" 요청 시 사용. 단, 루프 안 로직이 컬렉션 클래스로 모여야 하면 /first-class-collection이 적합. /replace-loop-with-pipeline [commit-ref]로 호출.

• replace-temp-with-query

  임시 변수를 메서드 호출(query)로 치환하여 중복 제거·추출 용이성 확보. "임시 변수 메서드로", "temp 제거", "지역 변수를 쿼리로", "/replace-temp-with-query" 요청 시 사용. 단, 임시 변수가 서로 얽혀 치환 불가면 /extract-method-object가 적합. /replace-temp-with-query [commit-ref]로 호출.

• segregate-functional-core

  I/O + 계산 혼재 또는 Mock stub + 계산 혼재 메서드를 Functional Core / Imperative Shell(빵속빵, Impure-Pure-Impure Sandwich)로 분리. "순수 함수 분리", "I/O와 계산 나눠", "mock 없이 테스트하게", "functional core", "/segregate-functional-core" 요청 시 사용. 단, 값 반환과 부수효과 분리(CQS)만이면 /separate-query-modifier가 적합. /segregate-functional-core [commi

• separate-query-modifier

  값 반환과 부수효과가 혼재된 메서드를 Query(순수)와 Modifier(부수효과)로 분리(CQS). "쿼리와 명령 분리", "getter가 상태를 바꿔", "CQS", "/separate-query-modifier" 요청 시 사용. 단, I/O 전체를 계산에서 떼어내는 것은 /segregate-functional-core가 적합. /separate-query-modifier [commit-ref]로 호출.

• system-wide-refactoring

  대화형 System-wide Refactoring — 변경 파일에서 Extract Method·Domain Logic 이동·Pull Up 등 클래스 경계를 넘는 구조 변경 후보를 찾아 승인 후 기법별 커밋으로 적용. "구조 리팩토링", "도메인 로직 이동", "클래스 분리", "system-wide", "/system-wide-refactoring" 요청 시 사용. 단, 메서드 내부 정돈(guard clause·extract variable 등)은 /tdd-tidy가 적합. /system-wide-refactoring [commit

• tdd-feature

  간결한 plan을 사용자와 합의한 뒤, feature(use case) 하나를 RGB(Red→Green→Blue) 사이클로 끝까지 자율 구현하는 오케스트레이터. 문제 정의·기능 분해·완료조건(programmer test) 합의까지는 사용자와 피드백을 주고받고(인터랙티브), 합의 후 구현은 그 feature의 모든 test에 대해 Red 전체→Green 전체→Blue 전체 3-phase로 피드백 없이 끝까지 진행하고, feature(use case) 전체를 phase마다 하나씩 최대 3개 커밋(reviewable-commits Why

• tdd-legacy

  테스트 없는 기존 코드에 행위 보존 안전망(Characterization → Approval → Mutation)을 구축한 뒤 개선 스킬로 핸드오프. "레거시에 테스트 추가", "안전망 구축", "characterization test" 요청 시 사용. /tdd-legacy로 호출.

• tdd-plan-input

  tdd-plan에 넘길 요구사항 원천 문서(xxx-plan-input.md)를 질의응답으로 점진 작성. 주제 한 줄이나 흩어진 메모에서 시작해 범위·도메인 규칙·예제·경계 조건·미확정 사항을 채운다. "요구사항 정리", "tdd-plan 입력 문서 만들기", "TDD 시작 전 요구사항 정리" 요청 시 사용. /tdd-plan-input으로 호출.

• tdd-plan

  TDD Planning (Spec Anchored) - 얇은 앵커 문서(규칙 + 예제 검산표 + 미확정)를 에이전트 1회 + 사용자 리뷰 1회로 작성. --full로 3단계 풀 플로우(도메인 규칙→예시→테스트 목록). "TDD 계획 문서", "앵커 문서 작성", "테스트 목록 뽑아줘", "plan 세우고 TDD", "/tdd-plan" 요청 시 사용. 단, 요구사항 원천 문서를 먼저 만드는 것은 /tdd-plan-input, plan 합의 후 자율 구현까지는 /tdd-feature가 적합. /tdd-plan [plan-doc-pat

• tdd-profile

  TDD 세션이 끝난 뒤 "어디서 시간·토큰이 많이 들었나"를 단계(Skill)·에이전트별로 집계하고 병목과 model/effort 조정안을 보고한다. 세션 transcript를 읽는 사후 분석이며 코드를 바꾸지 않는다. "이번 TDD 세션 병목 분석", "토큰 어디에 썼어", "어느 단계가 느렸어", "모델 조정 제안", "/tdd-profile" 요청 시 사용.

• tdd-rgb

  TDD RGB(Red→Green→Blue) 사이클 진행 — 테스트 목록의 한 항목씩 tdd-red·tdd-green·tdd-blue 에이전트에 순차 위임하고 기어(low/mid/high)로 검토 밀도를 조절. "RGB 사이클 돌려", "다음 테스트 진행", "TDD 사이클 계속", "red-green-blue", "/tdd-rgb" 요청 시 사용. 단, feature 하나를 plan 합의 후 끝까지 자율 구현하는 것은 /tdd-feature, 계획 문서만 작성하는 것은 /tdd-plan이 적합. /tdd-rgb [plan-doc-p

• tdd-tidy

  git diff 기준 변경 파일을 자동 탐지해 Composed Method 지향 Tidying Process를 TDD 사이클 없이 독립 실행. 완료 후 선택 기법 제안. "변경 파일 정리", "tidying만", "방금 바꾼 코드 정돈", "tidy first", "/tdd-tidy" 요청 시 사용. 단, 다른 클래스로 로직을 옮기는 구조 변경은 /system-wide-refactoring이 적합. /tdd-tidy [commit-ref]로 호출.

• tdd

  TDD 오케스트레이터 — 대상 클래스(FQCN)의 템플릿 문서·테스트 클래스를 생성하고 tdd-plan→tdd-rgb 워크플로우를 안내. "TDD 시작", "TDD로 새 클래스 만들자", "테스트 주도로 시작", "/tdd" 요청 시 사용. 단, 템플릿이 이미 있는 상태에서 사이클만 돌리는 것은 /tdd-rgb, 요구사항 정리부터는 /tdd-plan-input이 적합. /tdd <general|web-app> <FQCN>으로 호출.

Subagents (10)

• tdd-acceptance-builder

  승인된 Gherkin을 .feature + Runner + Four Layer(Steps→Protocol Driver→SUT)로 구축하거나, 기존 JUnit 인수 테스트를 .feature로 이관한다. cucumber-acceptance 스킬이 대상 파악 후 위임, 완료 후 직접 커밋.

• tdd-anchor-drafter

  TDD Plan 경량 모드 전담 — 원천 자료에서 앵커 문서(규칙·예제 검산표·미확정)와 .feature용 Gherkin 초안을 1회 호출로 작성한다. tdd-plan 스킬 기본 플로우가 호출, 초안 후 메인이 사용자 리뷰 1회를 받는다.

• tdd-blue

  TDD Blue phase - Composed Method 지향 Local Tidying Process (Guard Clauses → One Pile → Reorder → Normalize Symmetries → Chunk → Comment → Extract Variable → Split Loop → Trimming). RGB 사이클의 Blue 단계 또는 tdd-tidy의 standalone 대상 파일에 적용.

• tdd-domain-modeler

  TDD Plan 단계 1 초안 작성 — 도메인 규칙(0층: 계산·절사·상태 규칙 + 검산 전개)과 User Story(INVEST 점검 포함)를 템플릿 문서에 초안으로 채운다. tdd-plan 스킬이 단계 1에서 호출, 초안 후 메인이 사용자 승인을 받는다.

• tdd-example-designer

  TDD Plan 단계 2 초안 작성 — 도메인 규칙(0층)·User Story를 Gherkin 핵심 예시로 변환하고 경계 조건 5종(수치·크기·상태·시간·집계)을 스캔한다. tdd-plan 스킬이 단계 2에서 호출, 초안 후 메인이 사용자 승인을 받는다.

• tdd-green

  TDD Green phase - 최소 구현으로 테스트 통과. TPP와 make-it-work 전략 적용. tdd-rgb·tdd-feature 오케스트레이터가 tdd-red 직후 호출.

• tdd-plan-critic

  TDD Plan 문서를 결함을 찾으려 시도하는 적대적 검증자 — 정본 부재·모순·중복·경계 누락을 찾는다. tdd-domain-modeler·tdd-example-designer·tdd-test-list의 산출물이 모두 승인된 뒤 tdd-plan 스킬이 호출. 읽기 전용(수정하지 않음).

• tdd-red

  TDD Red phase - 실패하는 테스트만 작성. TDD 1법칙 전담. tdd-rgb·tdd-feature 오케스트레이터가 각 테스트 사이클의 첫 단계로 호출.

• tdd-skeleton-builder

  Walking Skeleton(실제 HTTP → 실제 앱 → 실제 DB의 가장 얇은 슬라이스)을 구축한다. OSIV·트랜잭션 경계·LAZY·DTO 등 영속성 경계를 이 단계에서 함께 확정. tdd-plan 단계 E-2에서 위임, 완료 후 직접 커밋.

• tdd-test-list

  TDD Plan 단계 3 초안 작성 — Gherkin에 없는 세밀 분기·내부 협력만 unit test 목록으로 정리하고 Degenerate→General 순서로 정렬한다. tdd-plan 스킬이 단계 3에서 호출, 초안 후 메인이 사용자 승인을 받는다.

Hooks (4)

• PreToolUse

  bash ${CLAUDE_PLUGIN_ROOT}/hooks/block-hunk-reviewer.sh

• PreToolUse

  bash ${CLAUDE_PLUGIN_ROOT}/hooks/observe-agent-start.sh

• PreToolUse

  bash ${CLAUDE_PLUGIN_ROOT}/hooks/mark-tdd-active.sh

• PostToolUse

  bash ${CLAUDE_PLUGIN_ROOT}/hooks/observe-agent-end.sh

Similar plugins