---
description: 설계/요구사항을 분석하여 구현 계획 생성
allowed-tools: Task, Read, Glob, Grep
---

# Design to Code

대화 컨텍스트의 설계/요구사항을 분석하고, 코드베이스를 탐색하여 구체적인 구현 계획을 생성합니다.

## 컨텍스트 정보

프로젝트 타입과 주요 의존성은 1단계에서 `package.json`을 `Read`로 읽어 확인합니다. `package.json`이 없으면 일반 프로젝트로 봅니다.

---

## 작업 순서

### 1. 설계/요구사항 확인

대화 컨텍스트에서 설계 또는 요구사항 확인:
- 이전 메시지에서 설계 문서, 기능 명세, 요구사항 찾기
- 없으면 → "구현할 설계나 요구사항을 먼저 설명해주세요" 안내

**확인할 내용:**
- 구현 목표 (무엇을 만들어야 하는가?)
- 주요 기능 목록
- 제약 조건 (기술 스택, 성능, 호환성 등)
- 참고할 기존 코드나 패턴
- 프로젝트 타입: `package.json`의 `dependencies`에 `react` 또는 `next`가 있으면 React 프로젝트

### 2. 코드베이스 분석 (Explore 에이전트)

Task 도구로 Explore 에이전트 실행:

```
Task(Explore): "프로젝트 구조를 분석하세요:
1. 폴더 구조 및 아키텍처 패턴 파악
2. 기존 컴포넌트/모듈 구조 확인
3. 공통 유틸리티, 훅, 컴포넌트 식별
4. 코딩 컨벤션 및 네이밍 패턴 파악
5. [설계와 관련된 기존 코드] 찾기"
```

### 3. 구현 계획 수립 (Plan 에이전트)

Task 도구로 Plan 에이전트 실행:

```
Task(Plan): "다음 설계를 구현하기 위한 계획을 수립하세요:

[설계/요구사항 요약]

코드베이스 분석 결과:
[Explore 결과 요약]

다음을 포함한 구현 계획 작성:
1. 단계별 구현 순서
2. 생성/수정할 파일 목록
3. 각 파일의 주요 구현 내용
4. 의존성 및 임포트 관계
5. 테스트 전략
6. 주의사항 및 엣지 케이스"
```

### 4. 설계 원칙 검증 (에이전트 병렬 실행)

설계의 품질을 검증하기 위해 에이전트들을 병렬로 실행:

**필수 에이전트:**

| 에이전트 | 검증 내용 |
|----------|----------|
| `fundamentals-readability` | 가독성 관점에서 설계 검증 |
| `fundamentals-predictability` | 예측 가능성 관점에서 설계 검증 |
| `fundamentals-cohesion` | 응집도 관점에서 설계 검증 |
| `fundamentals-coupling` | 결합도 관점에서 설계 검증 |

공통화·재사용 기회는 응집도·결합도 에이전트가 `fe-tradeoffs` 기준(함께 안 바뀌면 버그가 나는지, 앞으로도 같은 동작인지)으로 함께 판단합니다.

**조건부 에이전트 (React 프로젝트):**

| 에이전트 | 검증 내용 |
|----------|----------|
| `react-state-reviewer` | 상태 성질 기반 배치, Context 오용, 서버/클라이언트 상태 분리 검증 |
| `react-principles-reviewer` | 컴포넌트 데이터 소유, 부수효과 위치, 데이터 Fetching·비동기 경계, 네이밍 검증 |

**조건부 에이전트 (계획에 UI 컴포넌트가 있을 때):**

| 에이전트 | 검증 내용 |
|----------|----------|
| `a11y-reviewer` | 클릭 가능한 요소, 폼과 버튼 type, 인터랙티브 요소 중첩(카드 안 버튼 등), 아이콘 버튼 이름, 입력 레이블, 테이블 행 이동 구조를 코드 작성 전에 검증 |

**React 프로젝트 감지 방법:**
```bash
# 다음 중 하나라도 해당되면 React 프로젝트
- package.json에 "react" 또는 "next" 의존성 존재
- .tsx 또는 .jsx 파일 존재
```
> Next.js, Remix 등 React 기반 프레임워크도 자동 감지됩니다.

