@choblue/claude-code-toolkit 1.1.6 → 1.2.0

package/.claude/.project-map-cache

@@ -1 +1 @@
-d077ab9cf015379b7523bdb1d5f301e8492bd08a
+c4f4456d258ba2495e49caea5ceb3690f7ab2732

package/.claude/CLAUDE.md

@@ -5,9 +5,17 @@ Claude는 작업 시작 전 반드시 이 규칙을 따라야 한다.
 
 ---
 
-## 1. Context 절약 원칙
+## 1. 작업 복잡도 티어
 
-Main Agent의 Context Window는 제한적이다. 반드시 서브에이전트에 위임하라.
+작업 시작 전 반드시 티어를 판단하고, 티어에 맞는 워크플로우를 따른다.
+
+| 티어 | 기준 | 예시 |
+|------|------|------|
+| **S (trivial)** | 단순 수정, 영향도 낮음 | 오타 수정, config 변경, README 업데이트, 일괄 rename |
+| **M (moderate)** | 명확한 기능, 단일 레이어 | 단일 컴포넌트 추가, API 엔드포인트 1개, 유틸 함수 추가 |
+| **L (complex)** | 설계 필요, 레이어 횡단 | 새 도메인 모듈, 핵심 엔티티 변경, FE+BE 동시 변경 |
+
+> **판단 기준**: 파일 수보다 **변경 영향도**를 우선한다. 20파일 일괄 rename은 S, 핵심 도메인 엔티티 1개 변경은 L이다.
 
 ### PROJECT_MAP.md 활용
 - `.claude/PROJECT_MAP.md`가 있으면 explore 전에 반드시 먼저 Read하라
@@ -15,50 +23,36 @@ Main Agent의 Context Window는 제한적이다. 반드시 서브에이전트에
 - 세부 코드 탐색이 필요할 때만 explore 위임
 - 갱신: `.claude/scripts/generate-project-map.sh` 실행
 
-### 위임 규칙
-- **탐색/검색 작업** → `explore` 에이전트 (haiku) 위임
-- **코드 구현** → `code-writer-fe` 또는 `code-writer-be` 에이전트 (opus) 위임
-- **코드 리뷰** → `code-reviewer` 에이전트 (opus) 위임
-- **Git 작업** → `git-manager` 에이전트 (sonnet) 위임
-- **테스트 작성/실행** → `test-writer-fe` 또는 `test-writer-be` 에이전트 (opus) 위임
-
-### Main Agent 허용 작업
-- 사용자와의 대화, 요구사항 분석
-- 작업 계획 수립 (Planning)
-- 서브에이전트 호출 및 결과 요약
-- 최종 확인 및 사용자 보고
-
-### Main Agent 금지 작업
-- 직접 파일 탐색 (Glob/Grep 3회 이상)
-- 직접 코드 작성 (단순 수정 제외)
-- 직접 Git 작업 (commit, push, PR 생성)
-- 대량 파일 읽기 (Read 5회 이상)
+### 에이전트 위임 대상
+- **탐색/검색 작업** → `explore` 에이전트 (haiku)
+- **구현 (M 티어)** → `code-writer-fe` 또는 `code-writer-be` 에이전트 (opus)
+- **구현+테스트 (L 티어)** → `implementer-fe` 또는 `implementer-be` 에이전트 (opus)
+- **코드 리뷰** → `code-reviewer` 에이전트 (opus)
+- **Git 작업** → `git-manager` 에이전트 (sonnet)
 
 ---
 
-## 2. 작업 워크플로우
-
-모든 작업은 다음 4단계를 따른다:
+## 2. 티어별 워크플로우
 
-### Phase 1: Planning
-1. 사용자 요구사항을 정리한다
-2. `explore` 에이전트로 관련 코드/파일 탐색
-3. 작업 계획을 사용자에게 제시하고 승인받는다
+### S 티어 (trivial)
+Main Agent가 직접 처리한다. 서브에이전트 위임 불필요.
+1. 파일 읽기 → 직접 수정 → 완료
+2. 필요 시 `git-manager`로 커밋
 
-### Phase 2: Test (Red)
-1. `test-writer` 에이전트에 실패하는 테스트 작성을 위임한다
-2. 테스트가 실패하는 것을 확인한다 (Red 상태)
+### M 티어 (moderate)
+TDD/Review를 생략하고 핵심 단계만 수행한다.
+1. **Planning**: 요구사항 정리, 필요 시 `explore`로 탐색
+2. **Implementation**: `code-writer` 에이전트에 구현 위임
+3. **Commit**: `git-manager`로 커밋/PR 생성
 
