Review Desk

/impl-pipeline (batch) finishes the code. This skill is where the human reviews it — after the fact, one slice at a time, on work that is already complete and committed.

Two rules shape everything here:

1. Reviewing and fixing are separate phases. While the user is reading, nothing is edited. Every request becomes a queue item. The queue is applied in one pass at the end.
2. The user's words are the record. A fix item stores what the user actually said, verbatim, next to your interpretation of it — never only the interpretation.

Why (1): a user reviewing S-2 does not yet know what S-5 does. A fix applied at S-2 can be contradicted at S-5, and re-fixing costs more than waiting. Batching also lets overlapping edits to the same file be planned together instead of stepping on each other.

MUST invoke Skill(design-workflow) before running this skill.

Step 0 — Restore the run

ROOT=$(git rev-parse --show-toplevel); BRANCH=$(git branch --show-current)
SLUG=$(echo "$BRANCH" | tr '/' '-'); DIR="$ROOT/.claude/review/$SLUG"
cat "$DIR/run.json" "$DIR/context.json" 2>/dev/null
ls "$DIR"

run.json is the source of truth: slices, statuses, commit SHAs, carried items, artifact paths. INDEX.md (written by /change-walkthrough --all at the end of the run) is the reading entry point — open it, don't rebuild it.

Missing or stale run.json — reconstruct, do not guess:

1. S-*-gate.json files → slice IDs, verdicts, changed files, user_review_items.
2. git log --oneline <base>..HEAD → the checkpoint commits (their trailers carry Slice: S-n).
3. The ledger's ## 작업 큐 → titles, decisions, statuses.
4. Still ambiguous → ask the user which task document this branch implements. Never review a diff you cannot attribute to a slice.

Stale check — if git rev-parse --short HEAD is ahead of the last slice's commit_sha by commits the run did not make, say so: someone (probably the user) has worked on this branch since. Show those commits before starting; they are not part of any slice's review.

Step 1 — Open the desk

Present the whole run first, so the user knows the shape of what they are about to read:

리뷰 데스크 — feature/order-create · 6 슬라이스 · origin/dev 기준

  ⚠️ 막힌 것
  S-3  주문 항목 트랜잭션      보류 — 게이트 RED: 순환 참조   (S-4 스킵됨)

  검수 대기
  S-1  주문 모델 + 마이그레이션   a3f9c21 · +142/-6 · 이월 0 · tier A
  S-2  주문 리포지토리             5b1e004 · +88/-2  · 이월 2
  S-5  주문 API 라우트             9c2ff31 · +210/-14 · 이월 1 · tier A · 이해자료 ✓
  S-6  DI 등록 + 테스트            1d40aa2 · +61/-0  · 이월 0 · tier C

  이월 5건 · 사용자 판단 항목 3건
  순서: 막힌 것부터 볼까, 아니면 S-1부터 순서대로 볼까?

• Tier C slices (machine-certified boilerplate): offer to fold them — "S-6은 tier C다. 게이트가 전부 통과했고 이월 항목도 없다. 건너뛰고 마지막에 한 번에 볼까?" Never skip them silently.
• --from S-n / --slice S-n jump straight in.
• The user can stop after any slice and come back later — the queue and run.json persist. Say this once, at the desk opening.

Step 2 — One slice at a time

For the current slice, present in this order and stop — this is the loop's only wait:

1. 무엇을 한 슬라이스인가 — 제목, 구현한 결정(D-n)의 한 줄 요약 (원장 current --topic에서), 의존.
2. 변경 — git show --stat <commit_sha> (or the S-n.diff snapshot). → 실제 코드는 IDE에서 열도록 명령을 그대로 준다: git show <sha> / git diff <sha>^ <sha>.
3. 워크스루 — .claude/review/{slug}/S-{n}.md 경로. 이게 읽는 순서를 잡아준다.
4. 에이전트 리뷰 이월 항목 — S-{n}-agentreview.md 의 CARRY / QUESTION, 각각 근거와 제안까지. 이건 "고칠까 말까"를 사용자가 판단하라고 남겨둔 것이지, 통과했다는 뜻이 아니다.
5. 게이트 사용자 판단 항목 — S-{n}-gate.json 의 user_review_items (설계에 없는 추가 / 설계와 다름 / 미구현 / 글롭 밖 변경).
6. 이해 자료 — 이미 있으면 file:// 경로. 없고 슬라이스가 무거우면 지금 만들지 물어본다 (/explain-diff-html S-{n}).

Then branch on what the user says:

막힌(보류) 슬라이스는 다르게 제시한다: 시도한 것과 실패한 지점(S-{n}-blocked.md)을 먼저 보여주고, ① 지금 같이 고친다 ② 큐에 넣고 나중에 ③ 설계를 바꾼다 중에 고르게 한다.

• 커밋된 보류 슬라이스(<prefix>(...): … — 보류(미완))는 코드가 트리에 있다. 그대로 보면 된다.
• 스태시된 보류 슬라이스는 코드가 트리에 없다. git stash list 에서 impl-pipeline S-{n} parked 항목을 찾아 보여주고(git stash show -p stash@{k}), 되살릴지는 사용자가 정한다. 임의로 pop 하지 않는다.

Step 3 — The fix queue