**에이전트 실행 예시:**

```
// 필수 에이전트 (항상 실행 - 4개 병렬)
Task(fundamentals-readability): "다음 구현 계획을 가독성 원칙으로 검증하세요:
[Plan 결과]
코드 분리, 추상화, 함수 쪼개기, 조건 네이밍, 매직 넘버, 시점 이동 관점에서 개선점을 제안하세요."

Task(fundamentals-predictability): "다음 구현 계획을 예측 가능성 원칙으로 검증하세요:
[Plan 결과]
이름 충돌, 반환 타입 통일, 숨은 로직 관점에서 개선점을 제안하세요."

Task(fundamentals-cohesion): "다음 구현 계획을 응집도 원칙으로 검증하세요:
[Plan 결과]
디렉토리 구조, 매직 넘버 관리, 폼 응집도 관점에서 개선점을 제안하세요. 공통화할 후보가 보이면 fe-tradeoffs 기준으로 묶을지 판단하세요."

Task(fundamentals-coupling): "다음 구현 계획을 결합도 원칙으로 검증하세요:
[Plan 결과]
단일 책임, 중복 코드 허용, Props Drilling 관점에서 개선점을 제안하세요. 재사용·중복 제거 후보는 fe-tradeoffs 기준으로 공통화할지 중복으로 둘지 판단하세요."

// React 프로젝트면 추가
Task(react-state-reviewer): "다음 구현 계획의 상태관리 전략을 검증하세요:
[Plan 결과]
상태 성질(수명/범위/빈도) 기반 도구 선택, Context 사용 적절성, 5단계 에스컬레이터 준수, 서버/클라이언트 상태 분리를 검토하세요."

Task(react-principles-reviewer): "다음 구현 계획을 React 개발 원칙으로 검증하세요:
[Plan 결과]
컴포넌트 데이터 소유(응집도/명시성), 부수효과 위치, 데이터 Fetching과 비동기 경계(Suspense·AsyncBoundary), 네이밍을 검토하세요."

// 계획에 화면·버튼·폼·목록 같은 UI 컴포넌트가 있으면 추가
Task(a11y-reviewer): "다음 구현 계획의 UI 구조를 접근성 관점에서 검증하세요:
[Plan 결과]
클릭 가능한 요소가 button/a로 설계됐는지, 폼과 버튼 type, 인터랙티브 요소 중첩(카드 안 버튼 등), 아이콘 버튼 이름, 입력 레이블, 테이블 행 이동 구조를 검토하세요."
```

### 5. 결과 종합 및 최종 계획 생성

모든 에이전트 결과를 종합하여 최종 구현 계획 작성.

---

## 출력 형식

```markdown
# 구현 계획: [기능명]

## 요약
- **목표:** [구현 목표 1줄 요약]
- **예상 파일 수:** N개 (신규: X, 수정: Y)
- **프로젝트 타입:** [React/일반]
- **검증 에이전트:** [실행된 에이전트 목록]

---

## 1. 설계 분석

### 요구사항 요약
[대화에서 파악한 요구사항 정리]

### 제약 조건
- [제약 1]
- [제약 2]

---

## 2. 코드베이스 분석 결과

### 프로젝트 구조
```
[관련 폴더 구조]
```

### 참고할 기존 패턴
| 패턴 | 파일 | 설명 |
|------|------|------|
| [패턴명] | [file:line] | [설명] |

### 재사용 가능한 기존 코드
- [컴포넌트/유틸리티]: [file:line]

---

## 3. 구현 계획

### 단계별 구현 순서

#### Phase 1: [단계명]
**목표:** [이 단계의 목표]

| 순서 | 작업 | 파일 | 설명 |
|------|------|------|------|
| 1 | [작업] | [경로] | [설명] |
| 2 | [작업] | [경로] | [설명] |

#### Phase 2: [단계명]
...

### 파일별 상세 구현

#### `src/components/NewComponent.tsx` (신규)
```tsx
// 주요 구조 스케치
interface Props {
  // ...
}

