Test Review

test-review: 工程成果物の出口ゲートレビュー

ISTQB/JSTQB の 静的テスト（レビュー） をテストプロセスの成果物へ適用する単機能スキル。 テストプロセス 7 活動の「並び」の 1 工程ではなく、各工程の出口で単発実施する横断ゲート。 機械検査（決定論）→ AI 定性レビュー（サブエージェント）→ 利用者の最終判定の 3 段で、 成果物の内容の正否と工程間の綻びの伝播を工程出口で堰き止める。

モニタリング（test-monitor が構築する計測基盤）とは別の道具: メトリクスは計画との差異を 検出し、内容の正否を見るのはレビュー。この分担を混ぜない。

工程とレビュー対象

| 工程引数 | 対象工程スキル | レビュー対象（既定パス: docs/test//） | |---|---|---| | spec ※ | feature-spec | docs/dev//spec.md | | design-doc ※ | basic-design | docs/dev//basic-design.md | | plan | test-plan | test-plan.md | | analyze | test-analyze | test-analysis.md | | design | test-design | test-design.md / test-case.md | | implement | test-implement | テストコード（プロジェクト規約パス） / test-procedures.md | | execute | test-execute | test-execution-log.md | | monitor | test-monitor | test-monitoring.md と計測基盤の実装物 | | report | test-report | test-summary-report.md |

※ spec / design-doc は軽量ゲート。テストプロセスの上流にある仕様・基本設計を対象とし、 他工程と違って AI 定性レビュー（test-reviewer サブエージェント）を起動しない。 機械検査 → 利用者判定 → 記録の 3 段で閉じる（手順 2 を飛ばす）。

• 理由: 仕様・設計の意味的な欠陥検出（矛盾・テスト可能性・検証可能性）は、テスト工程との

往復（early testing）が正式な担い手である。ゲートが検査するのは形式契約 （必須セクション・REQ-# の形式と一意性・参照整合）のみで、意味には踏み込まない。

• レビュー対象のパスだけが docs/dev// である点に注意する。レビュー記録の置き場所は

他工程と同じく docs/test//test-review-.md（原則 1 のまま変えない）。

• 検査内容: spec は必須セクション / REQ-# 定義見出しの一意性 / 受け入れ条件の空欄と REQ-# 紐づけ /

下流 test-analysis.md からの孤児参照（仕様改訂で参照先 REQ-# を消していないか）。 design-doc は必須セクション / 機能一覧の各行の REQ-# 参照必須と spec.md での実在 / test-case.md があれば CASE-# 突合。突合先が無い検査は SKIP（差し戻し理由にしない）。

mini サマリ（mini-test-*.md）はレビュー対象外（本編の収束後に作られる派生物のため）。 実施タイミングは 本編への利用者フィードバック収束後・mini サマリ作成前 を推奨する （指摘対応で本編が変わると mini の同期し直しになるため）。

このスキルがやらないこと（重要）

• 成果物を修正・代作しない。指摘と判定記録だけを行う。差し戻し後の修正は対象工程スキルの

再実行または利用者が行う。

• テスト対象のソースコード自体のレビューはしない（コード diff のレビューは diff-review 等の

領分）。implement 工程で見るのは「テストケースがテストとして正しく具体化されたか」まで。

• 継続監視・傾向分析・完了判定はしない（計測は test-monitor が構築する基盤、評価は

test-report の担当）。

このスキルが従う横断原則

testing-skills 全 8 スキル共通の原則。型は test-plan（参照実装）に揃える。 test-review はゲートという性質上、原則 3 を「指摘の管理」へ読み替えて適用する。

1. ファイル規約 + 任意入力

• 成果物（レビュー記録）の既定パスは docs/test//test-review-.md。
• プロジェクト側（CLAUDE.md / AGENTS.md 等）に成果物の配置規約があればそちらを優先する。
• レビュー対象は上表の工程成果物。**対象成果物が規約パスに無ければレビューを進めず、

対象工程スキル（/test- 。spec / design-doc は /feature-spec / /basic-design）の実行を提案するに留める**（代作しない）。

