phasegate 0.16.0 → 0.32.0

package/skills/codebase-mapper/SKILL.md

@@ -12,7 +12,7 @@ review: opus
 
 ## 出力物
 
-`docs/product/construction/codebase-map.md` — Unit・レイヤー分布・依存関係の可視化文書
+`{constructionDir}/codebase-map.md` — Unit・レイヤー分布・依存関係の可視化文書（パスは `phasegate.config.json` で設定）
 
 ---
 
@@ -31,7 +31,7 @@ review: opus
 # Codebase Mapper 計画
 
 ## スキャン対象
-- ソースコード: scripts/harness/
+- ソースコード: {phasegate.config.json の sourceDir}
 - 除外: __tests__/, node_modules/
 
 ## 出力粒度
@@ -41,7 +41,7 @@ review: opus
 - [ ] 循環依存検出
 
 ## 出力先
-docs/product/construction/codebase-map.md
+{constructionDir}/codebase-map.md
 
 ## QA
 [Question] Q1: ...
@@ -58,7 +58,7 @@ docs/product/construction/codebase-map.md
 
 ### Step 1: @unit/@layer アノテーションの収集
 
-Glob + Read を使い、`scripts/harness/**/*.ts`（テスト・fixture除外）から：
+Glob + Read を使い、`{sourceDir}/**/*.ts`（テスト・fixture除外）から：
 
 ```
 @unit {unit-name}
@@ -79,7 +79,7 @@ Unit間依存グラフを深さ優先探索でサイクル検出する。
 
 ### Step 4: マップ文書の生成
 
-`docs/product/construction/codebase-map.md` に出力。
+`{constructionDir}/codebase-map.md` に出力。
 
 ---
 
@@ -89,7 +89,7 @@ Unit間依存グラフを深さ優先探索でサイクル検出する。
 # Codebase Map
 
 生成日時: {date}
-スキャン対象: scripts/harness/
+スキャン対象: {sourceDir}
 総ファイル数: N（テスト除く）
 
 ---
@@ -137,8 +137,8 @@ validator-system
 ## アノテーション欠落の対処
 
 マップ生成後、`@unit`/`@layer` が欠落しているファイルが検出された場合:
-1. `L1-001`（require-unit-comment）/ `L1-002`（require-layer-comment）の違反として報告
-2. `quick-implementor` でアノテーションを追加
+1. Lintルール違反（require-unit-comment / require-layer-comment）として報告
+2. 欠落ファイル一覧を出力し、アノテーション追加を促す
 
 ---
 
@@ -146,6 +146,6 @@ validator-system
 
 | スキル/コマンド | 用途 |
 |--------------|------|
-| `pnpm run lint` | L1 archgateルールの全体スキャン |
+| `npx phasegate lint` | L1 archgateルールの全体スキャン |
 | `consistency-checker` | マップ生成後の設計文書整合性確認 |
 | `doc-freshness-checker` | マップと設計文書の鮮度を合わせて確認 |

package/skills/codex-delegator/SKILL.md

@@ -176,55 +176,18 @@ git diff HEAD~1
 git diff --name-only HEAD~1
 ```
 
-#### Step B.1: Tier 1 — 機械的チェック（スクリプト/grep）
+#### Step B.1: Tier 1 — 機械的チェック
 
