---
name: kiwa-review
description: |
  kiwa skill chain で生成された test 仕様書 (`/kiwa-design` 出力) と test code (`/kiwa-forge` `/kiwa-hardhat` `/kiwa-play` `/kiwa-rust` `/kiwa-go` 出力) を review する skill。
  3 mode — `spec-review` (生成 spec の 11 観点網羅 / 優先度妥当性 / 不足観点を判定) / `test-review` (spec vs 実装 test の整合 / 観点別 cover 率 / 追加すべき test を提案) / `result-review` (test 実行結果 / coverage 数値 / flaky 検出 / 統合 report 全体を集約 review)。
  v1.4-6 (Issue #581) で polyglot 4 layer (rust-unit / rust-integration / go-unit / go-integration) 対応追加、 v1.5-6 (Issue #597) で polyglot 縦深化 4 layer (rust-axum / rust-actix-web / go-gin / go-echo) 対応追加、 v1.7-6 (Issue #627) で polyglot 継続深化 2 layer (rust-tower-http / go-fiber) 対応追加、 5 言語 (TS / Python / Solidity / Rust / Go) + 6 web framework (axum / actix-web / tower-http / gin / echo / fiber) の spec vs test 整合 review を統一経路で扱う。
  単体起動 + 他 kiwa skill (kiwa-design / kiwa-forge / kiwa-hardhat / kiwa-play / kiwa-rust / kiwa-go / kiwa-test) の完了 step から自動呼出。 report は `tests/reports/review/` に Write。
user_invocable: true
context: conversation
agent: general-purpose
allowed-tools: Bash, Read, Glob, Grep, Write
---

# /kiwa-review — kiwa test 仕様書 + test code review skill

`/kiwa-design` 出力 spec と Layer 2 (`/kiwa-forge` / `/kiwa-hardhat` / `/kiwa-play`) 出力 test の品質を independent agent として review し、 不足観点 / 優先度妥当性 / spec vs 実装整合を判定して改善提案を report 化する。 kiwa 11 観点 catalog を SSOT として参照、 外部 skill (例 `/critique`) には依存しない (kiwa repo 内で完結、 OSS user がそのまま使える)。

## 前提

- 対象 spec が `tests/spec/{layer}/test-spec-{module}.{lang}.md` に存在 (`/kiwa-design` で生成済)
- test-review mode の場合は 対応 test file が `examples/{X}/test/` `examples/{X}/hardhat-test/` `examples/{X}/tests/` または `tests/fixtures/{X}/...` に存在
- 出力先 `tests/reports/review/` への Write 権限

## ユーザーのリクエスト

$ARGUMENTS

## オプション

- `--mode {spec-review|test-review|result-review}` — review mode (必須)
- `--module {name}` — 対象 module 名 (spec / test file の特定キー)
- `--layer {contract|e2e|e2e-generic|a11y|visual|api|ui|data|cli|nextjs-server-action|nextjs-middleware|nextjs-rsc|nextjs-parallel-route|nuxt-server-route|nuxt-route-middleware|nuxt-nitro-plugin|sveltekit-load|sveltekit-action|sveltekit-handle|sveltekit-handle-fetch|sveltekit-handle-error|sveltekit-hooks-chain|remix-loader|remix-action|remix-resource-route|remix-nested-route-chain|astro-endpoint|astro-ssr|astro-view-transitions|solidstart-server-function|solidstart-api-route|qwikcity-action|qwikcity-loader|qwikcity-endpoint|edge-handler|rust-unit|rust-integration|rust-axum|rust-actix-web|rust-tower-http|go-unit|go-integration|go-gin|go-echo|go-fiber|auth|job-queue|cache|integration|unit|all}` — spec layer (default `all`、 spec path 解決に使用、 詳細は `/kiwa-design § 出力 path の決定` SSOT)。 spec-review / test-review / result-review 3 mode は全 layer に対応 (5 framework sub-feature は v1.2 milestone Issue #523 で追加、 v1.3-2 SvelteKit hooks chain は Issue #559 で追加、 v1.3-3 Astro view transitions は Issue #560 で追加、 v1.3-4 Remix nested route chain は Issue #561 で追加、 v1.4-6 polyglot Rust / Go 4 layer は Issue #581 で追加、 v1.5-6 polyglot 縦深化 Rust / Go web framework 4 layer は Issue #597 で追加、 v1.7-6 polyglot 継続深化 Rust tower-http + Go Fiber 2 layer は Issue #627 で追加、 v1.8 新 layer auth / job-queue / cache は Issue #642 で追加)
- `--spec-path {path}` — spec file path を明示指定 (`--module` の代替)
- `--test-path {path}` — test code path を明示指定 (test-review mode のみ、 default は spec から推定)
- `--lang {ja|en|<ISO 639-1>}` — report 生成言語 (省略時は Step 0 で AskUserQuestion、 詳細 `references/doc-language-selection.md`)
- `--no-auto-call` — 他 skill からの自動呼出ではなく単体起動として動作 (chain effect 抑制)
- `--no-issue-create` — result-review 軸 5 = 0 検出時の自動 Issue 化 AskUserQuestion を skip (CI / 自動化用、 改善 3 / Issue #226)

## 実行フロー

### Step 0: 文書生成言語の選択 (skill 起動時 1 回)

AskUserQuestion で review report の生成言語を確認。 `--lang {code}` 引数指定時は skip。

選択肢 — 🇯🇵 日本語 (ja、 Recommended) / 🇬🇧 English (en) / 🌏 その他多言語 (free input)。 詳細 `references/doc-language-selection.md`。

確定後の言語 `$DOC_LANG` は Step 3 (report Write) で参照。 出力 path (Issue #341 SSOT):
- ja → `tests/reports/review/{mode}-review-{module}.ja.md`
- en → `tests/reports/review/{mode}-review-{module}.md`
- その他 → `tests/reports/review/{mode}-review-{module}.{lang_code}.md`

#### lang suffix 規約 (SSOT)

producer (`/kiwa-design`) と consumer (`/kiwa-test` / `/kiwa-review`) の file 名規約一致:

```bash
LANG_SUFFIX=""
[ "$DOC_LANG" != "en" ] && [ -n "$DOC_LANG" ] && LANG_SUFFIX=".${DOC_LANG}"
# 使用例: tests/spec/{layer}/test-spec-${MODULE}${LANG_SUFFIX}.md
```

SKILL.md 内の `{lang}.md` 表記は本規約に従って `${LANG_SUFFIX}.md` (en で空 / ja で `.ja` / その他で `.{code}`) に展開される。 input spec 検索時も同規約で path 解決。

### Step 1: mode 判定 + 入力読込

`--mode` 引数で 3 分岐。 spec-review / test-review / result-review いずれかを必ず実行 (mode 未指定時はエラー停止 + AskUserQuestion で確認)。

#### 1A: spec-review mode

入力:
- spec file (`tests/spec/{layer}/test-spec-{module}.{lang}.md`) を Read
- 対象 contract / app / 仕様書 (任意、 spec の「対象機能」 section から path 抽出)

#### 1B: test-review mode

入力:
- spec file を Read
- 対応 test file を Glob で特定:
  - Foundry: `{example}/test/*.t.sol` or `tests/fixtures/{example}/contract-test/*.t.sol`
  - Hardhat: `{example}/hardhat-test/*.test.cjs` or `tests/fixtures/{example}/hardhat-test/*.test.cjs`
  - Playwright (dApp): `{example}/tests/*.spec.ts` or `tests/fixtures/{example}/e2e-test/*.spec.ts`
  - 汎用 e2e (`--layer e2e-generic`): `{example}/tests/*.e2e.spec.ts` or `tests/fixtures/{example}/e2e-generic-test/*.spec.ts`
  - a11y (`--layer a11y`): `{example}/tests/*.a11y.test.ts` or `tests/fixtures/{example}/a11y-test/*.test.ts`
  - visual (`--layer visual`): `{example}/tests/*.visual.test.ts` or `tests/fixtures/{example}/visual-test/*.test.ts`
  - Next.js Server Actions (`--layer nextjs-server-action`): `{example}/tests/*.nextjs.test.ts` or `{example}/tests/integration/*.nextjs.test.ts`
  - Next.js middleware (`--layer nextjs-middleware`): `{example}/tests/*.middleware.test.ts` or `{example}/tests/integration/*.middleware.test.ts`
  - Next.js RSC (`--layer nextjs-rsc`): `{example}/tests/*.rsc.test.ts` or `{example}/tests/integration/*.rsc.test.ts`
  - Next.js Parallel Routes (`--layer nextjs-parallel-route`): `{example}/tests/*.parallel.test.ts` or `{example}/tests/integration/*.parallel.test.ts`
  - Nuxt 3 Server Routes (`--layer nuxt-server-route`): `{example}/tests/*.nuxt.test.ts` or `{example}/tests/integration/*.nuxt.test.ts`
  - Nuxt 3 route middleware (`--layer nuxt-route-middleware`): `{example}/tests/*.nuxt-mw.test.ts` or `{example}/tests/integration/*.middleware.test.ts`
  - Nuxt 3 Nitro plugin (`--layer nuxt-nitro-plugin`): `{example}/tests/*.nitro.test.ts` or `{example}/tests/integration/*.nitro.test.ts`
  - SvelteKit load + actions + hooks (`--layer sveltekit-load` / `--layer sveltekit-action` / `--layer sveltekit-handle` / `--layer sveltekit-handle-fetch` / `--layer sveltekit-handle-error` / `--layer sveltekit-hooks-chain`): `{example}/tests/*.svk.test.ts` or `{example}/src/**/*.test.ts` or `{example}/tests/hooks.server.test.ts` or `{example}/tests/hooks-sequence.test.ts`
  - Remix v2 / React Router v7 (`--layer remix-loader` / `--layer remix-action`): `{example}/tests/*.remix.test.ts` or `{example}/app/**/*.test.ts`
  - Remix v2 Resource Routes (`--layer remix-resource-route`): `{example}/tests/*.resource.test.ts` or `{example}/app/routes/**/*.test.ts`
  - Remix v2 nested route chain (`--layer remix-nested-route-chain`): `{example}/tests/*.remix-nested-chain.test.ts` or `{example}/tests/dashboard-nested.test.ts`
  - Astro Server Endpoints (`--layer astro-endpoint`): `{example}/tests/*.astro.test.ts` or `{example}/src/pages/api/*.test.ts`
  - Astro `.astro` page SSR (`--layer astro-ssr`): `{example}/tests/*.astro-ssr.test.ts` or `{example}/src/pages/**/*.test.ts`
  - Astro View Transitions (`--layer astro-view-transitions`): `{example}/tests/*.astro-vt.test.ts` or `{example}/tests/view-transitions.test.ts`
  - SolidStart Server Functions + API Routes (`--layer solidstart-server-function` / `--layer solidstart-api-route`): `{example}/tests/*.solidstart.test.ts` or `{example}/src/lib/**/*.test.ts` or `{example}/src/routes/api/*.test.ts`
  - Qwik City routeAction + routeLoader + Endpoints (`--layer qwikcity-action` / `--layer qwikcity-loader` / `--layer qwikcity-endpoint`): `{example}/tests/*.qwik.test.ts` or `{example}/src/routes/**/*.test.ts`
  - Edge runtime fetch handler (`--layer edge-handler`): `{example}/tests/*.edge.test.ts` or `{example}/src/index.test.ts`
  - Rust cargo test unit (`--layer rust-unit`、 Issue #581 v1.4-6): `examples/{example}/tests/*.rs` (cargo の integration test 慣習、 1 file = 1 crate)
  - Rust cargo test integration (`--layer rust-integration`、 Issue #581 v1.4-6): `examples/{example}/tests/*_integration.rs` or `examples/{example}/tests/*.rs` (mock_server 経路、 unit と同 dir、 file 名 suffix or test 関数 prefix で識別)
  - Rust axum Router test (`--layer rust-axum`、 Issue #597 v1.5-6): `examples/{example}/tests/*_axum.rs` (`kiwa::axum::test_app(router)` + `TestApp::request(HttpMethod, path)` chain 経路、 file 名 suffix `_axum` で識別、 `cargo test --features kiwa/axum` で feature opt-in)
  - Rust actix-web App test (`--layer rust-actix-web`、 Issue #597 v1.5-6): `examples/{example}/tests/*_actix.rs` (`kiwa::actix::test_app(factory)` + `TestApp::request(HttpMethod, path)` chain 経路、 file 名 suffix `_actix` で識別、 `cargo test --features kiwa/actix-web` で feature opt-in、 `App` は `!Clone` で factory closure 必須)
  - Rust tower-http middleware chain test (`--layer rust-tower-http`、 Issue #627 v1.7-6): `examples/{example}/tests/*_tower_http.rs` (`kiwa::tower_http::test_chain(layers, router)` + 6 middleware helper (`cors::test_cors` / `trace::assert_trace_id` / `compression::test_compression` + `assert_compressed` / `auth::with_bearer` + `with_basic` / `rate_limit::exhaust` / `timeout::assert_timed_out`) 経路、 file 名 suffix `_tower_http` で識別、 `cargo test --features kiwa/tower-http` で feature opt-in、 tower-http feature は内部で axum feature を暗黙有効化、 `TestApp` / `TestResponse` surface は axum adapter と 1:1)
  - Go testing.T unit (`--layer go-unit`、 Issue #581 v1.4-6): `examples/{example}/*_test.go` (Go 同 package test 慣習、 black-box test は `{pkg}_test` package suffix)
  - Go testing.T integration (`--layer go-integration`、 Issue #581 v1.4-6): `examples/{example}/integration/*_test.go` (別 sub-package、 `package integration_test` で mock_server 経路を分離)
  - Go Gin engine test (`--layer go-gin`、 Issue #597 v1.5-6): `examples/{example}/*_gin_test.go` (`kiwa-test-go/gin` subpackage、 `ginAdapter.NewTestServer(t, engine)` + `srv.Request(method, path)` chain 経路、 file 名 suffix `_gin_test.go` で識別、 black-box `{pkg}_test` package)
  - Go Echo instance test (`--layer go-echo`、 Issue #597 v1.5-6): `examples/{example}/*_echo_test.go` (`kiwa-test-go/echo` subpackage、 `echoAdapter.NewTestServer(t, e)` + `srv.Request(method, path)` chain 経路、 file 名 suffix `_echo_test.go` で識別、 surface は gin adapter と 1:1)
  - Go Fiber App test (`--layer go-fiber`、 Issue #627 v1.7-6): `examples/{example}/*_fiber_test.go` (`kiwa-test-go/fiber` subpackage、 `kiwa_fiber.NewTestServer(t, app)` + `srv.Request(method, path)` chain 経路、 file 名 suffix `_fiber_test.go` で識別、 fasthttp base のため内部は `*App.Test(*http.Request)` hook 経由、 surface は gin / echo adapter と 1:1、 `kiwa-test-go/fiber` v0.4 + fasthttp 互換 API (`NormalizeRequest` / `NormalizeResponse`) で kiwa 契約 normalize)
  - Auth session / provider / DB adapter mock (`--layer auth`、 Issue #642 v1.8 + Issue #652/#653 v1.9-1/-2): `{example}/tests/*.auth.test.ts` or `packages/auth/tests/*.test.ts` (`@kiwa-test/auth` の 5 provider (NextAuth v5 `setupNextAuthEnv` / Lucia v3 `setupLuciaEnv` / Better Auth `setupBetterAuthEnv` / Clerk `setupClerkEnv` / Auth0 `setupAuth0Env`) を statement-level に mapping、 session mock + OAuth provider mock + email/password + magic link + 2FA + passkey + organizations + Clerk orgs + Auth0 tenant + rules + Management API mock の sub-feature を 1 file 内で cover、 `--provider {nextauth|lucia|better-auth|clerk|auth0|all}` で provider 別 review 対応)
  - Job queue / event queue / edge queue / AWS queue (`--layer job-queue`、 Issue #642 v1.8 + Issue #654/#655 v1.9-3/-4): `{example}/tests/*.queue.test.ts` or `packages/queue/tests/*.test.ts` (`@kiwa-test/queue` の 4 provider (BullMQ `setupBullMQEnv` (sandbox / testcontainers) + Inngest `setupInngestEnv` (stub / dev-server) + Cloudflare Queues `setupCloudflareQueuesEnv` (miniflare / wrangler) + AWS SQS `setupSQSEnv` (stub / localstack)) を statement-level に mapping、 job add / process / retry / fail / drain / delay + event send / step function / concurrency + queue send / consumer batch / DLQ + SQS FIFO / batch / long polling / visibility timeout の sub-feature を 1 file 内で cover、 `--provider {bullmq|inngest|cloudflare|sqs|all}` で provider 別 review 対応)
  - Cache (`--layer cache`、 Issue #642 v1.8 + Issue #656/#657 v1.9-5/-6): `{example}/tests/*.cache.test.ts` or `packages/cache/tests/*.test.ts` (`@kiwa-test/cache` の 3 provider (Redis `setupCacheEnv` (in-memory / testcontainers) + ioredis / node-redis 2 client + Memcached `setupMemcachedEnv` (stub / testcontainers) + memjs / memcached 2 client + KeyDB `setupKeyDBEnv` (stub / testcontainers) + ioredis 互換 client) を statement-level に mapping、 get / set / delete / TTL / expiry / Pub/Sub / publish-subscribe / assertPublished + Memcached 8 command + consistent-hash + KeyDB multi-master + cross-region Pub/Sub の sub-feature を 1 file 内で cover、 `--provider {redis|memcached|keydb|all}` で provider 別 review 対応)
- 11 観点 catalog (`.claude/skills/kiwa-design/references/viewpoints-catalog.md`) を Read
- 新 3 layer 専用観点の追加 SSOT
  - `e2e-generic`: 9 column (Mode `static`/`fetch`/`node`/`ssr` + Route + Action + Expected) を Layer 2 mapping と照合
  - `a11y`: 9 column (Mode `jsdom`/`playwright` + Component + WCAG-rule + Severity) を axe-core rule 適用率で照合
  - `visual`: 9 column (State + Component + Viewport + Threshold + Mask) を baseline file 存在 + diff 結果で照合

#### 1C: result-review mode

入力:
- 統合 report (`tests/reports/integrated/{example}-{target}.{lang}.md`) を Read (`/kiwa-test` 完了時に生成済)
- 各子 report も Read:
  - coverage report: `tests/reports/contract/coverage-report-{example}.{lang}.md` (Foundry / Hardhat 別 round 履歴も含む)
  - spec-review report: `tests/reports/review/spec-review-{example}.{lang}.md`
  - test-review report: `tests/reports/review/test-review-{example}.{lang}.md`
- test 実行結果数値 (passing / failing / skipped / 各 round timing / flaky 指標)
- spec file の 「不足している仕様」 section (後追い項目の存在 check)

### Step 2: review 実行 (mode 別)

#### 2A: spec-review mode の review 観点 (5 軸)

| 軸 | 評価内容 | passing 基準 |
|---|---|---|
| **観点網羅** | 11 観点 catalog のうち、 spec が選択しなかった観点について「適用条件を満たすのに選択漏れ」が無いか判定 | 適用条件を満たす全観点が選択されている |
| **TC 件数妥当性** | 観点ごとに最低 1 件 (正常系は 1+)、 高リスク機能は 観点あたり 3+ 件 | 各観点で 1+ TC、 高リスク機能は密度高 |
| **優先度妥当性** | リスク表との整合、 「全 TC が低」 等の偏り検出 | リスク 5 基準と優先度判定が一致 |
| **入力 / 期待結果の具体性** | 抽象表現 (「適切に」「正しく」) 禁止、 具体値 / 具体 assertion | 全 TC で具体値、 abstract phrase 0 件 |
| **不足している仕様 section の使い方** | 仕様不明点が「不足している仕様」 に bullet 化されている、 spec が勝手に補完していない | 不明点が明示、 「(なし)」 は仕様完備の場合のみ |

各軸に 0-10 score を付与、 `weighted_score = (網羅 0.3 + 件数 0.2 + 優先度 0.2 + 具体性 0.2 + 不足明示 0.1)` で総合判定 (7.0 以上で PASS)。

#### 2B: test-review mode の review 観点 (5 軸)

| 軸 | 評価内容 | passing 基準 |
|---|---|---|
| **TC ID mapping** | spec の全 TC ID が test code に存在 (1:1 mapping)、 spec にない test ID は許容するが flag | spec TC 100% 実装、 余剰 test は別途記載 |
| **観点 grouping 一致** | test code の describe / コメント (`// 観点 N: {name}`) が spec の観点 grouping と一致 | 全観点 grouping が spec と同名 |
| **assertion 品質** | spec の「期待結果」 column と test の `expect()` / `assertEq()` が意味的に対応、 truthy 判定 (`toBeTruthy()`) ではなく具体値 assertion | 抽象 assertion (`toBeTruthy` 等) 0 件、 具体値検証 |
| **観点別 cover 率** | 観点ごとに spec TC が全件実装されているか (例 観点 5 権限が 5 TC 設計、 test に 3 件しかなければ 60%) | 各観点 100% (実装漏れなし) |
| **追加すべき test 提案** | spec にも test にも無いが、 contract / UI 実装を見て「この観点 / 機能の test も追加すべき」 と判定 | 提案を report に列挙 (実装漏れと将来 enhancement を区別) |

各軸 0-10 score、 `weighted_score = (mapping 0.3 + grouping 0.15 + assertion 0.25 + cover 0.2 + 提案 0.1)` で総合判定。

### Step 3: report Write

`tests/reports/review/{mode}-review-{module}.{$DOC_LANG}.md` に 5 section format で Write。

```markdown
# {Mode} Review Report — {module}

Generated: {ISO8601}
Skill: /kiwa-review --mode {mode}
Target: {spec_path} / {test_paths}

## 1. 判定サマリ

| 軸 | スコア | weight | 重み付き |
|---|---|---|---|
| {軸 1} | 8/10 | 0.30 | 2.40 |
| {軸 2} | ... | ... | ... |
| **Weighted Score** | **{N.N}/10** | 1.00 | (7.0 以上で PASS) |

**判定 — ✅ PASS / ❌ FAIL** ({reason})

## 2. critical / major 指摘

### 1. {severity}: {issue}
- **場所**: {spec section or test file:line}
- **詳細**: {issue}
- **改善案**: {suggestion}

### 2. ...

## 3. minor 指摘 (参考)

...

## 4. 追加すべき test 提案 (test-review mode のみ)

| 観点 | 提案 TC | 理由 |
|---|---|---|
| 11 回帰 | grantTimedAccess(addr, 0) で 0 秒 grant が即時 expire するか | spec に未設計、 contract 側 edge case |
| 4 状態遷移 | listing 中の NFT を seller が approve 取り消した場合 | spec の前提条件 column が薄い |

## 5. 総評

{3-5 文の総合評価、 spec / test code の強み・弱み・次のアクション推奨}
```

### Step 4: chain return

他 skill から自動呼出された場合 (例 `/kiwa-design` 完了後の auto call)、 review 結果を呼出元に return:
- PASS → 呼出元の chain 継続 (次 skill 起動)
- FAIL critical あり → 呼出元に critical 指摘の summary を return、 user に AskUserQuestion で「無視して継続 / spec or test 修正 / chain 中断」を選ばせる

`--no-auto-call` 指定時は chain return せず report Write だけで終了。

#### result-review mode: 軸 5 = 0 (後追い項目残存) 検出時の自動 Issue 化 (改善 3 / Issue #226)

`--mode result-review` で軸 5 (後追い項目 = spec の「不足している仕様」 bullet の Issue / TODO 紐付け率) の score = 0 を検出した場合、 後追い bullet が放置されている。 Step 4 で AskUserQuestion を強制発火する。

判定 logic。

1. spec file (`tests/spec/{layer}/test-spec-{module}.{lang}.md`) の「不足している仕様」 section から bullet 一覧を抽出
2. 各 bullet について Issue 番号 (`#NNN`) / TODO 注記 (`TODO:` / `FIXME:`) の引用が末尾にあるか check
3. 引用率 = 0 (どの bullet にも紐付けがない) なら軸 5 = 0 critical 警告となる

検出時のアクション。

```text
question: "spec の「不足している仕様」 に {N} 件 bullet があるが、 Issue / TODO 紐付けが 0 件です。 どう処理しますか?"
header: "後追い項目"
multiSelect: false

選択肢:
- label: "🆕 全 {N} 件を別 Issue 化 (gh api で自動起票) (Recommended)"
  description: "理由 — spec の後追い項目を恒久的に追跡可能化、 result-review 軸 5 critical を解消。 1 bullet = 1 Issue で起票、 title は「feat-improve(spec): {module} の不足仕様『{bullet 1 行目 40 字}』 を解消」、 body は bullet + 関連 spec file path を含む。 ⭐⭐⭐⭐⭐"
- label: "📝 spec file に TODO 注記を追加 (各 bullet 末尾に TODO: 追記)"
  description: "理由 — Issue 化までは大げさだが追跡したい、 spec 内に TODO 注記を残す。 軸 5 = 部分 score (0.5 程度) に格上げ。 ⭐⭐⭐"
- label: "⏭️ そのまま完了 (軸 5 = 0 を許容)"
  description: "理由 — bullet は spec author の memo として後で読めば良い、 自動追跡は不要。 result-review weighted_score が落ちることを許容。 ⭐⭐"
```

`🆕` 選択時は `gh api repos/{owner}/{repo}/issues --method POST` で N 件並列起票 (template = `feat-improve`、 `Closes` は持たず、 PR 起票時に手動連携)。 起票後 spec file 内の対応 bullet 末尾に Issue 番号を `Edit` で書き戻し、 軸 5 を再計算する。

`📝` 選択時は spec file の各 bullet 末尾に ` (TODO: 後追い)` を追記し、 軸 5 を再計算。

`⏭️` 選択時は何もせず Step 4 を通常 chain return で終了。

`--no-issue-create` 引数 (新規追加予定) で本判定を skip 可能 (CI / 自動化用)。

## 完了条件

- `tests/reports/review/{mode}-review-{module}.{lang}.md` が 5 section format で Write 済
- weighted_score が計算されて判定 (PASS / FAIL) 確定
- critical / major 指摘 + 追加 test 提案が列挙
- 自動呼出時は呼出元への chain return が正しく動作

## 他 kiwa skill との chain 連携

| 呼出元 skill | 呼出 mode | 呼出タイミング | 用途 |
|---|---|---|---|
| `/kiwa-design` Step 5 完了後 | `spec-review` | spec 生成完了、 Layer 2 へ進む前 | 観点漏れ / 優先度判定ミス を check |
| `/kiwa-forge` Step 5d 完了後 | `test-review` | Foundry test 生成 + auto loop 完了後 | spec vs test 整合、 追加 test 提案 |
| `/kiwa-hardhat` Step 5d 完了後 | `test-review` | Hardhat test 生成 + auto loop 完了後 | 同上 |
| `/kiwa-play` Step 9 完了後 | `test-review` | Playwright spec 生成 + 4 round PASS 後 | 同上、 UI 起点 e2e 整合 |
| `/kiwa-test` Step 5 完了後 | `result-review` | 統合 report 生成後、 全 chain 完了時 | coverage / passing / flaky / 子 review score を集約 review、 後追い項目を最終 check |

各 skill の SKILL.md には「完了 step の末尾で `/kiwa-review --mode {spec|test}-review --module {X}` を内部呼出」 と明記される (本 skill 新設に伴う SKILL.md 修正)。

## references

- `references/spec-review-axes.md` — spec-review mode の 5 軸詳細 + 評価例 + score 判定基準
- `references/test-review-axes.md` — test-review mode の 5 軸詳細 + 評価例 + score 判定基準
- `references/result-review-axes.md` — result-review mode の 5 軸詳細 + 評価例 + score 判定基準
- `references/doc-language-selection.md` — 文書生成言語選択 共通 SSOT (kiwa skill 共用、 symlink で参照)

## 関連

- 観点 SSOT: `.claude/skills/kiwa-design/references/viewpoints-catalog.md` (11 観点 catalog)
- spec format SSOT: `docs/SKILL-DESIGN.ja.md` (9 section 統一テンプレ)
- 親 Issue (本 skill の motivation): #215 (mint-nft fixtures 化 docs 検証で gap 発見、 reviewer agent 欠落を補完)
- 同並列 skill: `/kiwa-design` `/kiwa-forge` `/kiwa-hardhat` `/kiwa-play`