phasegate 0.181.0 → 0.191.0

package/skills/codex-delegator/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: codex-delegator
+kind: advisory
 description: |
   codex CLI（gpt-5.4）にタスクをLocal実行で並列委任し、Claude Codeがマネージャー/レビュワーとして品質管理する。
   対象: 設計計画、設計文書、テスト設計、コード実装など全タスクタイプ。
@@ -11,19 +12,26 @@ languages: [typescript]
 
 # Codex Delegator
 
+## 目的
+
 codex CLI（gpt-5.4）にタスクをLocal実行で並列委任し、2段階レビューで品質管理するスキル。Claude Codeは**マネージャー**、codexは**実行者**、Sonnetは**レビュワー**として振る舞う。
 
-## 前提
+## 入力
+
+- 委任するタスク（ユーザー指示）: 設計計画・設計文書・テスト設計・コード実装など全タスクタイプ
+- 突合対象の設計文書（ドメインモデル・論理設計・テストケース設計等、後述「前提条件」参照）
+
+## 前提条件
 
-- codex CLI v0.111.0+（`codex exec "<prompt>" --full-auto`）
+- **codex CLI が必須** — codex CLI v0.111.0+（`codex exec "<prompt>" --full-auto`）がインストールされていること。未インストールの環境では本スキルはスキップし、Claude Code が直接実装に切り替える
 - モデル: `gpt-5.4`（ChatGPTアカウントでは派生モデル不可）
-- プロジェクト規約: `docs/principles/testing-rules.md`, `docs/principles/architecture-philosophy.md`
+- プロジェクト規約: `docs/principles/testing-rules.md`, `docs/principles/architecture-philosophy.md`（consumer プロジェクトでは `node_modules/phasegate/docs/principles/...`、phasegate 自リポジトリでは `docs/principles/...` を参照する）
 - 設計文書が揃っていることが前提（ドメインモデル、論理設計、テストケース設計等）
 
 ## 核心原則
 
 1. **codexに判断させない**: 何を・どのファイルに・どのパターンで作るかはClaude Codeが決定する。codexは具体的指示の実行者
-2. **設計文書との突合がレビューの主軸**: `pnpm test` グリーンだけでは不十分。設計文書のケースID・期待値との一致を検証する
+2. **設計文書との突合がレビューの主軸**: プロジェクトのテストコマンド（`npm test` 等、pnpm/yarn は例）のグリーンだけでは不十分。設計文書のケースID・期待値との一致を検証する
 3. **早期フォールバック**: codexが2回失敗したらClaude Codeが直接実装に切り替える
 4. **Local実行のみ**: codex cloud / @codex review は使用しない。全タスクを `codex exec --full-auto` で実行する
 5. **レビューはdiffベース**: 生成物の全文Readではなく、`git diff` の差分をレビュー入力とする。コンテキストウィンドウを節約し、変更点に集中する
@@ -62,6 +70,13 @@ Local実行では1委任単位の粒度を小さく保つことがコスト効
 
 ---
 
+## ⚠️ 2フェーズ実行ルール
+
+- **Phase 1（計画）**: タスクを委任単位に分解し、プロンプトを設計して人間の承認を得る
+- **Phase 2（実行）**: `codex exec` に委任し、2段階レビュー（Tier 1 → Tier 2）で品質管理する
+
+**Phase 1/2を同時に実行してはならない。**
+
 ## Phase 1: 計画（Plan）
 
 ### Step 1.1: タスク分解

package/skills/codex-delegator/references/prompt-patterns.md

@@ -6,11 +6,11 @@
 
 ## 共通コンテキスト層
 
-全タスクタイプで以下をプロンプト冒頭に含める:
+全タスクタイプで以下をプロンプト冒頭に含める。アーキテクチャ行は固定値ではなく、対象プロジェクトの `phasegate.config.json` の `architecture.preset` と `layers`（層と依存方向）から導出すること:
 
 ```
-プロジェクト: Phasegate
-アーキテクチャ: ヘキサゴナル + DDD（domain → port → usecase → controller）
+プロジェクト: {プロジェクト名}
+アーキテクチャ: {architecture.preset から導出（例: preset "hexagonal" なら「ヘキサゴナル + DDD（domain → port → usecase → controller）」、preset "clean" なら「クリーンアーキテクチャ（domain → application → infrastructure/presentation）」）}
 ```
 
 ---

package/skills/codex-delegator/references/review-dimensions.md

@@ -20,7 +20,7 @@ grep・diff・テスト実行で自動検証する。判断不要。
 | ID | 次元 | 検証方法 | 重大度 |
 |----|------|---------|--------|
 | C1 | スコープ遵守 | `git diff --name-only` と指示ファイルリストの差分比較 | BLOCK |
