Plan Review

---
name: plan-review
description: Use when a planning document written by another session — strategy.md, campaign.md (작전계획) 초안·개정본, 또는 DP·M opord (작업 지침) 초안 — must be reviewed before the user's 재가. Triggers on "1차 리뷰 요청" from a peer session, "(다른 세션이 올린) 계획 리뷰해줘", "(저쪽 세션) 작전계획·작업 지침 봐줘". Does NOT trigger on PR 코드 리뷰(review 스킬), 하네스 파일 리뷰(harness-review 스킬), 계획을 직접 쓰거나 고치는 일(campaign·opord 스킬), 종결보고 접수·평가(campaign 평가 모드).
---

# Plan Review — 계획 문서 1차 리뷰

**재가 전에 계획의 구멍을 막는 관문이다.** 재가 뒤에 구멍이 드러나면 FRAGO·계획 개정으로 되돌아가고, 실행 중이면 이미 짠 코드까지 흔들린다. 리뷰어는 결함을 지적하고 고칠 방향을 준다. 문서는 작성 세션이 고친다.

## 1. 대상 확보

- **파일 전문을 연다.** opord 는 이슈 본문에 핵심 블록만 올라가므로(opord §7) 작성 세션 워크트리의 `docs/operations/<이슈>/opord-*.md` 를 읽는다. campaign·strategy 는 이슈 본문 미러도 전문이다.
- **상위 문서를 함께 연다.** opord 면 campaign.md 9항의 그 DP 행(소유 범위 칸이 거기 있다), campaign 이면 strategy.md 의 그 캠페인 행이다. 그 전략이 템플릿 12항 밖에 소유 범위·제한 항을 따로 세웠으면 그 항도 연다.
- **campaign·strategy 개정본이면** 머리의 개정 줄로 바뀐 항목을 잡는다. **opord 는 머리에 개정 줄이 없다** — 재가 전이라 부록 D 단편명령도 아직 없으므로, 직전 라운드의 지적 목록을 바뀐 자리로 삼는다. 어느 쪽이든 §2 의 관점 5 는 문서 전체에 다시 적용한다 — 새 조건이 안 바뀐 조건과 부딪힐 수 있다.
- **개정본은 세 범주를 리뷰어가 직접 훑는다** (`campaign` §4 가 정본) — 바뀐 값에서 **파생되는 양**, 그 대상을 **목적지로 삼는 경로**(sequel·결정지점·branch·착수 조건), **같은 사실을 말하는 다른 항**. 작성 세션이 낱말로 훑으면 셋 다 새고, 샌 자리는 개정 줄에 안 적혀 있어 바뀐 항목만 봐서는 안 보인다.

## 2. 여섯 관점 — 전부 돌고 관점마다 결과 줄을 남긴다

| # | 관점 | 판정 질문 | 방법 |
|---|---|---|---|
| 1 | 상위 정합 | 상위 문서가 이 DP·캠페인에 준 내용·선행·소유 범위·크기를 그대로 받았나. 상위가 "X 스킬 §N 으로" 처럼 절차를 지정했으면 그 요건이 이 문서에 들어 있나 | 상위 행과 항목별 대조 |
| 2 | 인용 조항 원문 | 이 문서나 상위 문서가 따르라고 지목한 rules·스킬 조항의 요건 항목이 하나도 안 빠졌나 | 조항 **원문**을 열고 요건 항목마다 "문서의 어느 칸·단계가 이걸 하나"를 적는다. 대응하는 칸·단계를 못 대면 누락이다 |
| 3 | 정찰 사실 | `파일:줄`·동작 주장·경로가 실제와 맞나. 같은 값이 두 단위·척도로 적힌 자리가 환산하면 같은 구간인가 | 직접 연다. 다 못 열면 결론이 기대는 주장부터 연다. 단위가 갈린 값은 환산값을 계산해 대조한다 — 두 표기가 각자 제자리에서는 자연스러워 낱말로도 값으로도 안 걸린다 |
| 4 | 검증 수단 실재 | 태스크마다 "이 변경이 깨지면 무엇이 잡나". 대체 검증으로 지목된 테스트·스냅샷·실기 항목이 **실제로 그 변경의 코드 경로를 지나나**. 문서가 적은 가장 유력한·위험한 양상에 검증이 붙었나 | 지목된 테스트가 그리는·부르는 경로를 코드로 따라간다 |
| 5 | 조건 간 충돌 | 결정지점·branch 가 발동한 세계에서도 단계 종료 조건·MOE 를 채울 수 있나. branch 가 뒤 DP·지표가 쓰는 산출물까지 없애나. 비율·임계값 판정이 성격 다른 대상을 한데 묶나 | 아래 워게임 |
| 6 | 신설물 배치 | 이 계획이 새로 만드는 문서·파일·타입·스킴이 같은 주제를 이미 다루는 정본과 두 갈래가 되지 않나. 짝지어진 두 위치(CLAUDE.md §1)를 한쪽만 고치지 않나 | 신설물의 주제어로 `docs`·`.claude`·소스를 grep 해 기존 정본을 찾고, 계획이 그쪽을 함께 고치거나 가리키는지 본다 |

