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

질문 예시:

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

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

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

반복 프로세스:

1. 질문 제시
2. 사용자 답변
3. 충분한가?
   • Yes → Phase 3
   • No → 추가 질문 (Phase 2 반복)

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

출력 형식:

## 정제된 프롬프트

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

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

---

## 위임 계획

### 병렬 실행 가능
- [ ] 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:

## 정제된 프롬프트

백엔드 로그인 보안 강화

**목표**: 세션 관리 개선, 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가 위임 계획을 실행