phasegate 0.181.0 → 0.191.0

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
@@ -8,9 +9,16 @@ languages: [typescript]
 
 # Pointer Validator
 
+## 目的
+
 設計文書内のファイルパス参照（ポインタ）の有効性を検証するスキル。
 `phasegate validate-pointers` CLIをラップし、broken pointer を検出・修正案を提示する。
 
+## 入力
+
+- 対象ディレクトリ: `--dir <path>`（デフォルト `docs/`）配下の設計文書
+- 検証対象ポインタ: Markdown `[text](path)` リンク / `@file:` `@ref:` / `filePath:` フィールドのパス参照（`http(s)://` URL は対象外）
+
 ## CLIの動作
 
 `p2:validate-pointers` は以下を検出する:

package/skills/quick-implementor/SKILL.md

@@ -6,11 +6,13 @@ languages: [typescript]
 
 # Quick Implementor
 
+## 目的
+
 Quick Mode下での軽微変更実装スキル。story-implementorの緩和版として、フルハーネスが過剰な変更に対して最低限の品質を維持しつつ高速に実装を行う。
 
 ## 適用条件チェック（必須）
 
-### 適用可能な変更カテゴリ
+### 入力（適用可能な変更カテゴリ）
 
 | カテゴリ | 例 |
 |---------|---|
@@ -33,7 +35,7 @@ Quick Mode下での軽微変更実装スキル。story-implementorの緩和版
 
 `type: fix | chore` でも、API契約変更・新ドメインモデル追加・レイヤー構造変更・複数Unitにまたがる実装変更が見えた場合は、通常の除外ルールを優先して `story-implementor` に切り替える。
 
-### 適用除外（フルハーネス必須 → story-implementor を使用）
+### 前提条件（適用除外・フルハーネス必須 → story-implementor を使用）
 
 - 新機能追加
 - API契約変更（Port/Adapter インターフェース変更）
@@ -55,7 +57,7 @@ Quick Mode下での軽微変更実装スキル。story-implementorの緩和版
 
 ---
 
-## ワークフロー
+## 実行フロー
 
 ### Step 1: 適用条件の判定
 
@@ -92,10 +94,10 @@ Quick Mode下での軽微変更実装スキル。story-implementorの緩和版
 ### Step 4: 検証
 
 ```bash
-pnpm test  # 全テスト グリーンを確認
+npm test  # 全テスト グリーンを確認（プロジェクトのテストコマンド。pnpm/yarn 等は適宜読み替える）
 ```
 
-### Step 5: コミット
+### 出力（Step 5: コミット）
 
 Atomic commit で変更をコミットする。コミットメッセージに `[quick]` プレフィックスを付与。作業対象WIがある場合は `Work-Item: WI-XXX` trailer を必ず含める。
 

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
 ```

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

@@ -14,7 +14,7 @@ languages: [typescript]
 
 ```
 テストケース設計フェーズ
-  unit-test-designer → it-test-designer → scenario-test-designer
+  scenario-test-designer → uiux-designer → unit-test-designer → it-test-designer
                           ↓
               test-coverage-checker
                           ↓
@@ -25,7 +25,7 @@ languages: [typescript]
 └────────────────────────────────────────────┘
                           ↓
 TDD実装フェーズ
-  story-implementor
+  implementation-readiness-checker → story-implementor
 ```
 
 ## 前提条件チェック
@@ -36,9 +36,11 @@ TDD実装フェーズ
 
 ### 推奨インプット（あれば参照）
 - **カバレッジレポート** — `docs/product/construction/{unit}/coverage_report.md`
-- **既存シナリオテスト** — `e2e/tests/**/*.spec.ts`（パターン参考）
+- **既存シナリオテスト** — 対象プロジェクトの構成（package.json scripts, playwright 設定, `phasegate.config.json` の paths）からテスト配置を特定してパターン参考にする。例（モノレポ構成の場合）: `e2e/tests/**/*.spec.ts`
 - **UIUX設計** — `docs/inception/{unit}/{story_id}/uiux_design.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` を参照）
+
+> **設計文書パスの注記:** 本スキルが扱う `docs/product/construction/{unit}/...` / `docs/inception/...` パスは既定値。consumer が `phasegate.config.json` の paths 設定を上書きしている場合はそちらに従う。
 
 ---
 
@@ -63,7 +65,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` を参照。**
@@ -184,11 +186,11 @@ 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. 判定結果を出力する
 
@@ -225,7 +227,7 @@ Phase 2 で設計するシナリオ / E2E テストファイル（`*.spec.ts` /
 - **テストコードは生成しない**（設計文書のみ）— 実装は `story-implementor` スキル（codex-delegator経由、またはメインセッションで直接実行）が行う
 - 疑似コードは実装の指針となる詳細レベルで記載する
 - TDDの「RED」フェーズで正しく失敗するテストを設計する