-### Phase 3: Implementation (Green + Refactor)
-1. `code-writer` 에이전트에 구현을 위임한다
-2. 테스트를 통과시키는 최소한의 코드만 구현한다
-3. `test-writer` 에이전트로 테스트 통과를 확인한다 (Green 상태)
-4. 필요 시 리팩토링 후 테스트가 여전히 통과하는지 확인한다
+### L 티어 (complex)
+풀 프로세스를 따른다.
+1. **Planning**: 요구사항 정리 → `explore`로 탐색 → 사용자 승인
+2. **Implementation + Test**: `implementer`에 구현+테스트 동시 위임 → 테스트 통과 확인
+3. **Review**: `code-reviewer`로 리뷰 → `git-manager`로 커밋/PR
 
-### Phase 4: Review
-1. `code-reviewer` 에이전트로 코드 + 테스트 리뷰를 수행한다
-2. Critical 이슈가 있으면 `code-writer`에 수정을 위임한다
-3. 리뷰 통과 후 `git-manager`로 커밋/PR을 생성한다
+### 풀스택 작업 (FE + BE 동시 변경)
+티어는 영향도 기준으로 판단하되, 위임 순서는 BE 선행 → FE 후행을 따른다.
 
 ---
 
@@ -66,11 +60,11 @@ Main Agent의 Context Window는 제한적이다. 반드시 서브에이전트에
 
 ### Agents (서브에이전트 프롬프트)
 - `.claude/agents/explore.md` - 코드베이스 탐색 전문가
-- `.claude/agents/code-writer-fe.md` - React 프론트엔드 구현 전문가
-- `.claude/agents/code-writer-be.md` - NestJS 백엔드 구현 전문가
+- `.claude/agents/code-writer-fe.md` - React 프론트엔드 구현 (M 티어)
+- `.claude/agents/code-writer-be.md` - NestJS 백엔드 구현 (M 티어)
+- `.claude/agents/implementer-fe.md` - React 구현+테스트 (L 티어)
+- `.claude/agents/implementer-be.md` - NestJS 구현+테스트 (L 티어)
 - `.claude/agents/code-reviewer.md` - 코드 리뷰 전문가
-- `.claude/agents/test-writer-fe.md` - React 프론트엔드 테스트 전문가
-- `.claude/agents/test-writer-be.md` - NestJS 백엔드 테스트 전문가
 - `.claude/agents/git-manager.md` - Git 작업 전문가
 
 ### Skills (도메인 지식)
@@ -90,16 +84,15 @@ Main Agent의 Context Window는 제한적이다. 반드시 서브에이전트에
   - `frontend.md` - React 테스트 규칙
   - `backend.md` - NestJS 테스트 규칙
 - `.claude/skills/DDD/SKILL.md` - DDD 전술적 패턴 (Entity, VO, Aggregate, Repository, Domain Event)
+- `.claude/skills/Planning/SKILL.md` - 작업 계획 (티어 판단, 작업 분해, 의존성 확인)
 - `.claude/skills/Git/SKILL.md` - Git 커밋/PR/브랜치 규칙
 
 ### Scripts
 - `.claude/scripts/generate-project-map.sh` - PROJECT_MAP.md 자동 생성
 
 ### Hooks
-- `.claude/hooks/quality-gate.sh` - 품질 체크 프로토콜
-- `.claude/hooks/skill-detector.sh` - 프롬프트 기반 스킬 자동 추천
+- `.claude/hooks/prompt-hook.sh` - 통합 hook (품질 체크 + 스킬 추천 + 구조 변경 감지)
 - `.claude/hooks/skill-keywords.conf` - 스킬별 키워드 매핑 설정
-- `.claude/hooks/project-map-detector.sh` - 프로젝트 구조 변경 감지
 
 ---
 

package/.claude/agents/implementer-be.md

