phasegate 0.183.0 → 0.191.0

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/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: |
   ケント・ベック + マーティン・ファウラー + アンクル・ボブ + エリック・エヴァンスの視点を統合したエンジニアリング思考フレームワーク。
   以下の場面で使用:

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

@@ -29,10 +29,10 @@ 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` を参照する）。**
 
 ---
 
@@ -98,6 +98,8 @@ 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]セクション必須**: 不明点や確認事項をまとめ、ユーザーからのフィードバックを受け取れるようにする。
 
 ---
@@ -142,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
@@ -169,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,5 +1,6 @@
 ---
 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]
 ---
@@ -93,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 (防御プリセット)
@@ -180,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,5 +1,6 @@
 ---
 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]
 ---

package/skills/pointer-validator/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: pointer-validator
+kind: advisory
 description: 設計文書内のファイルポインタ（相対パス参照）の有効性を検証するスキル（L4バリデータ拡張）。`phasegate validate-pointers` CLIを使い、ドキュメント内で参照されているファイルパスが実際に存在するかチェックする。使用タイミング: 「ドキュメントのリンク切れを確認して」「ポインタ検証を実行して」「broken pointer を探して」「設計文書の参照が正しいか確認して」など。
 model: sonnet
 review: opus

package/skills/quick-implementor/SKILL.md

@@ -94,7 +94,7 @@ Quick Mode下での軽微変更実装スキル。story-implementorの緩和版
 ### Step 4: 検証
 
 ```bash
-pnpm test  # 全テスト グリーンを確認
+npm test  # 全テスト グリーンを確認（プロジェクトのテストコマンド。pnpm/yarn 等は適宜読み替える）
 ```
 
 ### 出力（Step 5: コミット）

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

@@ -18,9 +18,11 @@ languages: [typescript]
 
 ### 任意インプット（あれば参照）
 - **UIモック** — `/mock/*.html`（画面フローの参考）
-- **テスト規約** — `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` を参照）
 - **既存シナリオテスト** — 既存パターンの参考
 
+> **設計文書パスの注記:** 上記および本スキルが扱う `docs/product/construction/{unit}/...` / `docs/inception/...` パスは既定値。consumer が `phasegate.config.json` の paths 設定を上書きしている場合はそちらに従う。
+
 ---
 
 ## ⛔ スキップ禁止
@@ -36,14 +38,18 @@ languages: [typescript]
 ```
 scenario-test-designer（本スキル）← テストケース設計の最初
         ↓
-it-test-designer
+uiux-designer ← シナリオテスト設計を入力にUI/UX定義
         ↓
 unit-test-designer
         ↓
+it-test-designer
+        ↓
 test-coverage-checker ← カバレッジ検証
         ↓
 テストロジック設計
         ↓
+implementation-readiness-checker
+        ↓
 story-implementor ← TDD実装
 ```
 
@@ -96,7 +102,7 @@ story-implementor ← 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` を参照。**
@@ -168,11 +174,11 @@ story-implementor ← TDD実装
 ## 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. 判定結果を出力する
 
@@ -208,37 +214,44 @@ story-implementor ← TDD実装
 
 ## 次ステップへの誘導
 
-シナリオテストケース設計完了後、以下の順序で進めてください：
+シナリオテストケース設計はテストケース設計フェーズの最初に位置づけられる（成果物 `scenario_test_design.md` は `uiux-designer` の必須インプット）。完了後、以下の順序で進めてください：
 
-### テストケース設計フェーズ（続き）
-1. **ITテストケース設計** — UseCase/Repository/Controllerのテストケース
-   - `it-test-designer` スキルを実行
+### UI/UX設計フェーズ
+1. **UI/UX定義** — シナリオテスト設計・論理設計・既存UIを加味した最終UI/UX策定
+   - `uiux-designer` スキルを実行
 
+### テストケース設計フェーズ（続き）
 2. **ユニットテストケース設計** — Entity/ValueObjectのテストケース
    - `unit-test-designer` スキルを実行
+3. **ITテストケース設計** — UseCase/Repository/Controllerのテストケース
+   - `it-test-designer` スキルを実行
 
 ### カバレッジ検証フェーズ
-3. **テストカバレッジ検証** — テストケース設計の網羅性チェック
+4. **テストカバレッジ検証** — テストケース設計の網羅性チェック
    - `test-coverage-checker` スキルを実行
    - カバレッジ90%以上を確認
 
 ### テストロジック設計フェーズ
-4. **テストロジック設計** — 各レベルの実装ロジック
+5. **テストロジック設計** — 各レベルの実装ロジック
    - `unit-test-logic-designer` → `it-test-logic-designer` → `scenario-test-logic-designer`
 
 ### TDD実装フェーズ
-5. **TDD実装** — Unit → IT → E2E の順序で実装
-   - `story-implementor` スキルを実行
+6. **実装準備検証・TDD実装** — Unit → IT → E2E の順序で実装
+   - `implementation-readiness-checker` → `story-implementor` スキルを実行
 
 **推奨フロー図:**
 ```
 scenario-test-designer（本スキル）
         ↓
-it-test-designer → unit-test-designer
+uiux-designer
+        ↓
+unit-test-designer → it-test-designer
         ↓
 test-coverage-checker
         ↓
 *-test-logic-designer（各レベル）
         ↓
+implementation-readiness-checker
+        ↓
 story-implementor
 ```