[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DM2MDPXMHMHV80JXM0BYTX":3,"skill-same:01M6DM2MDPXMHMHV80JXM0BYTX":64},{"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":28,"linkOnly":29,"markdownContent":30,"markdownBody":31,"frontMatter":32,"refName":44,"commitSha":45,"skillDirectory":46,"forksCount":47,"repositoryHtmlUrl":48,"repositoryHomepageUrl":6,"ownerHtmlUrl":49,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":50,"install":51,"resources":63},"01M6DM2MDPXMHMHV80JXM0BYTX","review-upgrade",null,"리뷰어 구성 강화 분석 (모델·역할 축)","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-upgrade\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27],"review","upgrade","review upgrade","cc","expand","add","opus","true","second","2026-11-10 10:12:30",false,"---\nname: review-upgrade\ndescription: 리뷰어 구성 강화 분석 (모델·역할 축)\nwhen_to_use: 직전 `\u002Freview` Step 3 리뷰어 구성 제안에서 opus 승격이 유의미한 역할이 있는지, 누락된 리뷰 관점을 메울 신규 리뷰어 추가가 필요한지, 또는 과부하 리뷰어 분할이 필요한지 second-opinion으로 검토할 때\ndisable-model-invocation: true\nusage: \"\u002Fcc-cmds:review-upgrade [--expand \u003C분야>[,\u003C분야>]]\"\noptions:\n    - name: \"--expand \u003C분야>[,\u003C분야>]\"\n      kind: flag\n      default: \"off (입력의 `리뷰 분야` 줄이 연 분야만 이어받는다 — 줄이 없는 옛 입력은 기술(기본))\"\n      summary: \"입력에서 이어받은 리뷰 분야에 더할 분야. 값은 `요구`와 `문서표현` 둘이다. 열린 분야가 없으면 요구·문서표현 관점의 ADD 를 제안하지 않고, 열린 분야가 있으면 그 분야를 담당 범위로 하는 ADD 와 재투입 안내에 분야를 함께 싣는다.\"\n      parse_note: \"`--expand` 다음 토큰을 값으로 취해 쉼표로 나눈다. 두 번 주면 합집합이고, 모르는 값은 경고 한 줄과 함께 버리며, 남은 값이 없으면 플래그를 주지 않은 것과 같다.\"\nnotes: |\n    이 커맨드는 `--expand` 하나만 받으며, 직전 `\u002Freview` Step 3 리뷰어 구성 제안이 현재 대화 컨텍스트에 있어야 동작한다. opus 승격, 누락 리뷰 관점 추가, 과부하 리뷰어 분할은 강화가 유의미할 때만 제안하며, 그 외에는 유지 사유를 제시한다. 독립 실행 시 결과가 불정확할 수 있다.\n---\n\nAnalyze the reviewer team composition proposed in the preceding `\u002Freview` Step 3 output and produce a second opinion along **two axes** — model and role — recommending only *reinforcing* changes.\n\n**Read `${CLAUDE_SKILL_DIR}\u002F..\u002F_common\u002Fteam-upgrade-analysis.md`** for the axis-agnostic engine: the two-axis Scope, restraint principle, role-gap detection + HARD LIMIT, the per-OPERATION gates (restraint \u002F split \u002F remove \u002F merge), OPERATION output format and integrity rules, the per-existing-role invariant, the degraded-axis handling, and the Cross-axis synthesis. Resolve every `{PLACEHOLDER}` in that core against the `## Bindings` below. The `## Review fields`, `## Operations Layer`, role-axis mapping, SPLIT-axis degradation, Precondition, review-lite conflict guard, schema-drift sync-note, and 3-path Fallback that follow are this skill's injected layers.\n\n## Bindings\n\n| Placeholder | Value |\n| --- | --- |\n| `{SCOPE_LABEL}` | `담당 범위` |\n| `{FIELD_ORDER}` | `역할 \u002F 모델 \u002F 담당 범위` |\n| `{SOURCE_STEP}` | `\u002Freview` Step 3 |\n| `{ROSTER_SOT}` | `\u002Freview` Step 3 (Korean table: `역할 | 모델 | 담당 범위`) |\n| `{LABEL_RELATION}` | verbatim-equal (the OPERATION Korean labels equal the Step 3 table headers verbatim) |\n| `{ROLE_GAP_ANCHOR}` | A gap is a review perspective the Step 3 risk-indicator table missed — see Role-axis mapping below. |\n| `{RE_EXPLORATION_ANCHOR}` | the PR diff + changed-file set + risk-indicator table |\n| `{LITE_GUARD_TARGET}` | review-lite (sonnet pin) |\n| `{PRECONDITION}` | the preceding `\u002Freview` Step 3 reviewer composition is in context |\n| `{MODEL_AXIS_DEGRADES_UNDER}` | never (the saved report preserves each reviewer's model) |\n| `{SAVED_DOC_LOCATION}` | `docs\u002Freviews\u002F\u003Creport>.md` |\n| `{REFEED_TARGET}` | live \u002F Path-1 → `\u002Freview` Step 3 re-proposal (prospective), the note carrying `--expand \u003C값>` when a field is open; Path-2 → `\u002Freview` Step 6 team re-creation (retrospective) in the session that wrote the report, whose re-creation proposal carries that session's `리뷰 분야` line unchanged — and when an inherited field is one that session did not open, a new `\u002Freview` call with `--expand \u003C값>` instead, since Step 6 reads no arguments and cannot open it (see `## Review fields` below) |\n\nNote the column order differs from design-upgrade: Step 3's schema places **모델 before 담당 범위**. `역할` \u002F `모델` are shared tokens; `담당 범위` substitutes design's `탐색 범위`. Every OPERATION that emits a full role triple does so in `역할 \u002F 모델 \u002F 담당 범위` order for paste-back parity; the ones that omit scope (they name a role rather than describe one) are unaffected by the order rule. Which OPERATIONs fall on which side is the core's to say — read it there rather than trusting a list here.\n\n## Review fields\n\nA review looks at the technical field always and at the `요구` and `문서표현` fields only when they were opened (item 14's Field scope of `..\u002Freview\u002Freferences\u002F01-reviewer-context-package.md`). This skill inherits the open fields from its input rather than deciding them.\n\n- **Argument parsing.** `$ARGUMENTS` takes one flag, `--expand \u003C분야>[,\u003C분야>]`. It takes the next token as its value, split on commas; the known values are `요구` and `문서표현`, and given twice the value is 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 it. Any other token is discarded with one Korean warning.\n- **Inherited fields.** On the live path and Path 1, read the `리뷰 분야` line above the Step 3 `역할 | 모델 | 담당 범위` table; on Path 2, read the saved report overview's `- **리뷰 분야**:` line. An input with no such line predates the line and reads as `기술(기본)` — on Path 1, say so in one Korean line (`붙여 넣은 제안에 리뷰 분야 줄이 없어 기술(기본)으로 읽었습니다.`). The open fields of this analysis are the inherited fields together with this call's own `--expand`.\n- **Fields follow the seat.** When a Path-1 or live `REMOVE`, `MERGE` or `SPLIT-REPLACE` takes away a seat whose `담당 범위` carries an open field, that field moves to the `담당 범위` of the seat that takes the coverage over, so no open field is left without a seat.\n- **Re-feed carries the fields.** When a field is open, the 재투입 대상 note carries it. Path 1 and live: the `\u002Freview` Step 3 re-proposal, with `--expand \u003C값>` written on the note. Path 2: the Step 6 team re-creation of the `\u002Freview` session that wrote the report, whose re-creation proposal carries that session's `리뷰 분야` line unchanged; when a field inherited here is one that session did not open, Step 6 cannot open it, because it reads no arguments and a field opens only through the flag — point to a new `\u002Freview` call carrying `--expand \u003C값>` instead.\n\n## Operations Layer\n\nThis skill extends the core with one additional OPERATION class and one forbidden-set entry.\n\n### `ADD-Coordinator` (review-only OPERATION)\n\nThe `\u002Freview` Scope Coordinator (a >50-file PR meta\u002Forchestration role: Round 0 file-risk classification + per-round coverage audit + cross-cutting issue synthesis) is **not a domain perspective**, so it cannot pass the core's 3-condition restraint gate. It is therefore declared here, outside the core, as a reinforcement-direction OPERATION with its own gate.\n\n**2-condition structural gate (bypasses the restraint gate)** — BOTH required:\n\n1. The confirmed scope exceeds 50 files — measured against the **Step 1c-narrowed** scope (if the user chose \"특정 경로만\" \u002F \"리뷰 분할\", the effective scope may be ≤50, in which case this fails).\n2. No Step 3 role performs the coordinator function.\n\n**Invariant interaction**: ADD-Coordinator mints a brand-new role → exempt from the per-existing-role invariant, combines freely. Carryover guard: (a) the new coordinator name must not collide with any existing roster role, (b) gate condition (2) already enforces at most one coordinator per proposal.\n\n**Coordinator-targeting OPERATION rules**: `UPGRADE`-Coordinator is **valid** (an existing sonnet coordinator → opus; cross-cutting synthesis is exactly an opus strength) — this needs no separate op, the shared `UPGRADE` targets the coordinator role. ADD-Coordinator (when absent) and UPGRADE-Coordinator (when present) are mutually exclusive by precondition, so the per-existing-role invariant stays cleanly satisfied. `REMOVE`-Coordinator is **deliberately left valid**: a coordinator is the role most easily added for a scope that later narrows, so it is exactly where the ratchet has to be able to release — a removal still has to clear the core's remove gate, including the coverage-succession field naming who picks the orchestration up.\n\n**Path-2 suppress**: gate condition (1)'s Step 1c-narrowed effective scope is not preserved in the saved report (the report `## 개요` holds only the raw `변경 규모: 파일 X개`, not the post-1c effective scope). Therefore **ADD-Coordinator is not emitted on Path-2 (suppressed)** — same Path-2 quantitative-signal absence as the SPLIT degradation below. Falling back to raw `변경 규모` risks misjudging the effective scope, so it is not adopted (honesty first; state the caveat).\n\n### Forbidden-set append\n\n- `SPLIT-REPLACE`-Coordinator is **forbidden** (splitting a unified cross-cutting synthesis role constructively violates clean cleavage).\n- `MERGE`-Coordinator is **forbidden** — folding the coordinator into a domain reviewer destroys the same unified cross-cutting synthesis that the split ban protects, only from the other side. The split ban alone stopped this while the core had no merge; it does not any more, so the ban is written out rather than inferred.\n\nBoth entries append to the core's forbidden-set; read that set in the core rather than restating it here.\n\n## Role-axis mapping (review)\n\nThe core's role axis here means **uncovered review perspective**, drawn from: security \u002F performance \u002F code-quality \u002F logic \u002F error-handling \u002F type-safety \u002F testing \u002F api-contract \u002F concurrency \u002F data-integrity \u002F design-conformance (the last only when a design document was supplied to the review — see the review context package's conditional 17th item). **There is no `ADD` whose `담당 범위` is a field that is not open** (`## Review fields` below): with no field open, no `ADD` proposes a `요구` or `문서표현` perspective, so a second opinion does not widen the default technical scope back.\n\n**Risk-indicator reconciliation rule (the heart of the restraint)**: Step 3's risk-indicator → reviewer mapping (auth→security, DB→perf\u002FDB, public-API→API-contract, external→security+integration, async→concurrency) is Step 3's own coverage contract. An `ADD` fires only when ALL hold:\n\n- (a) the diff shows a signal for that perspective,\n- (b) none of the Step 3 proposal's `담당 범위` owns that perspective,\n- (c) it is not already routed by a *fired* risk-indicator mapping,\n- (d) it is not already absorbed into an existing reviewer's role-specific checklist.\n\nBecause those checklists are broad, the restraint gate's distinct-expertise bar (condition 3) is high and most candidates drop at (c)\u002F(d). The canonical valid `ADD`: Step 3 misclassified the PR type so an indicator that *should* have fired did not, leaving a perspective (e.g. DB migration → data-integrity) genuinely uncovered.\n\n**An open field is a perspective too, under the same gate.** An `ADD` whose `담당 범위` is an open field (`## Review fields` below) is emitted with the perspective its tag maps to: `요구` → logic, or design-conformance when a spec document was supplied; `문서표현` → code-quality.\n\n**SPLIT-over-`담당 범위`**: fires when a single `담당 범위` spans two separable perspectives and this PR's volume would starve one side. The overload evidence here is **quantitative** (file count + diff size of the parent perspective's slice, from the in-context per-file statistics) — this is where the core HARD LIMIT item 2 (\"a large hit is SPLIT input\") applies. PARTITION: `childA.담당 범위 ⊎ childB.담당 범위 = parent.담당 범위 (no overlap, no loss)`. The split gate's step-4 cross-axis reconciliation chooses between SPLIT (two sonnets, parallel focus, +coordination, +1 headcount) and UPGRADE (promote the parent to opus, single synthesis preserved).\n\n## SPLIT-axis degradation (review Path-2)\n\nThe SPLIT overload evidence (quantitative per-file statistics) is in context only on live \u002F Path-1. **On Path-2 (saved-report reverse-engineering), per-file diff statistics are absent → quantitative SPLIT gating degrades to N\u002FA (suppressed)** — the mirror image of design's model-axis N\u002FA. Concretely, this is the core's \"consuming skill MAY declare the SPLIT comparison term N\u002FA\" hook: on Path-2 the core split gate's step 4 and the Cross-axis synthesis treat the **SPLIT comparison term** as N\u002FA and fall through to the UPGRADE-parent alone (exactly symmetric to proceeding on the role axis alone when the model term is N\u002FA). So on Path-2 only `ADD` (perspective gap) + `UPGRADE` (model) fire; `SPLIT-REPLACE` and `ADD-Coordinator` are not emitted, and the caveat is stated. **`REMOVE` and `MERGE` degrade the same way and for the same reason**: the remove gate's \"this domain is thin for *this* unit of work\" and the merge gate's inverse-cleavage condition both rest on the per-file quantitative signal that Path-2 does not carry. The saved report does preserve the roster, so their lookup keys exist — but a lookup key is not evidence, and proposing a seat's deletion from a roster listing alone is exactly the cost-shaped reasoning the core bans. Suppressed, with the caveat stated. (Model-axis N\u002FA is the core binding `{MODEL_AXIS_DEGRADES_UNDER}` — `never` for review; SPLIT-axis N\u002FA is this injected instruction — both availability degradations reach the same core gate\u002Fsynthesis sites through their own channel.)\n\n## Precondition\n\nThis skill requires the preceding `\u002Freview` Step 3 reviewer composition to be in context. It is a `disable-model-invocation: true` second-opinion skill and does NOT auto-chain `\u002Freview`.\n\n**review-lite conflict guard**: if the in-context proposal looks like a `\u002Freview-lite` composition (fixed 2×sonnet — a dedicated security reviewer + a code-quality\u002Flogic reviewer; opus excluded; no Scope Coordinator; a single Y\u002FN gate), both axes conflict with the lite contract — UPGRADE→opus violates the sonnet pin, and every role-axis OPERATION mutates a roster the lite skill fixes by design, shrinking it no less than growing it (ADD-Coordinator also contradicts \"no Scope Coordinator\"). Emit a Korean caveat and proceed only on explicit user confirmation; otherwise recommend `\u002Fcc-cmds:review`. (Consistent with the cross-reference in `review-lite\u002FSKILL.md`.)\n\n**Schema-drift sync note**: the source of truth is `\u002Freview` Step 3's reviewer-composition field set (`역할 | 모델 | 담당 범위` — Korean table). If Step 3 changes that field set, manually sync this skill's OPERATION Korean labels and model aliases. Because this skill's labels are **verbatim-equal** to the Step 3 table headers (design-upgrade's are a conceptual translation of English prose), the drift coupling is tighter — a header rename in Step 3 breaks the verbatim match directly. Do NOT touch `review\u002FSKILL.md`. The residual risk of a missed sync is accepted without a lint (single-direction, one (consumer, source-step) pair).\n\n## Fallback\n\nWhen the precondition is not met, follow a 3-path fallback. The re-feed target is path-conditional — emit a per-path \"재투입 대상\" note so the user does not paste back into the wrong slot.\n\n- **Path 1 — session roster paste** (full two-axis): the user pastes the Step 3 `역할 | 모델 | 담당 범위` table together with the `리뷰 분야` and `기획서` lines above it → full two-axis analysis. The open fields are read from that `리뷰 분야` line as `## Review fields` says, `기술(기본)` with the one-line notice when the paste has none, joined with this call's `--expand`. This path uniquely still holds Step 3's `위험 신호` directly, the freshest reconciliation input. **재투입 대상**: `\u002Freview` Step 3 re-proposal (prospective); when a field is open, write `--expand \u003C값>` on the note.\n\n- **Path 2 — reverse-engineer from a saved review report** (model + perspective-ADD axes complete; every quantitatively-gated OPERATION degraded): unlike design, `docs\u002Freviews\u002F\u003Creport>.md` `## 개요`'s `리뷰 팀 구성` preserves all three axes as `역할 ([모델]): [담당 범위]` → the **model axis (UPGRADE) is fully restored**, and the perspective-gap `ADD` is restorable subject to the caveats below. But **the per-file quantitative signal is absent, so quantitative SPLIT and ADD-Coordinator gating degrade to N\u002FA \u002F suppressed** (see SPLIT-axis degradation above; symmetric to design Path-2's model-axis N\u002FA). Caveats to state:\n    - (i) This is an AS-RUN roster (generated from the approved Step 3, possibly modified at Step 6 — retrospective), so it is followup-team information, not a live proposal.\n    - (ii) Step 3's `위험 신호` is not preserved → reconcile `ADD` from the report's `## 미검토 영역` (direct ADD input, but a **conditional section — may be omitted when not applicable**) + finding `[category]` tags + bounded diff re-read. When `## 미검토 영역` is absent, re-derive ADD from the secondary inputs (`[category]` tags + bounded re-read) alone; ADD input confidence is lower in that case, so \"fully restored\" holds **only when `## 미검토 영역` exists**.\n    - (iii) On multiple report versions, use the highest version.\n    - (iv) **Every OPERATION resting on the per-file quantitative signal is suppressed** — quantitative SPLIT, ADD-Coordinator, and both reducing operations (see SPLIT-axis degradation above). Path-2 output is limited to UPGRADE + ADD (perspective gap).\n    - (v) The open fields are read from the overview's `- **리뷰 분야**:` line, `기술(기본)` when the report has none, joined with this call's `--expand` (`## Review fields`).\n  - **재투입 대상**: `\u002Freview` Step 6 team re-creation (retrospective). Step 6 requires augmented fields (Re-creation reason \u002F Previous review coverage \u002F Additional analysis scope) + an approval cycle, not the Step 3 form, so there is no slot a `역할 | 모델 | 담당 범위` OPERATION drops into verbatim. Map the Path-2 output instead: the OPERATION roster delta that Path-2 can actually produce (per caveat (iv) above) → Step 6 **Additional analysis scope** (plus the re-created roster); each ADD's rationale → Step 6 **Previous review coverage** (covered vs uncovered, citing the report's `## 미검토 영역`); **Re-creation reason** is supplied separately by the user \u002F next-turn model (the emit does not force it). This keeps \"paste back without ambiguity\" aligned with Step 6's input schema. When a field is open, the note says that the re-creation proposal carries the session's `리뷰 분야` line unchanged, and that a field inherited here which the session did not open needs a new `\u002Freview` call carrying `--expand \u003C값>`, since Step 6 cannot open it.\n\n- **Path 3 — start a new `\u002Freview`**: when neither is available, two-axis analysis is impossible — emit a Korean notice (e.g., *\"분석할 리뷰어 구성이 없습니다. 먼저 `\u002Fcc-cmds:review`를 실행해 Step 3 리뷰어 구성을 받은 뒤 다시 호출하세요.\"*) and stop.\n\n## OPERATION worked example\n\nEmit full-triple OPERATIONs in `역할 \u002F 모델 \u002F 담당 범위` order (paste-back parity with Step 3):\n\n```\n[ADD]\n- 역할 \u002F 모델 \u002F 담당 범위: 데이터 정합성 리뷰어 \u002F sonnet \u002F DB 마이그레이션·스키마 변경·트랜잭션 경계·정합성 제약\n- 근거: PR이 마이그레이션을 포함하나 Step 3가 PR 타입을 일반 기능으로 분류해 data-integrity indicator 미발화 → 어느 리뷰어의 담당 범위도 미커버\n- 기대 효과: 마이그레이션 정합성 회귀를 전담 관점으로 포착\n\n[UPGRADE]\n- 역할: 보안 전담 리뷰어\n- 현재 모델 → 권장 모델: sonnet → opus\n- 변경 사유: 멀티 서비스 인증 위임 경로의 크로스 도메인 추론이 opus 강점에 정합\n- 기대 효과: 미묘한 authn bypass 검출률 향상\n\n[REMOVE]\n- 역할: 동시성 리뷰어\n- 커버리지 승계: 로직 리뷰어 (동시성 관점을 담당 범위에 포함)\n- 근거: Step 3가 async 지표로 발화시켰으나 좁혀진 범위의 async 변경은 기존 헬퍼 호출부 2줄뿐이라 전담 관점이 낼 판단이 없음\n- 기대 효과: 판단이 없는 좌석을 비워 라운드2 교차검증의 신호 대 잡음비 개선\n\n역할\u002F모델 변경 불필요 (해당 시): 나머지 리뷰어는 현재 구성 유지 — 근거: ...\n```\n","Analyze the reviewer team composition proposed in the preceding `\u002Freview` Step 3 output and produce a second opinion along **two axes** — model and role — recommending only *reinforcing* changes.\n\n**Read `${CLAUDE_SKILL_DIR}\u002F..\u002F_common\u002Fteam-upgrade-analysis.md`** for the axis-agnostic engine: the two-axis Scope, restraint principle, role-gap detection + HARD LIMIT, the per-OPERATION gates (restraint \u002F split \u002F remove \u002F merge), OPERATION output format and integrity rules, the per-existing-role invariant, the degraded-axis handling, and the Cross-axis synthesis. Resolve every `{PLACEHOLDER}` in that core against the `## Bindings` below. The `## Review fields`, `## Operations Layer`, role-axis mapping, SPLIT-axis degradation, Precondition, review-lite conflict guard, schema-drift sync-note, and 3-path Fallback that follow are this skill's injected layers.\n\n## Bindings\n\n| Placeholder | Value |\n| --- | --- |\n| `{SCOPE_LABEL}` | `담당 범위` |\n| `{FIELD_ORDER}` | `역할 \u002F 모델 \u002F 담당 범위` |\n| `{SOURCE_STEP}` | `\u002Freview` Step 3 |\n| `{ROSTER_SOT}` | `\u002Freview` Step 3 (Korean table: `역할 | 모델 | 담당 범위`) |\n| `{LABEL_RELATION}` | verbatim-equal (the OPERATION Korean labels equal the Step 3 table headers verbatim) |\n| `{ROLE_GAP_ANCHOR}` | A gap is a review perspective the Step 3 risk-indicator table missed — see Role-axis mapping below. |\n| `{RE_EXPLORATION_ANCHOR}` | the PR diff + changed-file set + risk-indicator table |\n| `{LITE_GUARD_TARGET}` | review-lite (sonnet pin) |\n| `{PRECONDITION}` | the preceding `\u002Freview` Step 3 reviewer composition is in context |\n| `{MODEL_AXIS_DEGRADES_UNDER}` | never (the saved report preserves each reviewer's model) |\n| `{SAVED_DOC_LOCATION}` | `docs\u002Freviews\u002F\u003Creport>.md` |\n| `{REFEED_TARGET}` | live \u002F Path-1 → `\u002Freview` Step 3 re-proposal (prospective), the note carrying `--expand \u003C값>` when a field is open; Path-2 → `\u002Freview` Step 6 team re-creation (retrospective) in the session that wrote the report, whose re-creation proposal carries that session's `리뷰 분야` line unchanged — and when an inherited field is one that session did not open, a new `\u002Freview` call with `--expand \u003C값>` instead, since Step 6 reads no arguments and cannot open it (see `## Review fields` below) |\n\nNote the column order differs from design-upgrade: Step 3's schema places **모델 before 담당 범위**. `역할` \u002F `모델` are shared tokens; `담당 범위` substitutes design's `탐색 범위`. Every OPERATION that emits a full role triple does so in `역할 \u002F 모델 \u002F 담당 범위` order for paste-back parity; the ones that omit scope (they name a role rather than describe one) are unaffected by the order rule. Which OPERATIONs fall on which side is the core's to say — read it there rather than trusting a list here.\n\n## Review fields\n\nA review looks at the technical field always and at the `요구` and `문서표현` fields only when they were opened (item 14's Field scope of `..\u002Freview\u002Freferences\u002F01-reviewer-context-package.md`). This skill inherits the open fields from its input rather than deciding them.\n\n- **Argument parsing.** `$ARGUMENTS` takes one flag, `--expand \u003C분야>[,\u003C분야>]`. It takes the next token as its value, split on commas; the known values are `요구` and `문서표현`, and given twice the value is 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 it. Any other token is discarded with one Korean warning.\n- **Inherited fields.** On the live path and Path 1, read the `리뷰 분야` line above the Step 3 `역할 | 모델 | 담당 범위` table; on Path 2, read the saved report overview's `- **리뷰 분야**:` line. An input with no such line predates the line and reads as `기술(기본)` — on Path 1, say so in one Korean line (`붙여 넣은 제안에 리뷰 분야 줄이 없어 기술(기본)으로 읽었습니다.`). The open fields of this analysis are the inherited fields together with this call's own `--expand`.\n- **Fields follow the seat.** When a Path-1 or live `REMOVE`, `MERGE` or `SPLIT-REPLACE` takes away a seat whose `담당 범위` carries an open field, that field moves to the `담당 범위` of the seat that takes the coverage over, so no open field is left without a seat.\n- **Re-feed carries the fields.** When a field is open, the 재투입 대상 note carries it. Path 1 and live: the `\u002Freview` Step 3 re-proposal, with `--expand \u003C값>` written on the note. Path 2: the Step 6 team re-creation of the `\u002Freview` session that wrote the report, whose re-creation proposal carries that session's `리뷰 분야` line unchanged; when a field inherited here is one that session did not open, Step 6 cannot open it, because it reads no arguments and a field opens only through the flag — point to a new `\u002Freview` call carrying `--expand \u003C값>` instead.\n\n## Operations Layer\n\nThis skill extends the core with one additional OPERATION class and one forbidden-set entry.\n\n### `ADD-Coordinator` (review-only OPERATION)\n\nThe `\u002Freview` Scope Coordinator (a >50-file PR meta\u002Forchestration role: Round 0 file-risk classification + per-round coverage audit + cross-cutting issue synthesis) is **not a domain perspective**, so it cannot pass the core's 3-condition restraint gate. It is therefore declared here, outside the core, as a reinforcement-direction OPERATION with its own gate.\n\n**2-condition structural gate (bypasses the restraint gate)** — BOTH required:\n\n1. The confirmed scope exceeds 50 files — measured against the **Step 1c-narrowed** scope (if the user chose \"특정 경로만\" \u002F \"리뷰 분할\", the effective scope may be ≤50, in which case this fails).\n2. No Step 3 role performs the coordinator function.\n\n**Invariant interaction**: ADD-Coordinator mints a brand-new role → exempt from the per-existing-role invariant, combines freely. Carryover guard: (a) the new coordinator name must not collide with any existing roster role, (b) gate condition (2) already enforces at most one coordinator per proposal.\n\n**Coordinator-targeting OPERATION rules**: `UPGRADE`-Coordinator is **valid** (an existing sonnet coordinator → opus; cross-cutting synthesis is exactly an opus strength) — this needs no separate op, the shared `UPGRADE` targets the coordinator role. ADD-Coordinator (when absent) and UPGRADE-Coordinator (when present) are mutually exclusive by precondition, so the per-existing-role invariant stays cleanly satisfied. `REMOVE`-Coordinator is **deliberately left valid**: a coordinator is the role most easily added for a scope that later narrows, so it is exactly where the ratchet has to be able to release — a removal still has to clear the core's remove gate, including the coverage-succession field naming who picks the orchestration up.\n\n**Path-2 suppress**: gate condition (1)'s Step 1c-narrowed effective scope is not preserved in the saved report (the report `## 개요` holds only the raw `변경 규모: 파일 X개`, not the post-1c effective scope). Therefore **ADD-Coordinator is not emitted on Path-2 (suppressed)** — same Path-2 quantitative-signal absence as the SPLIT degradation below. Falling back to raw `변경 규모` risks misjudging the effective scope, so it is not adopted (honesty first; state the caveat).\n\n### Forbidden-set append\n\n- `SPLIT-REPLACE`-Coordinator is **forbidden** (splitting a unified cross-cutting synthesis role constructively violates clean cleavage).\n- `MERGE`-Coordinator is **forbidden** — folding the coordinator into a domain reviewer destroys the same unified cross-cutting synthesis that the split ban protects, only from the other side. The split ban alone stopped this while the core had no merge; it does not any more, so the ban is written out rather than inferred.\n\nBoth entries append to the core's forbidden-set; read that set in the core rather than restating it here.\n\n## Role-axis mapping (review)\n\nThe core's role axis here means **uncovered review perspective**, drawn from: security \u002F performance \u002F code-quality \u002F logic \u002F error-handling \u002F type-safety \u002F testing \u002F api-contract \u002F concurrency \u002F data-integrity \u002F design-conformance (the last only when a design document was supplied to the review — see the review context package's conditional 17th item). **There is no `ADD` whose `담당 범위` is a field that is not open** (`## Review fields` below): with no field open, no `ADD` proposes a `요구` or `문서표현` perspective, so a second opinion does not widen the default technical scope back.\n\n**Risk-indicator reconciliation rule (the heart of the restraint)**: Step 3's risk-indicator → reviewer mapping (auth→security, DB→perf\u002FDB, public-API→API-contract, external→security+integration, async→concurrency) is Step 3's own coverage contract. An `ADD` fires only when ALL hold:\n\n- (a) the diff shows a signal for that perspective,\n- (b) none of the Step 3 proposal's `담당 범위` owns that perspective,\n- (c) it is not already routed by a *fired* risk-indicator mapping,\n- (d) it is not already absorbed into an existing reviewer's role-specific checklist.\n\nBecause those checklists are broad, the restraint gate's distinct-expertise bar (condition 3) is high and most candidates drop at (c)\u002F(d). The canonical valid `ADD`: Step 3 misclassified the PR type so an indicator that *should* have fired did not, leaving a perspective (e.g. DB migration → data-integrity) genuinely uncovered.\n\n**An open field is a perspective too, under the same gate.** An `ADD` whose `담당 범위` is an open field (`## Review fields` below) is emitted with the perspective its tag maps to: `요구` → logic, or design-conformance when a spec document was supplied; `문서표현` → code-quality.\n\n**SPLIT-over-`담당 범위`**: fires when a single `담당 범위` spans two separable perspectives and this PR's volume would starve one side. The overload evidence here is **quantitative** (file count + diff size of the parent perspective's slice, from the in-context per-file statistics) — this is where the core HARD LIMIT item 2 (\"a large hit is SPLIT input\") applies. PARTITION: `childA.담당 범위 ⊎ childB.담당 범위 = parent.담당 범위 (no overlap, no loss)`. The split gate's step-4 cross-axis reconciliation chooses between SPLIT (two sonnets, parallel focus, +coordination, +1 headcount) and UPGRADE (promote the parent to opus, single synthesis preserved).\n\n## SPLIT-axis degradation (review Path-2)\n\nThe SPLIT overload evidence (quantitative per-file statistics) is in context only on live \u002F Path-1. **On Path-2 (saved-report reverse-engineering), per-file diff statistics are absent → quantitative SPLIT gating degrades to N\u002FA (suppressed)** — the mirror image of design's model-axis N\u002FA. Concretely, this is the core's \"consuming skill MAY declare the SPLIT comparison term N\u002FA\" hook: on Path-2 the core split gate's step 4 and the Cross-axis synthesis treat the **SPLIT comparison term** as N\u002FA and fall through to the UPGRADE-parent alone (exactly symmetric to proceeding on the role axis alone when the model term is N\u002FA). So on Path-2 only `ADD` (perspective gap) + `UPGRADE` (model) fire; `SPLIT-REPLACE` and `ADD-Coordinator` are not emitted, and the caveat is stated. **`REMOVE` and `MERGE` degrade the same way and for the same reason**: the remove gate's \"this domain is thin for *this* unit of work\" and the merge gate's inverse-cleavage condition both rest on the per-file quantitative signal that Path-2 does not carry. The saved report does preserve the roster, so their lookup keys exist — but a lookup key is not evidence, and proposing a seat's deletion from a roster listing alone is exactly the cost-shaped reasoning the core bans. Suppressed, with the caveat stated. (Model-axis N\u002FA is the core binding `{MODEL_AXIS_DEGRADES_UNDER}` — `never` for review; SPLIT-axis N\u002FA is this injected instruction — both availability degradations reach the same core gate\u002Fsynthesis sites through their own channel.)\n\n## Precondition\n\nThis skill requires the preceding `\u002Freview` Step 3 reviewer composition to be in context. It is a `disable-model-invocation: true` second-opinion skill and does NOT auto-chain `\u002Freview`.\n\n**review-lite conflict guard**: if the in-context proposal looks like a `\u002Freview-lite` composition (fixed 2×sonnet — a dedicated security reviewer + a code-quality\u002Flogic reviewer; opus excluded; no Scope Coordinator; a single Y\u002FN gate), both axes conflict with the lite contract — UPGRADE→opus violates the sonnet pin, and every role-axis OPERATION mutates a roster the lite skill fixes by design, shrinking it no less than growing it (ADD-Coordinator also contradicts \"no Scope Coordinator\"). Emit a Korean caveat and proceed only on explicit user confirmation; otherwise recommend `\u002Fcc-cmds:review`. (Consistent with the cross-reference in `review-lite\u002FSKILL.md`.)\n\n**Schema-drift sync note**: the source of truth is `\u002Freview` Step 3's reviewer-composition field set (`역할 | 모델 | 담당 범위` — Korean table). If Step 3 changes that field set, manually sync this skill's OPERATION Korean labels and model aliases. Because this skill's labels are **verbatim-equal** to the Step 3 table headers (design-upgrade's are a conceptual translation of English prose), the drift coupling is tighter — a header rename in Step 3 breaks the verbatim match directly. Do NOT touch `review\u002FSKILL.md`. The residual risk of a missed sync is accepted without a lint (single-direction, one (consumer, source-step) pair).\n\n## Fallback\n\nWhen the precondition is not met, follow a 3-path fallback. The re-feed target is path-conditional — emit a per-path \"재투입 대상\" note so the user does not paste back into the wrong slot.\n\n- **Path 1 — session roster paste** (full two-axis): the user pastes the Step 3 `역할 | 모델 | 담당 범위` table together with the `리뷰 분야` and `기획서` lines above it → full two-axis analysis. The open fields are read from that `리뷰 분야` line as `## Review fields` says, `기술(기본)` with the one-line notice when the paste has none, joined with this call's `--expand`. This path uniquely still holds Step 3's `위험 신호` directly, the freshest reconciliation input. **재투입 대상**: `\u002Freview` Step 3 re-proposal (prospective); when a field is open, write `--expand \u003C값>` on the note.\n\n- **Path 2 — reverse-engineer from a saved review report** (model + perspective-ADD axes complete; every quantitatively-gated OPERATION degraded): unlike design, `docs\u002Freviews\u002F\u003Creport>.md` `## 개요`'s `리뷰 팀 구성` preserves all three axes as `역할 ([모델]): [담당 범위]` → the **model axis (UPGRADE) is fully restored**, and the perspective-gap `ADD` is restorable subject to the caveats below. But **the per-file quantitative signal is absent, so quantitative SPLIT and ADD-Coordinator gating degrade to N\u002FA \u002F suppressed** (see SPLIT-axis degradation above; symmetric to design Path-2's model-axis N\u002FA). Caveats to state:\n    - (i) This is an AS-RUN roster (generated from the approved Step 3, possibly modified at Step 6 — retrospective), so it is followup-team information, not a live proposal.\n    - (ii) Step 3's `위험 신호` is not preserved → reconcile `ADD` from the report's `## 미검토 영역` (direct ADD input, but a **conditional section — may be omitted when not applicable**) + finding `[category]` tags + bounded diff re-read. When `## 미검토 영역` is absent, re-derive ADD from the secondary inputs (`[category]` tags + bounded re-read) alone; ADD input confidence is lower in that case, so \"fully restored\" holds **only when `## 미검토 영역` exists**.\n    - (iii) On multiple report versions, use the highest version.\n    - (iv) **Every OPERATION resting on the per-file quantitative signal is suppressed** — quantitative SPLIT, ADD-Coordinator, and both reducing operations (see SPLIT-axis degradation above). Path-2 output is limited to UPGRADE + ADD (perspective gap).\n    - (v) The open fields are read from the overview's `- **리뷰 분야**:` line, `기술(기본)` when the report has none, joined with this call's `--expand` (`## Review fields`).\n  - **재투입 대상**: `\u002Freview` Step 6 team re-creation (retrospective). Step 6 requires augmented fields (Re-creation reason \u002F Previous review coverage \u002F Additional analysis scope) + an approval cycle, not the Step 3 form, so there is no slot a `역할 | 모델 | 담당 범위` OPERATION drops into verbatim. Map the Path-2 output instead: the OPERATION roster delta that Path-2 can actually produce (per caveat (iv) above) → Step 6 **Additional analysis scope** (plus the re-created roster); each ADD's rationale → Step 6 **Previous review coverage** (covered vs uncovered, citing the report's `## 미검토 영역`); **Re-creation reason** is supplied separately by the user \u002F next-turn model (the emit does not force it). This keeps \"paste back without ambiguity\" aligned with Step 6's input schema. When a field is open, the note says that the re-creation proposal carries the session's `리뷰 분야` line unchanged, and that a field inherited here which the session did not open needs a new `\u002Freview` call carrying `--expand \u003C값>`, since Step 6 cannot open it.\n\n- **Path 3 — start a new `\u002Freview`**: when neither is available, two-axis analysis is impossible — emit a Korean notice (e.g., *\"분석할 리뷰어 구성이 없습니다. 먼저 `\u002Fcc-cmds:review`를 실행해 Step 3 리뷰어 구성을 받은 뒤 다시 호출하세요.\"*) and stop.\n\n## OPERATION worked example\n\nEmit full-triple OPERATIONs in `역할 \u002F 모델 \u002F 담당 범위` order (paste-back parity with Step 3):\n\n```\n[ADD]\n- 역할 \u002F 모델 \u002F 담당 범위: 데이터 정합성 리뷰어 \u002F sonnet \u002F DB 마이그레이션·스키마 변경·트랜잭션 경계·정합성 제약\n- 근거: PR이 마이그레이션을 포함하나 Step 3가 PR 타입을 일반 기능으로 분류해 data-integrity indicator 미발화 → 어느 리뷰어의 담당 범위도 미커버\n- 기대 효과: 마이그레이션 정합성 회귀를 전담 관점으로 포착\n\n[UPGRADE]\n- 역할: 보안 전담 리뷰어\n- 현재 모델 → 권장 모델: sonnet → opus\n- 변경 사유: 멀티 서비스 인증 위임 경로의 크로스 도메인 추론이 opus 강점에 정합\n- 기대 효과: 미묘한 authn bypass 검출률 향상\n\n[REMOVE]\n- 역할: 동시성 리뷰어\n- 커버리지 승계: 로직 리뷰어 (동시성 관점을 담당 범위에 포함)\n- 근거: Step 3가 async 지표로 발화시켰으나 좁혀진 범위의 async 변경은 기존 헬퍼 호출부 2줄뿐이라 전담 관점이 낼 판단이 없음\n- 기대 효과: 판단이 없는 좌석을 비워 라운드2 교차검증의 신호 대 잡음비 개선\n\n역할\u002F모델 변경 불필요 (해당 시): 나머지 리뷰어는 현재 구성 유지 — 근거: ...\n```\n",{"name":5,"notes":33,"usage":34,"options":35,"description":7,"when_to_use":42,"disable-model-invocation":43},"이 커맨드는 `--expand` 하나만 받으며, 직전 `\u002Freview` Step 3 리뷰어 구성 제안이 현재 대화 컨텍스트에 있어야 동작한다. opus 승격, 누락 리뷰 관점 추가, 과부하 리뷰어 분할은 강화가 유의미할 때만 제안하며, 그 외에는 유지 사유를 제시한다. 독립 실행 시 결과가 불정확할 수 있다.","\u002Fcc-cmds:review-upgrade [--expand \u003C분야>[,\u003C분야>]]",[36],{"kind":37,"name":38,"default":39,"summary":40,"parse_note":41},"flag","--expand \u003C분야>[,\u003C분야>]","off (입력의 `리뷰 분야` 줄이 연 분야만 이어받는다 — 줄이 없는 옛 입력은 기술(기본))","입력에서 이어받은 리뷰 분야에 더할 분야. 값은 `요구`와 `문서표현` 둘이다. 열린 분야가 없으면 요구·문서표현 관점의 ADD 를 제안하지 않고, 열린 분야가 있으면 그 분야를 담당 범위로 하는 ADD 와 재투입 안내에 분야를 함께 싣는다.","`--expand` 다음 토큰을 값으로 취해 쉼표로 나눈다. 두 번 주면 합집합이고, 모르는 값은 경고 한 줄과 함께 버리며, 남은 값이 없으면 플래그를 주지 않은 것과 같다.","직전 `\u002Freview` Step 3 리뷰어 구성 제안에서 opus 승격이 유의미한 역할이 있는지, 누락된 리뷰 관점을 메울 신규 리뷰어 추가가 필요한지, 또는 과부하 리뷰어 분할이 필요한지 second-opinion으로 검토할 때",true,"master","f5e7f5e77d5e8603b1ec0e9247198315c7910461","plugins\u002Fcc-cmds\u002Fskills\u002Freview-upgrade",1,"https:\u002F\u002Fgithub.com\u002FNharu\u002Fcc-cmds","https:\u002F\u002Fgithub.com\u002FNharu","2026-11-11 07:18:55",{"source":8,"skillName":5,"commands":52,"prompt":62,"zipAvailable":43},[53,56,59],{"tool":54,"command":55},"npx","npx skills add Nharu\u002Fcc-cmds --skill review-upgrade",{"tool":57,"command":58},"bunx","bunx skills add Nharu\u002Fcc-cmds --skill review-upgrade",{"tool":60,"command":61},"pnpm","pnpm dlx skills add Nharu\u002Fcc-cmds --skill review-upgrade","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FNharu\u002Fcc-cmds\u002Fblob\u002Fmaster\u002Fplugins\u002Fcc-cmds\u002Fskills\u002Freview-upgrade\u002FSKILL.md",[],[65,76,89,96,111,122],{"skillNo":66,"name":67,"nameZh":6,"description":68,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":69,"categories":70,"keywords":71,"publishedAt":28},"01M6DNB8T41Y37D3M9JKHFT7HV","zeroargs","zero-argument command","https:\u002F\u002Fgithub.com\u002FNharu\u002Fcc-cmds\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Freadme-gen\u002Fsimple\u002Fzeroargs\u002FSKILL.md",[],[67,72,73,22,74,75],"when","argument","command","ZeRO",{"skillNo":77,"name":19,"nameZh":6,"description":78,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":79,"categories":80,"keywords":86,"publishedAt":28},"01M6DNB5TG3T9QMEF3HPKJPER0","에이전트 팀을 활용한 다관점 코드 리뷰","https:\u002F\u002Fgithub.com\u002FNharu\u002Fcc-cmds\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Freadme-gen\u002Fpre-yq-skills\u002Freview\u002FSKILL.md",[81],{"categoryNo":82,"categoryName":83,"taxonomyType":84,"taxonomyTypeDesc":85},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[19,87,26,88],"pr","diff",{"skillNo":90,"name":91,"nameZh":6,"description":92,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":93,"categories":94,"keywords":95,"publishedAt":28},"01M6DNAYNZFJR1TATEM9PVHGH2","implement","설계 문서 기반 구현","https:\u002F\u002Fgithub.com\u002FNharu\u002Fcc-cmds\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Freadme-gen\u002Fpre-yq-skills\u002Fimplement\u002FSKILL.md",[],[91,26],{"skillNo":97,"name":98,"nameZh":6,"description":99,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":100,"categories":101,"keywords":110,"publishedAt":28},"01M6DNAVQF4KERY94V79NVWAZA","design","에이전트 팀을 활용한 기능 설계 토론 진행","https:\u002F\u002Fgithub.com\u002FNharu\u002Fcc-cmds\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Freadme-gen\u002Fpre-yq-skills\u002Fdesign\u002FSKILL.md",[102,105],{"categoryNo":103,"categoryName":104,"taxonomyType":84,"taxonomyTypeDesc":85},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":106,"categoryName":107,"taxonomyType":108,"taxonomyTypeDesc":109},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[98,26],{"skillNo":112,"name":113,"nameZh":6,"description":114,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":115,"categories":116,"keywords":119,"publishedAt":28},"01M6DNASB3J3JQMZD57YBDHZ1A","design-upgrade","팀원 모델 업그레이드 분석","https:\u002F\u002Fgithub.com\u002FNharu\u002Fcc-cmds\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Freadme-gen\u002Fpre-yq-skills\u002Fdesign-upgrade\u002FSKILL.md",[117,118],{"categoryNo":103,"categoryName":104,"taxonomyType":84,"taxonomyTypeDesc":85},{"categoryNo":106,"categoryName":107,"taxonomyType":108,"taxonomyTypeDesc":109},[120,98,20,26,121],"design upgrade","haiku",{"skillNo":123,"name":124,"nameZh":6,"description":125,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":126,"categories":127,"keywords":130,"publishedAt":28},"01M6DNAA53K13C0REE8FDT3QHR","design-review","설계 문서 최종 리뷰","https:\u002F\u002Fgithub.com\u002FNharu\u002Fcc-cmds\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Freadme-gen\u002Fpre-yq-skills\u002Fdesign-review\u002FSKILL.md",[128,129],{"categoryNo":103,"categoryName":104,"taxonomyType":84,"taxonomyTypeDesc":85},{"categoryNo":106,"categoryName":107,"taxonomyType":108,"taxonomyTypeDesc":109},[19,98,131,26],"design review"]