[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DM1YZ0YC5ZHS6WBTB8P9Z2":3,"skill-same:01M6DM1YZ0YC5ZHS6WBTB8P9Z2":90},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":41,"linkOnly":42,"markdownContent":43,"markdownBody":44,"frontMatter":45,"refName":70,"commitSha":71,"skillDirectory":72,"forksCount":73,"repositoryHtmlUrl":74,"repositoryHomepageUrl":6,"ownerHtmlUrl":75,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":76,"install":77,"resources":89},"01M6DM1YZ0YC5ZHS6WBTB8P9Z2","review-lite",null,"2인 팀을 활용한 경량 코드 리뷰","Nharu\u002Fcc-cmds","Nharu","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F14357133?v=4","01M6DKV0D72FEBQABDAGSZ021P","nano","01M6DKV0TVG5GV22WQZBNRZ3ZT",3,"MIT","https:\u002F\u002Fgithub.com\u002FNharu\u002Fcc-cmds\u002Fblob\u002Fmaster\u002Fplugins\u002Fcc-cmds\u002Fskills\u002Freview-lite\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40],"review lite","review","diff","true","URL","condition","gap","false","expand","base","cc","files","coverage","view","gh","gh pr","csv","git","report","git merge","pr","merge","2026-11-10 10:12:30",false,"---\nname: review-lite\ndescription: 2인 팀을 활용한 경량 코드 리뷰\nwhen_to_use: 빠른 코드 리뷰가 목적이고 다관점 심층 분석이 불필요할 때 (큰 PR coverage gap, 미묘한 race condition·authn bypass 검출률 약화 가능)\ndisable-model-invocation: true\nusage: \"\u002Fcc-cmds:review-lite [\u003Ctarget>] [--base-sha \u003Csha>] [--declared-files \u003Ccsv>] [--expand \u003C분야>[,\u003C분야>]]\"\noptions:\n    - name: \"\u003Ctarget>\"\n      kind: positional\n      required: false\n      summary: \"리뷰 대상 (PR 번호\u002FURL, 브랜치, 파일\u002F디렉토리, 또는 생략 시 현재 브랜치 자동 감지). PR 크기 무관 — 큰 PR 은 report 의 *리뷰 범위* 섹션에 미커버 영역 명시.\"\n    - name: \"--base-sha \u003Csha>\"\n      kind: flag\n      default: \"off (`gh pr view … baseRefName` 또는 기본 브랜치에서 base 를 스스로 유도)\"\n      summary: \"diff 의 base 를 호출자가 지정. 넘겨받은 값은 `git merge-base --is-ancestor` 로 검증하며, 실패하면 기존 유도로 폴백하고 그 사실을 리포트 개요에 남긴다. lite 에서도 동일하다.\"\n      parse_note: \"`--base-sha` 다음 토큰을 값으로 취한다. 값이 없으면 플래그를 무시하고 기존 유도를 쓴다.\"\n    - name: \"--declared-files \u003Ccsv>\"\n      kind: flag\n      default: \"off (변경 파일 집합을 diff 에서만 유도)\"\n      summary: \"이 변경이 건드리기로 선언된 파일 집합(쉼표 구분). diff 는 무엇이 바뀌었는지만 말하므로, 선언 밖 파일을 지목할 수 있게 한다.\"\n      parse_note: \"`--declared-files` 다음 토큰을 값으로 취한다. 쉼표·공백을 포함할 수 있으므로 인용 부호로 감싸 넘긴다.\"\n    - name: \"--expand \u003C분야>[,\u003C분야>]\"\n      kind: flag\n      default: \"off (기술 분야만 리뷰 — 추정한 요구 지적과 문서 표현 다듬기는 등급 없이 `## 범위 밖 관찰` 절에만 남는다)\"\n      summary: \"기본에서 빠진 리뷰 분야를 연다. 값은 `요구`와 `문서표현` 둘이며, 고정 2인 가운데 코드 품질·로직 리뷰어가 맡는다. lite 는 문서를 받는 길이 없어 기획서는 늘 없음이다 — 기획서와 대조하려면 \u002Fcc-cmds:review 를 쓴다.\"\n      parse_note: \"`--expand` 다음 토큰을 값으로 취해 쉼표로 나눈다. 두 번 주면 합집합이고, 모르는 값은 경고 한 줄과 함께 버리며, 남은 값이 없으면 플래그를 주지 않은 것과 같다. 이 토큰과 값은 대상 뒤 여분 토큰 판정 전에 인자열에서 제거된다.\"\n---\n\nConduct a lightweight code review using a fixed 2-member sonnet agent team for the given task.\nAll team discussions and inter-agent communication should be in English to optimize token usage.\nUser-facing communication and saved documentation should be in Korean.\n\nThis skill is the lightweight sibling of `review`. It trades depth for predictable token cost: a fixed 2-member sonnet team (Security reviewer + Code-quality\u002FLogic reviewer) replaces the dynamic risk-indicator-driven composition, the discussion runs a single round + one cross-validation round (no follow-ups), the Explore subagent is skipped (the lead explores directly with `grep` + `Read`), and the second-positional `\u003Cdirective>` argument is dropped. Use `review` when subtle invariants — concurrency, authn bypass — or large-PR depth-driven scope splitting matter more than speed.\n\n## Input\n\n> _Consistency Note: README의 user-facing 요약은 frontmatter `options[]`에서 자동 생성됨. 본 섹션은 runtime-agent 작동 규약이며, 변경 시 frontmatter도 함께 갱신._\n\n`$ARGUMENTS` can be: a PR URL (`https:\u002F\u002Fgithub.com\u002F...\u002Fpull\u002FN`), a PR number, a branch name, a file\u002Fdirectory path, or empty (auto-detect from current branch). The base `review` skill's second positional `\u003Cdirective>` is **not supported** in lite — see Step 1a for the dropped-token warning.\n\n## Workflow\n\n### Step 0: Tool Loading\n\nLoad deferred tools via ToolSearch before any other step (`Agent` is built-in — do not load it):\n- `ToolSearch(\"select:AskUserQuestion,mcp__cc-cmds__question_form\")` — MUST load before Step 1 (the form's schema missing from the result means the form is unavailable)\n- `ToolSearch(\"select:SendMessage\")`\n- `ToolSearch(\"select:TaskStop\")`\n\n**Before calling AskUserQuestion, Read `${CLAUDE_SKILL_DIR}\u002F..\u002F_common\u002Faskuserquestion.md`.** Apply the hard constraints from that file to every AskUserQuestion call in this skill.\n\n**Read `${CLAUDE_SKILL_DIR}\u002F..\u002F_common\u002Fagent-team-protocol.md` here, not at Step 4.** It carries the spawn \u002F ledger \u002F dispatch+convergence \u002F escalation contract and the task-assignment header. Reading the dispatch contract in the same place as the tools it governs is the placement the sibling skills take. This moves where the file is read and nothing else — lite's deliberate carve-out from the protocol's `### Round budget` stays stated at Step 4, where it binds and where its number belongs.\n\n---\n\n### Step 1: PR Detection & Scope Confirmation (Korean)\n\n#### Pre-validation: gh CLI status check\n\nWhen `$ARGUMENTS` is not a file path, verify gh CLI before auto-detect:\n1. `command -v gh` — if not installed, install gh and ask user to run `gh auth login`\n2. `gh auth status` — if not authenticated, ask user to run `gh auth login`\n3. `gh api repos\u002F{owner}\u002F{repo}` — if no access, ask user to switch to the correct account\n\nProceed to 1a after pre-validation passes.\n\n#### 1a: Input parsing & target detection\n\nParse `$ARGUMENTS`:\n\n- **PR URL** (`https:\u002F\u002Fgithub.com\u002F...\u002Fpull\u002FN`) → extract PR number → `gh pr view {number}`\n- **Number** → treat as PR number → `gh pr view {number}`\n- **Branch name pattern** → `gh pr list --head {branch} --json number,title --jq '.[0]'`\n- **File path** → scoped file review (inform user: \"파일 경로 기반 리뷰입니다. PR 기반 리뷰 시 추가 컨텍스트(PR 댓글, CI 상태 등)를 활용할 수 있습니다.\")\n- **`--base-sha \u003Csha>` and `--declared-files \u003Ccsv>`** → scope hints from a caller that already knows both. Each takes the **next token** as its value, and both the flag and its value are removed from the argument string before the remainder is judged below. `--base-sha` names the commit the change branched from — verified in 1b, never trusted. `--declared-files` is the comma-separated set the change was supposed to touch; quote it. A flag whose value is missing is dropped along with the flag rather than consuming the following token.\n- **`--expand \u003C분야>[,\u003C분야>]`** → opens fields the default leaves closed (item 14's Field scope of `..\u002Freview\u002Freferences\u002F01-reviewer-context-package.md`). It takes the **next token** as its value, and both the flag and its value are removed from the argument string before the remainder is judged below — otherwise the value would be read as an extra token after the target and draw the directive warning. Split the value on commas; the known values are `요구` and `문서표현`. Given twice, the open fields are the union. An unknown value is discarded with one Korean warning naming it; when nothing is left, it is as if the flag were not given. A flag whose value is missing is dropped along with the flag, without consuming the next token. The directive is still discarded as below; only this flag opens a field.\n- **Any other token beginning with `--`** → not a directive and not silently absorbed. Emit one Korean warning naming the token and discard it, the same disposition the bullet below takes. The two bullets differ only in what they name: this one exists because an unrecognized flag reaching the discard path as prose would be reported as a rejected *directive*, which sends the reader looking for a directive nobody wrote.\n- **Mixed input with extra tokens after the target** (e.g., \"PR #42 보안 중심으로\"): extract the target only. Emit one Korean warning and discard the remainder: *\"리뷰 지시문은 review-lite에서 지원하지 않아 무시합니다. 가중치 분석이 필요하면 \u002Fcc-cmds:review 를 사용하세요.\"* Do NOT propagate the directive to team composition, context package, or the report.\n- **Ambiguous input** → clarify with AskUserQuestion\n\nWhen `$ARGUMENTS` is empty, run auto-detect chain:\n\n1. `gh pr view --json number,title,url,state,isDraft,baseRefName,additions,deletions,changedFiles` → success: PR review\n2. Failure: `gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'` → `git diff {DEFAULT_BRANCH}...HEAD --stat` → if diff exists: local diff review\n3. No diff: AskUserQuestion to request review target\n\n**If target is a non-PR (local diff or file path)**, Read `${CLAUDE_SKILL_DIR}\u002F..\u002Freview\u002Freferences\u002F03-non-pr-mode.md` to apply adaptations to Steps 2-5 (context package items 2\u002F5, document header, checklist focus).\n\n#### 1b: Context collection\n\n**For PR targets:**\n\n```bash\n# Repository slug (used in subsequent gh api calls)\nREPO=$(gh repo view --json nameWithOwner --jq '.nameWithOwner')\n\n# PR metadata (latestReviews = current state snapshot per reviewer; full history via gh api ...\u002Freviews below)\ngh pr view $PR_NUMBER --json number,title,body,state,isDraft,labels,milestone,\\\n  assignees,reviewRequests,latestReviews,headRefName,baseRefName,url,createdAt,\\\n  additions,deletions,changedFiles\n\n# Changed files with per-file statistics (path, additions, deletions; '.[] | .path' for path-only)\ngh pr view $PR_NUMBER --json files --jq '[.files[] | {path,additions,deletions}]'\n\n# Full diff\ngh pr diff $PR_NUMBER\n\n# Existing inline review comments\ngh api --paginate \"repos\u002F$REPO\u002Fpulls\u002F$PR_NUMBER\u002Fcomments\" | \\\n  jq '[.[] | {author: .user.login, file: .path, line: .line, body: .body, \\\n  created_at: .created_at, resolved: (.resolved \u002F\u002F false)}]' | \\\n  jq -s 'add'\n\n# Review decisions\ngh api --paginate \"repos\u002F$REPO\u002Fpulls\u002F$PR_NUMBER\u002Freviews\" | \\\n  jq '[.[] | {author: .user.login, state: .state, body: .body, \\\n  submitted_at: .submitted_at}]' | \\\n  jq -s 'add'\n\n# General PR comments\ngh pr view $PR_NUMBER --json comments \\\n  --jq '[.comments[] | {author: .author.login, body: .body, createdAt: .createdAt}]'\n\n# CI check status\ngh pr checks $PR_NUMBER --json name,state,bucket 2>\u002Fdev\u002Fnull || echo \"[]\"\n```\n\n**For local diff targets:**\n\n```bash\ngit diff {DEFAULT_BRANCH}...HEAD        # full diff\ngit log {DEFAULT_BRANCH}..HEAD --oneline  # commit history\n```\n\n**A supplied `--base-sha` is verified, never trusted — and lite is no different.** Run `git merge-base --is-ancestor \u003Csupplied base> \u003Ctarget head>`. `\u003Ctarget head>` is this review's target named explicitly — the branch, or the PR's head — and never the bare `HEAD` of whatever directory the command runs in; binding to the ambient head makes the guard depend on the caller's working directory, which is the same class of failure the flag exists to close. The substitution replaces the base derivation only; a PR target still collects its metadata and comments as before. On success take the diff against that base in either mode:\n\n\n**On failure fall back** to the derivation this step already has — `gh pr view … baseRefName` for a PR, `{DEFAULT_BRANCH}` for a local diff — and record one line in the report overview naming the rejected value and the base actually used. A base that is not an ancestor of `\u003Ctarget head>` produces a diff of a tree nobody wrote, and the report reads exactly as it would have, so nothing else surfaces the mistake. This costs one command and lite does not economize on it: the saving would be a review of the wrong change.\n\n#### 1c: Scope confirmation\n\n**A supplied `--declared-files` is compared against what actually changed.** List the changed paths for the diff just resolved and set them against the declared set. Name in the report's overview any changed path that is **outside** the declaration, and any declared path with **no** change. Neither is an error and neither narrows the review — the whole diff is reviewed either way — but the two lists are the only place the run says whether the change that landed is the change that was declared. Git can say which files moved; only the declaration says which ones were meant to. With no flag, skip this and say nothing.\n\nPresent to user (in Korean):\n- Review target type (PR \u002F local diff \u002F user-specified)\n- PR title\u002Fnumber\u002FURL (if PR)\n- Change statistics (file count, additions, deletions)\n- Key changed files\u002Fmodules\n- Existing PR review comment summary (if any)\n- CI status (highlight failed checks if any)\n\n**No large-PR gate**: PR size is not a lite-savings axis. Proceed regardless of size; the Step 5 *리뷰 범위* section will explicitly disclose any context-window-driven coverage gap. Proceed after user confirmation.\n\n#### 1d: Edge case handling\n\n| Case | Handling |\n|------|----------|\n| Draft PR | Proceed with review, mark draft status in report header |\n| Closed\u002FMerged PR | AskUserQuestion to confirm whether to continue |\n| Multiple PRs on same branch | List all, let user choose |\n| Fork PR | `gh pr view` handles normally |\n| No GitHub remote | Skip all gh commands, switch to local diff mode |\n| gh CLI not installed | Install gh, then ask user to run `gh auth login`. gh is required |\n| gh auth failure | Ask user to run `gh auth login`. Retry after authentication |\n\n---\n\n### Step 2: Codebase Exploration (lead-direct)\n\nThe `Explore` subagent is not used in lite — the lead explores directly with `grep` + `Read`.\n\nExplore based on the changed file list:\n- Related modules and dependencies (callers, importers) — `grep -r` from project root, scoped to changed files' siblings.\n- Related test files — `grep -r` for the changed module names + project test directory conventions.\n- Existing patterns and conventions in the affected area — `Read` representative neighbours.\n- Architectural context — `Read` top-level structure files (e.g., index\u002Frouter\u002Fmanifest).\n\nThis exploration output is the key input for Step 3 reviewer context packages.\n\n**Read each source file once** — the per-stage read cache in `## Constraints` binds here, and it binds hardest here: lite's lead explores directly rather than through an `Explore` subagent, so every re-read of an unchanged file is spent out of the lead's own context.\n\n---\n\n### Step 3: Team Composition Announcement (Korean)\n\n**No proposal cycle.** The team composition is fixed and announced to the user with a single Y\u002FN gate.\n\nAnnouncement template (Korean):\n\n```\n**리뷰 팀 구성** (review-lite 고정 2인):\n- 리뷰 분야: 기술(기본)\n- 기획서: 없음\n\n| 역할 | 모델 | 담당 범위 |\n|------|------|-----------|\n| 보안 전담 리뷰어 | sonnet | 위협 모델, 인증·인가, 입력 검증, 시크릿\u002F크레덴셜, 암호 사용, 세션·토큰 처리, 의존성 취약점 |\n| 코드 품질·로직 리뷰어 | sonnet | 로직 정확성, API 계약, 가독성·유지보수성, 테스트, 성능 |\n\n이 구성으로 진행할까요?\n```\n\nThe `리뷰 분야` line is `기술(기본)`, or `기술 + ` followed by the fields `--expand` opened in the order 「요구, 문서표현」. The `기획서` line is always `없음`: lite has no way to take a document, and a review against a spec is `\u002Fcc-cmds:review`'s, as the directive warning in Step 1a already says. **An open field adds no seat.** Both `요구` and `문서표현` join the `담당 범위` of the 코드 품질·로직 리뷰어, and each reviewer's context package carries the field line item 14's Field scope asks for.\n\nBranch on user response:\n- **Approve** → proceed to Step 4 (spawn the team)\n- **Reject\u002Fabort** → end review\n\nThe split is structural (path-agnostic): the security reviewer covers any security-sensitive change regardless of file path or keyword pattern. There is no path-regex gate — `crypto\u002F`, `signing\u002F`, `jwt-validator.ts`, `csrf.ts`, `rate-limit\u002F` etc. are all caught structurally by the dedicated security reviewer. There is also no `Scope Coordinator` role; the 2-member team self-divides scope, and any uncovered area is explicitly disclosed in the Step 5 report.\n\n**Review slug** (names the review-report doc + keys the ledger; it is no longer a harness team name):\n- PR review: `review-lite-pr{NUMBER}` (e.g., `review-lite-pr42`)\n- Local diff: `review-lite-{branch-name}` (e.g., `review-lite-feat-auth`)\n- File path: `review-lite-{short-slug}` (e.g., `review-lite-auth-module`)\n\n---\n\n### Step 4: Parallel Review (English, team internal)\n\nThe spawn \u002F ledger \u002F dispatch+convergence \u002F escalation contract and the task-assignment header come from `${CLAUDE_SKILL_DIR}\u002F..\u002F_common\u002Fagent-team-protocol.md`, **read in Step 0**. Reviewers are **nameless background tasks** (`Agent` with `subagent_type:\"claude\"`, `run_in_background:true`, **no `name`**), one fresh dispatch per `(role, round\u002Fphase)` key and resumed by `agentId` only inside that key, self-terminating on return — each reviewer's result is delivered by its **witness file**, and the return text is only an early-wake hint (see the protocol's witness contract and `witness_present` completion predicate). There is no `TeamCreate`\u002Fnamed-teammate\u002FDM machinery.\n\n**Before building each reviewer's context package, Read `${CLAUDE_SKILL_DIR}\u002F..\u002Freview\u002Freferences\u002F01-reviewer-context-package.md`** for the 17-item package contents, role-specific checklists, review protocol rounds, and review-specific facilitator additions.\n\n- **Early-stub the review-report doc** at spawn time (the report doc does not exist until Step 5, so pre-create the stub so the ledger has a home — no TMPDIR fallback). Write `docs\u002Freviews\u002F{slug}.md` (the Step 3 review slug) as: an H1 title, then a `\u003C!-- cc-design-ledger v3 … -->` HTML-comment block (after the H1, before the first `##`). Entry schema — the column list, the `state` domain, the per-row transient set and its terminal-strip rule (including the `epoch` exemption) — is defined once in `_common\u002Fagent-team-protocol.md`'s Role↔agentId ledger v3 and is not restated here. `scratchDir` = the reviewer's out-of-tree witness dir, recorded at spawn. Before the first spawn run the protocol's `## Spawn` command — `\u003Cplugin root>\u002Forchestrator\u002Fcc-team-witness-init.sh \u003Cthe Step 3 review slug>` (no `bash` in front — see the protocol's note) — and record the **printed path, literally** (not `$WITNESS_DIR`) as each reviewer's `scratchDir`; both Step-4 review rounds are witnessed (`{role-slug}.round-N.md`, sentinel\u002Fnonce per the protocol). Follow-up is disabled, so there are no later witnessed phases. **Re-read the ledger from disk before any dispatch or resume**; if the block is missing or unparseable — **or a `state=running` row carries no `witnessNonce`, or the non-aborted rows are in partial `epoch` presence** — **fail closed via `AskUserQuestion`** (never silent-skip; the nonce-absence and partial-`epoch` conditions mirror the protocol's derive-from-ledger fail-close so a legacy pre-v3 ledger has a local safety net — uniform `epoch` absence is **not** a fail-close, it is this skill's normal single-team shape routed to the epoch-agnostic roster).\n- **Spawn the fixed 2-member sonnet team** (Security reviewer + Code-quality\u002FLogic reviewer, both pinned to model `\"sonnet\"`) as nameless background tasks: for each call `Agent({ subagent_type: \"claude\", run_in_background: true, prompt: \u003Cself-contained assignment> })`. Embed the **task-assignment header** (from the protocol) verbatim atop each spawn prompt, followed by the reviewer's self-contained context package (a task does not share the lead's conversation). Record each returned `agentId` in the ledger immediately (`state=running`, round 1). **Stamp the round-1 `witnessNonce`** on every one of its rows in the same at-spawn recording window as `agentId`\u002F`scratchDir`, per the protocol Spawn section — no `epoch` stamp, since a single-team skill is uniform-`epoch`-absence handled by the roster's mode-(ii) epoch-agnostic path. Update the ledger on every state change.\n- **Progress checkpoint — this skill opts in.** Append the protocol's checkpoint clause verbatim after the task-assignment header in every reviewer dispatch and resume prompt (`## Per-skill parameter seam` → **Parameter — progress checkpoint**), substituting the same four tokens the header already substitutes. Reviewers publish to `${scratchDir}\u002Fpartial\u002F`; the lead reads no checkpoint in a live run.\n- **Re-entry notes — this skill opts in.** Append the protocol's re-entry notes clause (`## Per-skill parameter seam` → **Parameter — re-entry notes**) verbatim after the task-assignment header in every reviewer prompt:\n\n**Re-entry notes (MUST)**: directly above your `peer-read:` lines (directly above your sentinel when you have none), put a section that starts with the heading `## Re-entry notes`, at most 20 lines and 2,000 bytes, one entry per line — `path:line — why` for a place you would open first if you came back to this work, or one command you would re-run. No findings and no verdicts in it. The next dispatch of your role reads it as the starting point of its re-exploration.\n\n- All team-internal discussion in English.\n- NO code modifications allowed. Review only.\n- **The lead acts as a facilitator** driving the rounds within lite's own round cap — the deliberate carve-out recorded under **Round structure** below.\n\n#### Round structure (fixed — round hard-cap = 2)\n\n1. **Round 1 — Initial Review**: each reviewer independently produces findings within their scope (per the role-specific checklist from `01-reviewer-context-package.md`). A reviewer's findings are delivered by its **witness** (`{role-slug}.round-1.md`) — confirm each reviewer's round-1 witness via `witness_present`, then read the witness (never the return), before proceeding.\n2. **Round 2 — Cross-Validation**: dispatch each reviewer's role afresh for round 2 (the task-assignment header + its own round-1 witness and the peer's round-1 witness, each named **by path** as Round-2 input, per `_common\u002Fagent-team-protocol.md` `## Multi-round`) for one cross-check pass (severity disagreements, missed cross-domain issues such as a security finding that also has performance implications, blind-spot disclosure). Confirm both round-2 witnesses via `witness_present` and read them. This convergence-by-witness-collection round IS the cross-validation; when both witnesses are `witness_present` and their bodies say \"no further input\" the team has converged.\n\n**No further rounds.** No follow-up or refinement cycle. **Total team-internal rounds = 2** (Round 1 + Round 2) — this is lite's round hard-cap; round 2 is one new dispatch per reviewer (the dispatch is the unit of lite's predictable cost — a dispatch-budget soft-cap under the round hard-cap; the in-round resumes of a send-back are not counted against it).\n\n**Deliberate carve-out from the shared Round budget.** The lite family keeps its own hard cap of 2 rather than adopting the cap in `_common\u002Fagent-team-protocol.md`'s `### Round budget`, because predictable token cost is the reason this skill exists and the shared cap would raise its round allowance — this divergence is intent, not drift.\n\n**Escalation** (per the protocol's reconcile ladder + failure phenotypes): **Case 1 — thin\u002Fempty witness** (counter) → re-scope + resume once; 2nd consecutive → `AskUserQuestion` (proceed without this reviewer \u002F re-scope once more \u002F abort); route an excluded reviewer through the protocol's Case-1 terminal disposition (`_common\u002Fagent-team-protocol.md` §Escalation Case 1 — the SOT for the ledger `state=aborted` stamp and the report-metadata exclusion mark) rather than re-specifying it here. **Case 2 — never-returns** → the protocol's reconcile-ladder death verdict fires → `TaskStop` + **same-round respawn** (new `agentId`, with the ledger row's `agentId` \u002F `outputFile` updated and its `stallMark` reset per the protocol); if the respawn also dies → `AskUserQuestion`. **Case 3 — non-conforming witness** (routing rule) → re-assign once; a recurrence feeds the Case 1 counter.\n\n---\n\n### Step 5: Result Synthesis & Documentation (Korean)\n\n**Before synthesizing review results, Read `${CLAUDE_SKILL_DIR}\u002F..\u002Freview\u002Freferences\u002F02-review-report-template.md`** for the severity system (P0~P3), merge rules, document structure template, and file naming\u002Fversion conventions.\n\nThe lead synthesizes all review results into a Korean document under `docs\u002Freviews\u002F` following the template. Report length is unconstrained (length is not a lite-savings axis); structure is the floor — P0~P3 severity tags and the structured finding list MUST be preserved.\n\n**P1 classification.** Write it exactly as the template's `### P1 분류 기준` and \"P1 Classification Grammar\" sections spell it — they own the grammar, so it is not restated here:\n\n- the `- **P1 분류**: 차단 N건 | 이월 가능 N건` line directly after `발견 요약`, always present — `차단 0건 | 이월 가능 0건` when there is no P1;\n- on every P1 item, exactly one `**[차단]**` or `**[이월 가능]**` tag and a `분류 근거` sub-bullet, and on every `**[이월 가능]**` item an `이월 제목` and an `이월 본문`;\n- the overview line `- **슬라이스 범위**: 적용 안 됨 — 인자 없음`, because this skill takes no `--slice` and so never applies a slice scope; there is no `다른 슬라이스 몫` line and no `## 다른 슬라이스 몫 (집계 제외)` section.\n\nThis skill registers no issue. Whether a report reading \"이월 후 머지 가능\" sends its carryable items to follow-up issues and merges is the person's decision.\n\n**Field lines and the out-of-scope section.** The overview carries `- **리뷰 분야**:` as announced in Step 3 and `- **기획서**: 없음`, directly after `변경 규모`. Carry each reviewer's `[범위 밖:\u003C분야>]` line into `## 범위 밖 관찰` as the template's \"Out-of-scope observations section\" spells it, and leave the section out when there is none. That section is not `## 리뷰 범위` below, whose name and meaning are unchanged.\n\n**Mandatory section — `## 리뷰 범위`** (coverage-gap explicit disclosure):\n\nEvery review-lite report MUST include this section so the user is never silently misled about uncovered files when a PR exceeds context-window throughput.\n\n```markdown\n## 리뷰 범위\n\n- 보안 전담 리뷰어 분담: \u003Cfiles>\n- 코드 품질·로직 리뷰어 분담: \u003Cfiles>\n- 미커버 영역: \u003Ccontext window 한계로 분담 못 된 files; 없으면 \"없음\">\n- 관점 한계: 2인 로스터 고정 — 보안·코드 품질·로직 외 관점(성능·동시성·API 계약·설계 정합 등)은 전담 리뷰어가 없습니다. 해당 축이 중요하면 \u002Fcc-cmds:review 를 사용하세요.\n```\n\nFor small PRs the *미커버 영역* line is typically *\"없음\"*. For large PRs that exceeded coverage during Round 1, list the uncovered files explicitly so the user can decide whether to re-run with `\u002Fcc-cmds:review` for full coverage.\n\nAfter saving the report:\n\n- Notify the user in Korean: *\"리뷰 보고서 저장을 완료했습니다. 팀을 정리한 뒤 결과를 공유드리겠습니다.\"*\n- **Read `${CLAUDE_SKILL_DIR}\u002F..\u002F_common\u002Fteam-cleanup.md`** and follow it **in full** — its four bullets are the process side (every reviewer self-terminated the moment it returned, so `TaskStop` is only for a wedged one), ledger hygiene, and removal of the team's witness directory. Do not summarize it here: the summary that used to sit on this line carried only the first two, and the witness directory was never removed.\n- Present the report summary to the user in Korean.\n- Emit the lite-redirect footer (single line, every invocation):\n\n```\nℹ️ 보안 민감 PR, deep audit, 큰 PR 의 정밀 분담, 또는 미묘한 동시성 검증이 필요한 경우 \u002Fcc-cmds:review 권장.\n```\n\n---\n\n### Step 6: Review Discussion & Follow-up (Korean, lead-only)\n\nAfter presenting the review report, discuss with the user.\n\n#### Lead direct handling (no team needed)\n\n- Detailed explanation of specific findings\n- Code section re-check (using `grep` + `Read` directly)\n- Severity re-assessment when user provides new context (e.g., \"이 코드 경로는 내부 전용입니다\")\n- Explanation of why a specific finding was not included\n\n#### No follow-up reviewer spawning\n\nFollow-up reviewer spawning is **disabled in lite**. If the user requests comprehensive analysis of areas not covered, severity-dispute independent re-evaluation, multi-perspective architectural follow-up, or blind-spot deep-dive, do NOT spawn new reviewer tasks (nameless background sub-agents). Instead emit in Korean: *\"더 깊은 분석이 필요하면 `\u002Fcc-cmds:review` 를 사용해주세요.\"* and continue lead-only refinement of the existing report. Step 6 stays lead-only.\n\n#### Document update rules\n\nRefer to `${CLAUDE_SKILL_DIR}\u002F..\u002Freview\u002Freferences\u002F02-review-report-template.md` \"Document Update Rules (Step 6)\" section for the 개정 이력 \u002F 철회된 항목 update conventions.\n\nRepeat until user is satisfied.\n\n---\n\n## Constraints\n\n- **No code modifications.** Review only.\n- **Source files are read once per review stage.** Within one stage, a source file already read is not read again. **A turn yield is not an invalidation point** — nothing about the file changed because the model stopped and resumed. There are exactly three invalidation points: this session wrote to that path with `Edit`\u002F`Write`; a git operation moved `HEAD` or the working tree (`checkout`, `rebase`, `merge`, `stash`, `pull`); or a new stage was entered. **Four things this cache never covers, and each for its own reason** — the **run ledger**, whose contract deliberately produces an under-claim that a stale read inverts into an over-claim; **witness files**, where there is no invalidation event the lead can observe at all, so the cache has nothing to key on; the reviewer **`output_file`**, which a cached read reports as byte-stable and therefore as WEDGED when it is being written normally; and the **gate snapshot**, whose whole purpose is to be re-derived. Those four are re-read every time they are consulted.\n- **Inter-agent communication must be in English.** User-facing communication and saved documents in Korean.\n- **Sonnet pin**: every reviewer uses model `\"sonnet\"`. Haiku is forbidden; opus is out of scope (use `\u002Fcc-cmds:review` if opus depth is required). Both of `\u002Fcc-cmds:review-upgrade`'s reinforcement axes are out of scope here — opus upgrade violates the sonnet pin, and reviewer add\u002Fsplit (and the Scope Coordinator add) mutates the fixed 2-member roster (run `\u002Fcc-cmds:review-upgrade` against a base `\u002Fcc-cmds:review` run instead).\n- **Nameless background sub-agents**: reviewers ARE `Agent({ subagent_type: \"claude\", run_in_background: true })` sub-agents, one fresh dispatch per `(role, round\u002Fphase)` key and resumed by `agentId` (`SendMessage` to the agentId) only inside that key. The **cross-review through witnesses on disk is required** — round 2's dispatch reads the reviewer's own round-1 witness and its peer's by path; a dispatch that reads no peer witness is not a team.\n- **Deferred tool loading**: Before using AskUserQuestion, SendMessage, or TaskStop, you MUST first load them via ToolSearch (see Step 0; `Agent` is built-in — do not load it). AskUserQuestion MUST be loaded before Step 1.\n- **PR comment dedup required**: when existing PR comments\u002Freviews exist, always provide them as context to reviewers. Filter or flag findings that duplicate existing comments.\n- **Fix suggestion inclusion**: include fix direction when clear. Judgment-based — decide based on issue type and complexity.\n- **CI failure routing**: when CI has failed checks, mention them in Step 1c. Add \"CI failure priority check area: [failed check name and related files]\" to the relevant reviewer's context package — security-sensitive failures (auth, secrets) route to the security reviewer; logic\u002Fbuild\u002Ftest failures route to the code-quality\u002Flogic reviewer.\n\nTask: $ARGUMENTS\n","Conduct a lightweight code review using a fixed 2-member sonnet agent team for the given task.\nAll team discussions and inter-agent communication should be in English to optimize token usage.\nUser-facing communication and saved documentation should be in Korean.\n\nThis skill is the lightweight sibling of `review`. It trades depth for predictable token cost: a fixed 2-member sonnet team (Security reviewer + Code-quality\u002FLogic reviewer) replaces the dynamic risk-indicator-driven composition, the discussion runs a single round + one cross-validation round (no follow-ups), the Explore subagent is skipped (the lead explores directly with `grep` + `Read`), and the second-positional `\u003Cdirective>` argument is dropped. Use `review` when subtle invariants — concurrency, authn bypass — or large-PR depth-driven scope splitting matter more than speed.\n\n## Input\n\n> _Consistency Note: README의 user-facing 요약은 frontmatter `options[]`에서 자동 생성됨. 본 섹션은 runtime-agent 작동 규약이며, 변경 시 frontmatter도 함께 갱신._\n\n`$ARGUMENTS` can be: a PR URL (`https:\u002F\u002Fgithub.com\u002F...\u002Fpull\u002FN`), a PR number, a branch name, a file\u002Fdirectory path, or empty (auto-detect from current branch). The base `review` skill's second positional `\u003Cdirective>` is **not supported** in lite — see Step 1a for the dropped-token warning.\n\n## Workflow\n\n### Step 0: Tool Loading\n\nLoad deferred tools via ToolSearch before any other step (`Agent` is built-in — do not load it):\n- `ToolSearch(\"select:AskUserQuestion,mcp__cc-cmds__question_form\")` — MUST load before Step 1 (the form's schema missing from the result means the form is unavailable)\n- `ToolSearch(\"select:SendMessage\")`\n- `ToolSearch(\"select:TaskStop\")`\n\n**Before calling AskUserQuestion, Read `${CLAUDE_SKILL_DIR}\u002F..\u002F_common\u002Faskuserquestion.md`.** Apply the hard constraints from that file to every AskUserQuestion call in this skill.\n\n**Read `${CLAUDE_SKILL_DIR}\u002F..\u002F_common\u002Fagent-team-protocol.md` here, not at Step 4.** It carries the spawn \u002F ledger \u002F dispatch+convergence \u002F escalation contract and the task-assignment header. Reading the dispatch contract in the same place as the tools it governs is the placement the sibling skills take. This moves where the file is read and nothing else — lite's deliberate carve-out from the protocol's `### Round budget` stays stated at Step 4, where it binds and where its number belongs.\n\n---\n\n### Step 1: PR Detection & Scope Confirmation (Korean)\n\n#### Pre-validation: gh CLI status check\n\nWhen `$ARGUMENTS` is not a file path, verify gh CLI before auto-detect:\n1. `command -v gh` — if not installed, install gh and ask user to run `gh auth login`\n2. `gh auth status` — if not authenticated, ask user to run `gh auth login`\n3. `gh api repos\u002F{owner}\u002F{repo}` — if no access, ask user to switch to the correct account\n\nProceed to 1a after pre-validation passes.\n\n#### 1a: Input parsing & target detection\n\nParse `$ARGUMENTS`:\n\n- **PR URL** (`https:\u002F\u002Fgithub.com\u002F...\u002Fpull\u002FN`) → extract PR number → `gh pr view {number}`\n- **Number** → treat as PR number → `gh pr view {number}`\n- **Branch name pattern** → `gh pr list --head {branch} --json number,title --jq '.[0]'`\n- **File path** → scoped file review (inform user: \"파일 경로 기반 리뷰입니다. PR 기반 리뷰 시 추가 컨텍스트(PR 댓글, CI 상태 등)를 활용할 수 있습니다.\")\n- **`--base-sha \u003Csha>` and `--declared-files \u003Ccsv>`** → scope hints from a caller that already knows both. Each takes the **next token** as its value, and both the flag and its value are removed from the argument string before the remainder is judged below. `--base-sha` names the commit the change branched from — verified in 1b, never trusted. `--declared-files` is the comma-separated set the change was supposed to touch; quote it. A flag whose value is missing is dropped along with the flag rather than consuming the following token.\n- **`--expand \u003C분야>[,\u003C분야>]`** → opens fields the default leaves closed (item 14's Field scope of `..\u002Freview\u002Freferences\u002F01-reviewer-context-package.md`). It takes the **next token** as its value, and both the flag and its value are removed from the argument string before the remainder is judged below — otherwise the value would be read as an extra token after the target and draw the directive warning. Split the value on commas; the known values are `요구` and `문서표현`. Given twice, the open fields are the union. An unknown value is discarded with one Korean warning naming it; when nothing is left, it is as if the flag were not given. A flag whose value is missing is dropped along with the flag, without consuming the next token. The directive is still discarded as below; only this flag opens a field.\n- **Any other token beginning with `--`** → not a directive and not silently absorbed. Emit one Korean warning naming the token and discard it, the same disposition the bullet below takes. The two bullets differ only in what they name: this one exists because an unrecognized flag reaching the discard path as prose would be reported as a rejected *directive*, which sends the reader looking for a directive nobody wrote.\n- **Mixed input with extra tokens after the target** (e.g., \"PR #42 보안 중심으로\"): extract the target only. Emit one Korean warning and discard the remainder: *\"리뷰 지시문은 review-lite에서 지원하지 않아 무시합니다. 가중치 분석이 필요하면 \u002Fcc-cmds:review 를 사용하세요.\"* Do NOT propagate the directive to team composition, context package, or the report.\n- **Ambiguous input** → clarify with AskUserQuestion\n\nWhen `$ARGUMENTS` is empty, run auto-detect chain:\n\n1. `gh pr view --json number,title,url,state,isDraft,baseRefName,additions,deletions,changedFiles` → success: PR review\n2. Failure: `gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'` → `git diff {DEFAULT_BRANCH}...HEAD --stat` → if diff exists: local diff review\n3. No diff: AskUserQuestion to request review target\n\n**If target is a non-PR (local diff or file path)**, Read `${CLAUDE_SKILL_DIR}\u002F..\u002Freview\u002Freferences\u002F03-non-pr-mode.md` to apply adaptations to Steps 2-5 (context package items 2\u002F5, document header, checklist focus).\n\n#### 1b: Context collection\n\n**For PR targets:**\n\n```bash\n# Repository slug (used in subsequent gh api calls)\nREPO=$(gh repo view --json nameWithOwner --jq '.nameWithOwner')\n\n# PR metadata (latestReviews = current state snapshot per reviewer; full history via gh api ...\u002Freviews below)\ngh pr view $PR_NUMBER --json number,title,body,state,isDraft,labels,milestone,\\\n  assignees,reviewRequests,latestReviews,headRefName,baseRefName,url,createdAt,\\\n  additions,deletions,changedFiles\n\n# Changed files with per-file statistics (path, additions, deletions; '.[] | .path' for path-only)\ngh pr view $PR_NUMBER --json files --jq '[.files[] | {path,additions,deletions}]'\n\n# Full diff\ngh pr diff $PR_NUMBER\n\n# Existing inline review comments\ngh api --paginate \"repos\u002F$REPO\u002Fpulls\u002F$PR_NUMBER\u002Fcomments\" | \\\n  jq '[.[] | {author: .user.login, file: .path, line: .line, body: .body, \\\n  created_at: .created_at, resolved: (.resolved \u002F\u002F false)}]' | \\\n  jq -s 'add'\n\n# Review decisions\ngh api --paginate \"repos\u002F$REPO\u002Fpulls\u002F$PR_NUMBER\u002Freviews\" | \\\n  jq '[.[] | {author: .user.login, state: .state, body: .body, \\\n  submitted_at: .submitted_at}]' | \\\n  jq -s 'add'\n\n# General PR comments\ngh pr view $PR_NUMBER --json comments \\\n  --jq '[.comments[] | {author: .author.login, body: .body, createdAt: .createdAt}]'\n\n# CI check status\ngh pr checks $PR_NUMBER --json name,state,bucket 2>\u002Fdev\u002Fnull || echo \"[]\"\n```\n\n**For local diff targets:**\n\n```bash\ngit diff {DEFAULT_BRANCH}...HEAD        # full diff\ngit log {DEFAULT_BRANCH}..HEAD --oneline  # commit history\n```\n\n**A supplied `--base-sha` is verified, never trusted — and lite is no different.** Run `git merge-base --is-ancestor \u003Csupplied base> \u003Ctarget head>`. `\u003Ctarget head>` is this review's target named explicitly — the branch, or the PR's head — and never the bare `HEAD` of whatever directory the command runs in; binding to the ambient head makes the guard depend on the caller's working directory, which is the same class of failure the flag exists to close. The substitution replaces the base derivation only; a PR target still collects its metadata and comments as before. On success take the diff against that base in either mode:\n\n\n**On failure fall back** to the derivation this step already has — `gh pr view … baseRefName` for a PR, `{DEFAULT_BRANCH}` for a local diff — and record one line in the report overview naming the rejected value and the base actually used. A base that is not an ancestor of `\u003Ctarget head>` produces a diff of a tree nobody wrote, and the report reads exactly as it would have, so nothing else surfaces the mistake. This costs one command and lite does not economize on it: the saving would be a review of the wrong change.\n\n#### 1c: Scope confirmation\n\n**A supplied `--declared-files` is compared against what actually changed.** List the changed paths for the diff just resolved and set them against the declared set. Name in the report's overview any changed path that is **outside** the declaration, and any declared path with **no** change. Neither is an error and neither narrows the review — the whole diff is reviewed either way — but the two lists are the only place the run says whether the change that landed is the change that was declared. Git can say which files moved; only the declaration says which ones were meant to. With no flag, skip this and say nothing.\n\nPresent to user (in Korean):\n- Review target type (PR \u002F local diff \u002F user-specified)\n- PR title\u002Fnumber\u002FURL (if PR)\n- Change statistics (file count, additions, deletions)\n- Key changed files\u002Fmodules\n- Existing PR review comment summary (if any)\n- CI status (highlight failed checks if any)\n\n**No large-PR gate**: PR size is not a lite-savings axis. Proceed regardless of size; the Step 5 *리뷰 범위* section will explicitly disclose any context-window-driven coverage gap. Proceed after user confirmation.\n\n#### 1d: Edge case handling\n\n| Case | Handling |\n|------|----------|\n| Draft PR | Proceed with review, mark draft status in report header |\n| Closed\u002FMerged PR | AskUserQuestion to confirm whether to continue |\n| Multiple PRs on same branch | List all, let user choose |\n| Fork PR | `gh pr view` handles normally |\n| No GitHub remote | Skip all gh commands, switch to local diff mode |\n| gh CLI not installed | Install gh, then ask user to run `gh auth login`. gh is required |\n| gh auth failure | Ask user to run `gh auth login`. Retry after authentication |\n\n---\n\n### Step 2: Codebase Exploration (lead-direct)\n\nThe `Explore` subagent is not used in lite — the lead explores directly with `grep` + `Read`.\n\nExplore based on the changed file list:\n- Related modules and dependencies (callers, importers) — `grep -r` from project root, scoped to changed files' siblings.\n- Related test files — `grep -r` for the changed module names + project test directory conventions.\n- Existing patterns and conventions in the affected area — `Read` representative neighbours.\n- Architectural context — `Read` top-level structure files (e.g., index\u002Frouter\u002Fmanifest).\n\nThis exploration output is the key input for Step 3 reviewer context packages.\n\n**Read each source file once** — the per-stage read cache in `## Constraints` binds here, and it binds hardest here: lite's lead explores directly rather than through an `Explore` subagent, so every re-read of an unchanged file is spent out of the lead's own context.\n\n---\n\n### Step 3: Team Composition Announcement (Korean)\n\n**No proposal cycle.** The team composition is fixed and announced to the user with a single Y\u002FN gate.\n\nAnnouncement template (Korean):\n\n```\n**리뷰 팀 구성** (review-lite 고정 2인):\n- 리뷰 분야: 기술(기본)\n- 기획서: 없음\n\n| 역할 | 모델 | 담당 범위 |\n|------|------|-----------|\n| 보안 전담 리뷰어 | sonnet | 위협 모델, 인증·인가, 입력 검증, 시크릿\u002F크레덴셜, 암호 사용, 세션·토큰 처리, 의존성 취약점 |\n| 코드 품질·로직 리뷰어 | sonnet | 로직 정확성, API 계약, 가독성·유지보수성, 테스트, 성능 |\n\n이 구성으로 진행할까요?\n```\n\nThe `리뷰 분야` line is `기술(기본)`, or `기술 + ` followed by the fields `--expand` opened in the order 「요구, 문서표현」. The `기획서` line is always `없음`: lite has no way to take a document, and a review against a spec is `\u002Fcc-cmds:review`'s, as the directive warning in Step 1a already says. **An open field adds no seat.** Both `요구` and `문서표현` join the `담당 범위` of the 코드 품질·로직 리뷰어, and each reviewer's context package carries the field line item 14's Field scope asks for.\n\nBranch on user response:\n- **Approve** → proceed to Step 4 (spawn the team)\n- **Reject\u002Fabort** → end review\n\nThe split is structural (path-agnostic): the security reviewer covers any security-sensitive change regardless of file path or keyword pattern. There is no path-regex gate — `crypto\u002F`, `signing\u002F`, `jwt-validator.ts`, `csrf.ts`, `rate-limit\u002F` etc. are all caught structurally by the dedicated security reviewer. There is also no `Scope Coordinator` role; the 2-member team self-divides scope, and any uncovered area is explicitly disclosed in the Step 5 report.\n\n**Review slug** (names the review-report doc + keys the ledger; it is no longer a harness team name):\n- PR review: `review-lite-pr{NUMBER}` (e.g., `review-lite-pr42`)\n- Local diff: `review-lite-{branch-name}` (e.g., `review-lite-feat-auth`)\n- File path: `review-lite-{short-slug}` (e.g., `review-lite-auth-module`)\n\n---\n\n### Step 4: Parallel Review (English, team internal)\n\nThe spawn \u002F ledger \u002F dispatch+convergence \u002F escalation contract and the task-assignment header come from `${CLAUDE_SKILL_DIR}\u002F..\u002F_common\u002Fagent-team-protocol.md`, **read in Step 0**. Reviewers are **nameless background tasks** (`Agent` with `subagent_type:\"claude\"`, `run_in_background:true`, **no `name`**), one fresh dispatch per `(role, round\u002Fphase)` key and resumed by `agentId` only inside that key, self-terminating on return — each reviewer's result is delivered by its **witness file**, and the return text is only an early-wake hint (see the protocol's witness contract and `witness_present` completion predicate). There is no `TeamCreate`\u002Fnamed-teammate\u002FDM machinery.\n\n**Before building each reviewer's context package, Read `${CLAUDE_SKILL_DIR}\u002F..\u002Freview\u002Freferences\u002F01-reviewer-context-package.md`** for the 17-item package contents, role-specific checklists, review protocol rounds, and review-specific facilitator additions.\n\n- **Early-stub the review-report doc** at spawn time (the report doc does not exist until Step 5, so pre-create the stub so the ledger has a home — no TMPDIR fallback). Write `docs\u002Freviews\u002F{slug}.md` (the Step 3 review slug) as: an H1 title, then a `\u003C!-- cc-design-ledger v3 … -->` HTML-comment block (after the H1, before the first `##`). Entry schema — the column list, the `state` domain, the per-row transient set and its terminal-strip rule (including the `epoch` exemption) — is defined once in `_common\u002Fagent-team-protocol.md`'s Role↔agentId ledger v3 and is not restated here. `scratchDir` = the reviewer's out-of-tree witness dir, recorded at spawn. Before the first spawn run the protocol's `## Spawn` command — `\u003Cplugin root>\u002Forchestrator\u002Fcc-team-witness-init.sh \u003Cthe Step 3 review slug>` (no `bash` in front — see the protocol's note) — and record the **printed path, literally** (not `$WITNESS_DIR`) as each reviewer's `scratchDir`; both Step-4 review rounds are witnessed (`{role-slug}.round-N.md`, sentinel\u002Fnonce per the protocol). Follow-up is disabled, so there are no later witnessed phases. **Re-read the ledger from disk before any dispatch or resume**; if the block is missing or unparseable — **or a `state=running` row carries no `witnessNonce`, or the non-aborted rows are in partial `epoch` presence** — **fail closed via `AskUserQuestion`** (never silent-skip; the nonce-absence and partial-`epoch` conditions mirror the protocol's derive-from-ledger fail-close so a legacy pre-v3 ledger has a local safety net — uniform `epoch` absence is **not** a fail-close, it is this skill's normal single-team shape routed to the epoch-agnostic roster).\n- **Spawn the fixed 2-member sonnet team** (Security reviewer + Code-quality\u002FLogic reviewer, both pinned to model `\"sonnet\"`) as nameless background tasks: for each call `Agent({ subagent_type: \"claude\", run_in_background: true, prompt: \u003Cself-contained assignment> })`. Embed the **task-assignment header** (from the protocol) verbatim atop each spawn prompt, followed by the reviewer's self-contained context package (a task does not share the lead's conversation). Record each returned `agentId` in the ledger immediately (`state=running`, round 1). **Stamp the round-1 `witnessNonce`** on every one of its rows in the same at-spawn recording window as `agentId`\u002F`scratchDir`, per the protocol Spawn section — no `epoch` stamp, since a single-team skill is uniform-`epoch`-absence handled by the roster's mode-(ii) epoch-agnostic path. Update the ledger on every state change.\n- **Progress checkpoint — this skill opts in.** Append the protocol's checkpoint clause verbatim after the task-assignment header in every reviewer dispatch and resume prompt (`## Per-skill parameter seam` → **Parameter — progress checkpoint**), substituting the same four tokens the header already substitutes. Reviewers publish to `${scratchDir}\u002Fpartial\u002F`; the lead reads no checkpoint in a live run.\n- **Re-entry notes — this skill opts in.** Append the protocol's re-entry notes clause (`## Per-skill parameter seam` → **Parameter — re-entry notes**) verbatim after the task-assignment header in every reviewer prompt:\n\n**Re-entry notes (MUST)**: directly above your `peer-read:` lines (directly above your sentinel when you have none), put a section that starts with the heading `## Re-entry notes`, at most 20 lines and 2,000 bytes, one entry per line — `path:line — why` for a place you would open first if you came back to this work, or one command you would re-run. No findings and no verdicts in it. The next dispatch of your role reads it as the starting point of its re-exploration.\n\n- All team-internal discussion in English.\n- NO code modifications allowed. Review only.\n- **The lead acts as a facilitator** driving the rounds within lite's own round cap — the deliberate carve-out recorded under **Round structure** below.\n\n#### Round structure (fixed — round hard-cap = 2)\n\n1. **Round 1 — Initial Review**: each reviewer independently produces findings within their scope (per the role-specific checklist from `01-reviewer-context-package.md`). A reviewer's findings are delivered by its **witness** (`{role-slug}.round-1.md`) — confirm each reviewer's round-1 witness via `witness_present`, then read the witness (never the return), before proceeding.\n2. **Round 2 — Cross-Validation**: dispatch each reviewer's role afresh for round 2 (the task-assignment header + its own round-1 witness and the peer's round-1 witness, each named **by path** as Round-2 input, per `_common\u002Fagent-team-protocol.md` `## Multi-round`) for one cross-check pass (severity disagreements, missed cross-domain issues such as a security finding that also has performance implications, blind-spot disclosure). Confirm both round-2 witnesses via `witness_present` and read them. This convergence-by-witness-collection round IS the cross-validation; when both witnesses are `witness_present` and their bodies say \"no further input\" the team has converged.\n\n**No further rounds.** No follow-up or refinement cycle. **Total team-internal rounds = 2** (Round 1 + Round 2) — this is lite's round hard-cap; round 2 is one new dispatch per reviewer (the dispatch is the unit of lite's predictable cost — a dispatch-budget soft-cap under the round hard-cap; the in-round resumes of a send-back are not counted against it).\n\n**Deliberate carve-out from the shared Round budget.** The lite family keeps its own hard cap of 2 rather than adopting the cap in `_common\u002Fagent-team-protocol.md`'s `### Round budget`, because predictable token cost is the reason this skill exists and the shared cap would raise its round allowance — this divergence is intent, not drift.\n\n**Escalation** (per the protocol's reconcile ladder + failure phenotypes): **Case 1 — thin\u002Fempty witness** (counter) → re-scope + resume once; 2nd consecutive → `AskUserQuestion` (proceed without this reviewer \u002F re-scope once more \u002F abort); route an excluded reviewer through the protocol's Case-1 terminal disposition (`_common\u002Fagent-team-protocol.md` §Escalation Case 1 — the SOT for the ledger `state=aborted` stamp and the report-metadata exclusion mark) rather than re-specifying it here. **Case 2 — never-returns** → the protocol's reconcile-ladder death verdict fires → `TaskStop` + **same-round respawn** (new `agentId`, with the ledger row's `agentId` \u002F `outputFile` updated and its `stallMark` reset per the protocol); if the respawn also dies → `AskUserQuestion`. **Case 3 — non-conforming witness** (routing rule) → re-assign once; a recurrence feeds the Case 1 counter.\n\n---\n\n### Step 5: Result Synthesis & Documentation (Korean)\n\n**Before synthesizing review results, Read `${CLAUDE_SKILL_DIR}\u002F..\u002Freview\u002Freferences\u002F02-review-report-template.md`** for the severity system (P0~P3), merge rules, document structure template, and file naming\u002Fversion conventions.\n\nThe lead synthesizes all review results into a Korean document under `docs\u002Freviews\u002F` following the template. Report length is unconstrained (length is not a lite-savings axis); structure is the floor — P0~P3 severity tags and the structured finding list MUST be preserved.\n\n**P1 classification.** Write it exactly as the template's `### P1 분류 기준` and \"P1 Classification Grammar\" sections spell it — they own the grammar, so it is not restated here:\n\n- the `- **P1 분류**: 차단 N건 | 이월 가능 N건` line directly after `발견 요약`, always present — `차단 0건 | 이월 가능 0건` when there is no P1;\n- on every P1 item, exactly one `**[차단]**` or `**[이월 가능]**` tag and a `분류 근거` sub-bullet, and on every `**[이월 가능]**` item an `이월 제목` and an `이월 본문`;\n- the overview line `- **슬라이스 범위**: 적용 안 됨 — 인자 없음`, because this skill takes no `--slice` and so never applies a slice scope; there is no `다른 슬라이스 몫` line and no `## 다른 슬라이스 몫 (집계 제외)` section.\n\nThis skill registers no issue. Whether a report reading \"이월 후 머지 가능\" sends its carryable items to follow-up issues and merges is the person's decision.\n\n**Field lines and the out-of-scope section.** The overview carries `- **리뷰 분야**:` as announced in Step 3 and `- **기획서**: 없음`, directly after `변경 규모`. Carry each reviewer's `[범위 밖:\u003C분야>]` line into `## 범위 밖 관찰` as the template's \"Out-of-scope observations section\" spells it, and leave the section out when there is none. That section is not `## 리뷰 범위` below, whose name and meaning are unchanged.\n\n**Mandatory section — `## 리뷰 범위`** (coverage-gap explicit disclosure):\n\nEvery review-lite report MUST include this section so the user is never silently misled about uncovered files when a PR exceeds context-window throughput.\n\n```markdown\n## 리뷰 범위\n\n- 보안 전담 리뷰어 분담: \u003Cfiles>\n- 코드 품질·로직 리뷰어 분담: \u003Cfiles>\n- 미커버 영역: \u003Ccontext window 한계로 분담 못 된 files; 없으면 \"없음\">\n- 관점 한계: 2인 로스터 고정 — 보안·코드 품질·로직 외 관점(성능·동시성·API 계약·설계 정합 등)은 전담 리뷰어가 없습니다. 해당 축이 중요하면 \u002Fcc-cmds:review 를 사용하세요.\n```\n\nFor small PRs the *미커버 영역* line is typically *\"없음\"*. For large PRs that exceeded coverage during Round 1, list the uncovered files explicitly so the user can decide whether to re-run with `\u002Fcc-cmds:review` for full coverage.\n\nAfter saving the report:\n\n- Notify the user in Korean: *\"리뷰 보고서 저장을 완료했습니다. 팀을 정리한 뒤 결과를 공유드리겠습니다.\"*\n- **Read `${CLAUDE_SKILL_DIR}\u002F..\u002F_common\u002Fteam-cleanup.md`** and follow it **in full** — its four bullets are the process side (every reviewer self-terminated the moment it returned, so `TaskStop` is only for a wedged one), ledger hygiene, and removal of the team's witness directory. Do not summarize it here: the summary that used to sit on this line carried only the first two, and the witness directory was never removed.\n- Present the report summary to the user in Korean.\n- Emit the lite-redirect footer (single line, every invocation):\n\n```\nℹ️ 보안 민감 PR, deep audit, 큰 PR 의 정밀 분담, 또는 미묘한 동시성 검증이 필요한 경우 \u002Fcc-cmds:review 권장.\n```\n\n---\n\n### Step 6: Review Discussion & Follow-up (Korean, lead-only)\n\nAfter presenting the review report, discuss with the user.\n\n#### Lead direct handling (no team needed)\n\n- Detailed explanation of specific findings\n- Code section re-check (using `grep` + `Read` directly)\n- Severity re-assessment when user provides new context (e.g., \"이 코드 경로는 내부 전용입니다\")\n- Explanation of why a specific finding was not included\n\n#### No follow-up reviewer spawning\n\nFollow-up reviewer spawning is **disabled in lite**. If the user requests comprehensive analysis of areas not covered, severity-dispute independent re-evaluation, multi-perspective architectural follow-up, or blind-spot deep-dive, do NOT spawn new reviewer tasks (nameless background sub-agents). Instead emit in Korean: *\"더 깊은 분석이 필요하면 `\u002Fcc-cmds:review` 를 사용해주세요.\"* and continue lead-only refinement of the existing report. Step 6 stays lead-only.\n\n#### Document update rules\n\nRefer to `${CLAUDE_SKILL_DIR}\u002F..\u002Freview\u002Freferences\u002F02-review-report-template.md` \"Document Update Rules (Step 6)\" section for the 개정 이력 \u002F 철회된 항목 update conventions.\n\nRepeat until user is satisfied.\n\n---\n\n## Constraints\n\n- **No code modifications.** Review only.\n- **Source files are read once per review stage.** Within one stage, a source file already read is not read again. **A turn yield is not an invalidation point** — nothing about the file changed because the model stopped and resumed. There are exactly three invalidation points: this session wrote to that path with `Edit`\u002F`Write`; a git operation moved `HEAD` or the working tree (`checkout`, `rebase`, `merge`, `stash`, `pull`); or a new stage was entered. **Four things this cache never covers, and each for its own reason** — the **run ledger**, whose contract deliberately produces an under-claim that a stale read inverts into an over-claim; **witness files**, where there is no invalidation event the lead can observe at all, so the cache has nothing to key on; the reviewer **`output_file`**, which a cached read reports as byte-stable and therefore as WEDGED when it is being written normally; and the **gate snapshot**, whose whole purpose is to be re-derived. Those four are re-read every time they are consulted.\n- **Inter-agent communication must be in English.** User-facing communication and saved documents in Korean.\n- **Sonnet pin**: every reviewer uses model `\"sonnet\"`. Haiku is forbidden; opus is out of scope (use `\u002Fcc-cmds:review` if opus depth is required). Both of `\u002Fcc-cmds:review-upgrade`'s reinforcement axes are out of scope here — opus upgrade violates the sonnet pin, and reviewer add\u002Fsplit (and the Scope Coordinator add) mutates the fixed 2-member roster (run `\u002Fcc-cmds:review-upgrade` against a base `\u002Fcc-cmds:review` run instead).\n- **Nameless background sub-agents**: reviewers ARE `Agent({ subagent_type: \"claude\", run_in_background: true })` sub-agents, one fresh dispatch per `(role, round\u002Fphase)` key and resumed by `agentId` (`SendMessage` to the agentId) only inside that key. The **cross-review through witnesses on disk is required** — round 2's dispatch reads the reviewer's own round-1 witness and its peer's by path; a dispatch that reads no peer witness is not a team.\n- **Deferred tool loading**: Before using AskUserQuestion, SendMessage, or TaskStop, you MUST first load them via ToolSearch (see Step 0; `Agent` is built-in — do not load it). AskUserQuestion MUST be loaded before Step 1.\n- **PR comment dedup required**: when existing PR comments\u002Freviews exist, always provide them as context to reviewers. Filter or flag findings that duplicate existing comments.\n- **Fix suggestion inclusion**: include fix direction when clear. Judgment-based — decide based on issue type and complexity.\n- **CI failure routing**: when CI has failed checks, mention them in Step 1c. Add \"CI failure priority check area: [failed check name and related files]\" to the relevant reviewer's context package — security-sensitive failures (auth, secrets) route to the security reviewer; logic\u002Fbuild\u002Ftest failures route to the code-quality\u002Flogic reviewer.\n\nTask: $ARGUMENTS\n",{"name":5,"usage":46,"options":47,"description":7,"when_to_use":68,"disable-model-invocation":69},"\u002Fcc-cmds:review-lite [\u003Ctarget>] [--base-sha \u003Csha>] [--declared-files \u003Ccsv>] [--expand \u003C분야>[,\u003C분야>]]",[48,52,58,63],{"kind":49,"name":50,"summary":51,"required":42},"positional","\u003Ctarget>","리뷰 대상 (PR 번호\u002FURL, 브랜치, 파일\u002F디렉토리, 또는 생략 시 현재 브랜치 자동 감지). PR 크기 무관 — 큰 PR 은 report 의 *리뷰 범위* 섹션에 미커버 영역 명시.",{"kind":53,"name":54,"default":55,"summary":56,"parse_note":57},"flag","--base-sha \u003Csha>","off (`gh pr view … baseRefName` 또는 기본 브랜치에서 base 를 스스로 유도)","diff 의 base 를 호출자가 지정. 넘겨받은 값은 `git merge-base --is-ancestor` 로 검증하며, 실패하면 기존 유도로 폴백하고 그 사실을 리포트 개요에 남긴다. lite 에서도 동일하다.","`--base-sha` 다음 토큰을 값으로 취한다. 값이 없으면 플래그를 무시하고 기존 유도를 쓴다.",{"kind":53,"name":59,"default":60,"summary":61,"parse_note":62},"--declared-files \u003Ccsv>","off (변경 파일 집합을 diff 에서만 유도)","이 변경이 건드리기로 선언된 파일 집합(쉼표 구분). diff 는 무엇이 바뀌었는지만 말하므로, 선언 밖 파일을 지목할 수 있게 한다.","`--declared-files` 다음 토큰을 값으로 취한다. 쉼표·공백을 포함할 수 있으므로 인용 부호로 감싸 넘긴다.",{"kind":53,"name":64,"default":65,"summary":66,"parse_note":67},"--expand \u003C분야>[,\u003C분야>]","off (기술 분야만 리뷰 — 추정한 요구 지적과 문서 표현 다듬기는 등급 없이 `## 범위 밖 관찰` 절에만 남는다)","기본에서 빠진 리뷰 분야를 연다. 값은 `요구`와 `문서표현` 둘이며, 고정 2인 가운데 코드 품질·로직 리뷰어가 맡는다. lite 는 문서를 받는 길이 없어 기획서는 늘 없음이다 — 기획서와 대조하려면 \u002Fcc-cmds:review 를 쓴다.","`--expand` 다음 토큰을 값으로 취해 쉼표로 나눈다. 두 번 주면 합집합이고, 모르는 값은 경고 한 줄과 함께 버리며, 남은 값이 없으면 플래그를 주지 않은 것과 같다. 이 토큰과 값은 대상 뒤 여분 토큰 판정 전에 인자열에서 제거된다.","빠른 코드 리뷰가 목적이고 다관점 심층 분석이 불필요할 때 (큰 PR coverage gap, 미묘한 race condition·authn bypass 검출률 약화 가능)",true,"master","f5e7f5e77d5e8603b1ec0e9247198315c7910461","plugins\u002Fcc-cmds\u002Fskills\u002Freview-lite",1,"https:\u002F\u002Fgithub.com\u002FNharu\u002Fcc-cmds","https:\u002F\u002Fgithub.com\u002FNharu","2026-11-13 01:36:53",{"source":8,"skillName":5,"commands":78,"prompt":88,"zipAvailable":69},[79,82,85],{"tool":80,"command":81},"npx","npx skills add Nharu\u002Fcc-cmds --skill review-lite",{"tool":83,"command":84},"bunx","bunx skills add Nharu\u002Fcc-cmds --skill review-lite",{"tool":86,"command":87},"pnpm","pnpm dlx skills add Nharu\u002Fcc-cmds --skill review-lite","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FNharu\u002Fcc-cmds\u002Fblob\u002Fmaster\u002Fplugins\u002Fcc-cmds\u002Fskills\u002Freview-lite\u002FSKILL.md",[],[91,102,113,120,135,147],{"skillNo":92,"name":93,"nameZh":6,"description":94,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":95,"categories":96,"keywords":97,"publishedAt":41},"01M6DNB8T41Y37D3M9JKHFT7HV","zeroargs","zero-argument command","https:\u002F\u002Fgithub.com\u002FNharu\u002Fcc-cmds\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Freadme-gen\u002Fsimple\u002Fzeroargs\u002FSKILL.md",[],[93,98,99,29,100,101],"when","argument","command","ZeRO",{"skillNo":103,"name":20,"nameZh":6,"description":104,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":105,"categories":106,"keywords":112,"publishedAt":41},"01M6DNB5TG3T9QMEF3HPKJPER0","에이전트 팀을 활용한 다관점 코드 리뷰","https:\u002F\u002Fgithub.com\u002FNharu\u002Fcc-cmds\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Freadme-gen\u002Fpre-yq-skills\u002Freview\u002FSKILL.md",[107],{"categoryNo":108,"categoryName":109,"taxonomyType":110,"taxonomyTypeDesc":111},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[20,39,22,21],{"skillNo":114,"name":115,"nameZh":6,"description":116,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":117,"categories":118,"keywords":119,"publishedAt":41},"01M6DNAYNZFJR1TATEM9PVHGH2","implement","설계 문서 기반 구현","https:\u002F\u002Fgithub.com\u002FNharu\u002Fcc-cmds\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Freadme-gen\u002Fpre-yq-skills\u002Fimplement\u002FSKILL.md",[],[115,22],{"skillNo":121,"name":122,"nameZh":6,"description":123,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":124,"categories":125,"keywords":134,"publishedAt":41},"01M6DNAVQF4KERY94V79NVWAZA","design","에이전트 팀을 활용한 기능 설계 토론 진행","https:\u002F\u002Fgithub.com\u002FNharu\u002Fcc-cmds\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Freadme-gen\u002Fpre-yq-skills\u002Fdesign\u002FSKILL.md",[126,129],{"categoryNo":127,"categoryName":128,"taxonomyType":110,"taxonomyTypeDesc":111},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":130,"categoryName":131,"taxonomyType":132,"taxonomyTypeDesc":133},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[122,22],{"skillNo":136,"name":137,"nameZh":6,"description":138,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":139,"categories":140,"keywords":143,"publishedAt":41},"01M6DNASB3J3JQMZD57YBDHZ1A","design-upgrade","팀원 모델 업그레이드 분석","https:\u002F\u002Fgithub.com\u002FNharu\u002Fcc-cmds\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Freadme-gen\u002Fpre-yq-skills\u002Fdesign-upgrade\u002FSKILL.md",[141,142],{"categoryNo":127,"categoryName":128,"taxonomyType":110,"taxonomyTypeDesc":111},{"categoryNo":130,"categoryName":131,"taxonomyType":132,"taxonomyTypeDesc":133},[144,122,145,22,146],"design upgrade","upgrade","haiku",{"skillNo":148,"name":149,"nameZh":6,"description":150,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":151,"categories":152,"keywords":155,"publishedAt":41},"01M6DNAA53K13C0REE8FDT3QHR","design-review","설계 문서 최종 리뷰","https:\u002F\u002Fgithub.com\u002FNharu\u002Fcc-cmds\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Freadme-gen\u002Fpre-yq-skills\u002Fdesign-review\u002FSKILL.md",[153,154],{"categoryNo":127,"categoryName":128,"taxonomyType":110,"taxonomyTypeDesc":111},{"categoryNo":130,"categoryName":131,"taxonomyType":132,"taxonomyTypeDesc":133},[20,122,156,22],"design review"]