phasegate 0.15.0

package/skills/codex-delegator/SKILL.md

@@ -0,0 +1,312 @@
+---
+name: codex-delegator
+description: |
+  codex CLI（gpt-5.4）にタスクをLocal実行で並列委任し、Claude Codeがマネージャー/レビュワーとして品質管理する。
+  対象: 設計計画、設計文書、テスト設計、コード実装など全タスクタイプ。
+  使用タイミング: 「codexに委任して」「codexで並列に作成」「codexに実装させて」「agentに依頼して」など、
+  codex CLIへのタスク委任・並列実行が必要な場面。
+model: codex
+---
+
+# Codex Delegator
+
+codex CLI（gpt-5.4）にタスクをLocal実行で並列委任し、2段階レビューで品質管理するスキル。Claude Codeは**マネージャー**、codexは**実行者**、Sonnetは**レビュワー**として振る舞う。
+
+## 前提
+
+- codex CLI v0.111.0+（`codex exec "<prompt>" --full-auto`）
+- モデル: `gpt-5.4`（ChatGPTアカウントでは派生モデル不可）
+- プロジェクト規約: `docs/principles/testing-rules.md`, `docs/principles/architecture-philosophy.md`
+- 設計文書が揃っていることが前提（ドメインモデル、論理設計、テストケース設計等）
+
+## 核心原則
+
+1. **codexに判断させない**: 何を・どのファイルに・どのパターンで作るかはClaude Codeが決定する。codexは具体的指示の実行者
+2. **設計文書との突合がレビューの主軸**: `pnpm test` グリーンだけでは不十分。設計文書のケースID・期待値との一致を検証する
+3. **早期フォールバック**: codexが2回失敗したらClaude Codeが直接実装に切り替える
+4. **Local実行のみ**: codex cloud / @codex review は使用しない。全タスクを `codex exec --full-auto` で実行する
+5. **レビューはdiffベース**: 生成物の全文Readではなく、`git diff` の差分をレビュー入力とする。コンテキストウィンドウを節約し、変更点に集中する
+
+---
+
+## 実行モデル
+
+全タスクを **codex Local** で実行する。
+
+```bash
+codex exec "<プロンプト>" --full-auto
+```
+
+### コミット前の自己点検
+
+codex対話モード内で `/review` を使用してコミット前にざっくり点検できる。
+
+```bash
+codex                # 対話モード起動
+/review              # ワーキングツリーの変更を点検
+/review Focus on edge cases and security issues  # 観点指定
+```
+
+### 粒度の制御
+
+Local実行では1委任単位の粒度を小さく保つことがコスト効率上重要。
+
+| 基準 | 推奨値 |
+|------|-------|
+| 変更ファイル数 | 3-5個以下 |
+| 生成行数 | 200行以下 |
+| 所要時間目安 | 5-15分 |
+
+粒度が大きすぎるタスクは分割する。分割してもLocal枠の消費が増えるだけなので、**品質が上がるなら迷わず分割する**。
+
+---
+
+## Phase 1: 計画（Plan）
+
+### Step 1.1: タスク分解
+
+ユーザーの指示を**委任単位（Delegation Unit）**に分解する。分解基準:
+
+| 基準 | 内容 |
+|------|------|
+| ファイル独立性 | 出力ファイルが重複しない |
+| 入力独立性 | 他の委任単位の出力を必要としない |
+| 粒度上限 | 1単位あたり変更ファイル3-5個以下、生成200行以下 |
+
+並列可能な単位は Wave にグループ化する。共有ファイル（barrel export等）への変更が必要なタスクは直列化する。
+
+### Step 1.2: タスクタイプ判定
+
+各委任単位にタスクタイプを付与し、適用するレビュー次元を決定する:
+
+| タスクタイプ | 判定基準 | 追加レビュー次元 |
+|------------|---------|----------------|
+| `design-plan` | inception配下の `*_plan.md` | 上位文書整合、QAセクション、配置ルール |
+| `design-doc` | construction配下の設計 `.md` | 計画との整合、アーキテクチャ原則、トレーサビリティ |
+| `implementation` | `.ts` 等のコード | テスト規約、レイヤー依存方向、型安全性 |
+| `test` | テストコード | ケース網羅、設計文書突合、テスト独立性 |
+
+### Step 1.3: プロンプト設計
+
+各委任単位のプロンプトを3層構造で構成する。詳細テンプレートは [references/prompt-patterns.md](references/prompt-patterns.md) を参照。
+
+```
+[コンテキスト層] 読むべきファイルパス + 関連ルールの具体的引用
+[タスク層]       作業内容、入力ファイル、出力ファイルパスと期待フォーマット
+[制約層]         変更許可ファイルのホワイトリスト、スコープ制限
+```
+
+**重要**: 「既存コードのパターンに従え」ではなく、具体的なパターンのコード例をインラインで添付する。
+
+**プロンプト長の判断**: 2000文字以下なら直接引数、超える場合は一時ファイルに書き出す。
+
+### Step 1.4: 計画出力
+
+以下のフォーマットで報告し、人間の承認を待つ:
+
+```markdown
+## Codex委任計画
+
+### タスク分解
+| # | 委任単位 | タスクタイプ | Wave | 出力ファイル |
+|---|---------|------------|------|------------|
+
+### 実行順序
+- Wave 1（並列）: A, B, C
+- Wave 2（Wave 1完了後）: D, E
+
+### レビュー次元
+コア次元（C1-C4）+ タスクタイプ別次元を適用
+
+### QA
+[Question] Q1: ...
+```
+
+### Phase 1 完了条件
+
+- 計画を報告した
+- 人間にボールを渡した
+- **codex exec はまだ実行していない**
+
+---
+
+## Phase 2: 実行（Execute）
+
+### 開始条件
+
+- 人間がPhase 1の計画を承認した
+- QAに全て回答済み（QAがある場合）
+
+### Step A: 委任（Delegate）
+
+Wave単位で Agent tool を使用し並列実行する。
+
+```bash
+# 各Agent内で実行
+codex exec "<プロンプト>" --full-auto
+```
+
+**並列度上限**: 同時実行は最大3タスク（レート制限考慮）。
+
+**実行結果の追跡**:
+
+```
+| # | 委任単位 | 状態 | 出力ファイル |
+|---|---------|------|------------|
+| 1 | A       | completed | path/to/file.ts |
+| 2 | B       | failed    | (エラー内容) |
+```
+
+**部分成功時**: 成功したタスクの結果は保持し、失敗分のみ再実行する。
+
+### Step B: レビュー（2段階Review）
+
+レビューは **Tier 1（機械的チェック）→ Tier 2（Sonnetによる設計突合）** の2段階で実行する。Tier 1でBLOCKが出た場合はTier 2に進まず即REJECTし、コンテキストを節約する。
+
+#### Step B.0: 差分抽出
+
+レビュー入力は**全文Readではなくdiff**を使う。
+
+```bash
+# 変更ファイル一覧
+git diff --stat HEAD~1
+# 変更内容（diffベース）
+git diff HEAD~1
+# スコープ外変更の検出
+git diff --name-only HEAD~1
+```
+
+#### Step B.1: Tier 1 — 機械的チェック（スクリプト/grep）
+
+Claude Codeがgrep・スクリプトで自動検証する。人間の判断不要な項目を高速に処理する。
+
+| ID | 次元 | 検証方法 | 重大度 |
+|----|------|---------|--------|
+| C1 | スコープ遵守 | `git diff --name-only` と指示ファイルリストの差分比較 | BLOCK |
+| C2 | 既存破壊なし | `pnpm test` 実行（既存テスト全パス確認） | BLOCK |
+| C3 | 命名一貫性 | grep: 日本語テスト名、`actual`変数、target/context構造 | BLOCK |
+| IM3 | レイヤー違反なし | grep: domain層ファイルからinfrastructure層へのimport検出 | BLOCK |
+| IM4 | 型安全性 | grep: 正当理由なき `any` / `as` の使用検出 | WARN |
+| TE1 | ケースID突合 | 設計文書のケースIDリスト vs テストファイル内のID（diff抽出） | BLOCK |
+| DP3 | 配置ルール準拠 | `git diff --name-only` とfolder_management_rules.mdのパス照合 | BLOCK |
+
+**Tier 1 判定**:
+```
+BLOCK が1つでもFAIL → REJECT（Tier 2スキップ）→ Step Cへ
+全PASS or WARNのみ  → Tier 2へ進む
+```
+
+#### Step B.2: Tier 2 — Sonnetによる設計突合チェック
+
+Agent tool（subagent_type未指定）でSonnetに以下の**最小限の入力**を渡してレビューさせる。
+
+**Tier 2への入力（これだけ）**:
+1. `git diff HEAD~1` の出力（変更差分のみ）
+2. Tier 1の結果サマリ（PASS/WARN一覧）
+3. 設計文書の**該当箇所の抜粋**（全文ではない）
+
+**Tier 2 レビュー次元**:
+
+| ID | 次元 | 検証内容 | 重大度 |
+|----|------|---------|--------|
+| C4 | 完了度 | 指示項目の欠落がないか | BLOCK |
+| DD1 | 計画との整合 | diffの内容が設計文書の方針と矛盾しないか | BLOCK |
+| DD2 | アーキテクチャ原則 | ヘキサゴナル・DDD原則に沿っているか | BLOCK |
+| DD4/IM-Y | YAGNI | 指示範囲外の「改善」「リファクタ」「将来への備え」がないか | BLOCK |
+| IM5 | DRY | 新規コードに既存コードとの重複がないか | WARN |
+| TE2 | 期待値突合 | Assertionの期待値が設計文書の期待結果と一致するか | BLOCK |
+| DD3 | トレーサビリティ | 各要素がストーリー/Unit要件に紐づいているか | WARN |
+
+詳細は [references/review-dimensions.md](references/review-dimensions.md) を参照。
+
+**Tier 2 判定**:
+```
+BLOCK が1つでもFAIL → REJECT → Step Cへ
+WARN のみ FAIL      → CONDITIONAL_PASS（WARNをまとめて修正）
+全PASS               → PASS（完了）
+```
+
+### Step C: 修正ループ（Fix Loop）
+
+#### 修正方針の判定
+
+| 条件 | アクション |
+|------|----------|
+| FAIL箇所が3箇所以下かつ局所的 | Claude Codeが自己修正 |
+| 4箇所以上または構造的問題 | codexに修正指示を再委任 |
+| 同一次元で2回連続FAIL | Claude Codeが自己修正に切替 |
+
+#### 修正指示の構造（codex再委任時）
+
+```
+## 修正指示（Round N）
+
+### 前回レビュー結果
+- FAIL次元: {ID}: {名前}
+
+### 修正箇所
+#### [{次元ID}] {ファイルパス}:{行番号}
+- 現状: {問題の具体的記述}
+- 期待: {あるべき状態}
+- 修正方法: {具体的手順}
+
+### 制約
+- 修正対象以外のコードに手を加えないこと
+```
+
+#### エスカレーション条件
+
+以下のいずれかでループ終了:
+
+| 条件 | アクション |
+|------|----------|
+| 同一ファイルに2回修正してもBLOCK解消せず | Claude Codeが直接修正 |
+| 修正が新たなBLOCKを生み出す（退行） | Claude Codeが直接修正 |
+| 修正対象がスコープ外に波及 | 人間にエスカレーション |
+
+エスカレーション時は以下を報告:
+
+```markdown
+## エスカレーション
+
+| ファイル | 問題 | 試行回数 |
+|---------|------|---------|
+
+### 選択肢
+1. Claude Codeが直接修正（推奨）
+2. タスク分解を見直して再委任
+3. 設計文書を修正してから再実行
+4. Opusにレビューを依頼（設計自体を疑う必要がある場合）
+```
+
+---
+
+## エラーハンドリング
+
+### codex exec 実行失敗
+
+| エラー種別 | 対策 |
+|-----------|------|
+| タイムアウト | タスクを分割して再実行 |
+| レート制限 | 並列度を下げて再試行（最大3回） |
+| 認証切れ | 人間にエスカレーション |
+| 出力が完全に誤り（言語違い等） | プロンプトを再設計して再実行（修正ではなく新規実行） |
+
+### 修正主体の判断基準
+
+| Claude Codeが直接修正 | codexに再委任 | 人間にエスカレーション |
+|---------------------|-------------|---------------------|
+| typo、import修正、コメント追加 | ロジック修正、新規メソッド追加 | 設計文書との矛盾、レイヤー違反 |
+| テストケース名の日本語化 | 構造的な書き直し | 集約の責務変更 |
+| WARN項目の軽微な修正 | 4箇所以上のBLOCK | スコープ外への波及 |
+
+---
+
+## 注意事項
+
+- codex CLIはChatGPTアカウントでは `gpt-5.4` のみ使用可能
+- `--full-auto` モードでのファイルシステム変更に注意。実行後に `git diff --stat` で想定外の変更がないか確認する
+- 設計スキルとして使用する場合、コード生成は行わない（設計文書のみ出力）
+- **ファイル配置は `docs/folder_management_rules.md` に従う**
+- codexへのプロンプトでは「読むべきファイル」だけでなく「そこから抽出した具体パターン」をインライン引用する
+- `/review` はコミット前の自己点検用。codex対話モード内で使用する

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

