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. 기존 엔드포인트 수정

범위 불명확 시

어디까지 수정하시겠습니까?

• 프론트엔드만
• 백엔드만
• 전체 스택

제약 불명확 시

기존 구조를 유지하시겠습니까?

• 패턴 유지 (최소 변경)
• 리팩토링 허용 (더 나은 구조)

반복 프로세스:

• 질문 제시

• 사용자 답변

• 충분한가?

• 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회당 1-3개만

• 선택지 제시: Yes/No 대신 구체적 옵션

• 병렬 우선: 위임 계획은 병렬 기본, 순차는 정당화

• 독립성: plan-mode와 별개 (프롬프트 정제 ≠ 구현 계획)

연동

항목 관계

orchestrator.md

위임 계획 작성 시 참조. 복잡한 요청 감지 시 이 skill 참조 권장

plan-mode

별개 (프롬프트 정제 ≠ 구현 설계)

Phase 3 출력 사용자 승인 후 orchestrator가 위임 계획을 실행