**관점 5 워게임** — 결정지점·branch·우발계획 행마다 두 방향으로 걷는다. 형식이 맞는지(ID 가 짝지어졌나)만 보고 넘어가면 이 관점을 안 돈 것이다.

0. **대상을 먼저 열거한다.** 결정지점 표·branch 표·우발계획 표의 **모든 행** ID 를 적는다 — `상시` 행도 든다. 워게임 줄은 이 목록과 1:1 이다. 빠진 ID 가 있으면 관점 5 를 안 돈 것이다.
1. **없어지는 것을 문장에서 찾는다.** `grep -n '<ID>' <대상 파일>` 을 실제로 돌려, 걸린 줄 번호를 워게임 줄의 근거 칸에 전부 적는다. 걸린 줄 가운데 발동 시 행동을 적은 **모든 문장**(DP 행 내용 칸·branch 칸·sequel)을 읽는다. "이 DP 를 세우지 않는다"·"폐기한다" 같은 문장이 걸리면 그 DP 가 만들던 **구체 산출물**(타겟·파일·테스트·스펙 절)을 하나씩 적는다. "파생 접근 전체" 같은 개념 수준 요약은 산출물이 아니다.
2. **남은 조건을 문장 그대로 읽는다.** 단계 종료 조건·sequel·MOE 지표 문장을 발동한 세계에 대입해 문자 그대로 충족 가능한지 본다. 결정지점이 대상 일부만 다른 경로로 보내는데 종료 조건이 대상 전체를 한 기준으로 묶어 판정하면 충돌이다.

```
<ID> [grep: <걸린 줄 번호 전부>] 발동 → 없어지는 산출물: <구체 목록 — 근거 문장 위치> | 그걸 쓰는 자리: <종료 조건·뒤 DP·MOE 지표> | 발동 세계의 종료 조건: 충족 가능 / <어느 문장이 못 채워지나>
```

**관점 2·6 대조 줄** — 두 관점은 판단 대신 아래 줄을 채운다. 오른쪽 칸이 `없음` 이거나 `아니오` 인 줄이 곧 지적 후보다.

```
관점 2: <조항 위치> "<요건 원문 그대로>" → <이 문서에서 그 요건 이름으로 그 일을 하는 칸·단계 위치 | 없음>
관점 6: 신설 <파일·문서> ↔ 기존 정본 <경로 §> → 이 계획이 기존 쪽을 고치거나 새 쪽을 가리키게 하나: <예 — 태스크 위치 | 아니오>
```

관점 2 는 지목된 절의 요건 문장을 **전부** 한 줄씩 적는다 — "반드시"·"필수"·"~해야 한다"·"~마다" 가 든 문장은 하나도 빼지 않는다. 오른쪽 칸에는 **요건과 같은 이름의 칸·단계**만 적는다. 다른 이름의 항목이 "사실상 그 역할을 한다"는 적지 않는다. **오른쪽이 `없음` 인 줄은 §3 게이트 2·3 으로 거르지 않고 곧장 지적이다.** 그 요건이 이 계획에는 맞지 않는다고 보이면, 면제 여부를 리뷰어가 정하지 말고 "재가 때 유저에게 물을 것"으로 지적에 싣는다. 관점 6 은 새 문서가 기존 정본과 역할을 나눴다고 봐도, 기존 정본을 읽는 사람이 새 문서로 넘어갈 길(포인터)이 계획에 없으면 `아니오` 다.