• 突合先の前工程成果物（例: analyze のレビューでの test-plan.md）が無い検査は

スキップし、その旨を記録へ明記する。

2. 調査優先 + 決定のみ質問

• 事実は機械検査と調査で埋める。トレーサビリティ欠落・テンプレ準拠は決定論スクリプトが、

内容の定性確認はサブエージェントが行い、利用者に確認作業を代行させない。

• 利用者にしか決められない判断だけ を AskUserQuestion で確認する。test-review では

最終判定（通過 / 条件付き通過 / 差し戻し） がこれに当たる（推奨案を先頭に添えて訊く）。 機械検査の NG は決定論なので訊かずに差し戻す。

• 流れは 機械検査 → 定性レビュー → 判定提示 → 利用者判定 → 記録書き込み。

3. 指摘の管理（early testing 原則の読み替え）

• レビューの指摘は記録ファイルの 「未解消の指摘」 で管理する。解消された指摘は削除する

（「解消済み」注記で残さない。全て解消したらセクションごと削除する）。

• 指摘から 仕様の穴 が割れた場合も、仕様書への反映はこのスキルでは行わない。対象工程

スキルの担当（各スキルの原則 3）なので、差し戻し理由として指摘に載せ、対象工程スキルの 再実行へ回す。

• 各工程が持つ「改善提案」セクションは test-review の記録には置かない（指摘の管理と二重に

なるため）。

• スキル自身がテスト対象のコードも成果物も修正しない。

4. 単機能の堅持

• test-review は レビューと判定記録だけ を行う。他スキルを呼び出さず、相互参照もしない。
• 差し戻し時は、記録の「次のステップ」で 対象工程スキルの再実行を提案 するに留める

（代わりに成果物を直さない）。

5. Progressive disclosure

• 本文は簡潔に保ち、詳細は references/ と scripts/ に置く。
• 機械検査: [scripts/review-check.sh](scripts/review-check.sh)（工程別の決定論検査）。
• 定性チェックリスト: [references/checklist.md](references/checklist.md)（工程別 7 区分 + 共通観点）。
• 記録テンプレ: [references/template.md](references/template.md)（test-review-.md の雛形）。

6. 成果物の記述スタイル

• 略号・コードネームを定義なしで使わない。初出で正式名称・意味を併記するか、平易な表現に

開く。記録単体で読み返して意味が取れることを基準にする。

• スキルの実行記録を成果物に含めない。利用者との Q&A ログ等は対話のテレメトリであって、

レビュー記録の内容ではない（実施日・判定・機械検査の結果サマリは記録の本文そのものなので 含める）。

手順

以下、`` はこのスキルの base directory（スキル起動時に表示される絶対パス）を指す。 サブエージェントへの prompt に埋め込むときは必ず実際の絶対パスに展開する。

手順 0: テスト対象と工程の確定

• 引数は [工程]。工程は `spec / design-doc / plan / analyze / design /

implement / execute / monitor / report` のいずれか。

• 工程が省略されたら自分で推定して確認する: docs/test// にある工程成果物と

test-review-*.md（レビュー済みの証跡）を突き合わせ、成果物があって未レビューの工程を 候補として利用者に確認する（推奨案先頭）。docs/dev// の spec.md / basic-design.md も同じ要領で候補に含める。

• テスト対象名も無ければ利用者に一言で確認する（英数字・ハイフンへ正規化）。

手順 1: 機械検査（決定論）

/scripts/review-check.sh を実行する。

• 成果物ディレクトリは工程で変わる。spec / design-doc は docs/dev/、

それ以外は docs/test/。spec / design-doc は第 3 引数で突合先の テスト成果物ディレクトリを渡せる（省略時は docs/dev/X → docs/test/X を導出。 導出先が無ければ突合を SKIP）。

• 検査内容: 対象成果物の存在・必須セクション・テーブル空欄・トレーサビリティ ID 突合

（要求 REQ-# / リスク R# / テスト条件 TC-# / ケース CASE-# / 欠陥候補 D# の参照先存在と網羅）。