-Claude Codeがgrep・スクリプトで自動検証する。人間の判断不要な項目を高速に処理する。
-
-| ID | 次元 | 検証方法 | 重大度 |
-|----|------|---------|--------|
-| C1 | スコープ遵守 | `git diff --name-only` と指示ファイルリストの差分比較 | BLOCK |
-| C2 | 既存破壊なし | `pnpm test` 実行（既存テスト全パス確認） | BLOCK |
-| C3 | 命名一貫性 | grep: 日本語テスト名、`actual`変数、target/context構造 | BLOCK |
-| IM3 | レイヤー違反なし | grep: domain層ファイルからinfrastructure層へのimport検出 | BLOCK |
-| IM4 | 型安全性 | grep: 正当理由なき `any` / `as` の使用検出 | WARN |
-| TE1 | ケースID突合 | 設計文書のケースIDリスト vs テストファイル内のID（diff抽出） | BLOCK |
-| DP3 | 配置ルール準拠 | `git diff --name-only` とfolder_management_rules.mdのパス照合 | BLOCK |
-
-**Tier 1 判定**:
-```
-BLOCK が1つでもFAIL → REJECT（Tier 2スキップ）→ Step Cへ
-全PASS or WARNのみ  → Tier 2へ進む
-```
+Claude Codeがgrep・スクリプトで自動検証する。共通次元（C1-C3: スコープ遵守・既存破壊なし・命名一貫性）+ タスクタイプ別次元（IM3/IM4, TE1/TE4, DP3）を適用。BLOCKが1つでもFAILならTier 2スキップで即REJECT。次元ID・検証方法の詳細は [references/review-dimensions.md](references/review-dimensions.md) の Tier 1 セクションを参照。
 
 #### Step B.2: Tier 2 — Sonnetによる設計突合チェック
 
-Agent tool（subagent_type未指定）でSonnetに以下の**最小限の入力**を渡してレビューさせる。
-
-**Tier 2への入力（これだけ）**:
+Agent tool経由でSonnetに以下の**最小限の入力**を渡す:
 1. `git diff HEAD~1` の出力（変更差分のみ）
 2. Tier 1の結果サマリ（PASS/WARN一覧）
 3. 設計文書の**該当箇所の抜粋**（全文ではない）
 
-**Tier 2 レビュー次元**:
-
-| ID | 次元 | 検証内容 | 重大度 |
-|----|------|---------|--------|
-| C4 | 完了度 | 指示項目の欠落がないか | BLOCK |
-| DD1 | 計画との整合 | diffの内容が設計文書の方針と矛盾しないか | BLOCK |
-| DD2 | アーキテクチャ原則 | ヘキサゴナル・DDD原則に沿っているか | BLOCK |
-| DD4/IM-Y | YAGNI | 指示範囲外の「改善」「リファクタ」「将来への備え」がないか | BLOCK |
-| IM5 | DRY | 新規コードに既存コードとの重複がないか | WARN |
-| TE2 | 期待値突合 | Assertionの期待値が設計文書の期待結果と一致するか | BLOCK |
-| DD3 | トレーサビリティ | 各要素がストーリー/Unit要件に紐づいているか | WARN |
-
-詳細は [references/review-dimensions.md](references/review-dimensions.md) を参照。
-
-**Tier 2 判定**:
-```
-BLOCK が1つでもFAIL → REJECT → Step Cへ
-WARN のみ FAIL      → CONDITIONAL_PASS（WARNをまとめて修正）
-全PASS               → PASS（完了）
-```
+設計との整合（DD1/DD2）、YAGNI（DD4/IM-Y）、完了度（C4）、期待値突合（TE2）等を検証。BLOCKが1つでもFAILならREJECT、WARNのみならCONDITIONAL_PASS。次元ID・検証内容・判定ロジックの詳細は [references/review-dimensions.md](references/review-dimensions.md) の Tier 2 セクションを参照。
 
 ### Step C: 修正ループ（Fix Loop）
 
@@ -238,21 +201,7 @@ WARN のみ FAIL      → CONDITIONAL_PASS（WARNをまとめて修正）
 
 #### 修正指示の構造（codex再委任時）
 
-```
-## 修正指示（Round N）
-
-### 前回レビュー結果
-- FAIL次元: {ID}: {名前}
-
-### 修正箇所
-#### [{次元ID}] {ファイルパス}:{行番号}
-- 現状: {問題の具体的記述}
-- 期待: {あるべき状態}
-- 修正方法: {具体的手順}
-
-### 制約
-- 修正対象以外のコードに手を加えないこと
-```
+修正指示テンプレート（Round N形式: FAIL次元・修正箇所・制約）は [references/prompt-patterns.md](references/prompt-patterns.md) の「修正指示テンプレート」セクションを参照。
 
 #### エスカレーション条件
 

