phasegate 0.15.0

package/skills/logical-designer/SKILL.md

@@ -0,0 +1,186 @@
+---
+name: logical-designer
+description: ドメインモデルから論理設計を作成。横断設計とストーリー固有設計の2モード（AIDLC Step 2.2）
+model: opus
+---
+
+# Logical Designer
+
+ドメインモデルをソースコード実装可能な論理設計に変換するスキル。AIDLCプロセスのStep 2.2に対応。
+
+## 2つのモード
+
+### 横断モード（Unit全体の設計）
+Unit単位でアーキテクチャの各層（DB → ドメイン → ユースケース → コントローラ → BFF → フロントエンド）の設計を行う。
+
+### ストーリー固有モード（個別ストーリーの設計）
+特定のストーリーを実装するために必要な論理設計を、横断設計に基づいて詳細化する。
+
+## 前提条件チェック
+
+### 必須インプット（存在しなければ`[Question]`で提供を要求）
+
+- **横断モード:**
+  - ドメインモデル（`docs/product/construction/{unit}/domain_model.md`）
+  - 統合契約（`docs/product/units/integration_contract.md`）
+
+- **ストーリー固有モード:**
+  - 横断論理設計（`docs/product/construction/{unit}/logical_design.md`）
+  - 対象ストーリーの定義（ストーリーID・受け入れ基準）
+
+### 任意インプット（あれば参照）
+- アーキテクチャルール文書（層の依存方向、設計原則等）
+- テスト規約文書
+- 環境設計（`docs/product/environment_contract.md`）
+- 既存の論理設計（フォーマット準拠・差分のみ設計）
+
+---
+
+## ⚠️ 上位レイヤー存在チェック
+
+**このスキルは AIDLC Step 5「論理設計」に対応します。実行前に上位設計の存在を確認してください。**
+
+### 依存する上位設計文書
+
+#### 横断モードの場合
+| ファイル | 必須 | チェック方法 |
+|---------|------|------------|
+| `docs/product/construction/{unit}/domain_model.md` | ✅ 必須 | 対象Unitのドメインモデル存在を確認 |
+| `docs/product/units/integration_contract.md` | ✅ 必須 | ファイルの存在を確認 |
+
+#### ストーリー固有モードの場合
+| ファイル | 必須 | チェック方法 |
+|---------|------|------------|
+| `docs/product/construction/{unit}/logical_design.md` | ✅ 必須 | 横断論理設計の存在を確認 |
+| `docs/product/units/{unit}.md` | ✅ 必須 | 対象ストーリーの定義を確認 |
+
+### 上位設計が存在しない場合のアクション
+
+上位設計文書が存在しない場合、**設計を開始せず**、以下を行う：
+
+1. **状況報告** — ユーザーに不足している設計文書を明示
+2. **選択肢提示** — 以下の選択肢を提示
+   - 上位設計（domain-designer）を先に実行する
+   - 上位設計をスキップして進める（非推奨）
+3. **ユーザー指示待ち** — 独自判断で設計を開始しない
+
+**報告テンプレート:**
+```markdown
+## ⚠️ 上位レイヤー設計が見つかりません
+
+以下の設計文書が存在しないため、論理設計を開始できません：
+- `docs/product/construction/{unit}/domain_model.md` ❌ 未作成
+
+### 推奨アクション
+`domain-designer` スキルを使用してドメインモデルを作成してください。
+
+### 選択肢
+1. **domain-designerを先に実行する**（推奨）
+2. **このまま進める**（上位設計なしで進める場合、整合性リスクあり）
+
+どちらを選択しますか？
+```
+
+---
+
+## ⚠️ 2フェーズ実行ルール
+
+**このスキルは必ず2フェーズに分けて実行する。Phase 1で計画を作成し、人間の承認を得てからPhase 2で成果物を作成する。Phase 1とPhase 2を同時に実行してはならない。**
+
+---
+
+## Phase 1: 計画（plan）
+
+### 目的
+設計方針・スコープ・不明点を整理し、人間の承認を得る。
+
+### 出力ファイル
+`docs/inception/{unit}/logical_design_plan.md`（横断）または `docs/inception/{unit}/{story_id}/logical_design_plan.md`（ストーリー固有）
+
+### 計画ファイルの構成
+
+```markdown
+# 論理設計計画: {Unit名 or ストーリーID}
+
+## 1. スコープ
+- 対象Unit / ストーリー
+- 設計対象の層（DB / Domain / UseCase / Controller / BFF / Frontend）
+
+## 2. 設計方針
+- アーキテクチャ層の定義とその根拠
+- 技術スタックの前提
+
+## 3. 設計内容サマリー（各層の設計概要を箇条書き）
+- DB層: ...
+- Domain層: ...
+- UseCase層: ...
+- ...
+
+## 4. QA（不明点・確認事項）
+
+### [Question] Q1: {質問タイトル}
+{質問の詳細と背景}
+**推奨案:** {AIの推奨案}
+
+[Answer]
+（人間が回答を記入）
+
+### [Question] Q2: ...
+...
+
+## 5. 前提条件・リスク
+- ...
+```
+
+### Phase 1 完了条件
+- 計画ファイルを出力した
+- 不明点がある場合は`[Question]`セクションに記載した
+- **人間にボールを渡した（「計画をレビューしてください」と伝えた）**
+- **成果物（論理設計本体）はまだ作成していない**
+
+---
+
+## Phase 2: 実行（execution）
+
+### 開始条件
+- 人間がPhase 1の計画を承認した
+- QAセクションの全[Question]に[Answer]が記入されている（QAがある場合）
+
+### ワークフロー（横断モード）
+
+1. **アーキテクチャ層の定義** — 技術スタックに基づき各層の責務を定義
+2. **DB層設計** — テーブル定義、インデックス、マイグレーション計画、ビュー
+3. **ドメイン層設計** — モジュール構成、リポジトリIF、ドメインサービス
+4. **アプリケーション層設計** — ユースケース一覧、処理フロー、入出力DTO
+5. **コントローラ/API層設計** — エンドポイント、スキーマ、バリデーション
+6. **BFF層設計**（フロントエンドがある場合） — Server Actions、データ変換
+7. **フロントエンド層設計**（フロントエンドがある場合） — コンポーネント、画面遷移、状態管理
+8. **テスト設計** — テスト対象×テストレイヤーの対応表、テストダブル方針
+9. **品質評価（engineering-perspective）** — 設計完了後、以下の観点で自己評価し、問題があれば修正してから成果物を確定する
+   - **SOLID/Clean Architecture**: 依存が内向きか、各層がSRPに従っているか、DIPが守られているか
+   - **コードスメル**: Feature Envy・Shotgun Surgery等の設計レベルスメルがないか
+   - **ドメイン表現**: 論理設計がドメインモデルの意図を正しく反映しているか（言語の一致）
+
+### ワークフロー（ストーリー固有モード）
+
+1. **スコープ確認** — 受け入れ基準を確認、横断設計の変更箇所を特定
+2. **各層の詳細設計** — 関係する層のみ詳細化、シーケンス図で連携フロー記述
+3. **マイグレーション・環境影響** — 新規テーブル/カラム/サービスの必要性、環境設計への影響を明記
+4. **品質評価（engineering-perspective）** — 横断モードと同様の観点で自己評価し、問題があれば修正してから成果物を確定する
+
+### 出力ファイル
+
+| 種別 | 配置先 |
+|------|--------|
+| 横断成果物 | `docs/product/construction/{unit}/logical_design.md` |
+| ストーリー固有成果物 | `docs/inception/{unit}/{story_id}/logical_design.md` |
+
+> **注意**: ストーリー固有の設計は `docs/inception/` に配置する（`docs/folder_management_rules.md` のルール準拠）。`docs/product/construction/` にはUnit全体の共有設計のみを配置する。
+
+---
+
+## 注意事項
+
+- **コードスニペットは生成しない**（設計文書のみ）
+- 層間の依存方向を厳守する（Domain → Port → UseCase → Controller）
+- テスト設計は設計文書の一部として含める