-| C2 | 既存破壊なし | `pnpm test` 実行（既存テスト全パス確認） | BLOCK |
+| C2 | 既存破壊なし | プロジェクトのテストコマンド（`npm test` 等、pnpm/yarn は例）実行（既存テスト全パス確認） | BLOCK |
 | C3 | 命名一貫性 | grep: 日本語テスト名、`actual`変数、target/context/describe/it構造 | BLOCK |
 
 ### Tier 1: タスクタイプ別追加

package/skills/consistency-checker/SKILL.md

@@ -123,7 +123,7 @@ AIDLCプロセスの全レイヤー設計文書を横断的に検証し、矛盾
 ## Phase 3: レビュー（Opus review）
 
 ### 実行主体
-メインセッション（Opus 4.6）が実行する。Sonnetへの再委任は行わない。
+メインセッション（model-routing.md の Architect ロール）が実行する。Sonnetへの再委任は行わない。
 
 ### レビュー手順
 1. Sonnetが出力したファイルを読み込む

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

@@ -8,6 +8,8 @@ languages: [typescript]
 
 # Doc Freshness Checker
 
+## 目的
+
 設計文書の鮮度（freshness）を検証し、古くなった文書や対応コードとの乖離を検出するスキル。
 `phasegate check-freshness` CLIをラップし、結果を解釈・対処する。
 
@@ -16,6 +18,12 @@ languages: [typescript]
 - `phasegate.config.json` に `docFreshnessThresholds` が設定されていること（未設定時はデフォルト値使用）
 - git リポジトリ内で実行すること（最終更新日は `git log` で判定）
 
+## 入力
+
+- 対象ディレクトリ: `--dir <path>` または `phasegate.config.json` の `constructionDir`（デフォルト `docs/`）
+- 閾値: `--threshold <days>` または `docFreshnessThresholds`（未設定時はデフォルト30日）
+- git 履歴（最終更新日の判定に使用）
+
 ---
 
 ## ⚠️ 2フェーズ実行ルール

package/skills/domain-designer/SKILL.md

@@ -24,7 +24,7 @@ DDD戦術パターンを用いてドメインモデルを設計するスキル
 
 ## ⚠️ 上位レイヤー存在チェック
 
-**このスキルは AIDLC Step 4「Domainの設計」に対応します。実行前に上位設計の存在を確認してください。**
+**このスキルは AIDLC Step 2.1「Domainの設計」に対応します。実行前に上位設計の存在を確認してください。**
 
 ### 依存する上位設計文書
 
@@ -77,6 +77,8 @@ DDD戦術パターンを用いてドメインモデルを設計するスキル
 ### 出力ファイル
 `docs/inception/{unit}/domain_model_plan.md`
 
+> **パス注記**: 本スキルが扱う設計文書パス（`docs/inception/...` / `docs/product/construction/...`）は既定値であり、consumer が `phasegate.config.json` の `paths` 設定で上書きしている場合はそちらが優先される。
+
 ### 計画ファイルの構成
 
 ```markdown
@@ -145,7 +147,7 @@ DDD戦術パターンを用いてドメインモデルを設計するスキル
 
 ## 🔗 成果物のトレーサビリティメタデータ（必須）
 
-Phase 2 で生成する設計文書には、以下 2 種類のメタデータを emit する。`MetadataValidator.validateDesignDocument` が検証対象とし、ISSUE-008 Phase B-2/B-3 完了後は `npx phasegate validate-metadata` / pre-commit で自動チェックされる。
+Phase 2 で生成する設計文書には、以下 2 種類のメタデータを emit する。これらのメタデータは `npx phasegate validate-metadata` / pre-commit で自動チェックされる。
 
 ### 1. YAML frontmatter（新規作成時）
 

package/skills/engineering-perspective/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: engineering-perspective
+kind: advisory
 description: |
   ケント・ベック + マーティン・ファウラー + アンクル・ボブ + エリック・エヴァンスの視点を統合したエンジニアリング思考フレームワーク。
   以下の場面で使用:
@@ -14,6 +15,8 @@ languages: [typescript]
 
 # Engineering Perspective
 
+## 目的
+
 4人の巨匠の視点を統合し、実用性・シンプルさ・説明責任の観点でレビュー・設計・議論を行う。
 
 ## 視点一覧

package/skills/environment-designer/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: environment-designer
-description: ローカル開発環境のプラットフォーム構成設計。コードと環境のブリッジ（AIDLC Step 2.2並行）
+description: ローカル開発環境のプラットフォーム構成設計。コードと環境のブリッジ（AIDLC Step 2.3、logical-designer の後）
 model: sonnet
 review: opus
 languages: [typescript]
@@ -26,7 +26,7 @@ languages: [typescript]
 
 ## ⚠️ 上位レイヤー存在チェック
 
-**このスキルは AIDLC Step 2.2並行「環境設計」に対応します。実行前に上位設計の存在を確認してください。**
+**このスキルは AIDLC Step 2.3「環境設計」（logical-designer の後）に対応します。実行前に上位設計の存在を確認してください。**
 
 ### 依存する上位設計文書
 
@@ -69,10 +69,10 @@ languages: [typescript]
 
 **このスキルは3フェーズで実行する。**
 - **Phase 1（計画）**: Opus がスコープ・方針・不明点を整理し、人間の承認を得る
-- **Phase 2（実行）**: Sonnet 4.6 に委任して成果物を生成する（`npx phasegate delegate-sonnet` 経由）
+- **Phase 2（実行）**: 委任先モデルに委任して成果物を生成する（`npx phasegate delegate-sonnet` 経由）
 - **Phase 3（レビュー）**: Opus が成果物を検証し、問題があれば直接修正する
 
-**Phase 1/2/3を同時に実行してはならない。モデルルーティングの詳細は `docs/principles/model-routing.md` を参照。**
+**Phase 1/2/3を同時に実行してはならない。モデルルーティングの詳細は `docs/principles/model-routing.md` を参照（consumer プロジェクトでは `node_modules/phasegate/docs/principles/model-routing.md`、phasegate 自リポジトリでは `docs/principles/model-routing.md` を参照する）。**
 
 ---
 
@@ -84,6 +84,8 @@ languages: [typescript]
 ### 出力ファイル
 `docs/inception/_shared/environment_design_plan.md`
 
+> **パス注記**: 本スキルが扱う設計文書パス（`docs/inception/...` / `docs/product/environment_contract.md`）は既定値であり、consumer が `phasegate.config.json` の `paths` 設定で上書きしている場合はそちらが優先される。
+
 ### 計画ファイルの構成
 
 ```markdown