package/skills/consistency-checker/SKILL.md

@@ -20,10 +20,10 @@ AIDLCプロセスの全レイヤー設計文書を横断的に検証し、矛盾
 
 **このスキルは3フェーズで実行する。**
 - **Phase 1（計画）**: Opus がスコープ・方針・不明点を整理し、人間の承認を得る
-- **Phase 2（実行）**: Sonnet 4.6 に委任して成果物を生成する（`scripts/delegate-sonnet.sh` 経由）
+- **Phase 2（実行）**: プロジェクトのモデルルーティング設定に従い、実行モデルに委譲して成果物を生成する
 - **Phase 3（レビュー）**: Opus が成果物を検証し、問題があれば直接修正する
 
-**Phase 1/2/3を同時に実行してはならない。モデルルーティングの詳細は `docs/principles/model-routing.md` を参照。**
+**Phase 1/2/3を同時に実行してはならない。**
 
 ---
 
@@ -119,8 +119,6 @@ AIDLCプロセスの全レイヤー設計文書を横断的に検証し、矛盾
 
 ---
 
----
-
 ## Phase 3: レビュー（Opus review）
 
 ### 実行主体
@@ -128,7 +126,7 @@ AIDLCプロセスの全レイヤー設計文書を横断的に検証し、矛盾
 
 ### レビュー手順
 1. Sonnetが出力したファイルを読み込む
-2. `docs/principles/model-routing.md` のレビュー観点 R1〜R7 に沿って検証する
+2. プロジェクトのレビュー基準に沿って検証する
 3. **スキル固有レビュー観点**を検証する
 4. 判定結果を出力する
 
@@ -139,10 +137,8 @@ AIDLCプロセスの全レイヤー設計文書を横断的に検証し、矛盾
 - [ ] 推奨アクションが実行可能か（対応スキル名が明記されているか）
 - [ ] 偽陰性がないか（明らかな不整合を見逃していないか）
 
-### engineering-perspective レビュー観点（WARN基準）
-- [ ] ドメインスメル（責務混在・言語の乖離・境界不明確）がレイヤー横断で検出されているか
-- [ ] SOLID違反（SRP・DIP）が設計レイヤー間で見逃されていないか
-- [ ] コードスメル（Shotgun Surgery等）の兆候が設計変更の波及パターンから検出されているか
+### 品質観点のレビュー
+品質観点（SOLID、コードスメル、ドメインスメル）のレビューが必要な場合は `engineering-perspective` スキルを併用する。
 
 ### 判定と修正
 - **BLOCK項目にFAIL** → Opusが直接修正してから完了とする

package/skills/consistency-checker/references//343/203/201/343/202/247/343/203/203/343/202/257/343/203/252/343/202/271/343/203/210.md

@@ -50,11 +50,14 @@
 
 ```
 # ストーリーID抽出（マークダウンテーブルから）
-grep -oE 'US-[0-9]+|US-DEV-[0-9]+' docs/product/user_stories.md
+# {storyIdPattern} はプロジェクトのストーリーID正規表現（例: US-[0-9]+）
+grep -oE '{storyIdPattern}' {userStoriesPath}
 
 # Unit内のストーリー参照抽出
-grep -oE 'US-[0-9]+|US-DEV-[0-9]+' docs/product/units/*.md
+grep -oE '{storyIdPattern}' {unitsDir}/*.md
 
 # ドメインモデルの集約名抽出
-grep -E '^### .+集約|Aggregate' docs/product/construction/*/domain_model.md
+grep -E '^### .+集約|Aggregate' {constructionDir}/*/domain_model.md
 ```