관점마다 결과를 한 줄로 남긴다 — `관점 N: 이상 없음 (<확인한 것>)` 또는 지적 번호. 줄이 없는 관점은 안 돈 것이다.

| 이렇게 넘어가고 싶어지면 | 실제로는 |
|---|---|
| "요건 X 는 다른 항목이 사실상 흡수한다" | 요건 이름이 문서에 없으면 누락이다. 작성 세션이 칸 하나 더 다는 데 드는 비용은 작고, 빠진 채 재가되면 실행자가 그 요건을 모른다 |
| "이 계획에는 그 요건의 축이 성립하지 않는다" | 조항 적용을 면제하는 건 리뷰어 권한이 아니다. 면제가 맞다고 봐도 지적으로 올려 유저가 정하게 한다 |
| "새 문서와 기존 문서는 역할이 나뉘어 있다" | 나뉘었어도 기존 쪽이 새 쪽을 안 가리키면 기존 쪽을 읽는 사람은 새 문서를 못 찾는다 |
| "결정지점·branch ID 가 다 짝지어져 있다" | 짝이 맞는 건 형식이다. 발동 뒤에 사라지는 산출물을 문장 단위로 따라가야 한다 |
| "미결 시 기본 행동이 있으니 흡수됐다" | 같은 사건을 다른 행이 다르게 처리하면 실행자가 어느 쪽을 따를지 모른다. 기본 행동의 존재는 충돌을 없애지 않는다 |

## 3. 지적 게이트

지적으로 올리기 전에 셋을 통과해야 한다. 하나라도 못 넘으면 올리지 않는다.

1. **관찰 가능한 결과** — 재가된 계획대로 실행하면 무엇이 틀어지나 (산출물 누락·검증 공백·도달 불가 종료 조건·잘못된 경로). "이론상 가능"은 결과가 아니다.
2. **이미 흡수되지 않나** — 다른 항목·상위 문서·기존 코드가 그 구멍을 이미 막고 있지 않나. 확인은 grep·파일 열기로 한다. 흡수됐다고 판정하려면 **그 일을 하는 칸·단계·코드를 위치로 댈 수 있어야 한다.** 조항이 요구한 항목이 없는데 "비슷한 구조가 실질적으로 대신한다"는 흡수가 아니라 누락이다.
3. **의도와 어긋나나** — 작성 세션이 일부러 그렇게 정한 근거가 문서에 있으면 그 근거부터 읽는다. 근거가 서면 지적이 아니다. **예외는 관점 2 의 `없음` 줄이다** — 조항 요건을 면제하는 판단은 근거가 적혀 있어도 리뷰어가 닫지 않고 재가 안건으로 올린다.

**결정은 지적 대상이 아니다.** 노력선·최종상태·라인업·DP 순서처럼 유저가 정할 자리는 리뷰어가 대신 고르지 않는다 — "재가 때 유저에게 물을 것"으로 넘긴다.

## 4. 결과 전달

요청한 세션(또는 유저)에게 보낸다. 형식:

- 첫 줄에 **통과** 또는 **수정 요청 N건**.
- 지적마다: 문서 위치(항목·태스크) → 근거(`파일:줄`·조항 원문) → 틀어지는 결과 → 고칠 방향.
- 통과여도 확인한 핵심 사실 한두 줄을 붙인다 — 작성 세션이 무엇이 검증됐는지 안다.

**재리뷰** — 반영본을 받으면 지적한 자리와 그 반영이 건드린 항목만 파일에서 확인한다. 경로 오기처럼 사실만 바로잡는 정정은 재리뷰 없이 받는다.

**통과 뒤에 유저 재가로 간다.** 재가는 작성 세션이 유저에게 직접 받는다.

## 5. 종료 기록 — skill_end

한 문서의 리뷰가 통과로 끝나거나 요청자가 리뷰를 거둬들이면 `python3 .claude/hooks/log-record.py skill_end --name plan-review` (명령·compliance 규칙은 CLAUDE.md §1). 수정 요청 → 재리뷰 라운드는 같은 런이다 — 통과 시점에 한 번 기록한다.