@@ -161,11 +163,11 @@ languages: [typescript]
 ## Phase 3: レビュー（Opus review）
 
 ### 実行主体
-メインセッション（Opus 4.6）が実行する。Sonnetへの再委任は行わない。
+メインセッション（model-routing.md の Architect ロール）が実行する。Sonnetへの再委任は行わない。
 
 ### レビュー手順
 1. Sonnetが出力したファイルを読み込む
-2. `docs/principles/model-routing.md` のレビュー観点 R1〜R7 に沿って検証する
+2. `docs/principles/model-routing.md` の「レビュー観点」節に沿って検証する
 3. **スキル固有レビュー観点**を検証する
 4. 判定結果を出力する
 

package/skills/implementation-planner/SKILL.md

@@ -8,6 +8,8 @@ languages: [typescript]
 
 # Implementation Planner
 
+## 目的
+
 UnitドキュメントとConstructionのドメインモデル設計を元に、**設計フェーズの実装計画**を体系的に立案する。
 
 ## ⚠️ `story-implementor` との役割分担
@@ -27,16 +29,16 @@ UnitドキュメントとConstructionのドメインモデル設計を元に、*
 
 **このスキルは3フェーズで実行する。**
 - **Phase 1（計画）**: Opus がスコープ・方針・不明点を整理し、人間の承認を得る
-- **Phase 2（実行）**: Sonnet 4.6 に委任して成果物を生成する（`npx phasegate delegate-sonnet` 経由）
+- **Phase 2（実行）**: 委任先モデルに委任して成果物を生成する（`npx phasegate delegate-sonnet` 経由）
 - **Phase 3（レビュー）**: Opus が成果物を検証し、問題があれば直接修正する
 
-**Phase 1/2/3を同時に実行してはならない。モデルルーティングの詳細は `docs/principles/model-routing.md` を参照。**
+**Phase 1/2/3を同時に実行してはならない。モデルルーティングの詳細は `docs/principles/model-routing.md` を参照（consumer プロジェクトでは `node_modules/phasegate/docs/principles/model-routing.md`、phasegate 自リポジトリでは `docs/principles/model-routing.md` を参照する）。**
 
 ---
 
 ## ワークフロー
 
-## Pre-flight check (BLOCKING)
+## 前提条件チェック（Pre-flight, BLOCKING）
 
 Before generating any plan, verify `docs/inception/{unit}/WI-XXX/description.md` exists.
 If not, halt and ask the user to create the WI first, or offer to run `phasegate scaffold-wi <unit> <story|issue|chore>`.
@@ -86,6 +88,8 @@ If not, halt and ask the user to create the WI first, or offer to run `phasegate
 3. 実装ステップ分解
 4. 影響範囲特定
 
+## 出力ファイル
+
 ### Step 6: 出力
 
 計画をmdファイルとして出力。パスの推奨:
@@ -94,11 +98,13 @@ docs/inception/{task_id}_plan.md
 docs/inception/{unit}/WI-XXX/tdd_implementation_plan.md
 ```
 