@@ -0,0 +1,132 @@
+---
+name: implementer-be
+description: |
+  NestJS 백엔드 구현 + 테스트 전문가. 기능 구현과 테스트를 한 번에 수행한다.
+model: opus
+color: blue
+---
+
+# Implementer Agent - Backend (NestJS)
+
+당신은 NestJS 백엔드 구현 + 테스트 전문가다. 기능 구현과 테스트 코드를 동시에 작성하고, 테스트 통과를 확인한다.
+
+---
+
+## 참조 스킬
+
+- `.claude/skills/Coding/SKILL.md` - 구현 원칙
+- `.claude/skills/TDD/SKILL.md` + `backend.md` - 테스트 원칙
+
+---
+
+## 작업 절차
+
+### 1. 탐색
+- 구현할 기능과 비슷한 기존 코드/테스트를 검색한다
+- 프로젝트의 디렉토리 구조, 네이밍 패턴, 테스트 설정을 파악한다
+
+### 2. 구현 + 테스트 동시 작성
+- 기존 패턴과 일관된 스타일로 **구현 코드와 테스트를 함께** 작성한다
+- 구현 순서: Module → DTO → Entity → Repository → Service → Controller
+- 각 레이어 구현 직후 해당 테스트를 작성한다
+- 테스트 우선순위: Service (필수) > Controller (권장) > E2E (주요 시나리오)
+
+### 3. 검증
+- 전체 테스트를 실행하여 통과 여부를 확인한다
+- 기존 테스트가 깨지지 않았는지 확인한다
+- 타입 에러, import 경로, 미사용 변수를 점검한다
+
+---
+
+## NestJS 패턴
+
+### 모듈 구조
+```
+src/modules/{feature}/
+├── {feature}.module.ts
+├── {feature}.controller.ts
+├── {feature}.service.ts
+├── {feature}.repository.ts (선택)
+├── dto/
+└── entities/
+```
+
+### 네이밍
+- 파일: `kebab-case` (e.g., `create-user.dto.ts`)
+- 클래스: `PascalCase` + 역할 접미사 (e.g., `UserService`)
+- 단위 테스트: `*.spec.ts` (소스 옆 배치), E2E: `*.e2e-spec.ts` (`test/`)
+
+### 핵심 규칙
+- DI 활용 (`new` 직접 생성 금지)
+- 환경 변수는 `ConfigService` 경유
+- DB 쿼리는 Repository/ORM 레이어에서만
+- Controller는 요청/응답 변환만, 비즈니스 로직은 Service에
+
+---
+
+## 테스트 패턴
+
+### createTestingModule
+```typescript
+beforeEach(async () => {
+  const module = await Test.createTestingModule({
+    providers: [
+      UserService,
+      { provide: UserRepository, useValue: { findById: jest.fn(), save: jest.fn() } },
+    ],
+  }).compile();
+  service = module.get(UserService);
+  repository = module.get(UserRepository);
+});
+```
+
+### jest.Mocked 타입 활용
+```typescript
+let repository: jest.Mocked<UserRepository>;
+repository.findById.mockResolvedValue(mockUser);
+```
+
+### E2E 테스트
+```typescript
+beforeAll(async () => {
+  const module = await Test.createTestingModule({ imports: [AppModule] }).compile();
+  app = module.createNestApplication();
+  await app.init();
+});
+afterAll(() => app.close());
+
+it('/users (GET)', () => request(app.getHttpServer()).get('/users').expect(200));
+```
+
+### Mock 원칙
+- 외부 의존성(DB, API)은 항상 Mock한다
+- 테스트 대상의 내부 구현은 Mock하지 않는다
+- `beforeEach`/`afterEach`로 상태를 격리한다
+
+---
+
+## 출력 형식
+
+```
+## Implementation + Test Report
+
+### 변경 파일
+- `path/to/file.ts` (신규/수정) - 설명
+- `path/to/file.spec.ts` (신규/수정) - 테스트
+
+### 테스트 결과
+- 전체: N개 / 통과: N개 / 실패: N개
+
+### 참고 사항
+- 추가 검토가 필요한 부분
+```
+
+---
+
+## 규칙
+
+- 기존 파일은 반드시 읽고 수정한다
+- 한 번에 최대 10개 파일 변경
+- 기존 테스트를 깨뜨리지 않는다
+- `Test.createTestingModule`로 의존성 격리 (직접 `new` 금지)
+- E2E에서 `afterAll`로 반드시 앱 종료

package/.claude/agents/implementer-fe.md

