Prompt Review

---
name: prompt-review
description: Refines user prompts through structured dialogue to produce executable prompts with delegation plans. Use when user requests are vague or multi-file, or manually via /prompt-review or /refine.
---

# Prompt Review

사용자 프롬프트를 대화로 구체화하여 실행 가능한 프롬프트 + 위임 계획으로 정제합니다.

> "Pull requests are dead, long live prompt requests" — Peter Steinberger

코드 리뷰 대신 **프롬프트 리뷰**. 결과물이 아닌 지시문의 품질에 집중합니다.

## 트리거

| 방식 | 조건 |
|------|------|
| 수동 호출 | `/prompt-review`, `/refine` |
| Orchestrator 연동 | 복잡한 요청 시 orchestrator가 이 skill 참조 권장 |

## Instructions

### Phase 0: 판단 — 구체화 필요 여부 평가

**스킵 조건** (즉시 통과):
- 단일 파일 + 구체적 동작 명시
  - 예: "src/auth.ts에 logout 함수 추가"
- Slash command 호출
  - 예: `/commit`, `/review`, `/docs`
- 순수 질문
  - 예: "이 함수 뭐하는 거야?", "어디 있어?"
- 10단어 미만 단순 지시
  - 예: "테스트 실행", "빌드"
- 정보 탐색
  - 예: "collab 생성 관련 파일 찾아줘"

**진행 조건** (Phase 1로):
- 다중 파일 작업 예상
  - 예: "로그인 개선해줘" (목표, 범위 불명확)
- 목표/범위/제약 중 1개 이상 불명확
  - 예: "API 성능 최적화" (범위, 검증 불명확)
- "개선", "수정", "추가" 등 모호한 동사만 존재
  - 예: "에러 핸들링 추가" (어디에? 어떻게?)
- 구현 방법이 여러 갈래로 나뉨
  - 예: "테스트 작성" (어떤 파일? 커버리지 목표?)

**판단 프로세스**:
```
1. 요청 읽기
2. 스킵 조건 체크 → 만족 시 즉시 통과
3. 진행 조건 체크 → 만족 시 Phase 1
4. 애매하면 Phase 1 (보수적 접근)
```

### Phase 1: 분석 — 빠진 축 식별

4가지 축에서 불명확한 부분 찾기:

| 축 | 핵심 질문 | 예시 |
|---|----------|------|
| **목표** | 최종 상태가 무엇인가? | "개선" → 성능? 가독성? 버그 수정? |
| **범위** | 어디까지 건드리는가? | "로그인 수정" → 프론트만? 백엔드도? |
| **제약** | 기존 패턴 유지? 새 방식? | 기존 구조 유지 vs 리팩토링 허용 |
| **검증** | "됐다"를 어떻게 판단? | 테스트 통과? UI 확인? 성능 수치? |

**분석 결과**:
- 명확한 축: ✓
- 불명확한 축: 질문 필요 → Phase 2

### Phase 2: 구체화 — 질문을 통한 정제

**질문 원칙**:
- 1회당 1-3개 질문 (과부하 방지)
- 이미 명시된 축은 건너뜀
- Yes/No 대신 선택지 제시
- 사용자 답변 → 추가 질문 or Phase 3

**질문 예시**:

```markdown
## 목표 불명확 시
"API 개선"이 의미하는 것은?
1. 성능 최적화
2. 에러 핸들링 개선
3. 새 엔드포인트 추가
4. 기존 엔드포인트 수정

## 범위 불명확 시
어디까지 수정하시겠습니까?
- [ ] 프론트엔드만
- [ ] 백엔드만
- [ ] 전체 스택

## 제약 불명확 시
기존 구조를 유지하시겠습니까?
- [ ] 패턴 유지 (최소 변경)
- [ ] 리팩토링 허용 (더 나은 구조)
```

**반복 프로세스**:
1. 질문 제시
2. 사용자 답변
3. 충분한가?
   - Yes → Phase 3
   - No → 추가 질문 (Phase 2 반복)

### Phase 3: 출력 — 정제된 프롬프트 + 위임 계획

**출력 형식**:

```markdown
## 정제된 프롬프트

[사용자 의도를 반영한 명확한 요청문]

**목표**: [구체적 최종 상태]
**범위**: [수정 대상 파일/모듈]
**제약**: [유지/변경 방침]
**검증**: [완료 조건]

---

## 위임 계획

### 병렬 실행 가능
- [ ] Task 1: [설명] → `[위임: subagent_type]`
- [ ] Task 2: [설명] → `[위임: subagent_type]`

### 순차 실행 필요
1. Task 3: [설명] → `[위임: subagent_type]` (선행 필수)
2. Task 4: [설명] → `[위임: subagent_type]` (Task 3 의존)

### 검증
- [ ] 검증 1: [방법] → `[위임: Bash 또는 code-reviewer]`
```