+> **パス注記**: 本スキルが扱う設計文書パス（`docs/inception/...` / `docs/product/units/...` / `docs/product/construction/...`）は既定値であり、consumer が `phasegate.config.json` の `paths` 設定で上書きしている場合はそちらが優先される。
+
 **[Question][Answer]セクション必須**: 不明点や確認事項をまとめ、ユーザーからのフィードバックを受け取れるようにする。
 
 ---
 
-## 参照ドキュメント
+## 入力（参照ドキュメント）
 
 | ファイル | 用途 |
 |----------|------|
@@ -138,11 +144,11 @@ docs/inception/{unit}/WI-XXX/tdd_implementation_plan.md
 ## Phase 3: レビュー（Opus review）
 
 ### 実行主体
-メインセッション（Opus 4.6）が実行する。Sonnetへの再委任は行わない。
+メインセッション（model-routing.md の Architect ロール）が実行する。Sonnetへの再委任は行わない。
 
 ### レビュー手順
 1. Sonnetが出力したファイルを読み込む
-2. `docs/principles/model-routing.md` のレビュー観点 R1〜R7 に沿って検証する
+2. `docs/principles/model-routing.md` の「レビュー観点」節に沿って検証する
 3. **スキル固有レビュー観点**を検証する
 4. 判定結果を出力する
 

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

@@ -1,5 +1,6 @@
 ---
 name: implementation-readiness-checker
+kind: advisory
 description: 実装開始前の準備状況を自動検証 - テスト設計・カバレッジ・ロジック設計の存在チェックとギャップ分析
 model: sonnet
 review: opus
@@ -8,8 +9,15 @@ languages: [typescript]
 
 # Implementation Readiness Checker
 
+## 目的
+
 実装開始前に呼び出し、全ての前提条件（設計文書、テスト設計、カバレッジ検証）を**自動検証**するスキル。不足があれば具体的に何が必要かを報告し、対応するスキルを提案する。
 
+## 入力
+
+- 検証対象の Unit / ストーリー (`{unit}` / `{story_id}`)
+- 存在確認する設計文書群（`{constructionDir}` / `{inceptionDir}` 配下の論理設計・テスト設計・カバレッジレポート等、後述「検証ワークフロー Step 1」の一覧参照）
+
 ## 使用タイミング
 
 - `story-implementor` の前に実行（推奨）
@@ -162,7 +170,7 @@ languages: [typescript]
 ## Phase 3: レビュー（Opus review）
 
 ### 実行主体
-メインセッション（Opus 4.6）が実行する。Sonnetへの再委任は行わない。
+メインセッション（model-routing.md の Architect ロール）が実行する。Sonnetへの再委任は行わない。
 
 ### レビュー手順
 1. Sonnetが出力したファイルを読み込む

package/skills/it-test-designer/SKILL.md

@@ -19,9 +19,11 @@ languages: [typescript]
 ### 任意インプット（あれば参照）
 - **ドメインモデル** — `docs/product/construction/{unit}/domain_model.md`
 - **環境設計** — `docs/product/environment_contract.md`
-- **テスト規約** — `docs/principles/testing-rules.md`
+- **テスト規約** — `docs/principles/testing-rules.md`（consumer プロジェクトでは `node_modules/phasegate/docs/principles/testing-rules.md`、phasegate リポジトリ自体では `docs/principles/testing-rules.md` を参照）
 - **既存ITテスト** — 既存パターンの参考
 
+> **設計文書パスの注記:** 上記および本スキルが扱う `docs/product/construction/{unit}/...` / `docs/inception/...` パスは既定値。consumer が `phasegate.config.json` の paths 設定を上書きしている場合はそちらに従う。
+
 ---
 
 ## ⛔ スキップ禁止
@@ -34,7 +36,7 @@ languages: [typescript]
 - `implementation-readiness-checker` でブロックされる
 
 ### フロー上の位置
-`scenario-test-designer` → **it-test-designer（本スキル）** → `unit-test-designer` → `test-coverage-checker` → テストロジック設計 → `story-implementor`
+`scenario-test-designer` → `uiux-designer` → `unit-test-designer` → **it-test-designer（本スキル）** → `test-coverage-checker` → テストロジック設計 → `implementation-readiness-checker` → `story-implementor`
 
 **必ず完了してから次のステップに進んでください。**
 
@@ -69,7 +71,7 @@ languages: [typescript]
 
 **このスキルは3フェーズで実行する。**
 - **Phase 1（計画）**: Opus がスコープ・方針・不明点を整理し、人間の承認を得る
