create-ai-project 1.16.2 → 1.17.0

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

@@ -2,11 +2,21 @@
 description: 分解済みタスクを自律実行モードで実装
 ---
 
-subagents-orchestration-guideスキルの指針に従い、**オーケストレーター**として振る舞います — 役割はサブエージェントの呼び出し、データの受け渡し、結果の報告。
+## オーケストレーター定義
+
+**コアアイデンティティ**: 「私は作業者ではない。オーケストレーターである。」（subagents-orchestration-guideスキル参照）
+
+**実行プロトコル**:
+1. **全作業をサブエージェントに委譲** — 役割はサブエージェントの呼び出し、データの受け渡し、結果の報告
+2. **4ステップサイクルに厳密に従う**: task-executor → エスカレーションチェック → quality-fixer → commit
+3. **自律実行モード移行**: ユーザーの実行指示とタスクファイルの存在をもってバッチ承認とする
+4. **スコープ**: 全タスクのコミット完了またはエスカレーション発生で完了
+
+**重要**: 全てのコミット前にquality-fixerを実行。
 
 作業計画書: $ARGUMENTS
 
-## 📋 実行前の前提確認
+## 実行前提条件
 
 ### タスクファイル存在チェック
 ```bash
@@ -23,24 +33,23 @@ subagents-orchestration-guideスキルの指針に従い、**オーケストレ
 
 | 状態 | 判定基準 | 次のアクション |
 |------|---------|--------------|
-| タスク存在 | tasks/ディレクトリに.mdファイルあり | 自律実行モードへ移行 |
+| タスク存在 | tasks/ディレクトリに.mdファイルあり | ユーザーの実行指示をバッチ承認として自律実行へ移行 |
 | タスクなし＋計画書あり | 計画書は存在するがタスクファイルなし | ユーザーに確認 → task-decomposer実行 |
 | 両方なし | 計画書もタスクファイルもなし | エラー：実行条件を満たさない |
 
-## 🔄 タスク分解フェーズ（条件付き実行）
+## タスク分解フェーズ（条件付き実行）
 
-タスクファイルが存在しない場合の処理：
+タスクファイルが存在しない場合：
 
 ### 1. ユーザー確認
 ```
 タスクファイルが見つかりません。
 作業計画書: docs/plans/[計画書名].md
 
-計画書からタスクを分解して生成しますか？ (y/n): 
+計画書からタスクを生成しますか？ (y/n):
 ```
 
 ### 2. タスク分解実行（承認時）
-
 Taskツールでtask-decomposerを呼び出す:
 - `subagent_type`: "task-decomposer"
 - `description`: "作業計画をタスクに分解"
@@ -52,23 +61,52 @@ Taskツールでtask-decomposerを呼び出す:
 ! ls -la docs/plans/tasks/*.md | head -10
 ```
 
-✅ **推奨**: タスク生成完了後、自動的に自律実行モードへ移行
-❌ **避ける**: タスク未生成のまま実装を開始
+✅ **フロー**: タスク生成 → 自律実行（この順序で実行）
+
+## 実行前チェックリスト
+
+- [ ] docs/plans/tasks/にタスクファイルが存在することを確認
+- [ ] タスクの実行順序（依存関係）を特定
+- [ ] **環境チェック**: タスク単位のコミットサイクルを実行可能か？
+  - コミット機能が利用不可 → 自律実行モード前にエスカレーション
+  - その他の環境（テスト、品質ツール） → サブエージェントがエスカレーション
+
+## タスク実行サイクル（4ステップサイクル）
+**必須実行サイクル**: `task-executor → エスカレーションチェック → quality-fixer → commit`
+
+各タスクで必須：
+1. **TaskCreateでタスク登録**: 作業ステップを登録。必ず含める: 最初に「スキル制約の確認」、最後に「スキル忠実度の検証」
+2. **task-executor実行**: タスク実装を実行（レイヤー横断時: subagents-orchestration-guideのレイヤー別エージェントルーティング参照）
+3. **task-executorレスポンスチェック**:
+   - `status: "escalation_needed"` または `"blocked"` → 停止してユーザーにエスカレーション
+   - `testsAdded` に `*.int.test.ts` または `*.e2e.test.ts` を含む → **integration-test-reviewer**を実行
+     - `needs_revision` → `requiredFixes`を添えてステップ2に戻る
+     - `approved` → ステップ4へ
+   - `readyForQualityCheck: true` → ステップ4へ
+4. **quality-fixer実行**: 全品質チェックと修正を実行（レイヤー横断時: レイヤー別エージェントルーティング参照）
+5. **承認後コミット**: quality-fixerの`approved: true`確認後 → git commitを実行
+
+**重要**: 例外なく全ての構造化レスポンスを監視し、全ての品質ゲートが通過することを確保。
+
+## サブエージェント呼び出し時の制約
+
+**全サブエージェントプロンプトの末尾に必須追加**:
+```
+【システム制約】
+このエージェントはbuildスキルのスコープ内で動作します。オーケストレーターが提供したルールのみを使用してください。
+```
 