+
+パス変数は `phasegate.config.json` のプロジェクト設定から解決する。

package/skills/doc-freshness-checker/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: doc-freshness-checker
-description: 設計文書の鮮度チェック（L4バリデータ拡張）。`p2:check-freshness` CLIを使い、設計文書の最終更新日が閾値を超えていないか、コード変更と設計文書の乖離がないかを検出する。使用タイミング: 「設計文書が古くなっていないか確認して」「ドキュメントの鮮度チェックを実行して」「L4 freshness チェック」「設計とコードの乖離を調べて」など。
+description: 設計文書の鮮度チェック（L4バリデータ拡張）。`phasegate check-freshness` CLIを使い、設計文書の最終更新日が閾値を超えていないか、コード変更と設計文書の乖離がないかを検出する。使用タイミング: 「設計文書が古くなっていないか確認して」「ドキュメントの鮮度チェックを実行して」「L4 freshness チェック」「設計とコードの乖離を調べて」など。
 model: sonnet
 review: opus
 ---
@@ -8,7 +8,7 @@ review: opus
 # Doc Freshness Checker
 
 設計文書の鮮度（freshness）を検証し、古くなった文書や対応コードとの乖離を検出するスキル。
-`phase2-extensions` Unit の `p2:check-freshness` CLIをラップし、結果を解釈・対処する。
+`phasegate check-freshness` CLIをラップし、結果を解釈・対処する。
 
 ## 前提条件
 
@@ -34,11 +34,11 @@ review: opus
 # Doc Freshness チェック計画
 
 ## チェック対象スコープ
-- ディレクトリ: {デフォルト: docs/product/construction/}
+- ディレクトリ: {phasegate.config.json の constructionDir、デフォルト: docs/}
 - 閾値: {phasegate.config.json の値 or デフォルト 30日}
 
 ## 実行コマンド
-pnpm run p2:check-freshness [--dir {path}] [--threshold {days}]
+npx phasegate check-freshness [--dir {path}] [--threshold {days}]
 
 ## QA
 [Question] Q1: ...
@@ -57,11 +57,11 @@ pnpm run p2:check-freshness [--dir {path}] [--threshold {days}]
 ### Step 1: CLIの実行
 
 ```bash
-pnpm run p2:check-freshness
+npx phasegate check-freshness
 ```
 
 オプション:
-- `--dir <path>` — チェック対象ディレクトリ（デフォルト: `docs/product/construction/`）
+- `--dir <path>` — チェック対象ディレクトリ（デフォルト: `phasegate.config.json` の `constructionDir`）
 - `--threshold <days>` — 警告閾値（日数）
 
 ### Step 2: 結果の解釈

package/skills/engineering-perspective/SKILL.md

@@ -53,33 +53,8 @@ description: |
 
 ## スメル検知
 
-### コードスメル（ファウラー視点）
-
-| スメル | 兆候 | 対処 |
-|--------|------|------|
-| Long Method | メソッドが長い | Extract Method |
-| Feature Envy | 他クラスのデータ多用 | Move Method |
-| Primitive Obsession | 基本型の過剰使用 | Value Objectに置換 |
-| Shotgun Surgery | 変更が多クラスに波及 | Move Method/Field |
-
-### SOLID違反（アンクル・ボブ視点）
-
-| 原則 | 違反の兆候 | 対処 |
-|------|------------|------|
-| SRP | 変更理由が複数 | クラス分割 |
-| OCP | 変更時に既存コード修正 | 抽象化 |
-| LSP | 派生型で例外発生 | 継承の見直し |
-| ISP | 使わないメソッドに依存 | IF分割 |
-| DIP | 具象に依存 | 抽象に依存 |
-
-### ドメインスメル（エヴァンス + 統合視点）
-
-| スメル | 兆候 | 対処 |
-|--------|------|------|
-| 責務混在 | 集約に複数責務 | 概念を分離 |
-| 不適切なVO | nullable値オブジェクト | ドメイン的に分解 |
-| 言語の乖離 | コードと用語が不一致 | 命名統一 |
-| 境界不明確 | コンテキストが混在 | 境界を明確化 |
+コードスメル（ファウラー視点）、SOLID違反（アンクル・ボブ視点）、ドメインスメル（エヴァンス視点）を並行検知する。
+各スメルの詳細テーブルは [references/glossary.md](references/glossary.md) を参照。
 
 ## 評価基準
 
