Review Pack 스킬

작업이 끝났을 때, 사용자가 IDE를 열지 않고 문서 하나로 리뷰를 끝낼 수 있는 "리뷰 팩"을 생성한다.

워크플로우 원칙(계획 → 실행 → 리뷰 루프)의 마지막 단계다. 리뷰 팩은 작업 끝에 한 번 제시한다.

핵심 원칙

1. 문서 하나로 리뷰가 완결되어야 한다. file:line만 적으면 사용자가 IDE를 열어 그 위치로 가야 하므로, 핵심 코드는 문서 안에 직접 발췌해 스크롤만으로 읽히게 한다.
2. 봐야 할 것을 사용자 눈앞에 가져온다(push). 리뷰어가 코드를 찾아가는 비용을 작성자가 떠안는다.
3. push·PR은 절대 자동으로 하지 않는다. 리뷰 팩 제시 후 멈추고, 리뷰 통과 + 사용자 승인을 받은 뒤에 진행한다.
4. 한 문서로 묶는다. 검증·발견·수정안을 여러 블록(중간 정리 → 최종 보고 → 수정안…)으로 흩지 말고, 하나의 리뷰 팩 문서로 제시한다. 분절되면 "한 문서로 리뷰"라는 핵심 가치가 사라진다.
5. 🧑 리뷰 가이드는 생략 불가. 볼 순서 + 가장 봐줬으면 하는 곳을 반드시 넣는다 — 이게 단순 변경 목록과 리뷰 팩을 가르는 차별 요소다.

절차

1. 변경 범위 수집

• git status, git diff <base>..HEAD(또는 working tree), git log <base>..HEAD --oneline 으로 변경을 모은다.
• base 결정: 이슈 브랜치면 머지 베이스(main/develop), 단일 작업이면 작업 시작 커밋. 모호하면 사용자에게 base를 확인한다 (잘못된 base는 엉뚱한 diff를 만든다).
• 변경 파일 수, +추가/-삭제 라인 수를 집계한다.

1. 핵심 선별 — 아래 기준으로 인라인 발췌할 변경만 고른다. 나머지는 📎 전체 diff로 보낸다.

1. 리뷰 팩 작성 — 아래 출력 템플릿의 4요소 + 리뷰 가이드를 채운다.

1. 제시 후 멈춤 — 사용자 리뷰를 기다린다. 피드백이 오면 계획(A) 또는 실행(B) 단계로 되돌아간다.

핵심 선별 기준 — 무엇을 인라인 발췌할까

인라인으로 발췌 (②에 코드 첨부):

• 계획 분기에서 합의한 결정이 실제로 구현된 부분
• 비자명한 로직: 조건 분기, 동시성/race, 경계·에러 처리, 계약 검증(require/check)
• 제가 봐줬으면 하는 위험·불확실 지점

제외 (📎 전체 diff로):

• import, 포맷팅, 보일러플레이트, 기계적 리네임, 자동 생성물

발췌 형태

• 기본은 diff(`+/-`) — "무엇이 바뀌었나"를 보여준다.
• 새로 짠 핵심 함수 / 복잡한 로직은 최종 코드 통째로 — diff면 전부 +로 떠서 가독성이 떨어지므로, 결과 코드를 그대로 싣는다.
• 각 발췌 위에 path:line과 "왜 핵심:" 한 줄을 붙인다.

분량 가드

• 인라인 발췌가 과해지면(핵심 발췌가 너무 많거나 수백 줄) 핵심만 남기고 나머지는 📎로 보낸다.
• 무엇을 📎로 보냈는지 명시한다 — 조용히 생략하면 "다 보여줬다"고 오해를 부른다(silent truncation 금지).

저장 위치

• 기본: 대화에 직접 출력한다.
• 팩이 길거나 사용자가 에디터/Obsidian에서 보길 원하면, 스크래치패드 또는 회사 볼트 reports/에 .md로 저장하고 경로를 제시한다. (보관 가치가 있는 분석·의사결정이면 report 스킬 흐름을 따른다.)

출력 템플릿

## 리뷰 팩: <작업명>

### ① 변경 요약 — 한눈에
- 무엇을: ...
- 왜: ...
- 범위: 파일 N개, +X · -Y줄

### ② 핵심 변경 — 코드로 보기

#### 2-1. <무엇을 했나>  `path/to/file.kt:120-138`
> 왜 핵심: <이 코드가 어떤 결정을 구현하는지 한 줄>
​```kotlin
// diff 발췌 또는 (새 로직이면) 최종 코드 통째로
​```

#### 2-2. <다음 핵심 변경>  `path/to/other.ts:42-55`
> 왜 핵심: ...
​```ts
...
​```

### ③ 시각 확인
- before/after 스크린샷·GIF (UI 변경 시)
- 비-UI 변경이면: "N/A — 비-UI 변경" 명시

### ④ 검증 결과
- 테스트: `<명령>` → 통과 / 실패 (출력 발췌)
- 실기기·실행 검증: ...
- ⚠️ 로컬에서만 검증했다면 "로컬 통과 ≠ CI 통과"를 명시 (플랫폼차·lock 재생성 등으로 CI에서 깨질 수 있음)

### 🧑 리뷰 가이드 — 당신이 볼 순서
1. ①로 큰 그림 → 2. 의심되면 ②의 근거 → 3. ③/④로 동작 확인
→ **가장 봐줬으면 하는 부분**: <여기 한 줄>

### (선택) 적용 범위
- 수정안이 여럿이면 `AskUserQuestion`으로 "어디까지 적용할지"(예: 🔴만 / 🔴+🟡 / 검토만)를 물어 게이트를 둔다.

### 📎 전체 diff
- PR 링크 / 첨부 (핵심 외 나머지는 여기)

하지 말 것

• file:line만 나열하고 코드 발췌를 생략하는 것 (이 스킬의 존재 이유에 반함)
• 리뷰 팩 제시와 동시에 push·PR·머지를 진행하는 것
• 전체 diff를 통째로 인라인에 붙여 핵심을 묻히게 하는 것
• 산출물을 여러 블록(중간 정리·최종 보고·수정안…)으로 분절하는 것 — 한 문서로 묶는다
• 🧑 리뷰 가이드(볼 순서·집중 지점)를 빠뜨리는 것