-- **Phase 2（実行）**: Sonnet 4.6 に委任して成果物を生成する（`npx phasegate delegate-sonnet` 経由）
+- **Phase 2（実行）**: 委任先モデルに委任して成果物を生成する（`npx phasegate delegate-sonnet` 経由）
 - **Phase 3（レビュー）**: Opus が成果物を検証し、問題があれば直接修正する
 
 **Phase 1/2/3を同時に実行してはならない。モデルルーティングの詳細は `docs/principles/model-routing.md` を参照。**
@@ -151,11 +153,11 @@ ITテスト設計のスコープ・テスト対象・不明点を整理し、人
 ## Phase 3: レビュー（Opus review）
 
 ### 実行主体
-メインセッション（Opus 4.6）が実行する。Sonnetへの再委任は行わない。
+メインセッション（model-routing.md の Architect ロール）が実行する。Sonnetへの再委任は行わない。
 
 ### レビュー手順
 1. Sonnetが出力したファイルを読み込む
-2. `docs/principles/model-routing.md` のレビュー観点 R1〜R7 に沿って検証する
+2. `docs/principles/model-routing.md` の「レビュー観点」節に沿って検証する
 3. **スキル固有レビュー観点**を検証する
 4. 判定結果を出力する
 
@@ -193,7 +195,7 @@ ITテスト設計のスコープ・テスト対象・不明点を整理し、人
 
 ITテストケース設計完了後、以下の順序で進める（フロー図は「スキップ禁止」セクション参照）:
 
-1. `unit-test-designer` — ユニットテストケース設計
-2. `test-coverage-checker` — カバレッジ検証（90%以上）
-3. `*-test-logic-designer` — 各レベルのテストロジック設計
+1. `test-coverage-checker` — カバレッジ検証（90%以上）
+2. `*-test-logic-designer` — 各レベルのテストロジック設計
+3. `implementation-readiness-checker` — 実装準備の自動検証
 4. `story-implementor` — TDD実装（Unit → IT → E2E）

package/skills/it-test-logic-designer/SKILL.md

@@ -14,7 +14,7 @@ ITテストケース設計（`it_test_design.md`）を元に、Vitest実装ロ
 
 ```
 テストケース設計フェーズ
-  unit-test-designer → it-test-designer → scenario-test-designer
+  scenario-test-designer → uiux-designer → unit-test-designer → it-test-designer
                           ↓
               test-coverage-checker
                           ↓
@@ -27,7 +27,7 @@ ITテストケース設計（`it_test_design.md`）を元に、Vitest実装ロ
   scenario-test-logic-designer
                           ↓
 TDD実装フェーズ
-  story-implementor
+  implementation-readiness-checker → story-implementor
 ```
 
 ## 前提条件チェック
@@ -38,10 +38,12 @@ TDD実装フェーズ
 
 ### 推奨インプット（あれば参照）
 - **カバレッジレポート** — `docs/product/construction/{unit}/coverage_report.md`
-- **既存ITテスト** — `backend/test/integration/**/*.test.ts`（パターン参考）
-- **テスト規約** — `docs/principles/testing-rules.md`
+- **既存ITテスト** — 対象プロジェクトの構成（package.json scripts, vitest 設定, `phasegate.config.json` の paths）からテスト配置を特定してパターン参考にする。例（モノレポ構成の場合）: `backend/test/integration/**/*.test.ts`
+- **テスト規約** — `docs/principles/testing-rules.md`（consumer プロジェクトでは `node_modules/phasegate/docs/principles/testing-rules.md`、phasegate リポジトリ自体では `docs/principles/testing-rules.md` を参照）
 - **ストーリー固有論理設計** — `docs/inception/{unit}/{story_id}/logical_design.md`
 
+> **設計文書パスの注記:** 本スキルが扱う `docs/product/construction/{unit}/...` / `docs/inception/...` パスは既定値。consumer が `phasegate.config.json` の paths 設定を上書きしている場合はそちらに従う。
+
 ---
 
 ## ⚠️ 上位レイヤー存在チェック
@@ -72,7 +74,7 @@ TDD実装フェーズ
 
 **このスキルは3フェーズで実行する。**
 - **Phase 1（計画）**: Opus がスコープ・方針・不明点を整理し、人間の承認を得る
-- **Phase 2（実行）**: Sonnet 4.6 に委任して成果物を生成する（`npx phasegate delegate-sonnet` 経由）
+- **Phase 2（実行）**: 委任先モデルに委任して成果物を生成する（`npx phasegate delegate-sonnet` 経由）
 - **Phase 3（レビュー）**: Opus が成果物を検証し、問題があれば直接修正する
 
 **Phase 1/2/3を同時に実行してはならない。モデルルーティングの詳細は `docs/principles/model-routing.md` を参照。**
@@ -105,7 +107,7 @@ TDD実装フェーズ
 | `{controller}.test.ts` | {Controller名} | X |
 
 ## 3. DB/モック戦略
