phasegate 0.183.0 → 0.212.0

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/uiux-designer/references/uiux-design-template.md

@@ -11,7 +11,7 @@
 
 | 画面名 | パス | 対象ストーリー | 状態 |
 |--------|------|---------------|------|
-| {画面名} | `/path/to/screen` | US-XXX | 実装済/設計中 |
+| {画面名} | `/path/to/screen` | HXX-XX | 実装済/設計中 |
 
 ---
 
@@ -20,7 +20,7 @@
 ### 2.1 {画面名}
 
 #### 対象ストーリー
-- US-XXX: {ストーリー概要}
+- HXX-XX: {ストーリー概要}
 
 #### レイアウト
 ```
@@ -100,6 +100,6 @@ graph LR
 
 | 日付 | ストーリー | 変更内容 |
 |------|-----------|---------|
-| YYYY-MM-DD | US-XXX | 初版作成 |
-| YYYY-MM-DD | US-YYY | {画面名}を追加 |
+| YYYY-MM-DD | HXX-XX | 初版作成 |
+| YYYY-MM-DD | HYY-YY | {画面名}を追加 |
 ```

package/skills/unit-designer/SKILL.md

@@ -16,6 +16,7 @@ languages: [typescript]
 - **ユーザーストーリー一覧** — `docs/product/user_stories.md` またはストーリーが記載された文書
 
 ### 任意インプット（あれば参照）
+- **ユーザーストーリーマッピング（推奨）** — `docs/product/user_story_mapping.md`（S1.5 story-mapper の成果物）。MVP/Post-MVP のスコープ整理と優先順位を提供する。存在すれば Unit グルーピングと構築優先度の判断材料として取り込む
 - **既存の統合契約** — フォーマットに準拠する
 - **技術スタック概要** — 各層の技術選定（Gateway、API Server、DB等）
 - **プロダクト概要** — コアドメインの理解
@@ -24,13 +25,14 @@ languages: [typescript]
 
 ## ⚠️ 上位レイヤー存在チェック
 
-**このスキルは AIDLC Step 3「Unitの設計」に対応します。実行前に上位設計の存在を確認してください。**
+**このスキルは AIDLC Step 1.2「Unitの設計」に対応します。実行前に上位設計の存在を確認してください。**
 
 ### 依存する上位設計文書
 
 | ファイル | 必須 | チェック方法 |
 |---------|------|------------|
 | `docs/product/user_stories.md` | ✅ 必須 | ファイルの存在を確認 |
+| `docs/product/user_story_mapping.md` | 任意（推奨） | 存在すれば読み込み、MVP スコープを Unit グルーピングに反映する。無ければスキップしてよい |
 
 ### 上位設計が存在しない場合のアクション
 
@@ -65,10 +67,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 +82,8 @@ Unit分割の方針・グルーピングの根拠・不明点を整理し、人
 ### 出力ファイル
 `docs/inception/_shared/unit_design_plan.md`
 
+> **パス注記**: 本スキルが扱う設計文書パス（`docs/inception/...` / `docs/product/units/...`）は既定値であり、consumer が `phasegate.config.json` の `paths` 設定で上書きしている場合はそちらが優先される。
+
 ### 計画ファイルの構成
 
 ```markdown
@@ -129,7 +133,7 @@ Unit分割の方針・グルーピングの根拠・不明点を整理し、人
 
 ### ワークフロー
 
-1. **Unit定義の作成** — 各Unitの概要・担当ストーリー・機能要件・データモデル概要・外部依存を定義
+1. **Unit定義の作成** — 各Unitの概要・担当ストーリー・機能要件・データモデル概要・外部依存を定義。`user_story_mapping.md` があれば、その MVP スコープと優先順位を Unit グルーピング・構築順序の判断材料として反映する
 2. **統合契約の作成** — 技術スタック概要、依存関係図、公開APIエンドポイント、共通データフォーマット、認証認可を定義
 3. **マッピング検証** — 全ストーリーがいずれかのUnitに所属していることを確認
 
@@ -157,7 +161,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 +203,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実装
 ```
 

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