• NG が 1 件でもあれば自動で差し戻し: 定性レビューへ進まず、判定「差し戻し」と NG 内容を

記録へ書き込み（手順 4）、対象工程スキルの再実行を促して終了する。機械 NG は事実であり 利用者判定を待たない（原則 2）。SKIP（突合先なし等）は差し戻し理由にしない。

手順 2: AI 定性レビュー（サブエージェント）

工程が spec / design-doc のときは本手順を飛ばして手順 3 へ進む（軽量ゲート。 意味的な欠陥検出はテスト工程との往復が担い手であり、ここでは形式契約だけを見る）。 判定の材料は機械検査の結果のみになるため、手順 3 の推奨案は 「NG なし → 通過 / NG あり → 差し戻し」で提示する。

それ以外の工程では、機械検査を通過したら test-reviewer サブエージェントを 1 体起動 する。メインセッションで 成果物を作った直後でも独立した目で見られるよう、レビュー本体は必ずサブエージェントに任せる （自己レビューバイアスの排除）。prompt には必ず以下を含める:

工程: 
チェックリスト: /references/checklist.md（該当工程の区分 + 共通観点を適用）
レビュー対象: 
前工程成果物: 
機械検査の結果:

手順 3: 判定（利用者の最終承認）

• サブエージェントの指摘を重み順（must / want / nit）に提示し、**判定を AskUserQuestion

（推奨案先頭）で利用者に確認する**:

• 通過: 指摘なし、または全て解消済み。
• 条件付き通過: 軽微な指摘を残したまま次工程へ進んでよい（指摘は記録に残置し、解消時に

削除する）。

• 差し戻し: 指摘対応（対象工程スキルの再実行 or 利用者修正）後に再レビュー。
• 推奨案の目安: must 指摘あり → 差し戻し / want・nit のみ → 条件付き通過 / 指摘なし → 通過。

手順 4: 記録の書き込み

• [references/template.md](references/template.md) の構成で

docs/test//test-review-.md を書き込む（判定・実施日・機械検査サマリ・ 未解消の指摘のみ。指摘ゼロなら判定と実施日だけの薄い記録になる）。

• spec / design-doc も記録の置き場所は docs/test// で他工程と揃える

（test-review-spec.md / test-review-design-doc.md）。テンプレの「レビュー対象」に 書くパスだけが docs/dev//spec.md などになる。

• 再レビュー時は同ファイルを更新する（履歴を増やさない）。解消済みの指摘は削除する（原則 3）。

手順 5: 終了条件の確認と完了宣言

レビュー工程の終了条件は以下。利用者に「終わりか」と訊かれる前に、スキル側で判定して 宣言する:

1. 機械検査が実施済み（手順 1）。
2. 機械検査通過時は定性レビューが実施済みで、指摘が重み付きで提示済み（手順 2・3）。

spec / design-doc は定性レビューを行わないため、機械検査の結果提示をもって満たす。

1. 判定（通過 / 条件付き通過 / 差し戻し）が利用者確認済みで記録に明記済み（手順 3・4）。
2. test-review-.md が規約パスへ書き込み済みで、未解消の指摘だけが残っている（手順 4）。

• 全て満たしたら 「 のレビューは完了」と明言 して閉じる。判定が差し戻しでも

レビュー工程としては完了である（ゲートは未通過。対象工程スキルの再実行を提案して閉じる）。

• 満たしていない項目があれば、何が残っているかを列挙して先へ進めない。

用語（JSTQB 訳語 / 初出英語併記）

• レビュー（review）: 静的テストの一種。成果物を実行せずに内容の正否を評価する活動。
• 出口ゲート（exit gate）: 工程の完了宣言前に成果物の品質を確認する関門。本スキルの運用上の呼称。
• トレーサビリティ（traceability）: リスク・テスト条件・ケース・結果の間の対応関係。

機械検査は ID 突合でこの欠落を検出する。

• 差し戻し（rework）: 指摘対応のため成果物を対象工程へ戻す判定。

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: yasunori0418
• Source: yasunori0418/skills
• License: MIT

Install and usage instructions live in the source repository linked above.