@@ -99,37 +74,6 @@ description: |
 - [ ] SOLID違反・依存が外向き
 - [ ] モデル不一致・言語の乖離
 
-## 表現パターン
-
-### 質問
-
-| 視点 | パターン | 場面 |
-|------|----------|------|
-| 統合視点 | 「前提は？」 | 議論開始時 |
-| 統合視点 | 「具体例にすると？」 | 抽象的な話 |
-| ケント・ベック | 「テストは書いた？」 | 実装レビュー |
-| ファウラー | 「これ匂う？」 | コードレビュー |
-| アンクル・ボブ | 「依存の方向は？」 | 設計レビュー |
-| エヴァンス | 「ドメインエキスパートはこう呼ぶ？」 | 命名議論 |
-
-### 指摘
-
-| 視点 | パターン | 場面 |
-|------|----------|------|
-| 統合視点 | 「それって違くない？」 | スメル検知 |
-| ケント・ベック | 「今必要ないなら作らない」 | 過剰設計 |
-| ファウラー | 「リファクタしてから機能追加」 | 変更前 |
-| アンクル・ボブ | 「責務が複数ある」 | SRP違反 |
-| エヴァンス | 「コンテキストが混ざってる」 | 境界不明確 |
-
-### 開発アプローチ
-
-- 「バーティカルスライスでまず価値提供」（統合視点）
-- 「Make it work, make it right, make it fast」（ケント・ベック）
-- 「2回目で抽象化を検討」（ファウラー）
-- 「ボーイスカウトルール: 来た時より美しく」（アンクル・ボブ）
-- 「モデルとコードを一致させる」（エヴァンス）
-
 ## 参照ドキュメント
 
 - **統合モデル**: [references/domain-model.md](references/domain-model.md) - 完全なドメインモデル図

package/skills/engineering-perspective/references/domain-model.md

@@ -211,153 +211,22 @@ classDiagram
 
 素早いフィードバックとシンプルさを重視。
 
-**適用場面:**
-- テスト戦略の検討
-- 開発プロセスの改善
-- 過剰設計の防止
-
-**キーフレーズ:**
-- "Make it work, make it right, make it fast"
-- "YAGNI - 今必要ないなら作らない"
-- "小さなステップで進む"
+**適用場面:** テスト戦略の検討、開発プロセスの改善、過剰設計の防止
 
 ### FowlerPatterns（リファクタリング視点）
 
 コードの匂いの検知と改善パターンの提案。
 
-**適用場面:**
-- コードレビュー
-- レガシーコードの改善
-- 設計パターンの適用
-
-**検知するコードスメル:**
-| スメル | 説明 | リファクタリング |
-|--------|------|------------------|
-| Long Method | 長すぎるメソッド | Extract Method |
-| Feature Envy | 他クラスのデータを多用 | Move Method |
-| Primitive Obsession | 基本型の過剰使用 | Replace with Value Object |
-| Shotgun Surgery | 変更が多クラスに影響 | Move Method/Field |
-| Divergent Change | 1クラスが複数理由で変更 | Extract Class |
+**適用場面:** コードレビュー、レガシーコードの改善、設計パターンの適用
 
 ### UncleBobPrinciples（クリーン設計視点）
 
 SOLID原則とクリーンアーキテクチャの適用。
 