-- 既存のテストパターン（`e2e/tests/**/*.spec.ts`）を参照してスタイルを統一する
+- 既存のテストパターンを参照してスタイルを統一する（テスト配置は対象プロジェクトの構成から特定する。例（モノレポ構成の場合）: `e2e/tests/**/*.spec.ts`）
 - クリーンアップを確実に行い、テスト間の独立性を保つ
 
 ---

package/skills/scenario-test-logic-designer/references/msw-patterns.md

@@ -2,12 +2,14 @@
 
 scenario-test-logic-designer スキルで使用する MSW (Mock Service Worker) パターンのリファレンス。
 
+> **配置パスについて:** 以下のモック配置ディレクトリ（`e2e/mocks/` 等）は対象プロジェクトの構成（`package.json` scripts, playwright 設定, `phasegate.config.json` の paths）から特定すること。本ファイルの具体値は例（モノレポ構成の場合）であり、テンプレート構造自体はそのまま流用してよい。
+
 ---
 
 ## ハンドラー テンプレート
 
 ```typescript
-// e2e/mocks/{context}/handlers.ts
+// 例（モノレポ構成の場合）: e2e/mocks/{context}/handlers.ts
 import { http, HttpResponse } from 'msw';
 
 export const {context}Handlers = [

package/skills/scenario-test-logic-designer/references/playwright-patterns.md

@@ -186,7 +186,7 @@ export const {SEED_NAME}_SEED = {
 };
 
 export async function seed{SeedName}(): Promise<void> {
-  // Supabase CLIまたはAPIでデータ投入
+  // プロジェクトが採用する DB/BaaS のツール・APIでデータ投入（例: Supabase CLI/API）
 }
 
 export async function cleanup{SeedName}(): Promise<void> {
@@ -222,6 +222,8 @@ export async function create{Entity}(page: Page, data: {Entity}Data): Promise<st
 
 ## 8. テスト実行コマンド
 
+実行コマンドは対象プロジェクトの構成（`package.json` scripts, playwright 設定, `phasegate.config.json` の paths）から特定する。以下は例（pnpm モノレポ構成の場合）。
+
 ```bash
 # 全シナリオテスト実行
 pnpm --filter e2e test

package/skills/skill-creator/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: skill-creator
+kind: advisory
 description: Create or update AgentSkills. Use when designing, structuring, or packaging skills with scripts, references, and assets.
 model: opus
 languages: [typescript]
@@ -7,8 +8,12 @@ languages: [typescript]
 
 # Skill Creator
 
+## Purpose
+
 This skill provides guidance for creating effective skills.
 
+> **前提・スコープ注記**: phasegate プロジェクトのスキル規約（frontmatter の `model:` / `review:` / `languages:`、正規見出し、日本語テスト規約）が優先される。本スキル内で説明する frontmatter 制限（`name` / `description` のみ）は Anthropic の汎用配布形式の記述であり、phasegate 規約と衝突する場合は phasegate 規約に従うこと。
+
 ## About Skills
 
 Skills are modular, self-contained packages that extend Codex's capabilities by providing
@@ -299,12 +304,10 @@ When editing the (newly-generated or existing) skill, remember that the skill is
 
 #### Learn Proven Design Patterns
 
-Consult these helpful guides based on your skill's needs:
-
-- **Multi-step processes**: See references/workflows.md for sequential workflows and conditional logic
-- **Specific output formats or quality standards**: See references/output-patterns.md for template and example patterns
+Apply these proven design patterns based on your skill's needs:
 
-These files contain established best practices for effective skill design.
+- **Multi-step processes**: Describe the workflow as an explicit ordered sequence of steps, and use conditional branches (e.g. "if X, do Y; otherwise Z") so the executing instance always knows the next action.
+- **Specific output formats or quality standards**: Embed a concrete template or worked example directly in the skill body and state the acceptance criteria, so outputs are reproducible and verifiable.
 
 #### Start with Reusable Skill Contents
 

package/skills/story-implementor/SKILL.md

@@ -38,6 +38,8 @@ languages: [typescript]
 | `docs/inception/{unit}/{story_id}/scenario_test_design.md` | 📋 推奨 | シナリオテスト設計の存在を確認 |
 | `docs/product/construction/{unit}/uiux_design.md` | 📋 推奨 | UIUX設計の存在を確認（フロントエンドがある場合） |
 
+> **パス注記**: 上表の設計文書パス（`docs/product/construction/...` / `docs/inception/...` / `docs/product/environment_contract.md`）は既定値であり、consumer が `phasegate.config.json` の `paths` 設定で上書きしている場合はそちらが優先される。
+
 ### テスト設計・ロジック設計の事前チェック
 
 **TDD実装の前に、テスト設計が完了していることを確認してください。テスト設計が不足している場合、テスト漏れのリスクがあります。**