package/skills/mock-designer/SKILL.md

@@ -0,0 +1,189 @@
+---
+name: mock-designer
+description: ユーザーストーリーからUIモックを作成。UI/UXの検証とフィードバック（AIDLC Step 2）
+model: sonnet
+review: opus
+---
+
+# Mock Designer
+
+ユーザーストーリーからUIモックアップを作成するスキル。AIDLCプロセスのStep 2「mock（モック）を作る」に対応。
+
+## 前提条件チェック
+
+### 必須インプット（存在しなければ`[Question]`で提供を要求）
+- **ユーザーストーリー一覧** — `docs/product/user_stories.md` またはストーリーが記載された文書
+
+### 任意インプット（あれば参照）
+- **プロダクト概要** — `docs/product/product_overview.md`（全体像・ユビキタス言語）
+- **既存モック** — `/mock` フォルダ内の既存HTMLファイル
+- **デザインシステム** — 色・フォント・コンポーネントの規約
+
+---
+
+## ⚠️ 上位レイヤー存在チェック
+
+**このスキルは AIDLC Step 2「mock（モック）を作る」に対応します。実行前に上位設計の存在を確認してください。**
+
+### 依存する上位設計文書
+
+| ファイル | 必須 | チェック方法 |
+|---------|------|------------|
+| `docs/product/user_stories.md` | ✅ 必須 | ファイルの存在を確認 |
+
+### 上位設計が存在しない場合のアクション
+
+上位設計文書が存在しない場合、**モック作成を開始せず**、以下を行う：
+
+1. **状況報告** — ユーザーに不足している設計文書を明示
+2. **選択肢提示** — 以下の選択肢を提示
+   - 上位設計（story-writer）を先に実行する
+   - 上位設計をスキップして進める（非推奨）
+3. **ユーザー指示待ち** — 独自判断でモック作成を開始しない
+
+**報告テンプレート:**
+```markdown
+## ⚠️ 上位レイヤー設計が見つかりません
+
+以下の設計文書が存在しないため、モック作成を開始できません：
+- `docs/product/user_stories.md` ❌ 未作成
+
+### 推奨アクション
+`story-writer` スキルを使用してユーザーストーリーを作成してください。
+
+### 選択肢
+1. **story-writerを先に実行する**（推奨）
+2. **このまま進める**（上位設計なしで進める場合、整合性リスクあり）
+
+どちらを選択しますか？
+```
+
+---
+
+## ⚠️ 3フェーズ実行ルール
+
+**このスキルは3フェーズで実行する。**
+- **Phase 1（計画）**: Opus がスコープ・方針・不明点を整理し、人間の承認を得る
+- **Phase 2（実行）**: Sonnet 4.6 に委任して成果物を生成する（`scripts/delegate-sonnet.sh` 経由）
+- **Phase 3（レビュー）**: Opus が成果物を検証し、問題があれば直接修正する
+
+**Phase 1/2/3を同時に実行してはならない。モデルルーティングの詳細は `docs/principles/model-routing.md` を参照。**
+
+---
+
+## Phase 1: 計画（plan）
+
+### 目的
+モック作成のスコープ・画面構成・不明点を整理し、人間の承認を得る。
+
+### 出力ファイル
+`docs/inception/_shared/mock_design_plan.md`
+
+### 計画ファイルの構成
+
+```markdown
+# UIモック作成計画
+
+## 1. スコープ
+- 対象ストーリー一覧
+- 作成する画面一覧
+
+## 2. 画面構成（ドラフト）
+| 画面名 | 対応ストーリー | 主要機能 |
+|--------|--------------|---------|
+
+## 3. 画面遷移図（ドラフト）
+```mermaid
+graph LR
+    A[ログイン] --> B[ダッシュボード]
+    B --> C[詳細画面]
+```
+
+## 4. デザイン方針
+- 使用するUIフレームワーク・スタイル
+- 色・フォント・コンポーネント規約
+
+## 5. QA（不明点・確認事項）
+
+### [Question] Q1: {質問タイトル}
+{質問の詳細と背景}
+**推奨案:** {AIの推奨案}
+
+[Answer]
+（人間が回答を記入）
+
+## 6. 前提条件・リスク
+- ...
+```
+
+### Phase 1 完了条件
+- 計画ファイルを出力した
+- 不明点がある場合は`[Question]`セクションに記載した
+- **人間にボールを渡した**
+- **モックファイルはまだ作成していない**
+
+---
+
+## Phase 2: 実行（execution）
+
+### 開始条件
+- 人間がPhase 1の計画を承認した
+- QAセクションの全[Question]に[Answer]が記入されている（QAがある場合）
+
+### ワークフロー
+
+1. **モック作成** — HTML、CSS、JavaScriptのみで画面モックを作成
+2. **インタラクション追加** — 必要に応じてクリック動作や画面遷移を実装
+3. **レビュー可能な状態に** — ブラウザで開けば即座に確認できる状態にする
+
+### Phase 2 最低出力基準（Sonnet委任時の品質制約）
+
+以下の基準を満たさない出力は不完全とみなし、Phase 3レビューでBLOCKとする。
+
+| 基準 | 最低要件 |
+|------|---------|
+| 画面数 | Phase 1計画の画面一覧と一致すること |
+| 画面遷移 | 計画の画面遷移図に沿ったリンク/ボタンが実装されていること |
+| ダミーデータ | 各画面に業務上意味のあるダミーデータが表示されていること |
+| レスポンシブ | 最低限デスクトップ表示で崩れないこと |
+| ブラウザ動作 | HTMLファイルを直接開いて即座に確認できること（外部依存なし） |
+
+### 出力ファイル
+
+| 種別 | 配置先 |
+|------|--------|
+| 成果物 | `/mock/{画面名}.html` |
+
+---
+
+---
+
+## Phase 3: レビュー（Opus review）
+
+### 実行主体
+メインセッション（Opus 4.6）が実行する。Sonnetへの再委任は行わない。
+
+### レビュー手順
+1. Sonnetが出力したファイルを読み込む
+2. `docs/principles/model-routing.md` のレビュー観点 R1〜R7 に沿って検証する
+3. **スキル固有レビュー観点**を検証する
+4. 判定結果を出力する
+
+### スキル固有レビュー観点（BLOCK基準）
+- [ ] Phase 1計画の全画面がモックとして作成されているか
+- [ ] 画面遷移が計画通りに動作するか
+- [ ] ユーザーストーリーの受け入れ基準に対応するUI要素が存在するか
+- [ ] ユビキタス言語に沿ったラベル・用語が使われているか
+
+### 判定と修正
+- **BLOCK項目にFAIL** → Opusが直接修正してから完了とする
+- **WARNのみFAIL** → Opusが直接修正してから完了とする
+- **全PASS** → 完了
+
+## 注意事項
+
+- モックはHTML、CSS、JavaScriptのみで作成（フレームワーク不使用）
+- 実装コードとは完全に分離する（`/mock`フォルダに配置）
+- データはダミーデータを使用
+- モックレビュー後、機能の漏れや追加があればユーザーストーリーへのフィードバックを提案する
+- **モックから発見された追加要件は `cascade-updater` を通じてストーリーに反映する**