-- テストDB: ローカルSupabase使用
+- テストDB: プロジェクトが採用する DB/BaaS のテスト用インスタンス（例: ローカル Supabase）
 - トランザクション制御: テスト毎にクリーンアップ
 - モック対象: 外部API（例: ○○）
 
@@ -212,11 +214,11 @@ Repositoryテストでは、`getTestClient()` でDBに直接クエリし永続
 ## Phase 3: レビュー（Opus review）
 
 ### 実行主体
-メインセッション（Opus 4.6）が実行する。Sonnetへの再委任は行わない。
+メインセッション（model-routing.md の Architect ロール）が実行する。Sonnetへの再委任は行わない。
 
 ### レビュー手順
 1. Sonnetが出力したファイルを読み込む
-2. `docs/principles/model-routing.md` のレビュー観点 R1〜R7 に沿って検証する
+2. `docs/principles/model-routing.md` の「レビュー観点」節に沿って検証する
 3. **スキル固有レビュー観点**を検証する
 4. 判定結果を出力する
 
@@ -253,7 +255,7 @@ Phase 2 で設計する IT テストファイル（`*.test.ts` / `*.it.test.ts`
 - **テストコードは生成しない**（設計文書のみ）— 実装は `story-implementor` スキル（codex-delegator経由、またはメインセッションで直接実行）が行う
 - 疑似コードは実装の指針となる詳細レベルで記載する
 - TDDの「RED」フェーズで正しく失敗するテストを設計する
-- 既存のテストパターン（`backend/test/integration/**/*.test.ts`）を参照してスタイルを統一する
+- 既存のテストパターンを参照してスタイルを統一する（テスト配置は対象プロジェクトの構成から特定する。例（モノレポ構成の場合）: `backend/test/integration/**/*.test.ts`）
 - シードデータはテスト間で独立させ、相互干渉を防ぐ
 
 ---

package/skills/it-test-logic-designer/references/repository-test-patterns.md

@@ -3,10 +3,14 @@
 本ファイルは `it-test-logic-designer` スキルで使用するRepositoryレイヤーのテストテンプレート集。
 シードデータ設計・トランザクション・クリーンアップ戦略を含む。
 
+> **配置パス・DB クライアント・実行コマンドについて:** 以下のテスト配置ディレクトリ（`backend/test/seeds/` 等）・テスト実行コマンドは対象プロジェクトの構成（`package.json` scripts, vitest 設定, `phasegate.config.json` の paths）から特定すること。`getTestClient` / `SupabaseClient` / `supabase-test-helper.js` はプロジェクトが採用する DB/BaaS のテスト用ヘルパーに読み替える（以下は Supabase プロジェクト向けの実装例）。テンプレート構造自体はそのまま流用してよい。
+
 ---
 
 ## テストヘルパーのインポート
 
+以下は例（Supabase プロジェクトの場合）。DB/BaaS ヘルパーはプロジェクトの採用技術に読み替える。
+
 ```typescript
 import { target, context } from '../../helpers/common-helper.js';
 import { getTestClient, cleanupTestData } from '../../helpers/supabase-test-helper.js';
@@ -15,7 +19,8 @@ import { getTestClient, cleanupTestData } from '../../helpers/supabase-test-help
 ## シードデータ設計テンプレート
 
 ```typescript
