create-ai-project 1.20.9 → 1.22.0

package/.claude/commands-ja/build.md

@@ -18,34 +18,77 @@ description: 分解済みタスクを自律実行モードで実装
 
 ## 実行前提条件
 
-### タスクファイル存在チェック
-```bash
-# 計画書の確認
-! ls -la docs/plans/*.md | grep -v template | tail -5
+### Implementation Readinessチェック
 
-# タスクファイルの確認
-! ls docs/plans/tasks/*.md 2>/dev/null || echo "⚠️ タスクファイルが見つかりません"
-```
+タスク処理の前に、ゲート対象となる作業計画書を特定する。
+
+**`$ARGUMENTS`が指定されている場合**は、それがユーザーから渡された作業計画書のパスである。自動解決を行わずそのまま使用する。`{plan-name}`はファイル名から `.md` 拡張子（および末尾に `-plan` がある場合はそれも）を除いて抽出する。
+
+**`$ARGUMENTS`が空の場合**、タスクファイルから自動解決する:
+1. `docs/plans/tasks/`内で本レシピが消費可能なパターンに一致するタスクファイルを列挙する（subagents-orchestration-guideの「Layer-Aware Agent Routing」で `task-executor` を経由するルートに対応）:
+   - `{plan-name}-task-*.md`（単層タスク。ルーティング表により backend 予約）
+   - `{plan-name}-backend-task-*.md`（複層計画の backend 部分）
+   - `{plan-name}-frontend-task-*.md` は本レシピでは消費**しない** — `task-executor-frontend` にルーティングされ、frontend build レシピが所有する
+2. マッチしたファイルから、以下のいずれかにマッチするものを除外する。これらは本実行の実装タスクではなく、他のワークフローフェーズに由来する: `*-task-prep-*.md`（readiness preflight タスク）、`_overview-*.md`（分解overviewファイル）、`*-phase*-completion.md`（フェーズ完了ファイル）、`review-fixes-*.md`（実装後レビュー修正）、`integration-tests-*-task-*.md`（統合テスト追加用スキャフォールディング）
+3. 残った各ファイルから、末尾の `-task-{NN}.md` または `-backend-task-{NN}.md` を取り除いて `{plan-name}` を抽出する
+4. 少なくとも1つのタスクファイルがマッチした場合、最も新しい mtime を持つ `{plan-name}` の `docs/plans/{plan-name}.md` を作業計画書とする。タイは辞書順最大の `{plan-name}` で解決する
+5. **消費可能なパターンが何もマッチせず、`docs/plans/tasks/`に `*-frontend-task-*.md` が存在する場合**: 停止してユーザーに報告する: 「frontend 命名のタスクファイルしか見つかりませんでした。frontend build レシピを実行する意図であればそちらに切り替えてください。計画が backend ならば、task-decomposer を再実行して backend 命名のタスクファイルを出力させるか、作業計画書のパスを `$ARGUMENTS` で指定してください。」
+6. 消費可能パターンも `*-frontend-task-*.md` も見つからない場合、**backendであることを積極的に示す信号が確認できた場合に限り** `docs/plans/`の最も新しい mtime の非テンプレート `.md` にフォールバックする。多くの計画書テンプレートには backend / frontend のいずれにも合致しない layer-neutral なパス（例: `src/presentation`、`src/app`）が含まれるため、frontend 信号の不在だけでは不十分 — backend の確証が必要である。計画書を読んで以下を確認する:
+
+   **Backend 信号（最低1つ必要）**:
+   - `## Impact Scope > ### Target Files`（または同等のセクション）の対象ファイルが backend マーカー（`**/api/**`、`**/server/**`、`**/services/**`、`**/backend/**`、`**/handlers/**`、`**/repositories/**`、または technical-spec スキルで宣言されたプロジェクト固有の backend パス）に**排他的に**マッチする
+   - 計画書の `## 関連ドキュメント` が、ファイル名から明示的に backend と特定できる Design Doc を参照している（例: `*-backend-design.md`、`backend-*-design.md`）
+   - 計画書のタイトル、`## 目的`、`## 背景` セクションが作業を backend と明示している（例: 「backend 実装」「APIエンドポイント」「データベースマイグレーション」「サーバーサイド」）
+
+   **Frontend 信号（1つでも該当すれば不適格扱いとなる。backend 信号が存在しても優先される）**:
+   - `## 関連ドキュメント` が `docs/ui-spec/*` を指している
+   - `## UI Specコンポーネント → タスクマッピング` セクションが存在する
+   - 対象ファイルが frontend パス（`**/components/**`、`**/pages/**`、`**/web/**`、`**/*.tsx`、`**/*.jsx`）に排他的に該当する
+   - 計画書のタイトルや目的が React、UI コンポーネント、画面、frontend を明示している
+
+   **判定**:
+   - backend 信号 ≥1 かつ frontend 信号 = 0 → 計画書を受容して進む
+   - それ以外（backend 信号がない、または frontend 信号が1つでもある、または layer-neutral なパスのみ）→ 停止して報告する: 「最も新しい作業計画書 `[path]` が backend 計画であることを確証できません（確認した信号と結果: [リスト]）。意図する backend 計画書のパスを `$ARGUMENTS` で指定するか、task-decomposer を先に実行して `docs/plans/tasks/` に backend 命名のタスクファイルを出力してください。」
+7. `docs/plans/`に計画書が一切存在しない場合は、停止して報告する: 「作業計画書が見つかりません。作業計画書のパスを `$ARGUMENTS` で指定するか、計画フェーズを先に完了してください。」
+
+作業計画書のヘッダを読み、`Implementation Readiness: <status>`の行を見つける。以下のルールを適用する:
+
+| ステータス | アクション |
+|--------|--------|
+| `ready` | Consumed Task Set の計算へ進む |
+| `escalated` | 作業計画書のReadiness Reportセクションを読み、AskUserQuestionで残存ギャップをユーザーに提示する: 「Implementation Readinessが`escalated`で、以下の残存ギャップがあります: [リスト]。実行を継続しますか？(y/n)」。`y`なら進む、`n`なら停止 |
+| `pending` | AskUserQuestionで提示する: 「Implementation Readinessが`pending`です。事前にreadiness preflightを実行して作業計画書の実装可能性を検証してから再開してください。preflightなしで継続しますか？(y/n)」。`y`なら進む、`n`なら停止 |
+| 行が存在しない | `pending`として扱う — readinessマーカー導入前に作成された古い作業計画書は明示的にpreflightすべき |
+
+### Consumed Task Set
+
+本実行で消費する **Consumed Task Set** を計算する — 本レシピが所有・実行・後で削除する正確なファイル群。Implementation Readinessチェックと同じ消費可能パターンを使用する:
+
+1. Implementation Readinessチェックで解決した `{plan-name}` について、`docs/plans/tasks/`内で `{plan-name}-task-*.md` または `{plan-name}-backend-task-*.md` にマッチするタスクファイルを列挙する。`{plan-name}-frontend-task-*.md` は除外する — frontend build レシピが所有する
+2. 以下にマッチするファイルを除外する: `*-task-prep-*.md`、`_overview-*.md`、`*-phase*-completion.md`、`review-fixes-*.md`、`integration-tests-*-task-*.md`（これらは他のワークフローフェーズに由来する）
+
+本レシピ内で「タスクファイル」と参照する箇所すべて — タスク生成判定フロー、タスク実行サイクルの反復、最終クリーンアップ — はこのセットを使用する。`docs/plans/tasks/*.md` を制限なく glob しない。
 
 ### タスク生成判定フロー
 