@@ -0,0 +1,165 @@
+# プロンプトパターン
+
+タスクタイプ別のcodex exec プロンプトテンプレート。3層構造（コンテキスト層・タスク層・制約層）に従う。
+
+---
+
+## 共通コンテキスト層
+
+全タスクタイプで以下をプロンプト冒頭に含める:
+
+```
+プロジェクト: Phasegate
+アーキテクチャ: ヘキサゴナル + DDD（domain → port → usecase → controller）
+```
+
+---
+
+## design-plan テンプレート
+
+```
+以下の設計計画を作成してください。
+
+## コンテキスト
+- 上位文書: {上位ファイルパス} を読んで用語・スコープを把握すること
+- 配置ルール: docs/folder_management_rules.md に従うこと
+
+## タスク
+{具体的な計画作成指示}
+
+## 出力ファイル
+- パス: {出力パス}
+- フォーマット: {セクション構成の指示}
+
+## 制約
+- 指示されたファイルのみ作成すること
+- 上位文書に存在しない概念を導入する場合は[Question]セクションに記載すること
+- コードは生成しないこと（設計文書のみ）
+```
+
+---
+
+## design-doc テンプレート
+
+```
+以下の設計文書を作成してください。
+
+## コンテキスト
+- 計画書: {対応する*_plan.mdパス} を読んで方針に従うこと
+- ドメインモデル: {domain_model.mdパス}（存在する場合）
+- アーキテクチャ原則: domain層にビジネスロジック集中、usecaseは調整役のみ
+
+## タスク
+{具体的な設計文書作成指示}
+
+## 入力ファイル
+{読むべきファイルの一覧}
+
+## 出力ファイル
+- パス: {出力パス}
+- フォーマット: {セクション構成、テーブル形式等}
+
+## 制約
+- 計画書のスコープから逸脱しないこと
+- 指示されたファイルのみ作成・変更すること
+- コードは生成しないこと
+```
+
+---
+
+## implementation テンプレート
+
+```
+以下のタスクをTDDで実装してください。
+
+## コンテキスト
+- 論理設計: {logical_design.mdパス} を読むこと
+- テスト設計: {unit_test_design.mdパス} のケースIDに従うこと
+
+## タスク
+{具体的な実装指示}
+
+## 実装対象ファイル
+{ファイルリスト（新規/更新を明記）}
+
+## テスト規約（必須遵守）
+- テストケース名は日本語で記述
+- AAAパターン（// Arrange, // Act, // Assert）
+- Act結果は `actual` に代入（resultは使わない）
+- describe/context/itの構造:
+  target(対象クラス/メソッド) > describe(ふるまい) > context(前提条件) > it(期待値)
+- ドメインエンティティ/値オブジェクトにモック禁止
+
+## パターン例
+以下の既存コードのパターンに従うこと:
+```typescript
+{既存コードから抽出した具体例をここに貼る}
+```
+
+## 制約
+- 変更許可ファイル: {ホワイトリスト}
+- 既存テストを壊さないこと
+- 上記以外のファイルを変更しないこと
+```
+
+---
+
+## test テンプレート
+
+```
+以下のテストを実装してください。
+
+## コンテキスト
+- テスト設計: {test_design.mdパス} のケースIDに従うこと
+- テストロジック: {test_logic.mdパス}（存在する場合）の疑似コードに従うこと
+
+## テストケース
+{ケースID一覧と概要}
+
+## テスト規約（必須遵守）
+- テストケース名は日本語で記述
+- AAAパターン（// Arrange, // Act, // Assert）
+- Act結果は `actual` に代入
+- target/describe/context/it構造
+
+## 実装対象ファイル
+{テストファイルパス（新規/更新を明記）}
+
+## 制約
+- テスト設計に記載されたケースIDのみ実装すること（追加しない）
+- 期待値はテスト設計の「期待結果」列に従うこと
+- 変更許可ファイル: {ホワイトリスト}
+```
+
+---
+
+## 修正指示テンプレート
+
+```
+## 修正指示（Round {N}）
+
+### 前回レビュー結果
+- verdict: REJECT
+- FAIL次元: {次元ID}: {次元名}
+
+### 修正箇所
+
+#### [{次元ID}] {ファイルパス}:{行番号}
+- 現状: {問題の具体的記述（コード/テキスト引用）}
+- 期待: {あるべき状態}
+- 修正方法: {具体的手順}
+
+### 制約
+- 修正対象以外のコードに手を加えないこと
+- 既存テストを壊さないこと
+- 他の正常な箇所を書き換えないこと
+```
+
+---
+
+## プロンプト設計の鉄則
+
+1. **具体例 > 抽象的な指示**: 「AAAパターンに従え」→ OK/NGコード例を添付
+2. **ホワイトリスト > ブラックリスト**: 「これ以外は変更するな」→ 「以下のファイルのみ変更可」
+3. **参照ファイルのパス + 抽出内容**: ファイルを読めと言うだけでなく、重要なルールをインライン引用
+4. **1委任単位 = 1明確なゴール**: 複数の目的を1プロンプトに詰め込まない

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

