dev-cycle-tdd

Dev Cycle (TDD)

TDD 방식으로 전체 개발 사이클을 단계별로 진행합니다.

입력

$ARGUMENTS

자동 진행 모드

작업 시작 전 echo $CLAUDE_CODE_SKIP_PERMISSIONS를 실행하여 값을 확인하세요.

• 값이 1이면 bypass permissions 모드로, 각 단계의 사용자 확인을 자동 승인하고 즉시 다음 단계로 진행하세요.
• 값이 비어있거나 0이면 기존 방식대로 각 단계마다 사용자 확인을 받으세요.

진행 방식

각 단계 완료 후 반드시 사용자 확인을 받고 다음 단계로 넘어가세요. (bypass permissions 모드 제외) 사용자가 수정을 요청하면 해당 단계를 다시 수행하세요.

---

STEP 1 — Plan (테스트 목록 포함)

$ARGUMENTS에서 작업 설명 부분을 추출하여 계획을 수립하세요:

1. 프로젝트 구조와 관련 코드를 탐색하세요.
2. git rev-parse --show-toplevel 명령으로 프로젝트 루트 경로를 확인하세요.
3. docs/PLAN.md를 프로젝트 루트에 작성하세요. (docs/ 폴더가 없으면 생성하세요.)

PLAN.md에는 반드시 테스트 목록 섹션이 포함되어야 합니다:

## 테스트 목록

### [클래스명]
- [ ] [동작 설명]
- [ ] [동작 설명]

### [클래스명]
- [ ] [동작 설명]

테스트 목록 작성 기준:

• 클래스/함수 단위로 그룹화합니다.
• 하나의 항목은 하나의 동작만 설명합니다.
• UI 레이어(Fragment/Composable)는 TDD 범위 밖으로 제외합니다.
• ViewModel, UseCase, Repository, 유틸 클래스를 중심으로 작성합니다.

4. 계획을 대화에 출력하세요.
5. bypass permissions 모드가 아닌 경우 사용자에게 확인을 요청하세요:

📋 계획이 작성되었습니다. docs/PLAN.md의 테스트 목록을 확인해주세요.
테스트 목록이 충분한가요? 수정이 필요하면 알려주세요. 진행할까요? (y/수정 요청)

---

STEP 2 — TDD Code (Red → Green → Refactor)

bypass permissions 모드가 아닌 경우 사용자 승인 후 진행하세요.

kotlin-expert sub-agent에게 다음 지시와 함께 작업을 위임하세요:

PLAN.md의 테스트 목록을 TDD 방식으로 구현하세요. 테스트 목록의 각 항목에 대해 다음 사이클을 반복합니다:

RED — 실패하는 테스트 하나를 작성합니다.

• // given, // when, // then 주석을 반드시 포함합니다.
• 테스트를 실행하여 실패를 직접 확인합니다.

  ./gradlew :<모듈>:testDebugUnitTest --tests "*.<TestClass>.<테스트이름>"
  

• 테스트가 통과한다면 테스트를 수정합니다. 에러가 난다면 에러를 고쳐 올바르게 실패하게 합니다.

GREEN — 테스트를 통과하는 최소한의 코드를 작성합니다.

• 테스트를 실행하여 통과를 직접 확인합니다.
• 다른 테스트가 깨졌다면 즉시 수정합니다.

REFACTOR — 그린 상태를 유지하면서 중복 제거, 이름 개선, 헬퍼 추출을 합니다.

• 동작을 추가하지 않습니다.

완료 — PLAN.md에서 해당 항목을 - [x]로 체크합니다.

다음 항목으로 넘어가 반복합니다.

철칙: 테스트보다 코드를 먼저 작성하지 않습니다. 테스트가 실패하는 것을 보지 않았다면 올바른 것을 테스트하는지 알 수 없습니다.

sub-agent가 완료되면 작업 요약을 대화에 출력하세요:

• 구현된 테스트 목록 (PLAN.md 체크 현황)
• 생성/수정된 파일 목록

bypass permissions 모드가 아닌 경우 사용자에게 확인을 요청하세요:

💻 TDD 코딩이 완료되었습니다.
구현된 테스트 목록을 확인해주세요. 수정이 필요하면 알려주세요. 리뷰를 진행할까요? (y/수정 요청)

---

STEP 3 — Review

bypass permissions 모드가 아닌 경우 사용자 승인 후 진행하세요.

1. code-reviewer sub-agent에게 리뷰를 위임하세요.

   • 리뷰 시 테스트 코드도 함께 검토 대상에 포함합니다.
   • 다음 항목을 추가로 확인하도록 지시하세요:
     • 모든 새 함수/메서드에 테스트가 있는지
     • 각 테스트에 // given, // when, // then 주석이 있는지
     • Thread.sleep() 또는 Dispatchers.Main 직접 사용 여부 (안티패턴)
     • mock이 실제 동작이 아닌 mock 동작을 검증하는지 (안티패턴)

2. 리뷰 결과를 대화에 출력하세요.

3. Critical 항목이 있으면:

   • 수정이 필요한 항목을 목록으로 보여주세요.
   • kotlin-expert sub-agent에게 수정을 위임하세요. (TDD 원칙 유지)
   • 수정 완료 후 재리뷰하세요.

4. Critical 항목이 없으면 bypass permissions 모드가 아닌 경우 사용자에게 확인을 요청하세요:

✅ 리뷰가 완료되었습니다.
커밋을 진행할까요? (y/수정 요청)

---

STEP 4 — Commit

bypass permissions 모드가 아닌 경우 사용자 승인 후 진행하세요.

1. git branch --show-current로 브랜치명에서 이슈 번호를 추출하세요.
   • 브랜치명 패턴 예: feature/#130/enhancement, fix/#31/crash-on-rotate
   • # 뒤의 숫자를 이슈 번호로 사용합니다. 찾지 못하면 사용자에게 입력받으세요.
2. git diff HEAD로 변경사항을 분석하여 적절한 type을 선택하세요.
3. 아래 형식으로 커밋 메시지를 작성하세요:

issue #<이슈번호> <type> : <메시지>

type 종류: feat, fix, refactor, chore, test, docs, style, perf

5. bypass permissions 모드가 아닌 경우 커밋 메시지를 대화에 출력하고 사용자 확인을 받으세요:

📝 커밋 메시지:
---
[작성된 메시지]
---
이대로 커밋할까요? (y/수정 요청)

6. 승인되면 (또는 bypass permissions 모드이면) git add와 git commit을 실행하세요.

---

완료

커밋 완료 후 전체 사이클 요약을 출력하세요:

🎉 TDD 개발 사이클 완료!

- 📋 계획: docs/PLAN.md
- 🧪 테스트: [통과 항목 수]/[전체 항목 수]
- 📝 결정 기록: docs/decisions/DECISIONS.md (생성된 경우)
- ✅ 커밋: [커밋 해시]