-タスクファイルの存在状態を確認し、適切な対応を決定:
+Consumed Task Set を確認し、適切な対応を決定する。注: 本セクションに到達するということは、上記の readiness check が作業計画書を解決済み（Steps 1-6 が成功）であることを意味する。「計画書なし」の状態は readiness check の Step 7 が既に終了させており、本表には到達しない。
 
 | 状態 | 判定基準 | 次のアクション |
 |------|---------|--------------|
-| タスク存在 | tasks/ディレクトリに.mdファイルあり | ユーザーの実行指示をバッチ承認として自律実行へ移行 |
-| タスクなし＋計画書あり | 計画書は存在するがタスクファイルなし | ユーザーに確認 → task-decomposer実行 |
-| 両方なし＋Design Docあり | 計画書・タスクファイルなし、docs/design/*.mdあり | work-plannerでDesign Docから作業計画書を作成し、タスク分解へ進む |
-| 両方なし | 計画書・タスクファイル・Design Docすべてなし | 前提条件未達成をユーザーに報告して停止 |
+| タスク存在 | Consumed Task Set が非空 | ユーザーの実行指示をバッチ承認として自律実行へ移行 |
+| タスクなし + `$ARGUMENTS`で計画書指定 | `$ARGUMENTS`が提供され Consumed Task Set が空 | ユーザーに確認 → task-decomposer実行 |
+| タスクなし + 計画書を自動解決 | Consumed Task Set が空かつ計画書が自動解決（readiness check の Step 6 経由）で得られ、backend 信号 ≥1 かつ frontend 信号 = 0 が確認済み | ユーザーに確認 → task-decomposer実行（Step 6 のレイヤー検証で frontend / 不確定な計画は既に除外されているため安全） |
+
+Design Doc から作業計画書がまだない状態で着手したい場合は、先に計画レシピを実行して計画書を生成してから本レシピを再起動する — 上記 readiness check は意図的に自動生成を行わず、レイヤー判断を明示的に保つ。
 
 ## タスク分解フェーズ（条件付き実行）
 
-タスクファイルが存在しない場合：
+Consumed Task Set が空の場合：
 
 ### 1. ユーザー確認
 ```
-タスクファイルが見つかりません。
-作業計画書: docs/plans/[計画書名].md
+Consumed Task Set にタスクファイルがありません。
+作業計画書: docs/plans/[plan-name].md
 
 計画書からタスクを生成しますか？ (y/n):
 ```
@@ -54,20 +97,17 @@ description: 分解済みタスクを自律実行モードで実装
 Agentツールでtask-decomposerを呼び出す:
 - `subagent_type`: "task-decomposer"
 - `description`: "作業計画をタスクに分解"
-- `prompt`: "作業計画書を読み込み、1コミット粒度の独立したタスクに分解。入力: docs/plans/[計画書名].md。出力: docs/plans/tasks/配下に個別タスクファイル生成。粒度: 1タスク = 1コミット = 独立して実行可能"
+- `prompt`: "作業計画書を読み込み、1コミット粒度の独立したタスクに分解。入力: docs/plans/[plan-name].md。出力: docs/plans/tasks/配下に個別タスクファイル生成。粒度: 1タスク = 1コミット = 独立して実行可能"
 
 ### 3. 生成確認
-```bash
-# 生成されたタスクファイルを確認
-! ls -la docs/plans/tasks/*.md | head -10
-```
+上記「Consumed Task Set」セクションの制限パターンを使って Consumed Task Set を再計算し、非空であることを確認する。依然として空の場合はユーザーにエスカレーション — task-decomposer が静かに失敗したか、想定パターンに合致しないファイルを生成した可能性がある。
 
-**フロー**: タスク生成 → 自律実行（この順序で実行）
+**フロー**: タスク生成 → Consumed Task Set 再計算 → 自律実行（この順序）
 
 ## 実行前チェックリスト
 
-- [ ] docs/plans/tasks/にタスクファイルが存在することを確認
-- [ ] タスクの実行順序（依存関係）を特定
+- [ ] Consumed Task Set が非空であることを確認（上記「Consumed Task Set」セクションで計算）
+- [ ] Consumed Task Set 内のタスク実行順序（依存関係）を特定
 - [ ] **環境チェック**: タスク単位のコミットサイクルを実行可能か？
   - コミット機能が利用不可 → 自律実行モード前にエスカレーション
   - その他の環境（テスト、品質ツール） → サブエージェントがエスカレーション
@@ -75,7 +115,7 @@ Agentツールでtask-decomposerを呼び出す:
 ## タスク実行サイクル（4ステップサイクル）
 **必須実行サイクル**: `task-executor → エスカレーションチェック → quality-fixer → commit`
 
-各タスクで必須：
+Consumed Task Set 内の各タスクで必須：
 1. **TaskCreateでタスク登録**: 作業ステップを登録。必ず含める: 最初に「ロード済みスキルから具体ルールを抽出」、最後に「抽出ルールを最終JSON前に検証」
 2. **task-executor を呼び出す**: タスク実装を実行（レイヤー横断 の場合は subagents-orchestration-guide の レイヤー別エージェントルーティング 参照）
 3. **task-executor レスポンスをチェック**:
@@ -126,7 +166,18 @@ Escalate when the required fix or investigation falls outside that scope.
    - 続いて quality-fixer、その後 fail した verifier のみ再実行。
    - 2サイクル後も fail が残る場合 → 残存指摘事項を添えてユーザーにエスカレーション
 
-4. **全て合格** → 完了レポートへ
+4. **全て合格** → 最終クリーンアップへ
+
+## 最終クリーンアップ
+
+完了レポートの前に、本レシピが消費した実装タスクファイルを削除する。作業内容はコミット済みで、`docs/plans/`はレシピ実行間で保持しない一時的な作業状態である:
+
+- Consumed Task Set 内のすべてのファイルを削除する
+- `docs/plans/tasks/{plan-name}-phase*-completion.md` にマッチするすべてのファイルを削除する（task-decomposer が生成した本 `{plan-name}` のフェーズ完了ファイル）
+- 該当する `docs/plans/tasks/_overview-{plan-name}.md` が存在する場合は削除する
+- 作業計画書本体（`docs/plans/{plan-name}.md`）は保持する — 最終レビュー後に削除するかはユーザーが判断する
+
+タスクファイルを削除できない場合（ファイルシステムエラー）、失敗を報告するが完了レポートをブロックしない。
 
 ## 出力例
 実装フェーズが完了しました。
@@ -134,6 +185,7 @@ Escalate when the required fix or investigation falls outside that scope.
 - 実装されたタスク: [タスク数]件
 - 品質チェック: すべて通過
 - コミット: [コミット数]件作成
+- クリーンアップ: docs/plans/tasks/ からタスクファイルを削除済み
 
 **責務境界**:
 - スコープ内: タスク分解から実装完了まで

package/.claude/commands-ja/front-build.md

@@ -14,40 +14,64 @@ description: フロントエンド実装を自律実行モードで実行
 
 **重要**: 全てのコミット前にquality-fixer-frontendを実行。
 
-作業計画: $ARGUMENTS
+作業計画書: $ARGUMENTS
 
 ## 実行前提条件
 
-### タスクファイル存在チェック
-```bash
-# 作業計画書を確認
-! ls -la docs/plans/*.md | grep -v template | tail -5
+### Implementation Readinessチェック
 
-# タスクファイルを確認
-! ls docs/plans/tasks/*.md 2>/dev/null || echo "⚠️ タスクファイルが見つかりません"
-```
+タスク処理の前に、ゲート対象となる作業計画書を特定する。
+
+**`$ARGUMENTS`が指定されている場合**は、それがユーザーから渡された作業計画書のパスである。自動解決を行わずそのまま使用する。`{plan-name}`はファイル名から `.md` 拡張子（および末尾に `-plan` がある場合はそれも）を除いて抽出する。
+
+**`$ARGUMENTS`が空の場合**、タスクファイルから自動解決する:
+1. `docs/plans/tasks/`内で本レシピが消費可能な唯一のパターンに一致するタスクファイルを列挙する（subagents-orchestration-guideの「Layer-Aware Agent Routing」により、`task-executor-frontend` が所有するファイル名サフィックスはこの形のみ）:
+   - `{plan-name}-frontend-task-*.md`
+   - 素の `{plan-name}-task-*.md` は消費**しない** — ルーティング表により backend 予約のファイル名で、backend build レシピが所有する。`{plan-name}-backend-task-*.md` も同様に消費しない。
+2. マッチしたファイルから、以下のいずれかにマッチするものを除外する。これらは本実行の実装タスクではなく、他のワークフローフェーズに由来する: `*-task-prep-*.md`（readiness preflight タスク）、`_overview-*.md`（分解overviewファイル）、`*-phase*-completion.md`（フェーズ完了ファイル）、`review-fixes-*.md`（実装後レビュー修正）、`integration-tests-*-task-*.md`（統合テスト追加用スキャフォールディング）
+3. 残った各ファイルから、末尾の `-frontend-task-{NN}.md` を取り除いて `{plan-name}` を抽出する
+4. 少なくとも1つのタスクファイルがマッチした場合、最も新しい mtime を持つ `{plan-name}` の `docs/plans/{plan-name}.md` を作業計画書とする。タイは辞書順最大の `{plan-name}` で解決する
+5. `*-frontend-task-*.md` が見つからず、かつ `docs/plans/`に非テンプレートの作業計画書が存在する場合、最も新しい計画書を自動採用してはならない — frontend タスクは明示的に命名されている必要がある。停止して報告する: 「`docs/plans/tasks/`に `*-frontend-task-*.md` が見つかりませんでした。本レシピを frontend 計画に対して実行する意図であれば、task-decomposer を再実行して frontend 命名のタスクファイルを出力させるか、作業計画書のパスを `$ARGUMENTS` で指定してください。計画が backend ならば、backend build レシピを使用してください。」
+
+作業計画書のヘッダを読み、`Implementation Readiness: <status>`の行を見つける。以下のルールを適用する:
+
+| ステータス | アクション |
+|--------|--------|
+| `ready` | Consumed Task Set の計算へ進む |
+| `escalated` | 作業計画書のReadiness Reportセクションを読み、AskUserQuestionで残存ギャップをユーザーに提示する: 「Implementation Readinessが`escalated`で、以下の残存ギャップがあります: [リスト]。実行を継続しますか？(y/n)」。`y`なら進む、`n`なら停止 |
+| `pending` | AskUserQuestionで提示する: 「Implementation Readinessが`pending`です。事前にreadiness preflightを実行して作業計画書の実装可能性を検証してから再開してください。preflightなしで継続しますか？(y/n)」。`y`なら進む、`n`なら停止 |
+| 行が存在しない | `pending`として扱う — readinessマーカー導入前に作成された古い作業計画書は明示的にpreflightすべき |
+
+### Consumed Task Set
+
+本実行で消費する **Consumed Task Set** を計算する — 本レシピが所有・実行・後で削除する正確なファイル群。ルーティング表により、消費可能なパターンは1つだけ:
+
+1. Implementation Readinessチェックで解決した `{plan-name}` について、`docs/plans/tasks/`内で `{plan-name}-frontend-task-*.md` にマッチするタスクファイルを列挙する。`{plan-name}-task-*.md` および `{plan-name}-backend-task-*.md` は除外する — `task-executor` にルーティングされ、backend build レシピが所有する
+2. 以下にマッチするファイルを除外する: `*-task-prep-*.md`、`_overview-*.md`、`*-phase*-completion.md`、`review-fixes-*.md`、`integration-tests-*-task-*.md`（これらは他のワークフローフェーズに由来する）
+
+本レシピ内で「タスクファイル」と参照する箇所すべて — タスク生成判定フロー、タスク実行サイクルの反復、最終クリーンアップ — はこのセットを使用する。`docs/plans/tasks/*.md` を制限なく glob しない。
 
 ### タスク生成判定フロー
 
-タスクファイルの存在状態を分析し、必要なアクションを決定:
+Consumed Task Set を確認し、適切な対応を決定する。注: `$ARGUMENTS`が空かつ `*-frontend-task-*.md` が存在しない場合は、上記の readiness check が既に実行を停止している — 以下の表で「タスクなし」が関わる行は、ユーザーが明示的に `$ARGUMENTS` を指定した場合にのみ発火する。
 
 | 状態 | 基準 | 次のアクション |
 |------|------|--------------|
-| タスク存在 | tasks/ディレクトリに.mdファイルあり | ユーザーの実行指示をバッチ承認として自律実行へ移行 |
-| タスクなし+計画あり | 計画書は存在するがタスクファイルなし | ユーザー確認 → task-decomposer実行 |
-| どちらもなし＋Design Docあり | 計画書・タスクファイルなし、docs/design/*.mdあり | work-plannerでDesign Docから作業計画書を作成し、タスク分解へ進む |
-| どちらもなし | 計画書・タスクファイル・Design Docすべてなし | 前提条件未達成をユーザーに報告して停止 |
+| タスク存在 | Consumed Task Set が非空 | ユーザーの実行指示をバッチ承認として自律実行へ移行 |
+| タスクなし + `$ARGUMENTS`で計画書指定 | `$ARGUMENTS`が提供され Consumed Task Set が空 | ユーザーに確認 → task-decomposer実行（frontend命名ルールにより `*-frontend-task-*.md` を出力する） |
+| どちらもなし＋Design Docあり + `$ARGUMENTS`提供 | `$ARGUMENTS`が提供され、計画書なし、Consumed Task Setなし、ただし docs/design/*.md が存在 | work-plannerでDesign Docから作業計画書を作成し、タスク分解へ進む |
+| どちらもなし | `$ARGUMENTS`なし、計画書なし、Consumed Task Setなし、Design Docなし | 前提条件未達成をユーザーに報告して停止 |
 
 ## タスク分解フェーズ（条件付き）
 
-タスクファイルが存在しない場合：
+Consumed Task Set が空の場合：
 
 ### 1. ユーザー確認
 ```
-タスクファイルが見つかりません。
-作業計画: docs/plans/[plan-name].md
+Consumed Task Set にタスクファイルがありません。
+作業計画書: docs/plans/[plan-name].md
 
-作業計画からタスクを生成しますか？ (y/n):
+作業計画書からタスクを生成しますか？ (y/n):
 ```
 
 ### 2. タスク分解（承認された場合）
@@ -57,17 +81,14 @@ Agentツールでtask-decomposerを呼び出す:
 - `prompt`: "作業計画を読み込み、アトミックなタスクに分解。入力: docs/plans/[plan-name].md。出力: docs/plans/tasks/配下に個別タスクファイル。粒度: 1タスク = 1コミット = 独立実行可能"
 
 ### 3. 生成確認
-```bash
-# 生成されたタスクファイルを確認
-! ls -la docs/plans/tasks/*.md | head -10
-```
+上記「Consumed Task Set」セクションの制限パターンを使って Consumed Task Set を再計算し、非空であることを確認する。依然として空の場合はユーザーにエスカレーション — task-decomposer が静かに失敗したか、想定パターンに合致しないファイルを生成した可能性がある。
 
-**フロー**: タスク生成 → 自律実行（この順序で実行）
+**フロー**: タスク生成 → Consumed Task Set 再計算 → 自律実行（この順序）
 
 ## 実行前チェックリスト
 
-- [ ] docs/plans/tasks/にタスクファイルが存在することを確認
-- [ ] タスクの実行順序（依存関係）を特定
+- [ ] Consumed Task Set が非空であることを確認（上記「Consumed Task Set」セクションで計算）
+- [ ] Consumed Task Set 内のタスク実行順序（依存関係）を特定
 - [ ] **環境チェック**: タスク単位のコミットサイクルを実行可能か？
   - コミット機能が利用不可 → 自律実行モード前にエスカレーション
   - その他の環境（テスト、品質ツール） → サブエージェントがエスカレーション
@@ -75,7 +96,7 @@ Agentツールでtask-decomposerを呼び出す:
 ## タスク実行サイクル（4ステップサイクル）
 **必須実行サイクル**: `task-executor-frontend → エスカレーションチェック → quality-fixer-frontend → commit`
 
-各タスクで必須：
+Consumed Task Set 内の各タスクで必須：
 1. **TaskCreateでタスク登録**: 作業ステップを登録。必ず含める: 最初に「ロード済みスキルから具体ルールを抽出」、最後に「抽出ルールを最終JSON前に検証」
 2. **Agent tool** (subagent_type: "task-executor-frontend") → タスクファイルパスを prompt に渡し、構造化レスポンスを受け取る
 3. **task-executor-frontend レスポンスをチェック**:
@@ -104,8 +125,6 @@ Use loaded skills to execute that scope.
 Escalate when the required fix or investigation falls outside that scope.
 ```
 
-! ls -la docs/plans/*.md | head -10
-
 承認ステータスを確認してから進む。確認後、自律実行モードを開始。要件変更を検出したら即座に停止。
 
 ## 実装後検証（全タスク完了後）
@@ -128,7 +147,18 @@ Escalate when the required fix or investigation falls outside that scope.
    - 続いて quality-fixer-frontend、その後 fail した verifier のみ再実行。
    - 2サイクル後も fail が残る場合 → 残存指摘事項を添えてユーザーにエスカレーション
 
-4. **全て合格** → 完了レポートへ
+4. **全て合格** → 最終クリーンアップへ
+
+## 最終クリーンアップ
+
+完了レポートの前に、本レシピが消費した実装タスクファイルを削除する。作業内容はコミット済みで、`docs/plans/`はレシピ実行間で保持しない一時的な作業状態である:
+
+- Consumed Task Set 内のすべてのファイルを削除する
+- `docs/plans/tasks/{plan-name}-phase*-completion.md` にマッチするすべてのファイルを削除する（task-decomposer が生成した本 `{plan-name}` のフェーズ完了ファイル）
+- 該当する `docs/plans/tasks/_overview-{plan-name}.md` が存在する場合は削除する
+- 作業計画書本体（`docs/plans/{plan-name}.md`）は保持する — 最終レビュー後に削除するかはユーザーが判断する
+
+タスクファイルを削除できない場合（ファイルシステムエラー）、失敗を報告するが完了レポートをブロックしない。
 
 ## 出力例
 フロントエンド実装フェーズ完了。
@@ -136,3 +166,4 @@ Escalate when the required fix or investigation falls outside that scope.
 - 実装タスク: [件数] タスク
 - 品質チェック: 全てパス
 - コミット: [件数] コミット作成
+- クリーンアップ: docs/plans/tasks/ からタスクファイルを削除済み

package/.claude/commands-ja/front-plan.md

@@ -43,17 +43,18 @@ Agentツールでacceptance-test-generatorを呼び出す:
 - UI Specあり: `prompt: "[パス]のDesign Docからテストスケルトンを生成。UI Specは[ui-specパス]。"`
 - UI Specなし: `prompt: "[パス]のDesign Docからテストスケルトンを生成。"`
 
-統合テストファイルパス、E2Eテストファイルパス（またはnull）、およびe2eAbsenceReasonを、subagents-orchestration-guideの「acceptance-test-generator → work-planner」セクションに従いwork-plannerに渡す。
+レーン別のテストファイルパスと不在理由を、subagents-orchestration-guideの「acceptance-test-generator → work-planner」セクションに従いwork-plannerに渡す。
 
 ### Step 3: 作業計画書作成
 Agentツールでwork-plannerを呼び出す:
 - `subagent_type`: "work-planner"
 - `description`: "作業計画書作成"
-- ステップ2でテストスケルトンを生成した場合:
-  - `generatedFiles.e2e`がnullでない場合:
-    `prompt`: "[パス]のDesign Docから作業計画を作成。統合テストファイル: [ステップ2の統合テストパス]。E2Eテストファイル: [ステップ2のE2Eテストパス]。統合テストは各フェーズ実装と同時に作成、E2Eテストは最終フェーズでのみ実行。"
-  - `generatedFiles.e2e`がnullの場合:
-    `prompt`: "[パス]のDesign Docから作業計画を作成。統合テストファイル: [ステップ2の統合テストパス]。E2Eテストスケルトンは生成されませんでした（理由: [e2eAbsenceReason]）。統合テストは各フェーズ実装と同時に作成。"
+- ステップ2でテストスケルトンを生成した場合、各レーンの状態を列挙する形でプロンプトを構築する:
+  - 必ず含める: "統合テストファイル: [パス または 'not generated']"
+  - E2Eの各レーン（`fixtureE2e`、`serviceE2e`）について:
+    - `generatedFiles.<lane>`がnullでない場合: "[lane] テストファイル: [パス]"
+    - `generatedFiles.<lane>`がnullの場合: "[lane] スケルトンは生成されませんでした（理由: [e2eAbsenceReason.<lane>]）"
+  - 配置ガイダンスを末尾に付加する: "統合テストは各フェーズ実装と同時に作成。fixture-e2eテストはUI機能フェーズと並行して作成。service-integration-e2eテストは最終フェーズでのみ実行。"
 - テストスケルトンを生成しなかった場合:
   `prompt`: "[パス]のDesign Docから作業計画を作成。"
 
@@ -67,7 +68,7 @@ Agentツールでwork-plannerを呼び出す:
 計画内容承認後、以下の標準レスポンスで終了
 ```
 フロントエンド計画フェーズ完了。
-- 作業計画: docs/plans/[計画名].md
+- 作業計画: docs/plans/[plan-name].md
 - ステータス: 承認済み
 
 実装は別途指示してください。

package/.claude/commands-ja/front-review.md

@@ -14,9 +14,10 @@ description: Design Doc準拠検証とセキュリティ検証、必要に応じ
 
 - 準拠検証 → code-reviewerが実行
 - セキュリティ検証 → security-reviewerが実行
-- 修正実装 → task-executor-frontendが実行
-- 品質チェック → quality-fixer-frontendが実行
-- 再検証 → code-reviewer / security-reviewerが実行
+- **コード側修正パス**: 修正実装 → task-executor-frontend、品質チェック → quality-fixer-frontend、再検証 → code-reviewer / security-reviewer
+- **設計側更新パス**: DD改訂 → technical-designer-frontend（updateモード）、DDレビュー → document-reviewer、複数DDの整合性 → design-sync（複数DD存在時のみ）、再検証 → code-reviewer
+
+オーケストレーターはサブエージェントを呼び出し、構造化JSONを渡す。設計側パスは、コードが正しいのにDesign Docが古くなっていた不整合（コードがDDに違反したケースではない）に適用される。
 
 Design Doc（省略時は直近のもの）: $ARGUMENTS
 
@@ -59,7 +60,24 @@ Agent toolでsecurity-reviewerを呼び出す:
 - `approved` または `approved_with_notes` → 合格
 - `needs_revision` → 不合格
 
-**両方の結果をサブエージェントの出力フィールドのみを使用して独立に報告**（サブエージェントのレスポンスにないフィールドを追加しない）:
+**両方の結果をサブエージェントの出力フィールドのみを使用して独立に報告**（サブエージェントのレスポンスにないフィールドを追加しない）。
+
+**早期終了（ルーティング対象なし）**: code-reviewer の `verdict` が `pass` かつ `acceptanceCriteria[]` のすべてのエントリが `status: "fulfilled"` かつ `identifierMismatches[]` が空かつ `qualityFindings[]` が空かつ security-reviewer の `findings[]` が空の場合、Steps 5-10 をスキップして直接 Step 11 へ進む — ルーティング対象がないため。クリーンな結果をユーザーに提示する。
+
+それ以外の場合、ユーザー提示の前に、オーケストレーターは以下のルールで finding ごとに推奨ルートを計算する（このルール自体は内部用 — ユーザー向けプロンプトには含めない）。ルールは code-reviewer の既存構造化フィールドのみを参照する。「DDの意図」のような解釈は不安定な推論を避けるため意図的に行わない:
+
+| Finding ソース | 既存フィールドから検出可能なパターン | 推奨ルート |
+|---------------|----------------------------------|----------|
+| `acceptanceCriteria[]` で `status: "partially_fulfilled"` または `"unfulfilled"` | 引用された `gap` から、コードがACを満たしていないことが示される — 追加実装が必要 | `c`（コード側修正） |
+| `acceptanceCriteria[]` で `status: "partially_fulfilled"` または `"unfulfilled"` | 引用された `gap` から、ACテキスト自体が実装済み（チームが受け入れた）挙動から乖離していることが示される — 実装が要件を満たしていないのではなく、DDのAC文言が誤った意図を捉えているケース（ACを読み、引用された `location` と比較して検証する） | `d`（設計側更新 — ACテキストが古い） |
+| `identifierMismatches[]` | `codeValue` が `designDocValue` のリネームとして妥当（camelCase ↔ kebab-case ↔ snake_case、略語の展開/省略、同じ概念を指す意味的なリネーム）— 引用された `location` を確認してコードが新名称を一貫して使用していることを検証 | `d`（設計側更新 — DDが古い可能性が高い） |
+| `identifierMismatches[]` | それ以外の identifier mismatch（型違い、cardinality違い、完全欠落など） | `c`（コード側修正） |
+| `qualityFindings[]` | 全カテゴリ（`dd_violation`、`maintainability`、`reliability`、`coverage_gap`） | `c`（コード側修正） |
+| security-reviewer `findings[]` | 全カテゴリ（`confirmed_risk`、`defense_gap`、`hardening`、`policy`） | `c`（コード側修正） |
+
+各 finding に対しユーザーが推奨を上書き可能。`status: "fulfilled"` の AC 項目はルーティング対象外（対応不要）。
+
+ユーザーへの提示形式（finding ごとに推奨ルートをラベル付け、ルートでグルーピング）:
 
 ```
 Code Compliance: [code-reviewerのcomplianceRate]
@@ -67,30 +85,57 @@ Code Compliance: [code-reviewerのcomplianceRate]
   Identifier Match Rate: [code-reviewerのidentifierMatchRate]
   Acceptance Criteria:
   - [fulfilled] [item] (confidence: [high/medium/low])
-  - [partially_fulfilled] [item]: [gap] — [suggestion]
-  - [unfulfilled] [item]: [gap] — [suggestion]
+  - [partially_fulfilled] [item]: [gap] — [suggestion] [recommended: c | d]
+  - [unfulfilled] [item]: [gap] — [suggestion] [recommended: c | d]
   Identifier Mismatches:
-  - [identifier]: DD=[designDocValue] Code=[codeValue] at [location]
+  - [identifier]: DD=[designDocValue] Code=[codeValue] at [location] [recommended: c | d]
   Quality Findings:
-  - [category] [location]: [description] — [rationale]
+  - [category] [location]: [description] — [rationale] [recommended: c]
 
 Security Review: [security-reviewerのstatus]
   Findings by category:
-  - [confirmed_risk] [location]: [description] — [rationale]
-  - [defense_gap] [location]: [description] — [rationale]
-  - [hardening] [location]: [description] — [rationale]
-  - [policy] [location]: [description] — [rationale]
+  - [confirmed_risk] [location]: [description] — [rationale] [recommended: c]
+  - [defense_gap] [location]: [description] — [rationale] [recommended: c]
+  - [hardening] [location]: [description] — [rationale] [recommended: c]
+  - [policy] [location]: [description] — [rationale] [recommended: c]
   Notes: [security-reviewerのnotes、存在する場合]
 
-修正を実行しますか？ (y/n):
+不整合の解消 — finding ごとに推奨ルートを承認または上書きする:
+  c) コード側修正  — コードがDesign Docに違反; コードを修正して合わせる
+  d) 設計側更新   — コードは正しい; Design Docが古いので改訂する
+  s) スキップ     — 現状を受け入れて変更しない
 ```
 
-両方合格でユーザーが`n`を選択: Steps 5-10をスキップし、Step 11へ。
+AskUserQuestionを使用する。デフォルト提示は **「すべての推奨ルートを承認」** — オーケストレーターの推奨が正しい典型ケース向けの単一確認。ユーザーが上書きしたい場合は finding ごとに c/d/s を収集する。すべてに対し `s` を選択した場合: Steps 5-10をスキップしてStep 11へ進む。
 
 ### Step 5: タスクテンプレートの読み込み
 
 documentation-criteriaスキルを読み込み、Step 6用のタスクファイルテンプレート（references/task-template.md）を取得。
 
+### Step 5d: 設計側更新
+
+ユーザーが少なくとも1つのfindingを `d` にルーティングした場合のみ、本ステップを実行する。すべてのルートが `c` または `s` の場合は、Step 6 へ直接スキップする。
+
+1. Agent tool で technical-designer-frontend を update モードで呼び出す:
+   - `subagent_type`: "technical-designer-frontend"
+   - `description`: "レビューfindingsからのDesign Doc更新"
+   - `prompt`: "[path]のDesign Docをupdateモードで更新する。実装は以下の点で乖離しており、チームはコード側ではなく設計側で受け入れる判断をした: [`d` ルートのfindingsを $STEP_2_OUTPUT の codeLocation と designDocValue 付きでリスト化]。該当セクションに現在のコードの挙動を反映し、履歴エントリを追加する。"
+
+2. document-reviewer を呼び出して更新後の Design Doc を検証する:
+   - `subagent_type`: "document-reviewer"
+   - `description`: "更新後Design Docのレビュー"
+   - `prompt`: "[path]の更新後Design Docの整合性と完成度をレビュー。"
+
+3. 複数のDesign Docが存在する場合（`ls docs/design/*.md | grep -v template | wc -l > 1`）、design-syncを呼び出す:
+   - `subagent_type`: "design-sync"
+   - `description`: "DD間整合性チェック"
+   - `prompt`: "source_design: [更新後DDのパス]。更新後の全Design Doc間の矛盾を検出。"
+   - `sync_status: conflicts_found` の場合: 矛盾をユーザーに提示し、影響を受けるDDに対して technical-designer-frontend を再起動して解消する。
+
+4. Step 5d 完了後:
+   - ユーザーが選択した `c` ルートがゼロの場合（すべて `d`、すべて `s`、または `c` を含まない `d` + `s` の混在）→ Steps 6-8 をスキップし、Step 9 で再検証へ進む
+   - `d` と `c` の両方が選択された場合 → 更新後のDDに対して `c` ルートのfindingsを再評価し、DD改訂で満たされたものは除外する。残った `c` ルートのfindings で Step 6 へ進む
+
 ### Step 6: タスクファイル作成
 
 `docs/plans/tasks/review-fixes-YYYYMMDD.md` にタスクファイルを作成。
@@ -113,7 +158,7 @@ Agent toolでquality-fixer-frontendを呼び出す:
 Agent toolでcode-reviewerを呼び出す:
 - `subagent_type`: "code-reviewer"
 - `description`: "準拠の再検証"
-- `prompt`: "修正後のDesign Doc準拠を再検証。Design Doc: [path]. Implementation files: [file list]. 前回の準拠問題: $STEP_2_OUTPUT。各問題が解決されたことを確認。"
+- `prompt`: "修正後のDesign Doc準拠を再検証。Design Doc: [path]. Implementation files: [file list]. 前回の準拠問題: $STEP_2_OUTPUT。各問題が解決されたこと（コード側または設計側いずれかで）を確認。"
 
 ### Step 10: security-reviewer再検証
 
@@ -122,7 +167,16 @@ Agent toolでsecurity-reviewerを呼び出す（セキュリティ修正が実
 - `description`: "セキュリティの再検証"
 - `prompt`: "修正後のセキュリティを再検証。前回の検出結果: $STEP_3_OUTPUT。Design Doc: [path]. Implementation files: [file list]。"
 
-### Step 11: 最終レポート
+### Step 11: 最終クリーンアップとレポート
+
+本レシピが作成したreview-fix用タスクファイル（存在すれば）を削除する。作業内容はコミット済みで、`docs/plans/`はレシピ実行間で保持しない一時的な作業状態である:
+
+- `docs/plans/tasks/review-fixes-YYYYMMDD.md` が存在すれば削除する
+
+タスクファイルを削除できない場合（ファイルシステムエラー）、失敗を報告するが最終レポートをブロックしない。
+
+その後、最終レポートを提示する:
+
 ```
 Code Compliance:
   初回: [X]%
@@ -135,9 +189,11 @@ Security Review:
 
 残存課題:
 - [手動対応が必要な項目]
+
+クリーンアップ: review-fixesタスクファイルを削除済み
 ```
 
-## 自動修正可能な項目
+## 自動修正可能な項目（コード側パス）
 - 単純な未実装受入条件
 - エラーハンドリング追加
 - 契約定義の修正
@@ -147,10 +203,16 @@ Security Review:
 ## 自動修正不可な項目
 - 根本的なビジネスロジック変更
 - アーキテクチャレベルの修正
-- Design Doc自体の不備
 - コミット済みシークレット（blocked → 人間の判断が必要）
 
-**スコープ**: Design Doc準拠検証、セキュリティレビュー、自動修正。
+## 設計側更新の対象
+設計側パスに適した不整合（コードが正しく、DDが古くなったケース）:
+- 新しい命名がチームの現行命名を反映している identifier rename
+- 元の要件意図に対し、DDが捉えた挙動より実装の方が合致している挙動変更
+- 新しい構造が妥当で、DDが旧構造を文書化していたままのコンポーネント分割・統合
+- 実装は既に満たしているがDDに列挙されていなかった新規AC
+
+**スコープ**: Design Doc準拠検証、セキュリティレビュー、コード側自動修正、および設計側更新ルーティング。
 
 ## サブエージェントのスコープ境界
 

package/.claude/commands-ja/implement.md

@@ -58,6 +58,19 @@ requirement-analyzerの`crossLayerScope`がレイヤー横断（backend + fronte
 
 **フロー厳守**: subagents-orchestration-guideスキルの「自律実行中のタスク管理」に従い、TaskCreate/TaskUpdateで4ステップを管理する
 
+## Implementation Readinessチェック（work-planner承認とtask-decomposerの間）
+
+work-plannerが完了しユーザーから一括承認を得た後、task-decomposerを呼び出す前に作業計画書のヘッダを読み、`Implementation Readiness: <status>`の行を見つける。以下のルールを適用する:
+
+| ステータス | アクション |
+|--------|--------|
+| `ready` | task-decomposerに進む |
+| `escalated` | 作業計画書のReadiness Reportセクションを読み、AskUserQuestionで残存ギャップをユーザーに提示する: 「Implementation Readinessが`escalated`で、以下の残存ギャップがあります: [リスト]。実行を継続しますか？(y/n)」。`y`なら進む、`n`なら停止 |
+| `pending` | AskUserQuestionで提示する: 「Implementation Readinessが`pending`です。事前にreadiness preflightを実行して作業計画書の実装可能性を検証してから再開してください。preflightなしで継続しますか？(y/n)」。`y`なら進む、`n`なら停止 |
+| 行が存在しない | `pending`として扱う — readinessマーカー導入前に作成された古い作業計画書は明示的にpreflightすべき |
+
+このチェックは全規模（Small / Medium / Large）に適用される。本レシピは規模に依存しないオーケストレーターであるため。
+
 ## サブエージェントのスコープ境界
 
 本レシピから呼び出すサブエージェントプロンプトの末尾に以下のブロックを必ず付与する:
@@ -101,11 +114,29 @@ subagents-orchestration-guideスキルの「自律実行中のタスク管理」
    - `blocked` → ユーザーにエスカレーション
 
 ### テスト情報の伝達
-acceptance-test-generator実行後、work-planner（subagent_type: "work-planner"）呼び出し時には以下を伝達：
-- 統合テストファイルパス（`generatedFiles.integration`から取得）
-- E2Eテストファイルパスまたはnull（`generatedFiles.e2e`から取得）
-- E2E不在理由（`e2eAbsenceReason`、E2Eがnullの場合）
-- 統合テストは実装と同時に作成、E2Eテストは全実装完了後に実行（E2Eパスが提供された場合）
+acceptance-test-generator実行後、work-planner（subagent_type: "work-planner"）呼び出し時にはレーン別に伝達する：
+- 統合テストファイルパス（`generatedFiles.integration`から取得）または null
+- fixture-e2eテストファイルパス（`generatedFiles.fixtureE2e`から取得）または null
+- service-integration-e2eテストファイルパス（`generatedFiles.serviceE2e`から取得）または null
+- レーン別の不在理由（`e2eAbsenceReason.fixtureE2e` / `e2eAbsenceReason.serviceE2e`、当該レーンが null の場合）
+- タイミングの明示: 統合テストは各フェーズ実装と並行して作成、fixture-e2eテストはUI機能フェーズと並行して作成、service-integration-e2eテストは最終フェーズでのみ実行
+
+### 最終クリーンアップ
+
+完了レポートの前に、本レシピが消費した実装タスクファイルを削除する。作業内容はコミット済みで、`docs/plans/`はレシピ実行間で保持しない一時的な作業状態である。
+
+本レシピは規模に依存せず、単層・複層のいずれの計画も実行する可能性があるため、クリーンアップはtask-decomposerの「Layer-aware naming」が出力するすべてのタスク命名パターンを対象とする:
+
+- 本実行で使用した作業計画書パスから導出した `{plan-name}` について、以下のいずれかにマッチするファイルすべてを削除する:
+  - `docs/plans/tasks/{plan-name}-task-*.md`（単層タスク）
+  - `docs/plans/tasks/{plan-name}-backend-task-*.md`（複層計画のbackend部分）
+  - `docs/plans/tasks/{plan-name}-frontend-task-*.md`（複層計画のfrontend部分）
+- 上記マッチから、以下のパターンに該当するものは除外する: `*-task-prep-*.md`、`_overview-*.md`、`*-phase*-completion.md`、`review-fixes-*.md`、`integration-tests-*-task-*.md`（これらは他のワークフローフェーズに由来する）
+- `docs/plans/tasks/{plan-name}-phase*-completion.md` にマッチするファイルすべてを削除する（task-decomposerが生成したフェーズ完了ファイル）
+- 該当する `docs/plans/tasks/_overview-{plan-name}.md` が存在する場合は削除する
+- 作業計画書本体（`docs/plans/{plan-name}.md`）は保持する — 最終レビュー後に削除するかはユーザーが判断する
+
+タスクファイルを削除できない場合（ファイルシステムエラー）、失敗を報告するが完了レポートをブロックしない。
 
 ## 実行方法
 

package/.claude/commands-ja/plan.md

@@ -36,20 +36,21 @@ description: 設計書から作業計画書を作成し計画承認を取得
    - 設計書の存在を確認し、ない場合はその旨をユーザーに通知
    - 複数ある場合は選択肢を提示（$ARGUMENTS で指定可能）
 
-2. **E2Eテストスケルトンの生成確認**
-   - E2Eテストスケルトンを先に生成するかユーザーに確認
-   - 生成を希望する場合: acceptance-test-generator でテストスケルトンを生成
+2. **テストスケルトンの生成確認**
+   - テストスケルトン（統合 + E2Eレーン）を先に生成するかユーザーに確認
+   - 生成を希望する場合: acceptance-test-generator を呼び出す
    - 生成結果を subagents-orchestration-guideスキル の連携仕様に従って次工程に引き継ぐ
 
 3. **作業計画書の作成**
    Agentツールでwork-plannerを呼び出す:
    - `subagent_type`: "work-planner"
    - `description`: "作業計画書作成"
-   - ステップ2でテストスケルトンを生成した場合:
-     - `generatedFiles.e2e`がnullでない場合:
-       `prompt`: "[パス]のDesign Docから作業計画を作成。統合テストファイル: [ステップ2の統合テストパス]。E2Eテストファイル: [ステップ2のE2Eテストパス]。統合テストは各フェーズ実装と同時に作成、E2Eテストは最終フェーズでのみ実行。"
-     - `generatedFiles.e2e`がnullの場合:
-       `prompt`: "[パス]のDesign Docから作業計画を作成。統合テストファイル: [ステップ2の統合テストパス]。E2Eテストスケルトンは生成されませんでした（理由: [e2eAbsenceReason]）。統合テストは各フェーズ実装と同時に作成。"
+   - ステップ2でテストスケルトンを生成した場合、各レーンの状態を列挙する形でプロンプトを構築する:
+     - 必ず含める: "統合テストファイル: [パス または 'not generated']"
+     - E2Eの各レーン（`fixtureE2e`、`serviceE2e`）について:
+       - `generatedFiles.<lane>`がnullでない場合: "[lane] テストファイル: [パス]"
+       - `generatedFiles.<lane>`がnullの場合: "[lane] スケルトンは生成されませんでした（理由: [e2eAbsenceReason.<lane>]）"
+     - 配置ガイダンスを末尾に付加する: "統合テストは各フェーズ実装と同時に作成。fixture-e2eテストはUI機能フェーズと並行して作成。service-integration-e2eテストは最終フェーズでのみ実行。"
    - テストスケルトンを生成しなかった場合:
      `prompt`: "[パス]のDesign Docから作業計画を作成。"
 
@@ -64,7 +65,7 @@ description: 設計書から作業計画書を作成し計画承認を取得
 ✅ **必須**: 計画内容の承認後は以下の定型応答で終了
 ```
 計画フェーズが完了しました。
-- 作業計画書: docs/plans/[計画書名].md
+- 作業計画書: docs/plans/[plan-name].md
 - 状態: 承認済み
 
 実装は別途ご指示ください。