-**適用場面:**
-- アーキテクチャ設計
-- 依存関係の評価
-- インターフェース設計
-
-**SOLID原則チェック:**
-| 原則 | 違反の兆候 | 対処 |
-|------|------------|------|
-| SRP | 変更理由が複数 | クラス分割 |
-| OCP | 変更時に既存コード修正 | 抽象化・ポリモーフィズム |
-| LSP | 派生型で例外発生 | 継承の見直し |
-| ISP | 使わないメソッドへの依存 | インターフェース分割 |
-| DIP | 具象への依存 | 抽象への依存に変更 |
+**適用場面:** アーキテクチャ設計、依存関係の評価、インターフェース設計
 
 ### EvansDDD（ドメイン駆動視点）
 
 ドメインモデルの品質とユビキタス言語の整合性。
 
-**適用場面:**
-- ドメインモデリング
-- コンテキスト境界の設計
-- 集約設計
-
-**チェックポイント:**
-| 観点 | 確認事項 | 問題時の対処 |
-|------|----------|--------------|
-| ユビキタス言語 | コードと用語が一致 | 命名の統一 |
-| 境界づけられたコンテキスト | 責務が明確 | コンテキスト分割 |
-| 集約 | 整合性境界が適切 | 集約の再設計 |
-| ドメインイベント | 重要な出来事を表現 | イベント追加 |
-
-## 統合評価フロー
-
-```
-問題/コード
-    ↓
-┌─────────────────────────────────────────┐
-│  IntegratorCore: 前提確認               │
-│  - コンテキストは？                      │
-│  - 境界は？                              │
-│  - 目的は？                              │
-└─────────────────────────────────────────┘
-    ↓
-┌─────────────────────────────────────────┐
-│  並行評価                                │
-│  ├─ KentBeck: TDD/XP観点                │
-│  ├─ Fowler: コードスメル検知            │
-│  ├─ UncleBob: SOLID/アーキテクチャ      │
-│  └─ Evans: ドメインモデル品質           │
-└─────────────────────────────────────────┘
-    ↓
-┌─────────────────────────────────────────┐
-│  IntegratorCore: 統合・判断              │
-│  - 各視点の結果を統合                    │
-│  - 実用性を考慮してフィルタ              │
-│  - シンプルな改善案を選択                │
-└─────────────────────────────────────────┘
-    ↓
-EvaluationResult + Guidance
-```
-
-## ビジネスルール
-
-### 統合Good判定ルール
-
-以下をすべて満たす場合にGoodと判定：
-
-| 視点 | 基準 |
-|------|------|
-| 統合視点 | シンプル・説明可能・実用的 |
-| ケント・ベック | テストがある・YAGNIに従う |
-| ファウラー | コードスメルがない |
-| アンクル・ボブ | SOLID原則に従う・依存が内向き |
-| エヴァンス | ドメインを適切に表現・言語が一致 |
-
-### 統合NG判定ルール
-
-以下のいずれかに該当する場合にNGと判定：
-
-| 視点 | NG条件 |
-|------|--------|
-| 統合視点 | 複雑・目的不明・説明不能 |
-| ケント・ベック | テストなし・過剰設計 |
-| ファウラー | 重大なコードスメル |
-| アンクル・ボブ | SOLID違反・依存が外向き |
-| エヴァンス | モデル不一致・言語の乖離 |
-
-### 優先順位ルール
-
-改善提案の優先順位：
-
-1. **実用性に影響するもの** (統合視点)
-2. **テスト容易性に影響するもの** (ケント・ベック視点)
-3. **保守性に影響するもの** (ファウラー・アンクル・ボブ視点)
-4. **ドメイン表現に影響するもの** (エヴァンス視点)
-
-## 表現パターン（統合版）
-
-### 質問パターン
-
-| 視点 | パターン | 使用場面 |
-|------|----------|----------|
-| 統合視点 | 「前提は？」 | 議論開始時 |
-| 統合視点 | 「具体例にすると？」 | 抽象的な話のとき |
-| ケント・ベック | 「テストは書いた？」 | 実装レビュー時 |
-| ファウラー | 「これ匂う？」 | コードレビュー時 |
-| アンクル・ボブ | 「依存の方向は？」 | 設計レビュー時 |
-| エヴァンス | 「ドメインエキスパートはこう呼ぶ？」 | 命名議論時 |
-
-### 指摘パターン
-
-| 視点 | パターン | 使用場面 |
-|------|----------|----------|
-| 統合視点 | 「それって違くない？」 | スメル検知時 |
-| ケント・ベック | 「今必要ないなら作らない」 | 過剰設計時 |
-| ファウラー | 「リファクタしてから機能追加」 | 変更前 |
-| アンクル・ボブ | 「責務が複数ある」 | SRP違反時 |
-| エヴァンス | 「コンテキストが混ざってる」 | 境界不明確時 |
+**適用場面:** ドメインモデリング、コンテキスト境界の設計、集約設計