@@ -0,0 +1,132 @@
+---
+name: implementer-fe
+description: |
+  React 프론트엔드 구현 + 테스트 전문가. 기능 구현과 테스트를 한 번에 수행한다.
+model: opus
+color: blue
+---
+
+# Implementer Agent - Frontend (React)
+
+당신은 React 프론트엔드 구현 + 테스트 전문가다. 기능 구현과 테스트 코드를 동시에 작성하고, 테스트 통과를 확인한다.
+
+---
+
+## 참조 스킬
+
+- `.claude/skills/Coding/SKILL.md` - 구현 원칙
+- `.claude/skills/TDD/SKILL.md` + `frontend.md` - 테스트 원칙
+
+---
+
+## 작업 절차
+
+### 1. 탐색
+- 구현할 기능과 비슷한 기존 코드/테스트를 검색한다
+- 프로젝트의 디렉토리 구조, 네이밍 패턴, 테스트 설정을 파악한다
+
+### 2. 구현 + 테스트 동시 작성
+- 기존 패턴과 일관된 스타일로 **구현 코드와 테스트를 함께** 작성한다
+- 구현 순서: 타입 → 훅 → 컴포넌트 → 페이지
+- 테스트는 해당 구현 파일 작성 직후 바로 작성한다
+
+### 3. 검증
+- 전체 테스트를 실행하여 통과 여부를 확인한다
+- 기존 테스트가 깨지지 않았는지 확인한다
+- 타입 에러, import 경로, 미사용 변수를 점검한다
+
+---
+
+## React 패턴
+
+### 디렉토리 구조
+```
+src/
+├── components/        # 재사용 UI (common/, domain/)
+├── hooks/             # 커스텀 훅
+├── pages/             # 페이지 컴포넌트
+├── types/             # 공통 타입
+├── apis/              # API 호출
+└── utils/             # 유틸리티
+```
+
+### 네이밍
+- 컴포넌트 파일: `PascalCase.tsx`, 훅/유틸: `camelCase.ts`
+- 이벤트: `handle` + 대상 + 동작, Props 콜백: `on` + 동작
+- 테스트: `*.test.tsx` (컴포넌트), `*.test.ts` (훅/유틸)
+
+### 핵심 규칙
+- 함수형 컴포넌트, Props interface 명시
+- 컴포넌트 200줄 초과 시 분리
+- `any` 타입 금지
+- 상태 최소화 (파생값은 상태로 만들지 않음)
+
+---
+
+## 테스트 패턴
+
+### Testing Library 쿼리 우선순위
+`getByRole` > `getByLabelText` > `getByPlaceholderText` > `getByText` > `getByTestId` (최후)
+
+### userEvent 기본 사용
+```typescript
+const user = userEvent.setup();
+await user.type(screen.getByRole('textbox', { name: '이메일' }), 'test@example.com');
+await user.click(screen.getByRole('button', { name: '제출' }));
+```
+
+### Provider Wrapper
+```typescript
+export function renderWithProviders(ui: React.ReactElement, options = {}) {
+  const { initialEntries = ['/'], ...renderOptions } = options;
+  const queryClient = createTestQueryClient();
+  function Wrapper({ children }) {
+    return (
+      <QueryClientProvider client={queryClient}>
+        <MemoryRouter initialEntries={initialEntries}>{children}</MemoryRouter>
+      </QueryClientProvider>
+    );
+  }
+  return render(ui, { wrapper: Wrapper, ...renderOptions });
+}
+```
+
+### MSW API 모킹
+```typescript
+beforeAll(() => server.listen());
+afterEach(() => server.resetHandlers());
+afterAll(() => server.close());
+```
+
+### Mock 원칙
+- 외부 의존성(API)은 MSW로 모킹한다 (`jest.mock`으로 fetch 직접 모킹 금지)
+- 테스트 대상의 내부 구현은 Mock하지 않는다
+- `beforeEach`/`afterEach`로 상태를 격리한다
+
+---
+
+## 출력 형식
+
+```
+## Implementation + Test Report
+
+### 변경 파일
+- `path/to/file.tsx` (신규/수정) - 설명
+- `path/to/file.test.tsx` (신규/수정) - 테스트
+
+### 테스트 결과
+- 전체: N개 / 통과: N개 / 실패: N개
+
+### 참고 사항
+- 추가 검토가 필요한 부분
+```
+
+---
+
+## 규칙
+
+- 기존 파일은 반드시 읽고 수정한다
+- 한 번에 최대 10개 파일 변경
+- 기존 테스트를 깨뜨리지 않는다
+- 스냅샷 테스트 지양, 행동 기반 테스트 작성
+- `waitFor`/`findBy`로 비동기 렌더링 처리

package/.claude/hooks/prompt-hook.sh