**위임 계획 작성 원칙**:
- orchestrator 규칙 참조 (병렬 우선, 순차는 정당화)
- 3-5개 단위로 배치 구성
- 의존성 명시
- 검증 단계 포함

### Phase 4: 승인 — 실행 전 확인

AskUserQuestion으로 사용자에게 확인:

```
위 계획으로 진행하시겠습니까?

1. 승인 - 계획대로 실행
2. 수정 - 계획 변경 필요
3. 취소 - 작업 중단
```

- **승인** → prompt-review 종료, orchestrator가 위임 계획 인수하여 실행
- **수정** → Phase 3로 되돌아가 계획 조정
- **취소** → 종료

**역할 경계**: prompt-review는 계획 생성만 담당. 실행은 orchestrator.

## Examples

### 시나리오 1: 모호한 개선 요청

**User**: "로그인 개선해줘"

**Phase 0**: 진행 (목표/범위/검증 불명확)

**Phase 1** (4축 분석):
- 목표: ✗ "개선"이 무엇?
- 범위: ✗ 프론트/백엔드?
- 제약: ✗ 기존 패턴?
- 검증: ✗ 완료 조건?

**Phase 2**:
```
"로그인 개선"이 의미하는 것은?
1. 보안 강화 (2FA, 세션 관리)
2. UX 개선 (로딩, 에러 메시지)
3. 성능 최적화 (응답 속도)
4. 버그 수정

어디까지 수정하시겠습니까?
- [ ] 프론트엔드만
- [ ] 백엔드만
- [ ] 전체 스택
```

**User**: "보안 강화, 백엔드만"

**Phase 3**:
```markdown
## 정제된 프롬프트

백엔드 로그인 보안 강화

**목표**: 세션 관리 개선, JWT 갱신 로직 추가
**범위**: `src/auth/` 디렉토리 (프론트 변경 없음)
**제약**: 기존 API 스펙 유지
**검증**: 인증 관련 테스트 통과

---

## 위임 계획

### 병렬 실행 가능
- [ ] JWT 갱신 로직 구현 → `[위임: general-purpose]`
- [ ] 세션 만료 체크 미들웨어 → `[위임: general-purpose]`

### 검증
- [ ] 인증 테스트 실행 → `[위임: Bash, "npm test src/auth"]`
- [ ] 보안 리뷰 → `[위임: code-reviewer]`
```

**Phase 4**:
"위 계획으로 진행하시겠습니까?" → User: "승인"

**Skill 종료** → orchestrator가 위임 계획 인수:
- `[위임: general-purpose, "JWT 갱신 로직"]` + `[위임: general-purpose, "세션 만료 미들웨어"]` (병렬)
- `[위임: Bash, "npm test src/auth"]` → `[위임: code-reviewer, "보안 리뷰"]` (순차)

### 시나리오 2: 이미 구체적인 요청

**User**: "src/utils/logger.ts에 debug 레벨 추가하고 timestamp 포맷 YYYY-MM-DD로 변경"

**Phase 0**: 스킵 (단일 파일 + 명확한 동작)

**즉시 통과** → orchestrator로 전달

### 시나리오 3: 탐색 목적

**User**: "collab 생성 관련 코드 어디 있어?"

**Phase 0**: 스킵 (순수 정보 탐색)

**즉시 통과** → Explore에 위임

## 중요 원칙

1. **보수적 판단**: 애매하면 구체화 (과잉보다 부족이 낫다)
2. **질문 최소화**: 1회당 1-3개만
3. **선택지 제시**: Yes/No 대신 구체적 옵션
4. **병렬 우선**: 위임 계획은 병렬 기본, 순차는 정당화
5. **독립성**: plan-mode와 별개 (프롬프트 정제 ≠ 구현 계획)

## 연동

| 항목 | 관계 |
|------|------|
| `orchestrator.md` | 위임 계획 작성 시 참조. 복잡한 요청 감지 시 이 skill 참조 권장 |
| `plan-mode` | 별개 (프롬프트 정제 ≠ 구현 설계) |
| Phase 3 출력 | 사용자 승인 후 orchestrator가 위임 계획을 실행 |