@@ -14,7 +14,7 @@ Unitテストケース設計（`unit_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
                           ↓
@@ -25,7 +25,7 @@ Unitテストケース設計（`unit_test_design.md`）を元に、Vitest実装
   it-test-logic-designer → scenario-test-logic-designer
                           ↓
 TDD実装フェーズ
-  story-implementor
+  implementation-readiness-checker → story-implementor
 ```
 
 ## 前提条件チェック
@@ -36,8 +36,10 @@ TDD実装フェーズ
 
 ### 推奨インプット（あれば参照）
 - **カバレッジレポート** — `docs/product/construction/{unit}/coverage_report.md`
-- **既存ユニットテスト** — `backend/test/unit/**/*.test.ts`（パターン参考）
-- **テスト規約** — `docs/principles/testing-rules.md`
+- **既存ユニットテスト** — 対象プロジェクトの構成（package.json scripts, vitest 設定, `phasegate.config.json` の paths）からテスト配置を特定してパターン参考にする。例（モノレポ構成の場合）: `backend/test/unit/**/*.test.ts`
+- **テスト規約** — `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 設定を上書きしている場合はそちらに従う。
 
 ---
 
@@ -61,7 +63,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` を参照。**
@@ -168,11 +170,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. 判定結果を出力する
 
@@ -213,7 +215,7 @@ Phase 2 で設計するテストファイル（`*.test.ts` / `*.spec.ts`）の
 - **テストコードは生成しない**（設計文書のみ）— 実装は `story-implementor` が行う
 - 疑似コードは実装の指針となる詳細レベルで記載する
 - TDDの「RED」フェーズで正しく失敗するテストを設計する
-- 既存のテストパターン（`backend/test/unit/**/*.test.ts`）を参照してスタイルを統一する
+- 既存のテストパターンを参照してスタイルを統一する（テスト配置は対象プロジェクトの構成から特定する。例（モノレポ構成の場合）: `backend/test/unit/**/*.test.ts`）
 
 ---
 

package/skills/unit-test-logic-designer/references/test-patterns.md

@@ -2,12 +2,14 @@
 
 unit-test-logic-designer が出力する `unit_test_logic.md` で使用するテストパターンのリファレンス。
 
+> **配置パス・実行コマンドについて:** 以下に登場するテスト配置ディレクトリ（`backend/test/helpers/` 等）・相対インポートパス・テスト実行コマンドは、対象プロジェクトの構成（`package.json` scripts, vitest 設定, `phasegate.config.json` の paths）から特定すること。本ファイルの具体値は例（モノレポ構成の場合）であり、疑似コードのテンプレート構造自体はそのまま流用してよい。
+
 ---
 
 ## 1. ファクトリ関数パターン
 
 ```typescript
-// backend/test/helpers/{context}-helper.ts
+// 例（モノレポ構成の場合）: backend/test/helpers/{context}-helper.ts
 
 /**
  * {集約名}のテスト用ファクトリ
@@ -24,6 +26,8 @@ export function create{Aggregate}(overrides?: Partial<{Aggregate}Props>): {Aggre
 
 ### 共通ヘルパーのインポート
 
+相対インポートの階層はテストファイルとヘルパーの実配置に依存する。以下は例（モノレポ構成の場合）。
+
 ```typescript
 import { target, context } from '../../../../helpers/common-helper.js';
 ```
@@ -195,6 +199,8 @@ expect(actual).toBe(expected);
 
 ## 7. テスト実行コマンド
 
+実行コマンドは対象プロジェクトの構成（`package.json` scripts, vitest 設定, `phasegate.config.json` の paths）から特定する。以下は例（pnpm モノレポ構成の場合）。
+
 ```bash
 # 全ユニットテスト実行
 pnpm --filter backend test:unit

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