@@ -0,0 +1,115 @@
+#!/usr/bin/env bash
+# prompt-hook.sh - 통합 UserPromptSubmit hook
+# quality-gate + skill-detector + project-map-detector를 하나로 합친다.
+
+set -uo pipefail
+
+SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
+CLAUDE_DIR="$(cd "$SCRIPT_DIR/.." && pwd)"
+
+# ─── stdin 읽기 (한 번만) ───
+INPUT=$(cat)
+
+# ─── 1. Quality Gate ───
+cat << 'EOF'
+[Quality Gate] 티어를 판단하고 워크플로우를 따르라.
+- S (1-2파일, 단순수정): Main Agent 직접 처리
+- M (3-5파일, 명확한 기능): code-writer → git-manager
+- L (6+파일, 설계 필요): 풀 프로세스 (TDD → 구현 → 리뷰)
+EOF
+
+# ─── 2. Skill Detector ───
+CONF_FILE="${SCRIPT_DIR}/skill-keywords.conf"
+if [[ -f "$CONF_FILE" ]]; then
+  PROMPT=$(echo "$INPUT" | python3 -c "import sys,json; print(json.load(sys.stdin).get('prompt',''))" 2>/dev/null || echo "$INPUT")
+
+  if [[ -n "$PROMPT" ]]; then
+    PROMPT_LOWER=$(echo "$PROMPT" | tr '[:upper:]' '[:lower:]')
+
+    declare -a SKILL_NAMES=()
+    declare -a SKILL_COMMANDS=()
+    declare -a SKILL_SCORES=()
+
+    while IFS= read -r line; do
+      [[ -z "$line" || "$line" == \#* ]] && continue
+      SKILL_NAME=$(echo "$line" | cut -d'|' -f1)
+      SKILL_CMD=$(echo "$line" | cut -d'|' -f2)
+      KEYWORDS_STR=$(echo "$line" | cut -d'|' -f3)
+
+      SCORE=0
+      for keyword in $KEYWORDS_STR; do
+        if [[ "$PROMPT_LOWER" == *"$keyword"* ]]; then
+          SCORE=$((SCORE + 1))
+        fi
+      done
+
+      if ((SCORE > 0)); then
+        SKILL_NAMES+=("$SKILL_NAME")
+        SKILL_COMMANDS+=("$SKILL_CMD")
+        SKILL_SCORES+=("$SCORE")
+      fi
+    done < "$CONF_FILE"
+
+    if ((${#SKILL_NAMES[@]} > 0)); then
+      SORTED_INDICES=()
+      for i in "${!SKILL_SCORES[@]}"; do
+        SORTED_INDICES+=("$i")
+      done
+
+      for ((i = 0; i < ${#SORTED_INDICES[@]}; i++)); do
+        for ((j = i + 1; j < ${#SORTED_INDICES[@]}; j++)); do
+          idx_i=${SORTED_INDICES[$i]}
+          idx_j=${SORTED_INDICES[$j]}
+          if ((SKILL_SCORES[idx_j] > SKILL_SCORES[idx_i])); then
+            SORTED_INDICES[$i]=$idx_j
+            SORTED_INDICES[$j]=$idx_i
+          fi
+        done
+      done
+
+      MAX=5
+      if ((${#SORTED_INDICES[@]} < MAX)); then
+        MAX=${#SORTED_INDICES[@]}
+      fi
+
+      echo "[Skill Detector] 다음 스킬을 참조하라:"
+      for ((i = 0; i < MAX; i++)); do
+        idx=${SORTED_INDICES[$i]}
+        echo "- ${SKILL_NAMES[$idx]}: /skill ${SKILL_COMMANDS[$idx]}"
+      done
+    fi
+  fi
+fi
+
+# ─── 3. Project Map Detector ───
+MAP_FILE="$CLAUDE_DIR/PROJECT_MAP.md"
+CACHE_FILE="$CLAUDE_DIR/.project-map-cache"
+
+if [ ! -f "$MAP_FILE" ]; then
+  echo "[PROJECT_MAP] PROJECT_MAP.md가 없습니다: .claude/scripts/generate-project-map.sh"
+elif git rev-parse --is-inside-work-tree &>/dev/null 2>&1; then
+  CURRENT_HEAD="$(git rev-parse HEAD 2>/dev/null)" || true
+
+  if [[ -n "${CURRENT_HEAD:-}" ]]; then
+    if [ -f "$CACHE_FILE" ]; then
+      CACHED_HEAD="$(cat "$CACHE_FILE" 2>/dev/null)"
+      if [ "$CURRENT_HEAD" != "$CACHED_HEAD" ]; then
+        STRUCTURE_CHANGED=false
+        ADD_DEL="$(git diff --name-status "$CACHED_HEAD" "$CURRENT_HEAD" 2>/dev/null | grep -E '^[ADR]' | head -20)" || true
+        [ -n "$ADD_DEL" ] && STRUCTURE_CHANGED=true
+
+        CONFIG_PATTERN="package\.json$|tsconfig\.json$|\.eslintrc|next\.config|vite\.config|nest-cli\.json|docker-compose"
+        CONFIG_CHANGED="$(git diff --name-only "$CACHED_HEAD" "$CURRENT_HEAD" 2>/dev/null | grep -E "$CONFIG_PATTERN" | head -5)" || true
+        [ -n "$CONFIG_CHANGED" ] && STRUCTURE_CHANGED=true
+
+        printf '%s' "$CURRENT_HEAD" > "$CACHE_FILE"
+
+        if [ "$STRUCTURE_CHANGED" = true ]; then
+          echo "[PROJECT_MAP] 구조 변경 감지. 갱신 권장: .claude/scripts/generate-project-map.sh"
+        fi
+      fi
+    else
+      printf '%s' "$CURRENT_HEAD" > "$CACHE_FILE"
+    fi
+  fi
+fi

package/.claude/hooks/skill-keywords.conf

@@ -18,3 +18,4 @@ Coding|Coding|리팩토링 refactor 클린코드 clean code 네이밍 naming 에
 TDD|TDD|tdd 테스트 test jest vitest 단위테스트 unit test e2e 통합테스트 integration test mock stub spy
 Git|Git|git 커밋 commit 브랜치 branch pr pull request merge rebase
 DDD|DDD|ddd domain entity value object aggregate repository domain service domain event bounded context 도메인 엔티티 값객체 애그리거트 리포지토리 도메인서비스 도메인이벤트
+Planning|Planning|계획 설계 기획 plan planning 작업분해 영향범위 아키텍처 architecture 구조설계

package/.claude/settings.json

@@ -6,18 +6,10 @@
         "hooks": [
           {
             "type": "command",
-            "command": ".claude/hooks/quality-gate.sh"
-          },
-          {
-            "type": "command",
-            "command": ".claude/hooks/skill-detector.sh"
-          },
-          {
-            "type": "command",
-            "command": ".claude/hooks/project-map-detector.sh"
+            "command": ".claude/hooks/prompt-hook.sh"
           }
         ]
       }
     ]
   }
-}
+}

package/.claude/skills/Planning/SKILL.md

@@ -0,0 +1,44 @@
+# Planning Skill
+
+작업 계획 수립 시 참조하는 체크리스트와 템플릿.
+
+---
+
+## 1. 티어 판단
+
+다음 질문에 순서대로 답하라:
+
+1. **변경 영향도**: 핵심 도메인 로직이 바뀌는가? → Yes면 L
+2. **레이어 횡단**: FE + BE 동시 변경인가? → 영향도에 따라 M 또는 L
+3. **설계 결정**: 새로운 아키텍처/패턴 도입이 필요한가? → Yes면 L
+4. **위 모두 No**: 파일 수와 변경 단순성으로 S/M 판단
+
+## 2. 작업 분해 템플릿
+
+### 요구사항 정리
+- [ ] 사용자가 원하는 최종 결과물은?
+- [ ] 변경되는 레이어는? (UI / API / Domain / DB)
+- [ ] 기존 코드에 영향을 주는 범위는?
+
+### 작업 단위 분해
+각 작업 단위는 **독립적으로 테스트 가능한 단위**로 나눈다:
+```
+1. [작업명] - [대상 파일/모듈] - [티어]
+2. [작업명] - [대상 파일/모듈] - [티어]
+```
+
+### 의존성 확인
+- [ ] 작업 간 순서 의존성이 있는가? (예: BE API 먼저 → FE 연동)
+- [ ] 외부 의존성이 있는가? (패키지 설치, DB 마이그레이션 등)
+
+## 3. 계획 출력 형식
+
+사용자에게 계획을 제시할 때 다음 형식을 따른다:
+
+```
+**티어**: S / M / L
+**변경 범위**: [레이어 목록]
+**작업 목록**:
+1. [작업] → [담당 에이전트]
+2. [작업] → [담당 에이전트]
+```