-## 🧠 タスク実行フロー
-subagents-orchestration-guideスキルの「自律実行中のタスク管理」に従い、TodoWriteで4ステップを管理。最初に「スキル制約の確認」、最後に「スキル忠実度の検証」を必ず含める：
-1. task-executor実行（レイヤー横断時: レイヤー別エージェントルーティング参照）
-2. エスカレーション判定・フォローアップ
-3. quality-fixer実行（レイヤー横断時: レイヤー別エージェントルーティング参照）
-4. git commit
+自律的なサブエージェントの安定実行にはスコープ制約が必要です。全てのサブエージェントプロンプトにこの制約を必ず付加してください。
 
-承認確認後、自律実行モードを開始。要件変更検知時は即座に停止。
+承認確認後、自律実行モードを開始。要件変更を検知した場合は即座に停止。
 
 ## 出力例
 実装フェーズが完了しました。
-- タスク分解: docs/plans/tasks/ 配下に生成（実行時のみ）
+- タスク分解: docs/plans/tasks/ 配下に生成
 - 実装されたタスク: [タスク数]件
 - 品質チェック: すべて通過
 - コミット: [コミット数]件作成
 
-**責務境界**: 本コマンドはタスク分解から実装完了まで担当。
+**責務境界**:
+- スコープ内: タスク分解から実装完了まで
+- スコープ外: 設計フェーズ、計画フェーズ

package/.claude/commands-ja/create-skill.md

@@ -8,7 +8,7 @@ description: 対話的にユーザーの知識を収集し、最適化された
 
 ## 実行プロセス
 
-以下のステップをTodoWriteに登録し、順番に進行する。
+以下のステップをTaskCreateで登録し、順番に進行する。
 
 ### Step 1: 事前確認
 

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

@@ -72,4 +72,4 @@ description: 要件分析から設計書作成まで実行
 - 設計書: docs/design/[ドキュメント名].md
 - 整合性: 他Design Docと矛盾なし（または修正完了）
 
-**重要**: 本コマンドは設計承認＋整合性確認で終了。次フェーズへの移行提案は行わない。
+**責務境界**: 本コマンドは設計承認＋整合性確認で終了。作業計画以降はスコープ外。

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

@@ -15,7 +15,7 @@ description: 問題を調査し、検証を経て解決策を導出する
 
 オーケストレーターがサブエージェントを呼び出し、構造化JSONを受け渡します。
 
-**TodoWrite登録**: 実行ステップをTodoWriteに登録し、計画的にタスクを進める
+**タスク登録**: 実行ステップをTaskCreateで登録し、計画的にタスクを進める
 
 ## ステップ0: 問題の構造化（investigator呼び出し前）
 
@@ -74,7 +74,7 @@ rule-advisorの出力から以下を確認：
 
 ## 実行ステップ
 
-以下をTodoWriteに登録して実行：
+以下をTaskCreateで登録して実行：
 
 ### ステップ1: 調査（investigator）
 

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

@@ -7,14 +7,19 @@ description: フロントエンド実装を自律実行モードで実行
 **コアアイデンティティ**: 「私は作業者ではない。オーケストレーターである。」（subagents-orchestration-guideスキル参照）
 
 **実行方法**:
-- タスク分解 → task-decomposer
-- フロントエンド実装 → task-executor-frontend
-- 品質チェックと修正 → quality-fixer-frontend
+- タスク分解 → task-decomposerが実行
+- フロントエンド実装 → task-executor-frontendが実行
+- 品質チェックと修正 → quality-fixer-frontendが実行
 - コミット → オーケストレーター（Bashツール）
 
 オーケストレーターはサブエージェントを呼び出し、構造化JSONを渡します。
 
-**重要**: 全てのコミット前にquality-fixer-frontendを実行。自律実行モード前にバッチ承認を取得。
+**実行プロトコル**:
+1. **全作業をサブエージェントに委譲** — 役割はサブエージェントの呼び出し、データの受け渡し、結果の報告
+2. **4ステップサイクルに厳密に従う**: task-executor-frontend → エスカレーションチェック → quality-fixer-frontend → commit
+3. **自律実行モード移行**: ユーザーの実行指示とタスクファイルの存在をもってバッチ承認とする
+
+**重要**: 全てのコミット前にquality-fixer-frontendを実行。
 
 作業計画: $ARGUMENTS
 