@@ -1,140 +0,0 @@
----
-name: doc-freshness-checker
-description: 設計文書の鮮度チェック（L4バリデータ拡張）。`phasegate check-freshness` CLIを使い、設計文書の最終更新日が閾値を超えていないか、コード変更と設計文書の乖離がないかを検出する。使用タイミング: 「設計文書が古くなっていないか確認して」「ドキュメントの鮮度チェックを実行して」「L4 freshness チェック」「設計とコードの乖離を調べて」など。
-model: sonnet
-review: opus
-languages: [typescript]
----
-
-# Doc Freshness Checker
-
-## 目的
-
-設計文書の鮮度（freshness）を検証し、古くなった文書や対応コードとの乖離を検出するスキル。
-`phasegate check-freshness` CLIをラップし、結果を解釈・対処する。
-
-## 前提条件
-
-- `phasegate.config.json` に `docFreshnessThresholds` が設定されていること（未設定時はデフォルト値使用）
-- git リポジトリ内で実行すること（最終更新日は `git log` で判定）
-
-## 入力
-
-- 対象ディレクトリ: `--dir <path>` または `phasegate.config.json` の `constructionDir`（デフォルト `docs/`）
-- 閾値: `--threshold <days>` または `docFreshnessThresholds`（未設定時はデフォルト30日）
-- git 履歴（最終更新日の判定に使用）
-
----
-
-## ⚠️ 2フェーズ実行ルール
-
-- **Phase 1（計画）**: チェック対象スコープを確認し、人間の承認を得る
-- **Phase 2（実行）**: CLIを実行し、結果を解釈してアクションを提案する
-
-**Phase 1/2を同時に実行してはならない。**
-
----
-
-## Phase 1: チェック計画（plan）
-
-### 出力（会話内のみ）
-
-```markdown
-# Doc Freshness チェック計画
-
-## チェック対象スコープ
-- ディレクトリ: {phasegate.config.json の constructionDir、デフォルト: docs/}
-- 閾値: {phasegate.config.json の値 or デフォルト 30日}
-
-## 実行コマンド
-npx phasegate check-freshness [--dir {path}] [--threshold {days}]
-
-## QA
-[Question] Q1: ...
-[Answer]
-```
-
-### Phase 1 完了条件
-- スコープを報告した
-- 人間にボールを渡した
-- **CLIはまだ実行していない**
-
----
-
-## Phase 2: 実行（execution）
-
-### Step 1: CLIの実行
-
-```bash
-npx phasegate check-freshness
-```
-
-オプション:
-- `--dir <path>` — チェック対象ディレクトリ（デフォルト: `phasegate.config.json` の `constructionDir`）
-- `--threshold <days>` — 警告閾値（日数）
-
-### Step 2: 結果の解釈
-
-`CheckDocFreshnessOutput` の構造:
-
-| フィールド | 意味 |
-|-----------|------|
-| `results[].status` | `ok` / `warn` / `error` |
-| `results[].documentPath` | チェック対象ファイルパス |
-| `results[].daysSinceUpdate` | 最終更新からの日数 |
-| `results[].threshold` | 設定閾値 |
-| `summary.error` | エラー件数（即対応必要） |
-| `summary.warn` | 警告件数（確認推奨） |
-
-### Step 3: アクションの提案
-
-| 状態 | 推奨アクション |
-|------|--------------|
-| `error`（閾値超過） | cascade-updater で上位設計文書を更新 |
-| `warn`（閾値近接） | 設計文書の内容確認・必要に応じて更新 |
-| `ok` | 対応不要 |
-
-### 出力フォーマット
-
-```markdown
-# Doc Freshness チェック結果
-
-## サマリー
-- 総ドキュメント数: N
-- ok: N / warn: N / error: N
-
-## 要対応（error）
-| ファイル | 最終更新 | 閾値超過日数 | 推奨アクション |
-|---------|---------|------------|--------------|
-
-## 要確認（warn）
-| ファイル | 最終更新 | 残り日数 |
-|---------|---------|---------|
-
-## 次のアクション
-（errorがある場合は `cascade-updater` の実行を提案）
-```
-
----
-
-## phasegate.config.json 設定例
-
-```json
-{
-  "docFreshnessThresholds": {
-    "domain_model.md": 90,
-    "logical_design.md": 60,
-    "unit_test_design.md": 30,
-    "default": 30
-  }
-}
-```
-
----
-
-## 関連スキル
-
-| スキル | 用途 |
-|-------|------|
-| `cascade-updater` | errorが検出された設計文書の更新 |
-| `consistency-checker` | 文書間整合性の検証（freshness修正後の確認） |

