All authors
Claude Skills by msbaek
github.com/msbaek28 skills0 installs3 views
- Consolidate Conditional동일한 결과를 내는 여러 조건문(OR 나열·중첩 AND)을 하나로 통합하고 의미 있는 boolean 메서드로 추출. "조건문 합쳐", "같은 결과 반환하는 if 정리", "중첩 if 평탄화", "/consolidate-conditional" 요청 시 사용. 단, 여러 메서드에 흩어진 동일 조건을 호출자 쪽으로 올리는 것은 /lift-up-conditional, 복잡한 조건식·분기를 메서드로 쪼개는 것은 /decompose-conditional이 적합. /consolidate-conditional [commit-ref]로 호출.Votes: 0GitHub stars: 8
- Cucumber Acceptance기능의 external behavior를 Cucumber 인수 테스트(주 검증층)로 구축 — .feature 실행으로 문서↔코드 드리프트를 구조적으로 차단, Four Layer(Steps→Protocol Driver→SUT), 태그 기반 가역 제외, 기존 JUnit 인수 테스트 이관. "인수 테스트 도입", "Gherkin을 실행 가능하게", "cucumber 셋업" 요청 시 사용. /cucumber-acceptance로 호출.Votes: 0GitHub stars: 8
- Decompose Conditional복잡한 if/then/else의 조건식과 각 분기를 의미 있는 메서드로 추출하여 가독성 향상. "조건문 분해", "if 가독성", "복잡한 조건식에 이름 붙여", "/decompose-conditional" 요청 시 사용. 단, 같은 결과를 내는 조건문들을 하나로 합치는 것은 /consolidate-conditional, 타입별 분기를 클래스로 바꾸는 것은 /replace-conditional-with-poly가 적합. /decompose-conditional [commit-ref]로 호출.Votes: 0GitHub stars: 8
- Discover Value ObjectPrimitive Obsession 제거 — 검증·연산이 따라다니는 primitive 필드(금액+통화, 이메일 문자열 등)를 도메인 개념을 담은 Value Object로 치환. "값 객체 도입", "primitive obsession", "Money 클래스로", "/discover-value-object" 요청 시 사용. 단, 함께 전달되는 파라미터 묶음을 객체로 바꾸는 것은 /introduce-parameter-object, 컬렉션을 감싸는 것은 /first-class-collection이 적합. /discover-value-object [commit-ref]로 호출.Votes: 0GitHub stars: 8
- Encapsulate Collection컬렉션 getter가 내부 List/Set을 직접 노출하는 것을 방지 — unmodifiable 반환 + add/remove 메서드 제공. "컬렉션 캡슐화", "getter가 List 그대로 노출", "unmodifiable로", "/encapsulate-collection" 요청 시 사용. 단, 컬렉션과 관련 로직을 전용 클래스로 뽑는 것은 /first-class-collection이 적합. /encapsulate-collection [commit-ref]로 호출.Votes: 0GitHub stars: 8
- Explicit Parameters암묵적 의존성(전역 변수·클래스 필드·싱글턴 접근)을 명시적 파라미터로 전환하여 메서드 투명성 향상. "숨은 의존성 드러내", "필드 대신 파라미터로", "전역 참조 제거", "/explicit-parameters" 요청 시 사용. 단, 파라미터가 많아져 묶어야 하면 /introduce-parameter-object, I/O와 계산 분리는 /segregate-functional-core가 적합. /explicit-parameters [commit-ref]로 호출.Votes: 0GitHub stars: 8
- Extract Method Object지역 변수가 서로 얽혀 Extract Method가 불가능한 거대 메서드를 별도 클래스(Method Object)로 추출. "긴 메서드를 클래스로", "지역 변수 때문에 추출 불가", "method object", "/extract-method-object" 요청 시 사용. 단, 지역 변수 얽힘 없이 잘라낼 수 있는 긴 메서드는 /intent-revealing-names(grouping→extract)가 적합. /extract-method-object [commit-ref]로 호출.Votes: 0GitHub stars: 8
- First Class Collection컬렉션과 그에 붙은 로직(필터·합계·검증)을 전용 클래스로 추출하여 First Class Collection 생성. "일급 컬렉션", "List<Order> 감싸는 클래스", "컬렉션 로직 모아", "/first-class-collection" 요청 시 사용. 단, getter 노출 방지만 필요하면 /encapsulate-collection, 단일 값 타입은 /discover-value-object가 적합. /first-class-collection [commit-ref]로 호출.Votes: 0GitHub stars: 8
- Intent Revealing Names하나의 긴 메서드를 grouping(Reorder/Chunk)·comment로 정돈해 책임을 드러낸 뒤 Arlo Belshee 6단계 네이밍(완전정직 이름 → Extract Method → Intent Revealing → Domain Abstraction)을 하나의 연속 흐름으로 관통하는 self-contained 워크플로우. "이 긴 메서드 이름이 하는 일을 안 드러낸다", "메서드 이름부터 정직하게 만들어서 쪼개줘", "이름 주도로 이 메서드 리팩토링" 요청 시 사용. 단, 여러 파일에 흩어진 개별 이름 스멜의 배치 교체는 /naming-process, 클래스 분리·도메인 이동 같은 대규모 구조 변경은 /system-wide-refactoring이 적합. /intent-revealing-names로 호출.Votes: 0GitHub stars: 8
- Introduce Assertion암묵적 가정(null 아님·범위·상태)을 Assert/Validate로 명시하여 가정 위반 시 즉시 발견. "assertion 추가", "전제 조건 명시", "가정을 코드로", "/introduce-assertion" 요청 시 사용. 단, 반복되는 null 검사를 객체로 대체하는 것은 /introduce-special-case가 적합. /introduce-assertion [commit-ref]로 호출.Votes: 0GitHub stars: 8
- Introduce Parameter Object반복되는 파라미터 그룹을 객체로 치환(IPO)하거나, 객체에서 꺼낸 값 대신 객체 자체를 전달(Preserve Whole Object). "파라미터 객체", "인자가 너무 많아", "start·end 대신 Range로", "/introduce-parameter-object" 요청 시 사용. 단, 결과 객체가 검증·연산을 가진 도메인 값이면 /discover-value-object가 적합. /introduce-parameter-object [commit-ref]로 호출.Votes: 0GitHub stars: 8
- Introduce Special Case반복되는 null 검사를 Special Case(Null Object) 클래스로 대체하여 다형성으로 처리. "null 객체 패턴", "null 체크 반복 제거", "특수 케이스 클래스", "/introduce-special-case" 요청 시 사용. 단, 단순 전제 조건 명시는 /introduce-assertion, 타입별 분기 전반은 /replace-conditional-with-poly가 적합. /introduce-special-case [commit-ref]로 호출.Votes: 0GitHub stars: 8
- Lift Up Conditional여러 메서드·분기에 중복된 동일 조건문을 상위(호출자 또는 메서드 시작)로 끌어올려 중복 제거. "조건 위로 올려", "같은 if가 여러 메서드에", "lift up", "/lift-up-conditional" 요청 시 사용. 단, 한 메서드 안에서 동일 결과를 내는 조건문 통합은 /consolidate-conditional이 적합. /lift-up-conditional [commit-ref]로 호출.Votes: 0GitHub stars: 8
- Naming ProcessArlo Belshee의 6단계 네이밍 프로세스와 Clean Code 네이밍 규칙을 적용해, 여러 파일에 흩어진 개별 이름 스멜(타입 반복·-er/-Utils·불용어·축약어 등)을 탐지하고 배치 교체하여 코드 가독성 향상. 단, 하나의 긴 메서드를 통째로 관통(grouping→extract→rename)하는 것은 /intent-revealing-names가 적합. /naming-process로 호출.Votes: 0GitHub stars: 8
- 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]로 호출.Votes: 0GitHub stars: 8
- 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]로 호출.Votes: 0GitHub stars: 8
- Replace Temp With Query임시 변수를 메서드 호출(query)로 치환하여 중복 제거·추출 용이성 확보. "임시 변수 메서드로", "temp 제거", "지역 변수를 쿼리로", "/replace-temp-with-query" 요청 시 사용. 단, 임시 변수가 서로 얽혀 치환 불가면 /extract-method-object가 적합. /replace-temp-with-query [commit-ref]로 호출.Votes: 0GitHub stars: 8
- Segregate Functional CoreI/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 [commit-ref]로 호출.Votes: 0GitHub stars: 8
- Separate Query Modifier값 반환과 부수효과가 혼재된 메서드를 Query(순수)와 Modifier(부수효과)로 분리(CQS). "쿼리와 명령 분리", "getter가 상태를 바꿔", "CQS", "/separate-query-modifier" 요청 시 사용. 단, I/O 전체를 계산에서 떼어내는 것은 /segregate-functional-core가 적합. /separate-query-modifier [commit-ref]로 호출.Votes: 0GitHub stars: 8
- 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-ref]로 호출.Votes: 0GitHub stars: 8
- 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-body 포함)으로 남긴다(자율). superpowers의 장황한 spec/plan 대신 개발에 맞는 간결 포맷을 쓴다. "기능을 TDD로 끝까지 구현", "plan 합의하고 자율 구현", "feature 단위 RGB", "use case TDD로 짜줘", "/tdd-feature" 요청 시 반드시 사용. 후속 "이어서", "다음 feature", ...Votes: 0GitHub stars: 8
- Tdd Legacy테스트 없는 기존 코드에 행위 보존 안전망(Characterization → Approval → Mutation)을 구축한 뒤 개선 스킬로 핸드오프. "레거시에 테스트 추가", "안전망 구축", "characterization test" 요청 시 사용. /tdd-legacy로 호출.Votes: 0GitHub stars: 8
- Tdd Plan Inputtdd-plan에 넘길 요구사항 원천 문서(xxx-plan-input.md)를 질의응답으로 점진 작성. 주제 한 줄이나 흩어진 메모에서 시작해 범위·도메인 규칙·예제·경계 조건·미확정 사항을 채운다. "요구사항 정리", "tdd-plan 입력 문서 만들기", "TDD 시작 전 요구사항 정리" 요청 시 사용. /tdd-plan-input으로 호출.Votes: 0GitHub stars: 8
- Tdd PlanTDD Planning (Spec Anchored) - 얇은 앵커 문서(규칙 + 예제 검산표 + 미확정)를 에이전트 1회 + 사용자 리뷰 1회로 작성. --full로 3단계 풀 플로우(도메인 규칙→예시→테스트 목록). "TDD 계획 문서", "앵커 문서 작성", "테스트 목록 뽑아줘", "plan 세우고 TDD", "/tdd-plan" 요청 시 사용. 단, 요구사항 원천 문서를 먼저 만드는 것은 /tdd-plan-input, plan 합의 후 자율 구현까지는 /tdd-feature가 적합. /tdd-plan [plan-doc-path] [--full]로 호출.Votes: 0GitHub stars: 8
- Tdd ProfileTDD 세션이 끝난 뒤 "어디서 시간·토큰이 많이 들었나"를 단계(Skill)·에이전트별로 집계하고 병목과 model/effort 조정안을 보고한다. 세션 transcript를 읽는 사후 분석이며 코드를 바꾸지 않는다. "이번 TDD 세션 병목 분석", "토큰 어디에 썼어", "어느 단계가 느렸어", "모델 조정 제안", "/tdd-profile" 요청 시 사용.Votes: 0GitHub stars: 8
- Tdd RgbTDD 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-path] [--gear=low|mid|high]로 호출.Votes: 0GitHub stars: 8
- Tdd Tidygit diff 기준 변경 파일을 자동 탐지해 Composed Method 지향 Tidying Process를 TDD 사이클 없이 독립 실행. 완료 후 선택 기법 제안. "변경 파일 정리", "tidying만", "방금 바꾼 코드 정돈", "tidy first", "/tdd-tidy" 요청 시 사용. 단, 다른 클래스로 로직을 옮기는 구조 변경은 /system-wide-refactoring이 적합. /tdd-tidy [commit-ref]로 호출.Votes: 0GitHub stars: 8
- TddTDD 오케스트레이터 — 대상 클래스(FQCN)의 템플릿 문서·테스트 클래스를 생성하고 tdd-plan→tdd-rgb 워크플로우를 안내. "TDD 시작", "TDD로 새 클래스 만들자", "테스트 주도로 시작", "/tdd" 요청 시 사용. 단, 템플릿이 이미 있는 상태에서 사이클만 돌리는 것은 /tdd-rgb, 요구사항 정리부터는 /tdd-plan-input이 적합. /tdd <general|web-app> <FQCN>으로 호출.Votes: 0GitHub stars: 8