package/skills/story-mapper/SKILL.md

@@ -66,10 +66,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` を参照する）。**
 
 ---
 
@@ -191,11 +191,11 @@ MVPスコープの方針・分類基準・不明点を整理し、人間の承
 ## 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/story-writer/SKILL.md

@@ -15,7 +15,7 @@ languages: [typescript]
 ## 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]`で提供を要求）
 - **要求文書** — 何を作るかを記述した文書。形式は問わない（議事録、要件メモ、口頭要約のテキスト等）
@@ -30,10 +30,10 @@ If not, halt and ask the user to create the WI first, or offer to run `phasegate
 
 **このスキルは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` を参照する）。**
 
 ---
 
@@ -120,11 +120,11 @@ If not, halt and ask the user to create the WI first, or offer to run `phasegate
 ## 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/test-coverage-checker/SKILL.md

@@ -14,7 +14,7 @@ languages: [typescript]
 
 ```
 テストケース設計フェーズ
-  scenario-test-designer → it-test-designer → unit-test-designer
+  scenario-test-designer → uiux-designer → unit-test-designer → it-test-designer
                           ↓
               ┌───────────────────────────┐
               │  test-coverage-checker    │ ← ここで実行
@@ -25,7 +25,7 @@ languages: [typescript]
   *-test-logic-designer（各レベル）
                           ↓
 TDD実装フェーズ