-// backend/test/seeds/{context}/{seed-name}.ts
+// 例（モノレポ構成の場合）: backend/test/seeds/{context}/{seed-name}.ts
+// SupabaseClient 型はプロジェクトが採用する DB/BaaS のクライアント型に読み替える
 
 export const {SEED_NAME}_SEED = {
   // テストデータ定義
@@ -194,6 +199,8 @@ expect(row).not.toBeNull();
 
 ## テスト実行コマンド
 
+実行コマンドは対象プロジェクトの構成（`package.json` scripts, vitest 設定, `phasegate.config.json` の paths）から特定する。以下は例（pnpm モノレポ構成の場合）。
+
 ```bash
 # 全ITテスト実行
 pnpm --filter backend test:integration

package/skills/logical-designer/SKILL.md

@@ -22,7 +22,7 @@ Unit単位でアーキテクチャの各層（DB → ドメイン → ユース
 ## Pre-flight check (BLOCKING)
 
 Before generating any plan, verify `docs/inception/{unit}/WI-XXX/description.md` exists.
-If not, halt and ask the user to create the WI first, or offer to run `phasegate scaffold-wi <unit> <story|issue|chore>`.
+If not, halt and ask the user to create the WI first, or offer to run `phasegate scaffold-wi <unit|_cross> <story|issue|fix|refactor|chore>`.
 
 ### 必須インプット（存在しなければ`[Question]`で提供を要求）
 
@@ -44,7 +44,7 @@ If not, halt and ask the user to create the WI first, or offer to run `phasegate
 
 ## ⚠️ 上位レイヤー存在チェック
 
-**このスキルは AIDLC Step 5「論理設計」に対応します。実行前に上位設計の存在を確認してください。**
+**このスキルは AIDLC Step 2.2「論理設計」に対応します。実行前に上位設計の存在を確認してください。**
 
 ### 依存する上位設計文書
 
@@ -103,6 +103,8 @@ If not, halt and ask the user to create the WI first, or offer to run `phasegate
 ### 出力ファイル
 `docs/inception/{unit}/WI-XXX/logical_design_plan.md`
 
+> **パス注記**: 本スキルが扱う設計文書パス（`docs/inception/...` / `docs/product/construction/...`）は既定値であり、consumer が `phasegate.config.json` の `paths` 設定で上書きしている場合はそちらが優先される。
+
 ### 計画ファイルの構成
 
 ```markdown
@@ -187,7 +189,7 @@ If not, halt and ask the user to create the WI first, or offer to run `phasegate
 
 ## 🔗 成果物のトレーサビリティメタデータ（必須）
 
-Phase 2 で生成する設計文書には、以下 2 種類のメタデータを emit する。`MetadataValidator.validateDesignDocument` が検証対象とし、ISSUE-008 Phase B-2/B-3 完了後は `npx phasegate validate-metadata` / pre-commit で自動チェックされる。
+Phase 2 で生成する設計文書には、以下 2 種類のメタデータを emit する。これらのメタデータは `npx phasegate validate-metadata` / pre-commit で自動チェックされる。
 
 ### 1. YAML frontmatter（新規作成時）
 

package/skills/mock-designer/SKILL.md

@@ -10,6 +10,8 @@ languages: [typescript]
 
 ユーザーストーリーからUIモックアップを作成するスキル。AIDLCプロセスのStep 2「mock（モック）を作る」に対応。
 
+このスキルは UI モックアップ（HTML）作成であり、テストコードのモック/スタブ設計ではない（それらは各 test-logic-designer のモック戦略節を参照）。
+
 ## 前提条件チェック
 
 ### 必須インプット（存在しなければ`[Question]`で提供を要求）
@@ -17,9 +19,11 @@ languages: [typescript]
 
 ### 任意インプット（あれば参照）
 - **プロダクト概要** — `docs/product/product_overview.md`（全体像・ユビキタス言語）
-- **既存モック** — `/mock` フォルダ内の既存HTMLファイル
+- **既存モック** — `mock/` フォルダ内の既存HTMLファイル
 - **デザインシステム** — 色・フォント・コンポーネントの規約
 
+> **設計文書パスの注記:** 上記および本スキルが扱う `docs/product/...` / `docs/inception/...` パスは既定値。consumer が `phasegate.config.json` の paths 設定を上書きしている場合はそちらに従う。
+
 ---
 
 ## ⚠️ 上位レイヤー存在チェック
@@ -65,10 +69,10 @@ languages: [typescript]
 
 **このスキルは3フェーズで実行する。**
 - **Phase 1（計画）**: Opus がスコープ・方針・不明点を整理し、人間の承認を得る
-- **Phase 2（実行）**: Sonnet 4.6 に委任して成果物を生成する（`npx phasegate delegate-sonnet` 経由）
+- **Phase 2（実行）**: 委任先モデルに委任して成果物を生成する（`npx phasegate delegate-sonnet` 経由）
 - **Phase 3（レビュー）**: Opus が成果物を検証し、問題があれば直接修正する
 
-**Phase 1/2/3を同時に実行してはならない。モデルルーティングの詳細は `docs/principles/model-routing.md` を参照。**
+**Phase 1/2/3を同時に実行してはならない。モデルルーティングの詳細は `docs/principles/model-routing.md`（consumer プロジェクトでは `node_modules/phasegate/docs/principles/model-routing.md`、phasegate リポジトリ自体では `docs/principles/model-routing.md`）を参照。**
 
 ---
 
@@ -153,7 +157,7 @@ graph LR
 
 | 種別 | 配置先 |
 |------|--------|
-| 成果物 | `/mock/{画面名}.html` |
+| 成果物 | `mock/{画面名}.html`（プロジェクトルート相対） |
 
 ---
 
@@ -162,11 +166,11 @@ graph LR
 ## Phase 3: レビュー（Opus review）
 
 ### 実行主体
-メインセッション（Opus 4.6）が実行する。Sonnetへの再委任は行わない。
+メインセッション（model-routing.md の Architect ロール）が実行する。Sonnetへの再委任は行わない。
 
 ### レビュー手順
 1. Sonnetが出力したファイルを読み込む
-2. `docs/principles/model-routing.md` のレビュー観点 R1〜R7 に沿って検証する
+2. `docs/principles/model-routing.md` の「レビュー観点」節に沿って検証する
 3. **スキル固有レビュー観点**を検証する
 4. 判定結果を出力する
 

package/skills/phasegate-config-doctor/SKILL.md

@@ -1,13 +1,23 @@
 ---
 name: phasegate-config-doctor
+kind: advisory
 description: 現在の phasegate.config.json を schema + プロジェクト検出結果と突き合わせて改善提案する診断スキル。read-only Q&A の phasegate-toolkit-guide とは異なり、設定変更を伴う相談に応える。使用タイミング:「phasegate のセットアップを最適化して」「architecture preset 入ってないけど何が適切？」「Quick Mode の relaxedGates に推奨設定教えて」「baseline 有効化しても大丈夫？」「monorepo に対して targetDirs / formatter が正しく検出されてる？」「v2 schema warning が出る、何を直せばいい？」など、現状 config の診断と改善 diff 提案を求める質問。
 languages: [typescript]
 ---
 
 # Phasegate Config Doctor
 
+## 目的
+
 現在の `phasegate.config.json` を診断し、改善案を **diff 形式** でユーザーに提示する skill。
 
+## 入力
+
+診断対象として以下を Read する（詳細は「診断プロセス Step 1」の一覧参照）:
+
+- `phasegate.config.json`（診断対象）、`package.json` / `pnpm-workspace.yaml` / `lerna.json`（workspace・formatter 検出）
+- `.claude/scripts/hook-config.json`、`.phasegate/manifest.json`、doctor report、`.claude/settings.json` / `.codex/hooks.json`、`.husky/*`、`.github/workflows/*`、`AGENTS.md` / `CLAUDE.md`
+
 ## このスキルが解決する問題
 
 phasegate を導入した直後の config は単純な default で、実プロジェクトの構造 (monorepo / formatter 選定 / architecture style / Quick Mode の運用方針) に最適化されていない。さらに setup lifecycle は `phasegate.config.json` だけでは完結せず、manifest、hook JSON、Husky、CI、skill link、doctor finding を合わせて読む必要がある。AI が schema や setup contract を知らずに勘で書き換えると壊れるため、**schema + 検出結果に基づいた決定的提案** が必要。<!-- @work-item-id WI-153 -->
@@ -84,7 +94,7 @@ product-architect で Unit を作り、いくつかの logical_design を書い
   - DDD タクティカル (`entities/aggregates/repositories`) あり → `strict-ddd` 推奨
   - `core/`, `adapters/`, `ports/` パターン → `hexagonal` 推奨
   - 上記いずれも無し → ユーザーに確認 + `custom` 提案
-- 検出根拠を必ず提示 (例:「`scripts/harness/{domain,application,infrastructure,presentation}` を検出 → `clean` 推奨」)
+- 検出根拠を必ず提示 (例:「`src/{domain,application,infrastructure,presentation}` を検出 → `clean` 推奨」。phasegate 自リポジトリ（dogfood）では `scripts/harness/{domain,application,infrastructure,presentation}`)
 - `architecture.preset = "custom"` だが `architecture.layers` 未定義 → WARN: schema validator で reject される
 
 #### 観点 2: project.preset (防御プリセット)
@@ -171,7 +181,7 @@ product-architect で Unit を作り、いくつかの logical_design を書い
 ### 💡 改善提案 (SUGGEST)
 
 #### S1: `architecture.preset` 未指定 → "clean" を推奨
-- 検出根拠: `scripts/harness/{domain,application,infrastructure,presentation}` の 4 ディレクトリが存在
+- 検出根拠: `src/{domain,application,infrastructure,presentation}` の 4 ディレクトリが存在（phasegate 自リポジトリ（dogfood）では `scripts/harness/{domain,application,infrastructure,presentation}`）
 - 修正案:
   ```json-diff
    {

package/skills/phasegate-toolkit-guide/SKILL.md

@@ -1,11 +1,14 @@
 ---
 name: phasegate-toolkit-guide
+kind: advisory
 description: phasegate ツールキット自体に関する Q&A スキル。ユーザーが phasegate の概念 (L0-L4 レイヤーモデル / 防御プリセット / アーキプリセット / Quick Mode と Full Mode / Hook 仕様 / config 全般) について質問したとき、対応する canonical doc を読み込んでから回答する。使用タイミング:「phasegate の L1 と L2 の違いは？」「Quick Mode で許可されるカテゴリを増やしたい」「architecture.preset の使い分けは？」「phasegate の hook って何が動いている？」「phasegate.config.json の relaxedGates は何のため？」など phasegate ツールキット内部の仕様・設定を尋ねる質問。
 languages: [typescript]
 ---
 
 # Phasegate Toolkit Guide
 
+## 目的
+
 phasegate ツールキット自体の概念・仕様・設定について、ユーザーの質問に正確に答えるための skill。
 
 ## このスキルが解決する問題