@@ -0,0 +1,116 @@
+# レビュー次元詳細
+
+レビューは2段階で実行する。Tier 1（機械的チェック）でBLOCKが出たらTier 2に進まず即REJECT。
+
+---
+
+## Tier割り当て概要
+
+| Tier | 実行主体 | 目的 | 入力 |
+|------|---------|------|------|
+| Tier 1 | Claude Code（grep/スクリプト） | 機械的に判定できる項目を高速処理 | `git diff`, ファイル一覧 |
+| Tier 2 | Sonnet（Agent tool経由） | 設計文書との意味的な突合 | diff + Tier 1結果 + 設計文書抜粋 |
+
+---
+
+## Tier 1: 機械的チェック（全タスクタイプ共通）
+
+grep・diff・テスト実行で自動検証する。判断不要。
+
+| ID | 次元 | 検証方法 | 重大度 |
+|----|------|---------|--------|
+| C1 | スコープ遵守 | `git diff --name-only` と指示ファイルリストの差分比較 | BLOCK |
+| C2 | 既存破壊なし | `pnpm test` 実行（既存テスト全パス確認） | BLOCK |
+| C3 | 命名一貫性 | grep: 日本語テスト名、`actual`変数、target/context/describe/it構造 | BLOCK |
+
+### Tier 1: タスクタイプ別追加
+
+#### implementation / test 共通
+
+| ID | 次元 | 検証方法 | 重大度 |
+|----|------|---------|--------|
+| IM3 | レイヤー違反なし | grep: domain層ファイルからinfrastructure層へのimport検出 | BLOCK |
+| IM4 | 型安全性 | grep: 正当理由なき `any` / `as` の使用検出 | WARN |
+
+#### test
+
+| ID | 次元 | 検証方法 | 重大度 |
+|----|------|---------|--------|
+| TE1 | ケースID突合 | 設計文書のケースIDリスト vs テストファイル内のID（機械的マッチング） | BLOCK |
+| TE4 | モック方針 | grep: domain層エンティティに対するmock/spy使用の検出 | BLOCK |
+
+#### design-plan / design-doc
+
+| ID | 次元 | 検証方法 | 重大度 |
+|----|------|---------|--------|
+| DP3 | 配置ルール準拠 | `git diff --name-only` と folder_management_rules.md のパス照合 | BLOCK |
+
+### Tier 1 判定
+
+```
+BLOCK が1つでもFAIL → REJECT（Tier 2スキップ）→ Step Cへ
+全PASS or WARNのみ  → Tier 2へ進む
+```
+
+---
+
+## Tier 2: Sonnetによる設計突合チェック
+
+### 入力（これだけ渡す）
+
+1. `git diff HEAD~1` の出力（変更差分のみ）
+2. Tier 1の結果サマリ（PASS/WARN一覧）
+3. 設計文書の**該当箇所の抜粋**（全文ではなく、対象ストーリー/Unitの該当セクション）
+
+### design-plan（inception文書）
+
+| ID | 次元 | 検証内容 | PASS条件 | 重大度 |
+|----|------|---------|----------|--------|
+| DP1 | 上位文書整合 | 上位レイヤー文書の用語・スコープと矛盾がないか | 上位文書に存在しない概念の未説明導入が0件 | BLOCK |
+| DP2 | QAセクション | 推測で決定した箇所が`[Question]`として記載されているか | 暗黙の前提が0件 | WARN |
+
+### design-doc（domain_model, logical_design, test_design等）
+
+| ID | 次元 | 検証内容 | PASS条件 | 重大度 |
+|----|------|---------|----------|--------|
+| DD1 | 計画との整合 | 対応するinception計画の方針と矛盾がないか | 計画スコープからの逸脱が0件 | BLOCK |
+| DD2 | アーキテクチャ原則 | ヘキサゴナル、DDD、レイヤー依存方向に違反がないか | domain→port→usecase→controllerの方向違反が0件 | BLOCK |
+| DD3 | トレーサビリティ | 各設計要素がストーリーまたはUnit要件に紐づいているか | 紐づけ不明の要素が0件 | WARN |
+| DD4 | YAGNI | 指示範囲外の設計要素が追加されていないか | 未要求の追加要素が0件 | BLOCK |
+
+### implementation（コード実装）
+
+| ID | 次元 | 検証内容 | PASS条件 | 重大度 |
+|----|------|---------|----------|--------|
+| C4 | 完了度 | 指示項目の欠落がないか | 未実装の指示項目が0件 | BLOCK |
+| IM2 | テストケース網羅 | テスト設計のケースIDが全て実装されているか | 未実装ケースが0件 | BLOCK |
+| IM-Y | YAGNI | 指示範囲外の「改善」「リファクタ」「将来への備え」がないか | 未要求の追加が0件 | BLOCK |
+| IM5 | DRY | 既存コードとの重複がないか | 明確な重複が0件 | WARN |
+
+### test（テストコード）
+
+| ID | 次元 | 検証内容 | PASS条件 | 重大度 |
+|----|------|---------|----------|--------|
+| C4 | 完了度 | 指示項目の欠落がないか | 未実装の指示項目が0件 | BLOCK |
+| TE2 | 期待値突合 | Assertionの期待値が設計文書の期待結果と一致するか | 不一致が0件 | BLOCK |
+| TE3 | テスト独立性 | テスト間に実行順序依存がないか | 共有状態への書き込みが0件 | WARN |
+
+### Tier 2 判定
+
+```
+BLOCK が1つでもFAIL → REJECT → Step Cへ
+WARN のみ FAIL      → CONDITIONAL_PASS（WARNをまとめて修正）
+全 PASS              → PASS（完了）
+```
+
+---
+
+## Opusへのエスカレーション
+
+通常のレビューフローではOpusを使用しない。以下の場合にのみ人間の判断でOpusに切り替える:
+
+- 設計文書自体の妥当性を疑う必要がある場合
+- アーキテクチャの根本的な判断が必要な場合
+- Sonnetのレビュー結果に人間が違和感を覚えた場合
+
+Opusへのエスカレーションは `kimunii-perspective` スキルを使用する。