package/skills/pointer-validator/SKILL.md

@@ -0,0 +1,96 @@
+---
+name: pointer-validator
+description: 設計文書内のファイルポインタ（相対パス参照）の有効性を検証するスキル（L4バリデータ拡張）。`p2:validate-pointers` CLIを使い、ドキュメント内で参照されているファイルパスが実際に存在するかチェックする。使用タイミング: 「ドキュメントのリンク切れを確認して」「ポインタ検証を実行して」「broken pointer を探して」「設計文書の参照が正しいか確認して」など。
+model: sonnet
+review: opus
+---
+
+# Pointer Validator
+
+設計文書内のファイルパス参照（ポインタ）の有効性を検証するスキル。
+`phase2-extensions` Unit の `p2:validate-pointers` CLIをラップし、broken pointer を検出・修正案を提示する。
+
+## CLIの動作
+
+`p2:validate-pointers` は以下を検出する:
+- Markdownの `[text](path)` 形式のリンク
+- `@file:` / `@ref:` 形式のポインタ
+- `filePath:` YAML/JSON フィールド内のパス参照
+- URLポインタはスキップ（`http://` / `https://` は検証対象外）
+
+---
+
+## ワークフロー（単一フェーズ）
+
+このスキルは軽量チェックのため単一フェーズで実行する。
+
+### Step 1: CLIの実行
+
+```bash
+pnpm run p2:validate-pointers
+```
+
+オプション:
+- `--dir <path>` — スキャン対象ディレクトリ（デフォルト: `docs/`）
+- `--fix` — 自動修正可能なポインタを修正（要確認）
+
+### Step 2: 結果の解釈
+
+`ValidateDocPointersOutput` の構造:
+
+| フィールド | 意味 |
+|-----------|------|
+| `results[].documentPath` | ポインタを含む文書ファイル |
+| `results[].pointerTarget` | 参照先パス |
+| `results[].pointerType` | `file-path` / `url` |
+| `results[].isResolvable` | 解決可能かどうか |
+| `results[].errorMessage` | エラー内容（nullなら正常） |
+| `summary.brokenPointers` | broken件数 |
+| `summary.skippedUrlPointers` | URLスキップ件数 |
+| `passed` | 全ポインタ有効ならtrue |
+
+### Step 3: 修正戦略の判断
+
+| broken原因 | 推奨アクション |
+|-----------|--------------|
+| ファイルが移動された | ポインタのパスを新パスに更新 |
+| ファイルが削除された | ポインタを削除 or 代替ファイルに変更 |
+| タイポ | パス修正 |
+| 未作成ファイルへの参照 | 意図的な前方参照として `[TODO]` マーカーを追加 |
+
+### 出力フォーマット
+
+```markdown
+# Pointer Validation 結果
+
+## サマリー
+- チェックドキュメント数: N
+- 総ポインタ数: N
+- broken: N / URL(スキップ): N
+
+## Broken Pointers（要修正）
+| 文書ファイル | 参照先 | エラー | 推奨修正 |
+|------------|--------|--------|---------|
+
+## 次のアクション
+（brokenがある場合）
+1. 上記テーブルの broken pointer を修正
+2. `pnpm run p2:validate-pointers` を再実行して0件を確認
+```
+
+---
+
+## 注意事項
+
+- URL（`http://` / `https://`）は検証対象外（ネットワーク依存を避けるため）
+- `--fix` オプションは明確な移動・リネームのみ自動修正。曖昧なケースはスキップ
+- broken件数 > 50 の場合は `--dir` でスコープを絞って段階的に対処する
+
+---
+
+## 関連スキル
+
+| スキル | 用途 |
+|-------|------|
+| `doc-freshness-checker` | 設計文書の鮮度チェック（セットで実行推奨） |
+| `consistency-checker` | 文書間の内容整合性チェック |