-  story-implementor
+  implementation-readiness-checker → story-implementor
 ```
 
 ## 前提条件チェック
@@ -233,7 +233,7 @@ UIUX設計で定義された全画面がシナリオテストでカバーされ
 ## Phase 3: レビュー（Opus review）
 
 ### 実行主体
-メインセッション（Opus 4.6）が実行する。Sonnetへの再委任は行わない。
+メインセッション（model-routing.md の Architect ロール）が実行する。Sonnetへの再委任は行わない。
 
 ### レビュー手順
 1. Sonnetが出力したファイルを読み込む
@@ -357,9 +357,7 @@ UIUX設計で定義された全画面がシナリオテストでカバーされ
 3. **`test-coverage-checker`** → カバレッジ再検証（本スキル）
 4. **`unit-test-logic-designer`** → ユニットテストロジック設計
 5. **`it-test-logic-designer`** → ITテストロジック設計
-6. **TDDエージェント** → テスト実装（RED→GREEN）
-   - `model-tdd-executor` → ユニットテスト
-   - `it-tdd-executor` → ITテスト
+6. **`story-implementor`** → テスト実装（RED→GREEN）を含むTDD実装
 
 ### 注意事項
 

package/skills/uiux-designer/SKILL.md

@@ -16,7 +16,7 @@ languages: [typescript]
 - **論理設計** — `docs/product/construction/{unit}/logical_design.md` または ストーリー固有論理設計
 
 ### 任意インプット（あれば参照）
-- **UIモック** — `/mock/*.html`（初期デザイン意図の参考）
+- **UIモック** — プロジェクトルート相対の `mock/` ディレクトリ配下の `*.html`（mock-designer の出力先。初期デザイン意図の参考）
 - **既存UI実装** — 関連する既存画面コンポーネント
 - **既存UIUX設計** — `docs/product/construction/{unit}/uiux_design.md`（更新時に参照）
 - **デザインシステム** — 色・フォント・コンポーネント規約
@@ -34,7 +34,9 @@ languages: [typescript]
 |---------|------|------------|
 | `docs/inception/{unit}/{story_id}/scenario_test_design.md` | ✅ 必須 | シナリオテスト設計の存在を確認 |
 | `docs/product/construction/{unit}/logical_design.md` | ✅ 必須 | 論理設計の存在を確認 |
-| `/mock/*.html` | 📋 推奨 | 初期モックの存在を確認 |
+| `mock/*.html`（プロジェクトルート相対、mock-designer の出力先） | 📋 推奨 | 初期モックの存在を確認 |
+
+> **パス注記**: 上表の設計文書パス（`docs/inception/...` / `docs/product/construction/...`）は既定値であり、consumer が `phasegate.config.json` の `paths` 設定で上書きしている場合はそちらが優先される。
 
 ### 上位設計が存在しない場合のアクション
 

package/skills/unit-designer/SKILL.md

@@ -24,7 +24,7 @@ languages: [typescript]
 
 ## ⚠️ 上位レイヤー存在チェック
 
-**このスキルは AIDLC Step 3「Unitの設計」に対応します。実行前に上位設計の存在を確認してください。**
+**このスキルは AIDLC Step 1.2「Unitの設計」に対応します。実行前に上位設計の存在を確認してください。**
 
 ### 依存する上位設計文書
 
@@ -65,10 +65,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` を参照する）。**
 
 ---
 
@@ -80,6 +80,8 @@ Unit分割の方針・グルーピングの根拠・不明点を整理し、人
 ### 出力ファイル
 `docs/inception/_shared/unit_design_plan.md`
 
+> **パス注記**: 本スキルが扱う設計文書パス（`docs/inception/...` / `docs/product/units/...`）は既定値であり、consumer が `phasegate.config.json` の `paths` 設定で上書きしている場合はそちらが優先される。
+
 ### 計画ファイルの構成
 
 ```markdown
@@ -157,7 +159,7 @@ Unit分割の方針・グルーピングの根拠・不明点を整理し、人
 
 ## 🔗 成果物のトレーサビリティメタデータ（必須）
 
-Phase 2 で生成する Unit 定義文書には、以下 2 種類のメタデータを emit する。`MetadataValidator.validateDesignDocument` が検証対象とし、ISSUE-008 Phase B-2/B-3 完了後は `npx phasegate validate-metadata` / pre-commit で自動チェックされる。
+Phase 2 で生成する Unit 定義文書には、以下 2 種類のメタデータを emit する。これらのメタデータは `npx phasegate validate-metadata` / pre-commit で自動チェックされる。
 
 ### 1. YAML frontmatter（新規作成時）
 
@@ -199,11 +201,11 @@ Phase 3 レビューで以下を BLOCK 基準として確認する:
 ## 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/unit-test-designer/SKILL.md

@@ -17,9 +17,11 @@ languages: [typescript]
 
 ### 任意インプット（あれば参照）
 - **論理設計** — `docs/product/construction/{unit}/logical_design.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` を参照）
 - **既存ユニットテスト** — 既存パターンの参考
 
+> **設計文書パスの注記:** 上記および本スキルが扱う `docs/product/construction/{unit}/...` / `docs/inception/...` パスは既定値。consumer が `phasegate.config.json` の paths 設定を上書きしている場合はそちらに従う。
+
 ---
 
 ## ⛔ スキップ禁止
@@ -35,14 +37,18 @@ languages: [typescript]
 ```
 scenario-test-designer
         ↓
-it-test-designer
+uiux-designer
         ↓
 unit-test-designer（本スキル）← ユニットテストケース設計
         ↓
+it-test-designer
+        ↓
 test-coverage-checker ← カバレッジ検証（ここでテストケース設計の網羅性をチェック）
         ↓
 テストロジック設計
         ↓
+implementation-readiness-checker
+        ↓
 story-implementor ← TDD実装
 ```
 
@@ -78,7 +84,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` を参照。**
@@ -150,11 +156,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. 判定結果を出力する
 
@@ -192,34 +198,42 @@ story-implementor ← TDD実装
 
 ユニットテストケース設計完了後、以下の順序で進めてください：
 
+### テストケース設計フェーズ（続き）
+1. **ITテストケース設計** — UseCase/Repository/Controllerのテストケース
+   - `it-test-designer` スキルを実行
+
 ### カバレッジ検証フェーズ
-1. **テストカバレッジ検証** — テストケース設計の網羅性チェック
+2. **テストカバレッジ検証** — テストケース設計の網羅性チェック
    - `test-coverage-checker` スキルを実行
    - 受け入れ基準・ドメインロジック・UseCaseのカバレッジを確認
    - カバレッジ90%以上を目指す
 
 ### テストロジック設計フェーズ
-2. **テストロジック設計** — 各レベルの実装ロジックを詳細設計
+3. **テストロジック設計** — 各レベルの実装ロジックを詳細設計
    - `unit-test-logic-designer` — ユニットテストの疑似コード設計
    - `it-test-logic-designer` — ITテストの疑似コード設計
    - `scenario-test-logic-designer` — シナリオテストの疑似コード設計
 
 ### TDD実装フェーズ
-3. **TDD実装** — Unit → IT → E2E の順序で実装
+4. **実装準備検証** — 実装前提条件の自動検証
+   - `implementation-readiness-checker` スキルを実行
+5. **TDD実装** — Unit → IT → E2E の順序で実装
    - `story-implementor` スキルを実行
 
 **推奨フロー図:**
 ```
-scenario-test-designer
-        ↓
-it-test-designer
+scenario-test-designer → uiux-designer
         ↓
 unit-test-designer（本スキル）
         ↓
+it-test-designer
+        ↓
 test-coverage-checker ← テストケース設計の網羅性チェック
         ↓
 unit-test-logic-designer → it-test-logic-designer → scenario-test-logic-designer
         ↓
+implementation-readiness-checker
+        ↓
 story-implementor ← TDD実装
 ```