@@ -35,7 +40,7 @@ description: フロントエンド実装を自律実行モードで実行
 
 | 状態 | 基準 | 次のアクション |
 |------|------|--------------|
-| タスク存在 | tasks/ディレクトリに.mdファイルあり | 自律実行へ進む |
+| タスク存在 | tasks/ディレクトリに.mdファイルあり | ユーザーの実行指示をバッチ承認として自律実行へ移行 |
 | タスクなし+計画あり | 計画書は存在するがタスクファイルなし | ユーザー確認 → task-decomposer実行 |
 | どちらもなし | 計画書もタスクファイルもなし | エラー: 前提条件未達成 |
 
@@ -52,7 +57,6 @@ description: フロントエンド実装を自律実行モードで実行
 ```
 
 ### 2. タスク分解（承認された場合）
-
 Taskツールでtask-decomposerを呼び出す:
 - `subagent_type`: "task-decomposer"
 - `description`: "作業計画をタスクに分解"
@@ -64,7 +68,15 @@ Taskツールでtask-decomposerを呼び出す:
 ! ls -la docs/plans/tasks/*.md | head -10
 ```
 
-✅ **フロー**: タスク生成 → 自律実行
+✅ **フロー**: タスク生成 → 自律実行（この順序で実行）
+
+## 実行前チェックリスト
+
+- [ ] docs/plans/tasks/にタスクファイルが存在することを確認
+- [ ] タスクの実行順序（依存関係）を特定
+- [ ] **環境チェック**: タスク単位のコミットサイクルを実行可能か？
+  - コミット機能が利用不可 → 自律実行モード前にエスカレーション
+  - その他の環境（テスト、品質ツール） → サブエージェントがエスカレーション
 
 ## タスク実行サイクル（4ステップサイクル） - フロントエンド特化
 
@@ -79,28 +91,38 @@ Taskツールを使用してサブエージェントを呼び出す：
 ### 構造化レスポンス仕様
 各サブエージェントはJSON形式で応答：
 - **task-executor-frontend**: status, filesModified, testsAdded, readyForQualityCheck
+- **integration-test-reviewer**: status (approved/needs_revision/blocked), requiredFixes
 - **quality-fixer-frontend**: status, checksPerformed, fixesApplied, approved
 
 ### 各タスクの実行フロー
 
 各タスクで必須：
 
-1. **TodoWrite更新**: 作業ステップを登録。必ず含める: 最初に「スキル制約の確認」、最後に「スキル忠実度の検証」
-2. **task-executor-frontend使用**: フロントエンド実装を実行
+1. **TaskCreateでタスク登録**: 作業ステップを登録。必ず含める: 最初に「スキル制約の確認」、最後に「スキル忠実度の検証」
+2. **task-executor-frontend実行**: フロントエンド実装を実行
    - 呼び出し例: `subagent_type: "task-executor-frontend"`, `description: "タスク実行"`, `prompt: "タスクファイル: docs/plans/tasks/[ファイル名].md 実装を実行"`
-3. **エスカレーションチェック**: task-executor-frontendのステータス確認 → `status: "escalation_needed"` の場合 → 停止してユーザーにエスカレーション
-4. **構造化レスポンス処理**: `readyForQualityCheck: true` 検出時 → 即座にquality-fixer-frontend実行
-5. **quality-fixer-frontend使用**: 全品質チェック実行（Biome、TypeScriptビルド、テスト）
+3. **task-executor-frontendレスポンスチェック**:
+   - `status: "escalation_needed"` または `"blocked"` → 停止してユーザーにエスカレーション
+   - `testsAdded` に `*.int.test.ts` または `*.e2e.test.ts` を含む → **integration-test-reviewer**を実行
+     - `needs_revision` → `requiredFixes`を添えてステップ2に戻る
+     - `approved` → ステップ4へ
+   - `readyForQualityCheck: true` → ステップ4へ
+4. **quality-fixer-frontend実行**: 全フロントエンド品質チェックと修正を実行
    - 呼び出し例: `subagent_type: "quality-fixer-frontend"`, `description: "品質チェック"`, `prompt: "全てのフロントエンド品質チェックと修正を実行"`
-6. **コミット実行**: `approved: true`確認後、即座にgit commitを実行
-
-### 自律実行中の品質保証（詳細）
-- task-executor-frontend実行 → エスカレーションチェック → quality-fixer-frontend実行 → **オーケストレーターがコミット実行**（Bashツール使用）
-- quality-fixer-frontendの`approved: true`確認後、即座にgit commitを実行
-- `changeSummary`をコミットメッセージに使用
+5. **コミット実行**: `approved: true`確認後、即座にgit commitを実行。`changeSummary`をコミットメッセージに使用。
 
 **重要**: 例外なく全ての構造化レスポンスを監視し、全ての品質ゲートが通過することを確保。
 