package/skills/product-architect/SKILL.md

@@ -0,0 +1,131 @@
+---
+name: product-architect
+description: ビジネス要求からプロダクト全体像を定義。ドメイン・アーキテクチャ・技術選定・制約（AIDLC Step 0）
+model: opus
+---
+
+# Product Architect
+
+ビジネス要求からプロダクトの全体像を定義するスキル。全スキルの土台となる文書を作成する。AIDLCプロセスの最初のステップ。
+
+## 前提条件チェック
+
+### 必須インプット（存在しなければ`[Question]`で提供を要求）
+- **ビジネス要求文書** — プロダクトの目的・背景・対象ユーザーを記述した文書（議事録、企画書、要件メモ等）
+
+### 任意インプット（あれば参照）
+- **既存プロダクト概要** — 更新する場合はフォーマットに準拠
+- **技術選定の前提** — 既に決まっている技術スタック
+- **ステークホルダーからのフィードバック** — ドメインの理解を深める材料
+
+---
+
+## ⚠️ 2フェーズ実行ルール
+
+**このスキルは必ず2フェーズに分けて実行する。Phase 1で計画を作成し、人間の承認を得てからPhase 2で成果物を作成する。Phase 1とPhase 2を同時に実行してはならない。**
+
+---
+
+## Phase 1: 計画（plan）
+
+### 目的
+プロダクト定義のスコープ・方針・不明点を整理し、人間の承認を得る。
+
+### 出力ファイル
+`docs/inception/_shared/product_overview_plan.md`
+
+### 計画ファイルの構成
+
+```markdown
+# プロダクト設計計画
+
+## 1. スコープ
+- プロダクトの目的と対象ユーザー概要
+- 設計対象セクション一覧
+
+## 2. ドメイン分析（ドラフト）
+- 特定されたコアドメイン
+- 主要業務概念の候補一覧（ユビキタス言語の種）
+
+## 3. アーキテクチャ方針（ドラフト）
+- 想定されるアーキテクチャスタイル
+- 技術スタック候補
+
+## 4. QA（不明点・確認事項）
+
+### [Question] Q1: {質問タイトル}
+{質問の詳細と背景}
+**推奨案:** {AIの推奨案}
+
+[Answer]
+（人間が回答を記入）
+
+## 5. 前提条件・リスク
+- ...
+```
+
+### Phase 1 完了条件
+- 計画ファイルを出力した
+- 不明点がある場合は`[Question]`セクションに記載した
+- **人間にボールを渡した**
+- **成果物（product_overview.md）はまだ作成していない**
+
+---
+
+## Phase 2: 実行（execution）
+
+### 開始条件
+- 人間がPhase 1の計画を承認した
+- QAセクションの全[Question]に[Answer]が記入されている（QAがある場合）
+
+### ワークフロー
+
+1. **プロダクト定義** — プロダクトの根本思想・解決する問題・対象ユーザーを定義
+2. **コアドメイン定義** — ユビキタス言語（主要概念とその定義）を整理
+3. **アーキテクチャ仕様** — 全体構造、レイヤー構成、技術スタック、分離方針を定義
+4. **技術選定と決定理由（ADR Summary）** — 主要な技術決定とその根拠を記録
+5. **制約** — 運用・実装・パフォーマンス上の制約を列挙
+
+### 出力ファイル
+
+| 種別 | 配置先 |
+|------|--------|
+| 成果物 | `docs/product/product_overview.md` |
+
+### product_overview.md の構成
+
+```markdown
+# {プロダクト名}
+
+## 1. プロダクト定義
+### 1.1 根本思想
+### 1.2 解決する問題
+### 1.3 対象ユーザー
+
+## 2. コアドメイン
+### 2.1 主要概念（ユビキタス言語）
+| 概念 | 定義 | 例 |
+### 2.2 概念間の関係図（Mermaid）
+
+## 3. アーキテクチャ仕様
+### 3.1 全体構造（レイヤー図）
+### 3.2 技術スタック
+| レイヤー | 技術 | 選定理由 |
+### 3.3 分離方針（認証/認可、同期/非同期 等）
+
+## 4. ADR Summary（技術決定記録）
+| # | 決定事項 | 選択肢 | 決定 | 理由 |
+
+## 5. 制約
+### 5.1 運用上の制約
+### 5.2 実装上の制約
+### 5.3 パフォーマンス要件
+```
+
+---
+
+## 注意事項
+
+- このドキュメントは全スキルの**前提**として参照される
+- ユビキタス言語はプロジェクト全体で一貫して使用する
+- 技術選定の「なぜ」を必ず記録する（ADR）