.claude/review/{branch-slug}/fix-queue.md — 리뷰 중에는 여기에만 쌓인다. 세션이 끊겨도 남는다.

### F-1 · S-2 · 네이밍
- status: 대기
- 유저: "get_point_by_user 말고 컨벤션대로 get_list_by_user_id 아니야?"
- 대상: apps/web-api/web_api/repositories/order_repository.py:34
- 조치: 리포지토리 public 메소드는 상세 네이밍 규칙 — `get_list_by_user_id` 로 변경, 호출부 2곳 수정
- 영향 슬라이스: S-2, S-5

### F-2 · S-5 · 설계변경
- status: 대기
- 유저: "주문 실패했을 때 402 말고 409로 주자"
- 대상: apps/web-api/web_api/routes/order.py:71
- 조치: D-4 supersede 후 라우트/DTO 수정
- 영향 슬라이스: S-5

유형: 버그 · 네이밍 · 리팩터 · 설계변경 · 설계승격 · 질문. - status: 는 대기 · 반영 · 기각 · 답변완료.

Rules:

• 유저 원문을 그대로 적는다. 요약하면 나중에 "내가 그런 말 했나"가 된다. 해석은 조치: 줄에.
• 같은 파일을 건드리는 항목끼리 묶어 둔다 (영향 슬라이스). 적용 순서를 정하는 근거다.
• 에이전트 리뷰의 CARRY 항목을 사용자가 받아들이면, 그것도 F-n 으로 들어온다 (출처를 적어라).
• 큐가 비어 있으면 Step 4를 건너뛴다.

리뷰가 끝나면 큐 전체를 한 번에 보여주고 확인받는다 — "이 8건을 반영한다. 빠진 것/취소할 것 있나?" 여기서 기각된 항목은 기각으로 남긴다. 지우지 않는다.

Step 4 — Apply the queue in one pass (--apply)

Order matters:

1. 설계변경 · 설계승격 먼저. 코드보다 원장이 앞선다:

   "$LEDGER" decide --file <task> --topic <slug> --supersedes D-n ...

   원장이 바뀐 뒤에야 그 결정을 구현한다. 반대로 하면 코드와 원장이 또 어긋난다.
2. 파일 그룹 단위로 순차 위임. 같은 파일을 건드리는 항목은 반드시 한 에이전트에게 한 번에 준다. 그룹끼리도 순차로 — 동시 실행하지 않는다(작업 트리를 공유한다). 위임 프롬프트에는 F-n 원문 + 조치 + 대상 file:line + 컨벤션 파일 경로를 인라인으로 넣는다.
3. 재게이트. 영향받은 슬라이스마다 /review-gate S-{n} --task <task>. RED면 그 그룹만 고치고 재시도(캡 2회). 캡을 넘기면 해당 F 항목을 대기로 되돌리고 사용자에게 보고 — 조용히 포기하지 않는다.
4. 네이밍 변경은 전수 검증. 심볼을 바꿨으면 재검색으로 잔존 호출부가 0인지 확인한다 (rg '\bget_point_by_user\b'). 코드베이스 전반 변경은 변경 후 재검색이 완료 조건이다.
5. 반영된 항목은 status: 반영, 근거(커밋 SHA 또는 파일:라인)를 적는다.

수정 결과는 슬라이스별로 요약해서 한 번에 보고한다. 슬라이스별로 다시 재검수를 강요하지 말고, 사용자가 원하면 그 슬라이스만 Step 2로 되돌아간다.

Step 5 — Commits and closing

수정 커밋을 어떻게 정리할지는 사용자가 정한다. 기본 제안:

• 커밋 메시지는 /commit-msg 로 만든다. AI 트레일러는 넣지 않는다.
• 푸시는 하지 않는다. 이미 푸시된 커밋은 rebase 대상에서 제외한다 — 사용자가 명시적으로 force-push를 요청하지 않는 한.
• 스테이징·커밋은 매번 사용자 승인. 배치 러닝의 1회 승인은 그 러닝 안에서만 유효했다.

마감:

"$LEDGER" slice-status --file <task> --slice n --status 승인   # 또는 커밋
"$LEDGER" task-status  --file <task> --status 구현완료 --log "S-1~S-n 검수 완료 · 수정 8건 반영 · 보류 1"

• 승인되지 않은 채 남은 이월 항목(기각·질문)은 task-log --type 검수 로 진행 로그에 한 줄씩 남긴다. 원장(## 결정 로그)에는 넣지 않는다 — 결정이 아니다.
• 보류 슬라이스가 남아 있으면 구현완료로 넘기지 않는다. 무엇이 왜 남았는지 명시하고 끝낸다.

Hard constraints

• 리뷰 중에는 소스를 고치지 않는다. Step 2에서의 편집은 금지. 전부 큐로.
• 유저 발언을 요약해서 큐에 넣지 않는다. 원문 보존.
• 자율 커밋 금지. 이 스킬에는 배치 러닝의 커밋 권한이 없다. 매번 승인.
• 푸시 금지. 예외 없음.
• 사용자가 안 본 슬라이스를 승인 처리하지 않는다. tier C 접기는 명시적 동의가 있을 때만.
• 원장 우회 금지. 설계 변경은 ledger decide, 검수 메모는 task-log. 문서 본문 직접 편집 금지.