+## サブエージェント呼び出し時の制約
+
+**全サブエージェントプロンプトの末尾に必須追加**:
+```
+【システム制約】
+このエージェントはbuildスキルのスコープ内で動作します。オーケストレーターが提供したルールのみを使用してください。
+```
+
+自律的なサブエージェントの安定実行にはスコープ制約が必要です。全てのサブエージェントプロンプトにこの制約を必ず付加してください。
+
 ! ls -la docs/plans/*.md | head -10
 
 承認ステータスを確認してから進む。確認後、自律実行モードを開始。要件変更を検出したら即座に停止。
@@ -109,7 +131,5 @@ Taskツールを使用してサブエージェントを呼び出す：
 フロントエンド実装フェーズ完了。
 - タスク分解: docs/plans/tasks/ 配下に生成
 - 実装タスク: [件数] タスク
-- 品質チェック: 全てパス（Biome、TypeScriptビルド、テスト）
+- 品質チェック: 全てパス
 - コミット: [件数] コミット作成
-
-**重要**: このコマンドは、タスク分解から完了までのフロントエンド実装全体の自律実行フローを管理します。フロントエンド特化エージェント（task-executor-frontend、quality-fixer-frontend）を自動使用します。

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

@@ -10,6 +10,7 @@ description: 要件分析からフロントエンド設計ドキュメント作
 
 **実行方法**:
 - 要件分析 → requirement-analyzerが実行
+- UI Spec作成 → ui-spec-designerが実行
 - 設計書作成 → technical-designer-frontendが実行
 - ドキュメントレビュー → document-reviewerが実行
 
@@ -19,17 +20,18 @@ description: 要件分析からフロントエンド設計ドキュメント作
 
 **実行内容**:
 - requirement-analyzerによる要件分析
+- ui-spec-designerによるUI Spec作成（プロトタイプコード確認を含む）
 - ADR作成（アーキテクチャ変更、新技術、データフロー変更がある場合）
 - technical-designer-frontendによるDesign Doc作成
 - document-reviewerによるドキュメントレビュー
 
-**責務境界**: このコマンドは設計書承認で責務完了。
+**責務境界**: このコマンドはフロントエンド設計ドキュメント（UI Spec/ADR/Design Doc）の承認で責務完了。作業計画以降はスコープ外。
 
 要件: $ARGUMENTS
 
 ## 実行フロー
 
-### 1. 要件分析フェーズ
+### Step 1: 要件分析フェーズ
 設計への影響が深いことを考慮し、まず対話により要件の背景と目的を理解:
 - 何の問題を解決したいか
 - 期待する成果と成功基準
@@ -42,20 +44,35 @@ description: 要件分析からフロントエンド設計ドキュメント作
   - `prompt: "要件: [ユーザー要件] 要件分析と規模判定を実施してください"`
 - **[停止]**: 要件分析結果を確認し、質問事項に対応
 
-### 2. 設計ドキュメント作成フェーズ
+### Step 2: UI Specフェーズ
+要件分析承認後、プロトタイプコードについてユーザーに確認:
+
+**ユーザーに確認**: 「この機能のプロトタイプコードはありますか？ある場合はコードへのパスを教えてください。プロトタイプはUI Specの参考資料として`docs/ui-spec/assets/`に配置されます。」
+
+- **[停止]**: プロトタイプコードの有無についてユーザーの回答を待つ
+
+UI Specを作成:
+- Taskツールで**ui-spec-designer**を呼び出す
+  - `subagent_type: "ui-spec-designer"`
+  - `description: "UI Spec作成"`
+  - PRDあり＋プロトタイプあり: `prompt: "[パス]のPRDからUI Specを作成。プロトタイプコードは[ユーザー提供パス]。プロトタイプをdocs/ui-spec/assets/{feature-name}/に配置"`
+  - PRDあり＋プロトタイプなし: `prompt: "[パス]のPRDからUI Specを作成。プロトタイプコードなし。"`
+  - PRDなし（中規模）: `prompt: "以下の要件に基づいてUI Specを作成: [requirement-analyzerの出力を渡す]。PRDなし。"`（プロトタイプパスがあれば追加）
+- **document-reviewer**でUI Specを検証
+  - `subagent_type: "document-reviewer"`, `description: "UI Specレビュー"`, `prompt: "doc_type: UISpec target: [ui-specパス] 整合性と完成度をレビュー"`
+- **[停止]**: UI Specをユーザーに提示し承認を取得
+
+### Step 3: 設計ドキュメント作成フェーズ
 規模判定に応じて適切な設計ドキュメントを作成:
 - Taskツールで**technical-designer-frontend**を呼び出す
   - ADRの場合: `subagent_type: "technical-designer-frontend"`, `description: "ADR作成"`, `prompt: "[技術決定]のADRを作成"`
-  - Design Docの場合: `subagent_type: "technical-designer-frontend"`, `description: "Design Doc作成"`, `prompt: "要件に基づいてDesign Docを作成"`
-- Taskツールで**document-reviewer**を呼び出して整合性検証
+  - Design Docの場合: `subagent_type: "technical-designer-frontend"`, `description: "Design Doc作成"`, `prompt: "要件に基づいてDesign Docを作成。UI Specは[ui-specパス]。UI Specのコンポーネント構造と状態設計を継承。"`
+- **document-reviewer**で整合性検証
   - `subagent_type: "document-reviewer"`, `description: "ドキュメントレビュー"`, `prompt: "[ドキュメントパス]の整合性と完成度をレビュー"`
 - **[停止]**: 設計の選択肢とトレードオフを提示し、ユーザー承認を取得
 
-**スコープ**: フロントエンド設計ドキュメント（ADR/Design Doc）の承認まで。作業計画以降はこのコマンドの範囲外。
-
 ## 出力例
 フロントエンド設計フェーズ完了。
+- UI Spec: docs/ui-spec/[機能名]-ui-spec.md
 - 設計ドキュメント: docs/design/[ドキュメント名].md または docs/adr/[ドキュメント名].md
 - 承認ステータス: ユーザー承認済み
-
-**重要**: このコマンドは設計承認で終了。次フェーズへの移行は提案しません。

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

@@ -9,6 +9,7 @@ description: 設計ドキュメントからフロントエンド作業計画書
 **Role**: オーケストレーター
 
 **実行方法**:
+- テストスケルトン生成 → acceptance-test-generatorが実行
 - 作業計画書作成 → work-plannerが実行
 
 オーケストレーターはサブエージェントを呼び出し、構造化JSONを渡します。
@@ -17,6 +18,7 @@ description: 設計ドキュメントからフロントエンド作業計画書
 
 **実行内容**:
 - 設計書の選択
+- acceptance-test-generatorによるテストスケルトン生成
 - work-plannerによる作業計画書作成
 - 計画承認の取得
 
@@ -31,19 +33,25 @@ description: 設計ドキュメントからフロントエンド作業計画書
 - 設計ドキュメントの存在を確認、なければユーザーに通知
 - 複数ある場合は選択肢を提示（$ARGUMENTSで指定可能）
 
-### 2. 作業計画書作成
+### 2. テストスケルトン生成
+Taskツールで**acceptance-test-generator**を呼び出す:
+- `subagent_type`: "acceptance-test-generator"
+- `description`: "テストスケルトン生成"
+- UI Specあり: `prompt: "[パス]のDesign Docからテストスケルトンを生成。UI Specは[ui-specパス]。"`
+- UI Specなし: `prompt: "[パス]のDesign Docからテストスケルトンを生成。"`
+
+### 3. 作業計画書作成
 Taskツールで**work-planner**を呼び出す:
-- `subagent_type: "work-planner"`
-- `description: "作業計画書作成"`
-- `prompt: "[パス]のDesign Docから作業計画を作成"`
-- ユーザーと対話して計画を完成させ、計画内容の承認を得る
+- `subagent_type`: "work-planner"
+- `description`: "作業計画書作成"
+- `prompt`: "[パス]のDesign Docから作業計画を作成。統合テストファイル: [step 2からのパス]。E2Eテストファイル: [step 2からのパス]。統合テストは各フェーズ実装と同時に作成、E2Eテストは最終フェーズでのみ実行。"
 
-選択された設計ドキュメントから作業計画を作成し、具体的な実装ステップとリスクを明確化。
+ユーザーと対話して計画を完成させ、計画内容の承認を得る。具体的な実装ステップとリスクを明確化。
 
 **スコープ**: 作業計画書作成と計画内容の承認取得まで。
 
 ## 完了時のレスポンス
-✅ **推奨**: 計画内容承認後、以下の標準レスポンスで終了
+計画内容承認後、以下の標準レスポンスで終了
 ```
 フロントエンド計画フェーズ完了。
 - 作業計画: docs/plans/[計画名].md

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

@@ -56,10 +56,10 @@ Design Doc準拠を検証:
 ユーザーが`y`を選択した場合:
 
 ## 修正実行前のメタ認知
-**必須**: `rule-advisor → TodoWrite → task-executor-frontend → quality-fixer-frontend`
+**必須**: `rule-advisor → TaskCreate → task-executor-frontend → quality-fixer-frontend`
 
 1. **rule-advisor実行**: 修正の本質を理解（表面的な対症療法 vs 根本解決）
-2. **TodoWrite更新**: 作業ステップを登録。必ず含める: 最初に「スキル制約の確認」、最後に「スキル忠実度の検証」。タスクテンプレートに従ってタスクファイル作成（documentation-criteriaスキル参照） → `docs/plans/tasks/review-fixes-YYYYMMDD.md`
+2. **TaskUpdateで更新**: 作業ステップを登録。必ず含める: 最初に「スキル制約の確認」、最後に「スキル忠実度の検証」。タスクテンプレートに従ってタスクファイル作成（documentation-criteriaスキル参照） → `docs/plans/tasks/review-fixes-YYYYMMDD.md`
 3. **task-executor-frontend実行**: 段階的自動修正（5ファイルで停止）
 4. **quality-fixer-frontend実行**: 品質ゲート通過を確認
 5. **再検証**: code-reviewerで改善を測定

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

@@ -37,13 +37,13 @@ requirement-analyzerの`crossLayerScope`がレイヤー横断（backend + fronte
 - 規模が変更 → 更新されたコンテキストでrequirement-analyzerを再実行
 - `confidence: "confirmed"` または規模変更なし → 次のステップへ進む
 
-### 5. 規模判定後：TodoWriteにフロー全ステップを登録（必須）
+### 5. 規模判定後：TaskCreateでフロー全ステップを登録（必須）
 
-規模判定完了後、**subagents-orchestration-guideスキルの該当フロー全ステップをTodoWriteに登録**。最初に「スキル制約の確認」、最後に「スキル忠実度の検証」を必ず含める。登録後、TodoWriteを参照してフローを進める。
+規模判定完了後、**subagents-orchestration-guideスキルの該当フロー全ステップをTaskCreateで登録**。最初に「スキル制約の確認」、最後に「スキル忠実度の検証」を必ず含める。登録後、TaskListを参照してフローを進める。
 
 ### 6. 次のアクション実行
 
-**TodoWriteの次のpendingタスクを実行**。
+**TaskListで次のpendingタスクを確認して実行**。
 
 ## 📋 subagents-orchestration-guideスキル準拠の実行
 
@@ -54,7 +54,7 @@ requirement-analyzerの`crossLayerScope`がレイヤー横断（backend + fronte
 - [ ] 停止ポイントを認識した → **全ての停止ポイントでAskUserQuestionを使用**
 - [ ] タスク実行後の4ステップサイクル（task-executor → エスカレーション判定・フォローアップ → quality-fixer → commit）を理解した
 
-**フロー厳守**: subagents-orchestration-guideスキルの「自律実行中のタスク管理」に従い、TodoWriteで4ステップを管理する
+**フロー厳守**: subagents-orchestration-guideスキルの「自律実行中のタスク管理」に従い、TaskCreate/TaskUpdateで4ステップを管理する
 
 ## 🚨 サブエージェント呼び出し時の制約
 
@@ -65,12 +65,17 @@ requirement-analyzerの`crossLayerScope`がレイヤー横断（backend + fronte
 
 ## 🎯 オーケストレーターとしての必須責務
 
-### タスク実行フロー
-subagents-orchestration-guideスキルの「自律実行中のタスク管理」に従い、TodoWriteで以下の4ステップを管理：
-1. task-executor実行（レイヤー横断時: レイヤー別エージェントルーティング参照）
-2. エスカレーション判定・フォローアップ
-3. quality-fixer実行（レイヤー横断時: レイヤー別エージェントルーティング参照）
-4. git commit
+### タスク実行品質サイクル
+subagents-orchestration-guideスキルの「自律実行中のタスク管理」に従い、TaskCreate/TaskUpdateで以下のステップを管理：
+1. **task-executor実行**: 実装を実行（レイヤー横断時: レイヤー別エージェントルーティング参照）
+2. **task-executorレスポンスチェック**:
+   - `status: "escalation_needed"` または `"blocked"` → 停止してユーザーにエスカレーション
+   - `testsAdded` に `*.int.test.ts` または `*.e2e.test.ts` を含む → **integration-test-reviewer**を実行
+     - `needs_revision` → `requiredFixes`を添えてステップ1に戻る
+     - `approved` → ステップ3へ
+   - それ以外 → ステップ3へ
+3. **quality-fixer実行**: 全品質チェックと修正を実行（レイヤー横断時: レイヤー別エージェントルーティング参照）
+4. **承認後コミット**: `approved: true`確認後 → git commitを実行
 
 ### テスト情報の伝達
 acceptance-test-generator実行後、work-planner呼び出し時には以下を伝達：

package/.claude/commands-ja/project-inject.md

@@ -12,7 +12,7 @@ CLAUDE.mdのセッション初期化で`project-context`スキルが毎セッシ
 
 ## 実行プロセス
 
-以下のステップをTodoWriteに登録し、順番に進行する。
+以下のステップをTaskCreateで登録し、順番に進行する。
 
 ### Step 1: 現状把握
 

package/.claude/commands-ja/refine-skill.md

@@ -8,7 +8,7 @@ description: ユーザーのスキル変更要求を最適化パターン評価
 
 ## 実行プロセス
 
-以下のステップをTodoWriteに登録し、順番に進行する。
+以下のステップをTaskCreateで登録し、順番に進行する。
 
 ### Step 1: 変更要求の理解
 

package/.claude/commands-ja/reverse-engineer.md

@@ -15,7 +15,7 @@ description: 既存コードベースからPRDとDesign Docを生成するリバ
 2. **ステップ間で構造化JSONを受け渡す** — `$STEP_N_OUTPUT`プレースホルダー記法を使用
 3. **コード読解はすべてサブエージェントが実施**
 
-**TodoWrite登録**: まずフェーズをTodoWriteに登録し、各フェーズ開始時に詳細ステップを追加登録する。
+**タスク登録**: まずフェーズをTaskCreateで登録し、各フェーズ開始時に詳細ステップを追加登録する。
 
 ## ステップ0: 初期設定
 
@@ -50,7 +50,7 @@ AskUserQuestionで以下を確認:
 
 ## フェーズ1: PRD生成
 
-**TodoWrite登録**:
+**タスク登録**:
 - ステップ1: PRDスコープ発見
 - ユニット毎の処理（各ユニットに対してステップ2-5）
 
@@ -189,7 +189,7 @@ prompt: |
 
 *ステップ0でDesign Docが要求された場合のみ実行*
 
-**TodoWrite登録**:
+**タスク登録**:
 - ステップ6: Design Docスコープマッピング
 - ユニット毎の処理（各ユニットに対してステップ7-10）
 

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

@@ -57,9 +57,9 @@ Design Doc準拠率を検証:
 ユーザーが `y` を選択した場合:
 
 #### 修正実行手順
-**必須**: `TodoWrite → task-executor → quality-fixer`
+**必須**: `TaskCreate → task-executor → quality-fixer`
 
-1. **TodoWrite更新**: 作業ステップを登録。必ず含める: 最初に「スキル制約の確認」、最後に「スキル忠実度の検証」。タスクテンプレート（documentation-criteriaスキル参照）に従いタスクファイル作成 → `docs/plans/tasks/review-fixes-YYYYMMDD.md`
+1. **TaskUpdateで更新**: 作業ステップを登録。必ず含める: 最初に「スキル制約の確認」、最後に「スキル忠実度の検証」。タスクテンプレート（documentation-criteriaスキル参照）に従いタスクファイル作成 → `docs/plans/tasks/review-fixes-YYYYMMDD.md`
 2. **task-executor実行**: 自動修正を段階的実行（5ファイル超過で停止）
 3. **quality-fixer実行**: 品質ゲート通過を確認
 4. **再検証**: 修正後のDesign Doc準拠率を再検証する。前回の準拠問題: $STEP_2_OUTPUT。各問題が解決されたことを確認する。

package/.claude/commands-ja/sync-skills.md

@@ -10,7 +10,7 @@ description: スキル修正後のメタデータ同期とrule-advisor精度最
 
 ## 実行プロセス
 
-以下のステップをTodoWriteに登録し、順番に進行する。
+以下のステップをTaskCreateで登録し、順番に進行する。
 
 ### Step 1: スキルファイルのスキャン
 

package/.claude/commands-ja/update-doc.md

@@ -8,7 +8,7 @@ description: 既存設計ドキュメント（Design Doc / PRD / ADR）をレビ
 
 **コアアイデンティティ**: 「私は作業者ではない。オーケストレーターである。」（subagents-orchestration-guideスキル参照）
 
-**初期アクション**: 実行前にステップ1-6をTodoWriteに登録する。
+**初期アクション**: 実行前にステップ1-6をTaskCreateで登録する。
 
 **実行プロトコル**:
 1. **全作業をサブエージェントに委譲** — 役割はサブエージェントの呼び出し、データの受け渡し、結果の報告
@@ -195,4 +195,4 @@ prompt: |
 - 更新されたドキュメント: docs/design/[ドキュメント名].md
 - 承認ステータス: ユーザー承認済み
 
-**重要**: 本コマンドはドキュメント承認で終了。次フェーズへの移行提案は行わない。
+**責務境界**: 本コマンドはドキュメント承認で終了。作業計画以降はスコープ外。

package/.claude/skills-en/documentation-criteria/SKILL.md

@@ -9,7 +9,8 @@ description: Guides PRD, ADR, Design Doc, and Work Plan creation with templates
 
 | Condition | Required Documents | Creation Order |
 |-----------|-------------------|----------------|
-| New Feature Addition | PRD -> [ADR] -> Design Doc -> Work Plan | After PRD approval |
+| New Feature Addition (backend) | PRD -> [ADR] -> Design Doc -> Work Plan | After PRD approval |
+| New Feature Addition (frontend/fullstack) | PRD -> **UI Spec** -> [ADR] -> Design Doc -> Work Plan | UI Spec before Design Doc |
 | ADR Conditions Met (see below) | ADR -> Design Doc -> Work Plan | Start immediately |
 | 6+ Files | ADR -> Design Doc -> Work Plan (Required) | Start immediately |
 | 3-5 Files | Design Doc -> Work Plan (Recommended) | Start immediately |
@@ -79,6 +80,37 @@ description: Guides PRD, ADR, Design Doc, and Work Plan creation with templates
 - Specific code examples (->Design Doc)
 - Resource assignments (->Work Plan)
 
+### UI Specification
+
+**Purpose**: Define UI structure, screen transitions, component decomposition, and interaction design for frontend features
+
+**Includes**:
+- Screen list and transition conditions
+- Component decomposition with state x display matrix (default/loading/empty/error/partial)
+- Interaction definitions linked to PRD acceptance criteria (EARS format)
+- Prototype management (code-based prototypes as attachments, not source of truth)
+- AC traceability from PRD to screens/components
+- Existing component reuse map and design tokens
+- Visual acceptance criteria (golden states, layout constraints)
+- Accessibility requirements (keyboard, screen reader, contrast)
+
+**Excludes**:
+- Technical implementation details (-> Design Doc)
+- API contracts and data layer design (-> Design Doc)
+- Test implementation (-> Test Strategy in Design Doc)
+- Implementation schedule (-> Work Plan)
+
+**Required Structural Elements**:
+- At least one component with state x display matrix and interaction table
+- AC traceability table mapping PRD ACs to screens/states
+- Screen list with transition conditions
+- Existing component reuse map (reuse/extend/new decisions)
+
+**Prototype Code Handling**:
+- Prototype code provided by user is placed in `docs/ui-spec/assets/{feature-name}/`
+- Prototype is an attachment to UI Spec, never the source of truth
+- UI Spec + Design Doc are the canonical specifications
+
 ### Design Document
 
 **Purpose**: Define technical implementation methods in detail
@@ -148,6 +180,8 @@ description: Guides PRD, ADR, Design Doc, and Work Plan creation with templates
 |----------|------|------------------|----------|
 | PRD | `docs/prd/` | `[feature-name]-prd.md` | See prd-template.md |
 | ADR | `docs/adr/` | `ADR-[4-digits]-[title].md` | See adr-template.md |
+| UI Spec | `docs/ui-spec/` | `[feature-name]-ui-spec.md` | See ui-spec-template.md |
+| UI Spec Assets | `docs/ui-spec/assets/{feature-name}/` | Prototype code files | - |
 | Design Doc | `docs/design/` | `[feature-name]-design.md` | See design-template.md |
 | Work Plan | `docs/plans/` | `YYYYMMDD-{type}-{description}.md` | See plan-template.md |
 | Task File | `docs/plans/tasks/` | `{plan-name}-task-{number}.md` | See task-template.md |
@@ -170,6 +204,7 @@ Required diagrams for each document (using mermaid notation):
 |----------|------------------|---------|
 | PRD | User journey diagram, Scope boundary diagram | Clarify user experience and scope |
 | ADR | Option comparison diagram (when needed) | Visualize trade-offs |
+| UI Spec | Screen transition diagram, Component tree diagram | Clarify screen flow and component structure |
 | Design Doc | Architecture diagram, Data flow diagram | Understand technical structure |
 | Work Plan | Phase structure diagram, Task dependency diagram | Clarify implementation order |
 
@@ -184,6 +219,7 @@ Required diagrams for each document (using mermaid notation):
 Templates are available in the `references/` directory:
 - [Design Document template](references/design-template.md)
 - [Product Requirements Document template](references/prd-template.md)
+- [UI Specification template](references/ui-spec-template.md)
 - [Work Plan template](references/plan-template.md)
 - [Architecture Decision Record template](references/adr-template.md)
 - [Task File template](references/task-template.md)