package/skills/implementation-planner/SKILL.md

@@ -1,167 +0,0 @@
----
-name: implementation-planner
-description: "Unit仕様とドメインモデル設計を元に実装計画を立てる。WI IDや機能名から関連Unitを特定し、API設計・レイヤー別実装方針を整理してmdファイルで出力する。使用タイミング: 実装計画を立てて、WI-XXXの実装方針を決めて、この機能の設計を整理して、など実装前の計画策定時。"
-model: sonnet
-review: opus
-languages: [typescript]
----
-
-# Implementation Planner
-
-## 目的
-
-UnitドキュメントとConstructionのドメインモデル設計を元に、**設計フェーズの実装計画**を体系的に立案する。
-
-## ⚠️ `story-implementor` との役割分担
-
-| 観点 | `implementation-planner`（本スキル） | `story-implementor` |
-|------|-------------------------------------|---------------------|
-| **目的** | 設計段階で実装方針を整理・合意する | TDD実装を実行する |
-| **タイミング** | 論理設計の前後（設計の方向性確認） | テスト設計・カバレッジ検証の後 |
-| **出力** | 実装計画書（API設計・レイヤー別方針） | TDD実装計画 → 実装コード |
-| **テスト設計** | 参照しない（設計フェーズのため） | 必須（テスト設計完了が前提） |
-
-**使い分けの指針:**
-- 「この機能どう実装する？」→ `implementation-planner`
-- 「テスト設計も終わった、TDD実装を始めたい」→ `story-implementor`
-
-## ⚠️ 3フェーズ実行ルール
-
-**このスキルは3フェーズで実行する。**
-- **Phase 1（計画）**: Opus がスコープ・方針・不明点を整理し、人間の承認を得る
-- **Phase 2（実行）**: Sonnet 4.6 に委任して成果物を生成する（`npx phasegate delegate-sonnet` 経由）
-- **Phase 3（レビュー）**: Opus が成果物を検証し、問題があれば直接修正する
-
-**Phase 1/2/3を同時に実行してはならない。モデルルーティングの詳細は `docs/principles/model-routing.md` を参照。**
-
----
-
-## ワークフロー
-
-## 前提条件チェック（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>`.
-
-```
-入力解析 → Unit特定 → ドメインモデル確認 → 既存実装確認 → 計画作成 → 出力
-```
-
-### Step 1: 入力解析
-
-ユーザー入力から抽出:
-- WI ID（WI-XXX形式）
-- 機能名・タスク説明
-- 優先度・制約条件
-
-### Step 2: Unit特定
-
-1. `docs/product/units/integration_contract.md`を読み込み
-2. 関連する公開APIエンドポイントを特定
-3. 該当Unitの`{unit}.md`を確認
-4. Unit間依存関係を整理
-
-**検索方法:**
-- Grep/Globツールを使用して `docs/product/units/` 配下からストーリーIDやキーワードを検索する
-- `integration_contract.md` から関連する公開APIエンドポイントを特定する
-
-### Step 3: ドメインモデル確認
-
-1. `docs/product/construction/{context}/domain_model.md`を読み込み
-2. 以下を把握:
-   - 集約と不変条件
-   - エンティティ・値オブジェクト
-   - ドメインイベント
-   - 状態遷移
-3. 必要に応じて`shared_kernel/domain_model.md`を参照
-
-### Step 4: 既存実装確認
-
-- Glob/Readツールを使用してプロジェクトの実装ディレクトリ構造を確認する
-- 既存の実装パターンを検索し、コードスタイル・ファイル配置を把握する
-
-### Step 5: 計画作成
-
-[references/plan-template.md](references/plan-template.md)のフォーマットに従って:
-1. API設計（新規/既存拡張）
-2. レイヤー別実装内容
-3. 実装ステップ分解
-4. 影響範囲特定
-
-## 出力ファイル
-
-### Step 6: 出力
-
-計画をmdファイルとして出力。パスの推奨:
-```
-docs/inception/{task_id}_plan.md
-docs/inception/{unit}/WI-XXX/tdd_implementation_plan.md
-```
-
-**[Question][Answer]セクション必須**: 不明点や確認事項をまとめ、ユーザーからのフィードバックを受け取れるようにする。
-
----
-
-## 入力（参照ドキュメント）
-
-| ファイル | 用途 |
-|----------|------|
-| `docs/product/units/integration_contract.md` | Unit間API定義・依存関係 |
-| `docs/product/units/{unit}.md` | ユーザーストーリー・機能要件 |
-| `docs/product/construction/{context}/domain_model.md` | ドメインモデル設計 |
-
-**詳細は以下を参照:**
-- [document-structure.md](references/document-structure.md): ドキュメント構造リファレンス
-- [workflow.md](references/workflow.md): 詳細ワークフロー
-- [plan-template.md](references/plan-template.md): 出力テンプレート
-
----
-
-## Unit一覧（クイックリファレンス）
-
-実行時に `docs/product/units/` 配下のUnit定義ファイルを動的に読み取ること。ハードコードしない。
-
----
-
-### Phase 2 最低出力基準（Sonnet委任時の品質制約）
-
-以下の基準を満たさない出力は不完全とみなし、Phase 3レビューでBLOCKとする。
-
-| 基準 | 最低要件 |
-|------|---------|
-| Unit特定 | 対象ストーリー/機能に関連するUnitが正しく特定されていること |
-| ドメインモデル参照 | 関連する集約・エンティティ・値オブジェクトが列挙されていること |
-| API設計 | 新規/既存拡張のエンドポイントが具体的に定義されていること |
-| レイヤー別実装内容 | 各層（Domain/UseCase/Controller/Infrastructure）の実装内容が記載されていること |
-| 実装ステップ | 実装順序が具体的なステップに分解されていること |
-| 影響範囲 | 変更が他Unit・他コンポーネントに与える影響が分析されていること |
-| QAセクション | 不明点・確認事項が[Question][Answer]形式で記載されていること |
-
----
-
-## Phase 3: レビュー（Opus review）
-
-### 実行主体
-メインセッション（Opus 4.6）が実行する。Sonnetへの再委任は行わない。
-
-### レビュー手順
-1. Sonnetが出力したファイルを読み込む
-2. `docs/principles/model-routing.md` のレビュー観点 R1〜R7 に沿って検証する
-3. **スキル固有レビュー観点**を検証する
-4. 判定結果を出力する
-
-### スキル固有レビュー観点（BLOCK基準）
-- [ ] 対象Unit/ドメインモデルの特定が正確か
-- [ ] API設計が統合契約と整合しているか
-- [ ] レイヤー間の依存方向が正しいか（Domain → Port → UseCase → Controller）
-- [ ] 実装ステップの順序が論理的か（依存関係に沿っているか）
-- [ ] 影響範囲の分析が漏れなく行われているか
-
-### 判定と修正
-- **BLOCK項目にFAIL** → Opusが直接修正してから完了とする
-- **WARNのみFAIL** → Opusが直接修正してから完了とする
-- **全PASS** → 完了
-
-## コードベース構成（クイックリファレンス）
-
-実行時にプロジェクトのディレクトリ構造を動的に確認すること。ハードコードしない。