package/skills/implementation-readiness-checker/SKILL.md

@@ -36,6 +36,8 @@ review: opus
 
 ## 検証ワークフロー
 
+> **パス設定:** 以下のファイルパスはプレースホルダで記述。`{constructionDir}` / `{inceptionDir}` は `phasegate.config.json` のプロジェクト設定から解決される。
+
 ### Step 1: ファイル存在チェック（自動実行）
 
 **以下のファイルの存在を実際に確認する（Glob/Readツールを使用）：**
@@ -44,27 +46,26 @@ review: opus
 
 | カテゴリ | ファイルパス | 作成スキル |
 |---------|------------|----------|
-| 論理設計 | `docs/product/construction/{unit}/logical_design.md` | `logical-designer` |
-| 論理設計 | `docs/inception/{unit}/{story_id}/logical_design.md` | `logical-designer` |
-| ユニットテスト設計 | `docs/product/construction/{unit}/unit_test_design.md` | `unit-test-designer` |
-| ITテスト設計 | `docs/product/construction/{unit}/it_test_design.md` | `it-test-designer` |
-| シナリオテスト設計 | `docs/inception/{unit}/{story_id}/scenario_test_design.md` | `scenario-test-designer` |
-| カバレッジレポート | `docs/product/construction/{unit}/coverage_report.md` | `test-coverage-checker` |
+| 論理設計 | `{constructionDir}/{unit}/logical_design.md` | `logical-designer` |
+| 論理設計 | `{inceptionDir}/{unit}/{story_id}/logical_design.md` | `logical-designer` |
+| ユニットテスト設計 | `{constructionDir}/{unit}/unit_test_design.md` | `unit-test-designer` |
+| ITテスト設計 | `{constructionDir}/{unit}/it_test_design.md` | `it-test-designer` |
+| シナリオテスト設計 | `{inceptionDir}/{unit}/{story_id}/scenario_test_design.md` | `scenario-test-designer` |
+| カバレッジレポート | `{constructionDir}/{unit}/coverage_report.md` | `test-coverage-checker` |
 
 #### 推奨ファイル（なくても実装可能だが、あればより安全）
 
 | カテゴリ | ファイルパス | 作成スキル |
 |---------|------------|----------|
-| ユニットテストロジック | `docs/product/construction/{unit}/unit_test_logic.md` | `unit-test-logic-designer` |
-| ITテストロジック | `docs/product/construction/{unit}/it_test_logic.md` | `it-test-logic-designer` |
-| シナリオテストロジック | `docs/inception/{unit}/{story_id}/scenario_test_logic.md` | `scenario-test-logic-designer` |
-| UIUX設計 | `docs/product/construction/{unit}/uiux_design.md` | `uiux-designer` |
+| ユニットテストロジック | `{constructionDir}/{unit}/unit_test_logic.md` | `unit-test-logic-designer` |
+| ITテストロジック | `{constructionDir}/{unit}/it_test_logic.md` | `it-test-logic-designer` |
+| シナリオテストロジック | `{inceptionDir}/{unit}/{story_id}/scenario_test_logic.md` | `scenario-test-logic-designer` |
+| UIUX設計 | `{constructionDir}/{unit}/uiux_design.md` | `uiux-designer` |
 