export function NewComponent({ ... }: Props) {
  // 주요 로직 설명
}
```

**구현 포인트:**
- [포인트 1]
- [포인트 2]

#### `src/hooks/useNewHook.ts` (신규)
...

---

## 4. 설계 검증 결과

### Toss Fundamentals 검증
| 원칙 | 에이전트 | 상태 | 피드백 |
|------|----------|------|--------|
| 가독성 | fundamentals-readability | ✅/🟡/🔴 | [피드백] |
| 예측 가능성 | fundamentals-predictability | ✅/🟡/🔴 | [피드백] |
| 응집도 | fundamentals-cohesion | ✅/🟡/🔴 | [피드백] |
| 결합도 | fundamentals-coupling | ✅/🟡/🔴 | [피드백] |

### 공통화·재사용 판단 (응집도·결합도 에이전트)
**공통화할 것:**
- [대상]: [근거 — fe-tradeoffs 판단 기준]

**중복으로 둘 것:**
- [대상]: [근거 — 동작이 갈라질 여지 등]

### react-state-reviewer 검증 (React 프로젝트)
| 원칙 | 상태 | 피드백 |
|------|------|--------|
| 상태 성질 분류 | ✅/🟡/🔴 | [피드백] |
| Context 사용 | ✅/🟡/🔴 | [피드백] |
| 서버/클라이언트 분리 | ✅/🟡/🔴 | [피드백] |

### react-principles-reviewer 검증 (React 프로젝트)
| 원칙 | 상태 | 피드백 |
|------|------|--------|
| 컴포넌트 데이터 소유 | ✅/🟡/🔴 | [피드백] |
| 부수효과 위치 | ✅/🟡/🔴 | [피드백] |
| 데이터 Fetching·비동기 경계 | ✅/🟡/🔴 | [피드백] |
| 네이밍 | ✅/🟡/🔴 | [피드백] |

### a11y-reviewer 검증 (UI 컴포넌트가 있을 때)
| 원칙 | 상태 | 피드백 |
|------|------|--------|
| 클릭 가능한 요소 (button/a) | ✅/🟡/🔴 | [피드백] |
| 폼과 버튼 type | ✅/🟡/🔴 | [피드백] |
| 인터랙티브 요소 중첩 | ✅/🟡/🔴 | [피드백] |
| 버튼·입력의 이름과 레이블 | ✅/🟡/🔴 | [피드백] |

---

## 5. 주의사항

### 잠재적 이슈
- ⚠️ [이슈 1]: [설명 및 대응 방안]
- ⚠️ [이슈 2]: [설명 및 대응 방안]

### 엣지 케이스
- [케이스 1]: [처리 방법]
- [케이스 2]: [처리 방법]

---

## 6. 테스트 전략

### 단위 테스트
| 대상 | 테스트 케이스 |
|------|--------------|
| [컴포넌트/함수] | [테스트 케이스 목록] |

### 통합 테스트
- [테스트 시나리오 1]
- [테스트 시나리오 2]

---

## 7. 다음 단계

구현을 시작하려면:
1. Phase 1부터 순서대로 진행
2. 각 파일 구현 후 테스트 확인
3. 구현을 마치면 `/fundamentals-review`로 변경분을 리뷰
4. [추가 안내사항]
```

---

## 사용 예시

```bash
# 1. 먼저 설계/요구사항 설명
"사용자 프로필 페이지를 만들어야 해.
- 프로필 이미지, 이름, 이메일 표시
- 프로필 수정 모달
- 비밀번호 변경 기능
- 계정 삭제 기능"

# 2. 커맨드 실행
/design-to-code
```

---

## 중요 사항

- **컨텍스트 의존**: 대화에서 설계/요구사항을 읽어옴
- **병렬 실행**: 검증 에이전트들은 병렬로 실행하여 효율성 확보
- **React 자동 감지**: package.json 또는 파일 확장자로 React 프로젝트 감지
- **구체적 파일 경로**: 생성/수정할 파일의 정확한 경로 명시
- **코드 스케치 포함**: 주요 구조와 인터페이스를 코드로 표현
- **한국어 출력**: 최종 리포트는 한국어로
- **결과 파일 저장**: 최종 리포트를 `design-to-code.md` 파일로 저장 (이미 존재하면 `---` 구분선과 함께 하단에 추가)