-### Step 2: カバレッジレポートの内容確認
+### Step 2: カバレッジレポートの確認
 
-`coverage_report.md` が存在する場合、その内容を読み取り：
-- カバレッジ率が90%以上か確認
-- 未カバー項目がないか確認
+`coverage_report.md` が存在する場合、`test-coverage-checker` の検証結果を参照する。
+カバレッジの詳細分析は `test-coverage-checker` が担当するため、本スキルでは存在確認のみ行う。
 
 ### Step 3: 検証結果の報告
 
@@ -151,64 +152,9 @@ review: opus
 
 ---
 
-## 既存実装に対するテスト追加モード
-
-既に実装が完了しているが、テストが不足している場合に使用。
-
-### 使用方法
-
-```
-「US-XXXは実装済みだが、ユニットテスト/ITテストが不足している。テスト追加の準備状況を確認してほしい」
-```
-
-### 検証内容
-
-1. **実装済みコードの分析**
-   - `backend/src/{context}/` の実装ファイルを確認
-   - Entity/ValueObject/UseCase/Repository/Controllerを特定
-
-2. **既存テストの確認**
-   - `backend/test/unit/{context}/` のユニットテスト
-   - `backend/test/integration/{context}/` のITテスト
-   - `e2e/tests/{context}/` のE2Eテスト
-
-3. **ギャップ分析**
-   - 実装済みコンポーネントに対するテストの存在/不存在を一覧化
-
-### 出力例
+## 既存実装に対するテスト追加
 
-```markdown
-## 🔍 既存実装のテスト状況分析: US-217
-
-### 実装済みコンポーネント
-
-| コンポーネント | 種類 | ユニットテスト | ITテスト | E2Eテスト |
-|--------------|------|--------------|---------|----------|
-| WithholdingTaxProcess | Entity | ❌ なし | - | - |
-| CsvData | ValueObject | ❌ なし | - | - |
-| ParseCsvUseCase | UseCase | - | ❌ なし | - |
-| WithholdingTaxRepository | Repository | - | ❌ なし | - |
-| UploadCsvController | Controller | - | ❌ なし | - |
-| CSVアップロードフロー | E2E | - | - | ✅ あり |
-
-### 不足テストの作成に必要なスキル
-
-| 不足テスト | 対応スキル | 優先度 |
-|----------|----------|-------|
-| Entity/VOのユニットテスト | `unit-test-designer` → `unit-test-logic-designer` | 高 |
-| UseCase/Repository/ControllerのITテスト | `it-test-designer` → `it-test-logic-designer` | 高 |
-
-### 推奨フロー
-
-1. **`unit-test-designer`** → 既存Entity/VOに対するテストケース設計
-2. **`it-test-designer`** → 既存UseCase/Repository/Controllerに対するテストケース設計
-3. **`test-coverage-checker`** → カバレッジ検証
-4. **`unit-test-logic-designer`** → ユニットテストロジック設計
-5. **`it-test-logic-designer`** → ITテストロジック設計
-6. **`story-implementor`** → TDD実装（RED→GREEN）
-```
-
----
+既に実装が完了しているがテストが不足している場合は、`test-coverage-checker` の「実装済みコードへのテスト追加モード」を使用すること。本スキルはファイル存在チェックに特化し、テストギャップ分析は `test-coverage-checker` が担当する。
 
 ---
 
@@ -219,7 +165,7 @@ review: opus
 
 ### レビュー手順
 1. Sonnetが出力したファイルを読み込む
-2. `docs/principles/model-routing.md` のレビュー観点 R1〜R7 に沿って検証する
+2. プロジェクトのレビュー基準に沿って検証する
 3. 判定結果を出力する
 
 ### 判定と修正