create-ai-project 1.14.11 → 1.14.12

package/.claude/commands-en/add-integration-tests.md

@@ -7,110 +7,123 @@ description: Add integration/E2E tests to existing backend codebase using Design
 
 **Scope**: Backend only (acceptance-test-generator supports backend only)
 
-**Role**: Orchestrator
+## Orchestrator Definition
+
+**Core Identity**: "I am not a worker. I am an orchestrator."
+
+**First Action**: Register Steps 0-8 to TodoWrite before any execution.
+
+**Why Delegate**: Orchestrator's context is shared across all steps. Direct implementation consumes context needed for review and quality check phases. Task files create context boundaries. Subagents work in isolated context.
 
 **Execution Method**:
-- Skeleton generation -> delegate to acceptance-test-generator
-- Task file creation -> orchestrator creates directly
-- Test implementation -> delegate to task-executor
-- Test review -> delegate to integration-test-reviewer
-- Quality checks -> delegate to quality-fixer
+- Skeleton generation → delegate to acceptance-test-generator
+- Task file creation → orchestrator creates directly (minimal context usage)
+- Test implementation → delegate to task-executor
+- Test review → delegate to integration-test-reviewer
+- Quality checks → delegate to quality-fixer
 
 Design Doc path: $ARGUMENTS
 
-**TodoWrite**: Register steps and update as each completes.
-
 ## Prerequisites
 - Design Doc must exist (created manually or via reverse-engineer)
 - Existing implementation to test
 
 ## Execution Flow
 
-### 1. Validate Design Doc (Orchestrator)
+### Step 0: Execute Skill
+
+Execute Skill: documentation-criteria (for task file template in Step 3)
+
+### Step 1: Validate Design Doc
+
 ```bash
 # Verify Design Doc exists
 ls $ARGUMENTS || ls docs/design/*.md | grep -v template | tail -1
 ```
 
-### 2. Skeleton Generation
+### Step 2: Skeleton Generation
 
-**Task tool invocation**:
-```
-subagent_type: acceptance-test-generator
-prompt: |
-  Generate test skeletons from Design Doc.
+Invoke acceptance-test-generator using Task tool:
+- `subagent_type`: "acceptance-test-generator"
+- `description`: "Generate test skeletons"
+- `prompt`: "Generate test skeletons from Design Doc at [path from Step 1]"
 
-  Design Doc: [path from Step 1]
+**Expected output**: `generatedFiles` containing integration and e2e paths
 
-  Output:
-  - Integration test skeletons (*.int.test.ts)
-  - E2E test skeletons if applicable (*.e2e.test.ts)
-```
+### Step 3: Create Task File [GATE]
 
-**Expected output**: `generatedFiles` containing integration and e2e paths
+Create task file at: `docs/plans/tasks/integration-tests-YYYYMMDD.md`
 
-### 3. Create Task File (Orchestrator)
+**Template**:
+```markdown
+---
+name: Implement integration tests for [feature name]
+type: test-implementation
+---
 
-Create task file following task template (see documentation-criteria skill):
-- Path: `docs/plans/tasks/integration-tests-YYYYMMDD.md`
-- Content: Test implementation tasks based on generated skeletons
-- Include skeleton file paths from Step 2 output in Target Files section
+## Objective
 
-### 4. Test Implementation
+Implement test cases defined in skeleton files.
 
-**Task tool invocation**:
-```
-subagent_type: task-executor
-prompt: |
-  Implement tests following the task file.
+## Target Files
 
-  Task file: docs/plans/tasks/integration-tests-YYYYMMDD.md
+- Skeleton: [path from Step 2 generatedFiles]
+- Design Doc: [path from Step 1]
 
-  Requirements:
-  - Follow TDD principles (Red-Green-Refactor)
-  - Implement each skeleton test case
-  - Run tests and verify they pass
-```
+## Tasks
 
-**Expected output**: `status`, `testsAdded`
+- [ ] Implement each test case in skeleton
+- [ ] Verify all tests pass
+- [ ] Ensure coverage meets requirements
 
-### 5. Test Review
+## Acceptance Criteria
 
-**Task tool invocation**:
+- All skeleton test cases implemented
+- All tests passing
+- No quality issues
 ```
-subagent_type: integration-test-reviewer
-prompt: |
-  Review test quality.
 
-  Test files: [paths from Step 2 generatedFiles]
-  Skeleton files: [original skeleton paths]
-```
+**Output**: "Task file created at [path]. Ready for Step 4."
+
+### Step 4: Test Implementation
+
+Invoke task-executor using Task tool:
+- `subagent_type`: "task-executor"
+- `description`: "Implement integration tests"
+- `prompt`: "Task file: docs/plans/tasks/integration-tests-YYYYMMDD.md. Implement tests following the task file."
+
+**Expected output**: `status`, `testsAdded`
+
+### Step 5: Test Review
+
+Invoke integration-test-reviewer using Task tool:
+- `subagent_type`: "integration-test-reviewer"
+- `description`: "Review test quality"
+- `prompt`: "Review test quality. Test files: [paths from Step 4 testsAdded]. Skeleton files: [paths from Step 2 generatedFiles]"
 
 **Expected output**: `status` (approved/needs_revision), `requiredFixes`
 
-**Flow control**:
-- `status: needs_revision` -> Return to Step 4 with `requiredFixes`
-- `status: approved` -> Proceed to Step 6
+### Step 6: Apply Review Fixes
 
-### 6. Quality Check
+Check Step 5 result:
+- `status: approved` → Mark complete, proceed to Step 7
+- `status: needs_revision` → Invoke task-executor with requiredFixes, then return to Step 5
 
-**Task tool invocation**:
-```
-subagent_type: quality-fixer
-prompt: |
-  Final quality assurance for test files.
+Invoke task-executor using Task tool:
+- `subagent_type`: "task-executor"
+- `description`: "Fix review findings"
+- `prompt`: "Fix the following issues in test files: [requiredFixes from Step 5]"
 
-  Scope: Test files added in this workflow
+### Step 7: Quality Check
 
-  Requirements:
-  - Run all tests
-  - Verify coverage meets requirements
-  - Fix any quality issues
-```
+Invoke quality-fixer using Task tool:
+- `subagent_type`: "quality-fixer"
+- `description`: "Final quality assurance"
+- `prompt`: "Final quality assurance for test files added in this workflow. Run all tests and verify coverage."
 
 **Expected output**: `approved` (true/false)
 
-### 7. Commit (Orchestrator)
+### Step 8: Commit
 
 On `approved: true` from quality-fixer:
 - Commit test files with appropriate message using Bash

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

@@ -19,7 +19,7 @@ Work plan: $ARGUMENTS
 
 ### Task Generation Decision Flow
 
-**Think deeply** Analyze task file existence state and determine the appropriate action:
+Analyze task file existence state and determine the appropriate action:
 
 | State | Criteria | Next Action |
 |-------|----------|-------------|
@@ -40,12 +40,11 @@ Generate tasks from the work plan? (y/n):
 ```
 
 ### 2. Task Decomposition (if approved)
-```
-@task-decomposer Read work plan and decompose into atomic tasks:
-- Input: docs/plans/[plan-name].md
-- Output: Individual task files in docs/plans/tasks/
-- Granularity: 1 task = 1 commit = independently executable
-```
+
+Invoke task-decomposer using Task tool:
+- `subagent_type`: "task-decomposer"
+- `description`: "Decompose work plan into tasks"
+- `prompt`: "Read work plan and decompose into atomic tasks. Input: docs/plans/[plan-name].md. Output: Individual task files in docs/plans/tasks/. Granularity: 1 task = 1 commit = independently executable"
 
 ### 3. Verify Generation
 ```bash

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

@@ -29,7 +29,7 @@ Requirements → requirement-analyzer → [Stop: Scale determination]
 
 Requirements: $ARGUMENTS
 
-**Think harder** Considering the deep impact on design, first engage in dialogue to understand the background and purpose of requirements:
+Considering the deep impact on design, first engage in dialogue to understand the background and purpose of requirements:
 - What problems do you want to solve?
 - Expected outcomes and success criteria
 - Relationship with existing systems

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

@@ -37,11 +37,10 @@ If the following are unclear, **ask with AskUserQuestion** before proceeding:
 
 ### 0.3 Problem Essence Understanding
 
-**Invoke rule-advisor via Task tool**:
-```
-subagent_type: rule-advisor
-prompt: Identify the essence and required rules for this problem: [Problem reported by user]
-```
+Invoke rule-advisor using Task tool:
+- `subagent_type`: "rule-advisor"
+- `description`: "Identify problem essence"
+- `prompt`: "Identify the essence and required rules for this problem: [Problem reported by user]"
 
 Confirm from rule-advisor output:
 - `taskAnalysis.mainFocus`: Primary focus of the problem
@@ -79,13 +78,10 @@ Register the following in TodoWrite and execute:
 
 ### Step 1: Investigation (investigator)
 
-**Task tool invocation**:
-```
-subagent_type: investigator
-prompt: Comprehensively collect information related to the following phenomenon.
-
-Phenomenon: [Problem reported by user]
-```
+Invoke investigator using Task tool:
+- `subagent_type`: "investigator"
+- `description`: "Collect problem information"
+- `prompt`: "Comprehensively collect information related to the following phenomenon. Phenomenon: [Problem reported by user]"
 
 **Expected output**: Evidence matrix, comparison analysis results, causal tracking results, list of unexplored areas, investigation limitations
 
@@ -115,13 +111,10 @@ Proceed to verifier once quality is satisfied.
 
 ### Step 3: Verification (verifier)
 
-**Task tool invocation**:
-```
-subagent_type: verifier
-prompt: Verify the following investigation results.
-
-Investigation results: [Investigation JSON output]
-```
+Invoke verifier using Task tool:
+- `subagent_type`: "verifier"
+- `description`: "Verify investigation results"
+- `prompt`: "Verify the following investigation results. Investigation results: [Investigation JSON output]"
 
 **Expected output**: Alternative hypotheses (at least 3), Devil's Advocate evaluation, final conclusion, confidence
 
@@ -132,15 +125,10 @@ Investigation results: [Investigation JSON output]
 
 ### Step 4: Solution Derivation (solver)
 
-**Task tool invocation**:
-```
-subagent_type: solver
-prompt: Derive solutions based on the following verified conclusion.
-
-Causes: [verifier's conclusion.causes]
-Causes relationship: [causesRelationship: independent/dependent/exclusive]
-Confidence: [high/medium/low]
-```
+Invoke solver using Task tool:
+- `subagent_type`: "solver"
+- `description`: "Derive solutions"
+- `prompt`: "Derive solutions based on the following verified conclusion. Causes: [verifier's conclusion.causes]. Causes relationship: [causesRelationship: independent/dependent/exclusive]. Confidence: [high/medium/low]"
 
 **Expected output**: Multiple solutions (at least 3), tradeoff analysis, recommendation and implementation steps, residual risks
 

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

@@ -31,7 +31,7 @@ Work plan: $ARGUMENTS
 
 ### Task Generation Decision Flow
 
-**Think deeply**: Analyze task file existence state and determine the appropriate action:
+Analyze task file existence state and determine the appropriate action:
 
 | State | Criteria | Next Action |
 |-------|----------|-------------|
@@ -52,12 +52,11 @@ Generate tasks from the work plan? (y/n):
 ```
 
 ### 2. Task Decomposition (if approved)
-```
-@task-decomposer Read work plan and decompose into atomic tasks:
-- Input: docs/plans/[plan-name].md
-- Output: Individual task files in docs/plans/tasks/
-- Granularity: 1 task = 1 commit = independently executable
-```
+
+Invoke task-decomposer using Task tool:
+- `subagent_type`: "task-decomposer"
+- `description`: "Decompose work plan into tasks"
+- `prompt`: "Read work plan and decompose into atomic tasks. Input: docs/plans/[plan-name].md. Output: Individual task files in docs/plans/tasks/. Granularity: 1 task = 1 commit = independently executable"
 
 ### 3. Verify Generation
 ```bash

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

@@ -30,7 +30,7 @@ Requirements: $ARGUMENTS
 ## Execution Flow
 
 ### 1. Requirement Analysis Phase
-**Think harder**: Considering the deep impact on design, first engage in dialogue to understand the background and purpose of requirements:
+Considering the deep impact on design, first engage in dialogue to understand the background and purpose of requirements:
 - What problems do you want to solve?
 - Expected outcomes and success criteria
 - Relationship with existing systems

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

@@ -38,7 +38,7 @@ Invoke **work-planner** using Task tool:
 - `prompt: "Create work plan from Design Doc at [path]"`
 - Interact with user to complete plan and obtain approval for plan content
 
-**Think deeply** Create a work plan from the selected design document, clarifying specific implementation steps and risks.
+Create a work plan from the selected design document, clarifying specific implementation steps and risks.
 
 **Scope**: Up to work plan creation and obtaining approval for plan content.
 

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

@@ -46,7 +46,7 @@ Follow subagents-orchestration-guide skill strictly and create work plan with th
    - Utilize deliverables from previous process according to subagents-orchestration-guide skill coordination specification
    - Interact with user to complete plan and obtain approval for plan content
 
-**Think deeply** Create a work plan from the selected design document, clarifying specific implementation steps and risks.
+Create a work plan from the selected design document, clarifying specific implementation steps and risks.
 
 **Scope**: Up to work plan creation and obtaining approval for plan content.
 

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

@@ -7,7 +7,6 @@ description: Design Doc compliance validation with optional auto-fixes
 ## Execution Method
 
 - Compliance validation → performed by code-reviewer
-- Rule analysis → performed by rule-advisor
 - Fix implementation → performed by task-executor
 - Quality checks → performed by quality-fixer
 - Re-validation → performed by code-reviewer
@@ -16,7 +15,7 @@ Orchestrator invokes sub-agents and passes structured JSON between them.
 
 Design Doc (uses most recent if omitted): $ARGUMENTS
 
-**Think deeply** Understand the essence of compliance validation and execute:
+Understand the essence of compliance validation and execute the following steps:
 
 ## Execution Flow
 
@@ -55,14 +54,13 @@ Execute fixes? (y/n):
 
 If user selects `y`:
 
-## Pre-fix Metacognition
-**Required**: `rule-advisor → TodoWrite → task-executor → quality-fixer`
+#### Fix Execution Steps
+**Required**: `TodoWrite → task-executor → quality-fixer`
 
-1. **Execute rule-advisor**: Understand fix essence (symptomatic treatment vs root solution)
-2. **Update TodoWrite**: Register work steps. Always include: first "Confirm skill constraints", final "Verify skill fidelity". Create task file following task template (see documentation-criteria skill) -> `docs/plans/tasks/review-fixes-YYYYMMDD.md`
-3. **Execute task-executor**: Staged auto-fixes (stops at 5 files)
-4. **Execute quality-fixer**: Confirm quality gate passage
-5. **Re-validate**: Measure improvement with code-reviewer
+1. **Update TodoWrite**: Register work steps. Always include: first "Confirm skill constraints", final "Verify skill fidelity". Create task file following task template (see documentation-criteria skill) -> `docs/plans/tasks/review-fixes-YYYYMMDD.md`
+2. **Execute task-executor**: Staged auto-fixes (stops at 5 files)
+3. **Execute quality-fixer**: Confirm quality gate passage
+4. **Re-validate**: Measure improvement with code-reviewer
 
 ### 4. Final Report
 ```
@@ -85,4 +83,4 @@ Remaining issues:
 - Architecture-level modifications
 - Design Doc deficiencies
 
-**Scope**: Design Doc compliance validation and auto-fixes.
+**Scope**: Design Doc compliance validation and auto-fixes.

package/.claude/commands-ja/add-integration-tests.md

@@ -7,110 +7,123 @@ description: Design Docを使用して既存バックエンドコードベース
 
 **スコープ**: バックエンドのみ（acceptance-test-generatorはバックエンドのみ対応）
 
-**Role**: オーケストレーター
+## オーケストレーター定義
+
+**コアアイデンティティ**: 「私は作業者ではない。オーケストレーターである。」
+
+**初動アクション**: ステップ0-8をTodoWriteに登録してから実行を開始。
+
+**委譲理由**: オーケストレーターとして、レビュー・品質チェックを含む全てのステップを完遂させるために、必要なコンテキストを維持する必要がある。タスクファイルをコンテキスト境界とし、全ての作業をサブエージェントが担うことでこれを実現する。
 
 **実行方法**:
 - スケルトン生成 → acceptance-test-generatorに委譲
-- タスクファイル作成 → オーケストレーターが直接作成
+- タスクファイル作成 → オーケストレーターが作成（テスト、設計書の最小限情報のみ）
 - テスト実装 → task-executorに委譲
 - テストレビュー → integration-test-reviewerに委譲
 - 品質チェック → quality-fixerに委譲
 
 Design Docパス: $ARGUMENTS
 
-**TodoWrite登録**: 各ステップを登録し、完了時に更新。
-
 ## 前提条件
 - Design Docが存在すること（手動またはreverse-engineerで作成）
 - テスト対象の既存実装があること
 
 ## 実行フロー
 
-### 1. Design Doc検証（オーケストレーター）
+### ステップ0: スキル実行
+
+スキル実行: documentation-criteria（ステップ3のタスクファイルテンプレート用）
+
+### ステップ1: Design Doc検証
+
 ```bash
 # Design Docの存在確認
 ls $ARGUMENTS || ls docs/design/*.md | grep -v template | tail -1
 ```
 
-### 2. スケルトン生成
+### ステップ2: スケルトン生成
 
-**Taskツールでの呼び出し**:
-```
-subagent_type: acceptance-test-generator
-prompt: |
-  Design Docからテストスケルトンを生成。
+Taskツールでacceptance-test-generatorを呼び出す:
+- `subagent_type`: "acceptance-test-generator"
+- `description`: "テストスケルトン生成"
+- `prompt`: "[ステップ1のパス]のDesign Docからテストスケルトンを生成"
 
-  Design Doc: [ステップ1のパス]
+**期待される出力**: `generatedFiles`（統合テストとE2Eのパスを含む）
 
-  出力:
-  - 統合テストスケルトン (*.int.test.ts)
-  - 該当する場合はE2Eテストスケルトン (*.e2e.test.ts)
-```
+### ステップ3: タスクファイル作成 [GATE]
 
-**期待される出力**: `generatedFiles`（統合テストとE2Eのパスを含む）
+タスクファイル作成先: `docs/plans/tasks/integration-tests-YYYYMMDD.md`
 
-### 3. タスクファイル作成（オーケストレーター）
+**テンプレート**:
+```markdown
+---
+name: [機能名]の統合テスト実装
+type: test-implementation
+---
 
-タスクテンプレートに従ってタスクファイルを作成（documentation-criteriaスキル参照）:
-- パス: `docs/plans/tasks/integration-tests-YYYYMMDD.md`
-- 内容: 生成されたスケルトンに基づくテスト実装タスク
-- 対象ファイルセクションにステップ2の出力からスケルトンファイルパスを含める
+## 目的
 
-### 4. テスト実装
+スケルトンファイルに定義されたテストケースを実装する。
 
-**Taskツールでの呼び出し**:
-```
-subagent_type: task-executor
-prompt: |
-  タスクファイルに従ってテストを実装。
+## 対象ファイル
 
-  タスクファイル: docs/plans/tasks/integration-tests-YYYYMMDD.md
+- スケルトン: [ステップ2のgeneratedFilesのパス]
+- Design Doc: [ステップ1のパス]
 
-  要件:
-  - TDD原則に従う（Red-Green-Refactor）
-  - 各スケルトンテストケースを実装
-  - テストを実行してパスを確認
-```
+## タスク
 
-**期待される出力**: `status`, `testsAdded`
+- [ ] スケルトンの各テストケースを実装
+- [ ] 全テストがパスすることを確認
+- [ ] カバレッジが要件を満たすことを確認
 
-### 5. テストレビュー
+## 受入条件
 
-**Taskツールでの呼び出し**:
+- 全スケルトンテストケースが実装済み
+- 全テストがパス
+- 品質チェック全項目パス
 ```
-subagent_type: integration-test-reviewer
-prompt: |
-  テスト品質をレビュー。
 
-  テストファイル: [ステップ2のgeneratedFilesのパス]
-  スケルトンファイル: [元のスケルトンパス]
-```
+**出力**: "タスクファイルを[パス]に作成しました。ステップ4へ進む準備完了。"
+
+### ステップ4: テスト実装
+
+Taskツールでtask-executorを呼び出す:
+- `subagent_type`: "task-executor"
+- `description`: "統合テスト実装"
+- `prompt`: "タスクファイル: docs/plans/tasks/integration-tests-YYYYMMDD.md。タスクファイルに従ってテストを実装。"
+
+**期待される出力**: `status`, `testsAdded`
+
+### ステップ5: テストレビュー
+
+Taskツールでintegration-test-reviewerを呼び出す:
+- `subagent_type`: "integration-test-reviewer"
+- `description`: "テスト品質レビュー"
+- `prompt`: "テスト品質をレビュー。テストファイル: [ステップ4のtestsAdded]。スケルトンファイル: [ステップ2のgeneratedFiles]"
 
 **期待される出力**: `status` (approved/needs_revision), `requiredFixes`
 
-**フロー制御**:
-- `status: needs_revision` → `requiredFixes`と共にステップ4に戻る
-- `status: approved` → ステップ6に進む
+### ステップ6: レビュー修正の適用
 
-### 6. 品質チェック
+ステップ5の結果を確認:
+- `status: approved` → 完了としてマーク、ステップ7へ進む
+- `status: needs_revision` → requiredFixesでtask-executorを呼び出し、ステップ5に戻る
 
-**Taskツールでの呼び出し**:
-```
-subagent_type: quality-fixer
-prompt: |
-  テストファイルの最終品質保証。
+Taskツールでtask-executorを呼び出す:
+- `subagent_type`: "task-executor"
+- `description`: "レビュー指摘の修正"
+- `prompt`: "テストファイルの以下の問題を修正: [ステップ5のrequiredFixes]"
 
-  スコープ: このワークフローで追加されたテストファイル
+### ステップ7: 品質チェック
 
-  要件:
-  - 全テストを実行
-  - カバレッジが要件を満たすことを確認
-  - 品質問題を修正
-```
+Taskツールでquality-fixerを呼び出す:
+- `subagent_type`: "quality-fixer"
+- `description`: "最終品質保証"
+- `prompt`: "このワークフローで追加されたテストファイルの最終品質保証。全テストを実行しカバレッジを確認。"
 
 **期待される出力**: `approved` (true/false)
 
-### 7. コミット（オーケストレーター）
+### ステップ8: コミット
 
 quality-fixerから`approved: true`の場合:
 - Bashで適切なメッセージを付けてテストファイルをコミット

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

@@ -19,7 +19,7 @@ subagents-orchestration-guideスキルの指針に従い、**オーケストレ
 
 ### タスク生成判定フロー
 
-**Think deeply** タスクファイルの存在状態を確認し、適切な対応を決定：
+タスクファイルの存在状態を確認し、適切な対応を決定:
 
 | 状態 | 判定基準 | 次のアクション |
 |------|---------|--------------|
@@ -40,12 +40,11 @@ subagents-orchestration-guideスキルの指針に従い、**オーケストレ
 ```
 
 ### 2. タスク分解実行（承認時）
-```
-@task-decomposer 作業計画書を読み込み、1コミット粒度の独立したタスクに分解：
-- 入力: docs/plans/[計画書名].md
-- 出力: docs/plans/tasks/配下に個別タスクファイル生成
-- 粒度: 1タスク = 1コミット = 独立して実行可能
-```
+
+Taskツールでtask-decomposerを呼び出す:
+- `subagent_type`: "task-decomposer"
+- `description`: "作業計画をタスクに分解"
+- `prompt`: "作業計画書を読み込み、1コミット粒度の独立したタスクに分解。入力: docs/plans/[計画書名].md。出力: docs/plans/tasks/配下に個別タスクファイル生成。粒度: 1タスク = 1コミット = 独立して実行可能"
 
 ### 3. 生成確認
 ```bash

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

@@ -29,7 +29,7 @@ description: 要件分析から設計書作成まで実行
 
 要件: $ARGUMENTS
 
-**Think harder** 設計への影響を深く考慮し、まず要件の背景と目的を理解するため対話を行い：
+設計への影響を深く考慮し、まず要件の背景と目的を理解するため対話を行い:
 - どのような問題を解決したいか
 - 期待される成果と成功基準
 - 既存システムとの関係性
@@ -42,7 +42,7 @@ description: 要件分析から設計書作成まで実行
 
 **実行内容**:
 - requirement-analyzerによる要件分析
-- ADR作成（アーキテクチャ変更、データフロー変更がある場合）
+- ADR作成（アーキテクチャ変更、新技術、データフロー変更がある場合）
 - technical-designerによるDesign Doc作成
 - document-reviewerによるドキュメントレビュー
 - design-syncによるDesign Doc間整合性検証
@@ -54,7 +54,7 @@ description: 要件分析から設計書作成まで実行
 1. requirement-analyzer → 要件分析
 2. technical-designer → Design Doc作成
 3. document-reviewer → 単一ドキュメント品質チェック
-4. ユーザー承認
+4. ユーザー承認（承認を待つ）
 5. design-sync → Design Doc間整合性検証
    - 矛盾あり → ユーザーに報告 → 修正指示待ち → technical-designer(update)で修正
    - 矛盾なし → 終了
@@ -72,4 +72,4 @@ description: 要件分析から設計書作成まで実行
 - 設計書: docs/design/[ドキュメント名].md
 - 整合性: 他Design Docと矛盾なし（または修正完了）
 
-**重要**: 本コマンドは設計承認＋整合性確認で終了。次フェーズへの移行提案は行わない。
+**重要**: 本コマンドは設計承認＋整合性確認で終了。次フェーズへの移行提案は行わない。

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

@@ -37,11 +37,10 @@ description: 問題を調査し、検証を経て解決策を導出する
 
 ### 0.3 問題の本質理解
 
-**Taskツールでrule-advisorを呼び出す**:
-```
-subagent_type: rule-advisor
-prompt: 以下の問題について、本質と必要なルールを特定してください: [ユーザーが報告した問題]
-```
+Taskツールでrule-advisorを呼び出す:
+- `subagent_type`: "rule-advisor"
+- `description`: "問題の本質特定"
+- `prompt`: "以下の問題について、本質と必要なルールを特定してください: [ユーザーが報告した問題]"
 
 rule-advisorの出力から以下を確認：
 - `taskAnalysis.mainFocus`: 問題の主要な焦点
@@ -79,13 +78,10 @@ rule-advisorの出力から以下を確認：
 
 ### ステップ1: 調査（investigator）
 
-**Taskツールでの呼び出し**:
-```
-subagent_type: investigator
-prompt: 以下の現象について、関連する情報を網羅的に収集してください。
-
-現象: [ユーザーが報告した問題]
-```
+Taskツールでinvestigatorを呼び出す:
+- `subagent_type`: "investigator"
+- `description`: "問題情報の収集"
+- `prompt`: "以下の現象について、関連する情報を網羅的に収集してください。現象: [ユーザーが報告した問題]"
 
 **期待される出力**: 証拠マトリクス、比較分析結果、因果追跡結果、未探索領域のリスト、調査の限界
 
@@ -115,13 +111,10 @@ investigatorの出力で`causeCategory: design_gap`または`recurrenceRisk: hig
 
 ### ステップ3: 検証（verifier）
 
-**Taskツールでの呼び出し**:
-```
-subagent_type: verifier
-prompt: 以下の調査結果を検証してください。
-
-調査結果: [調査のJSON出力]
-```
+Taskツールでverifierを呼び出す:
+- `subagent_type`: "verifier"
+- `description`: "調査結果の検証"
+- `prompt`: "以下の調査結果を検証してください。調査結果: [調査のJSON出力]"
 
 **期待される出力**: 代替仮説（最低3つ）、Devil's Advocate評価、最終結論、信頼度
 
@@ -132,15 +125,10 @@ prompt: 以下の調査結果を検証してください。
 
 ### ステップ4: 解決策導出（solver）
 
-**Taskツールでの呼び出し**:
-```
-subagent_type: solver
-prompt: 以下の検証済み結論に基づいて、解決策を導出してください。
-
-原因: [verifierのconclusion.causes]
-原因の関係性: [causesRelationship: independent/dependent/exclusive]
-信頼度: [high/medium/low]
-```
+Taskツールでsolverを呼び出す:
+- `subagent_type`: "solver"
+- `description`: "解決策の導出"
+- `prompt`: "以下の検証済み結論に基づいて、解決策を導出してください。原因: [verifierのconclusion.causes]。原因の関係性: [causesRelationship: independent/dependent/exclusive]。信頼度: [high/medium/low]"
 
 **期待される出力**: 複数の解決策（最低3つ）、トレードオフ分析、推奨案と実装ステップ、残存リスク
 

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

@@ -31,7 +31,7 @@ description: フロントエンド実装を自律実行モードで実行
 
 ### タスク生成判定フロー
 
-**THINK DEEPLY AND SYSTEMATICALLY**: タスクファイルの存在状態を分析し、必要なアクションを決定：
+タスクファイルの存在状態を分析し、必要なアクションを決定:
 
 | 状態 | 基準 | 次のアクション |
 |------|------|--------------|
@@ -52,12 +52,11 @@ description: フロントエンド実装を自律実行モードで実行
 ```
 
 ### 2. タスク分解（承認された場合）
-```
-@task-decomposer 作業計画を読み込み、アトミックなタスクに分解：
-- 入力: docs/plans/[plan-name].md
-- 出力: docs/plans/tasks/ 配下の個別タスクファイル
-- 粒度: 1タスク = 1コミット = 独立実行可能
-```
+
+Taskツールでtask-decomposerを呼び出す:
+- `subagent_type`: "task-decomposer"
+- `description`: "作業計画をタスクに分解"
+- `prompt`: "作業計画を読み込み、アトミックなタスクに分解。入力: docs/plans/[plan-name].md。出力: docs/plans/tasks/配下に個別タスクファイル。粒度: 1タスク = 1コミット = 独立実行可能"
 
 ### 3. 生成確認
 ```bash

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

@@ -4,18 +4,22 @@ description: 要件分析からフロントエンド設計ドキュメント作
 
 **コマンドコンテキスト**: このコマンドはフロントエンド設計フェーズ専用です。
 
-subagents-orchestration-guideスキルの指針に従い、**オーケストレーター**として振る舞います。
+## オーケストレーター定義
+
+**Role**: オーケストレーター
 
 **実行方法**:
-- 要件分析 → requirement-analyzer
-- 設計書作成 → technical-designer-frontend
-- ドキュメントレビュー → document-reviewer
+- 要件分析 → requirement-analyzerが実行
+- 設計書作成 → technical-designer-frontendが実行
+- ドキュメントレビュー → document-reviewerが実行
 
 オーケストレーターはサブエージェントを呼び出し、構造化JSONを渡します。
 
+## スコープ境界
+
 **実行内容**:
 - requirement-analyzerによる要件分析
-- ADR作成（アーキテクチャ変更、データフロー変更がある場合）
+- ADR作成（アーキテクチャ変更、新技術、データフロー変更がある場合）
 - technical-designer-frontendによるDesign Doc作成
 - document-reviewerによるドキュメントレビュー
 
@@ -26,24 +30,24 @@ subagents-orchestration-guideスキルの指針に従い、**オーケストレ
 ## 実行フロー
 
 ### 1. 要件分析フェーズ
-**Think harder**: 設計への影響が深いことを考慮し、まず対話により要件の背景と目的を理解：
+設計への影響が深いことを考慮し、まず対話により要件の背景と目的を理解:
 - 何の問題を解決したいか
 - 期待する成果と成功基準
 - 既存システムとの関係
 
-要件がある程度明確になったら：
-- Taskツールで **requirement-analyzer** を呼び出し
+要件がある程度明確になったら:
+- Taskツールで**requirement-analyzer**を呼び出す
   - `subagent_type: "requirement-analyzer"`
   - `description: "要件分析"`
   - `prompt: "要件: [ユーザー要件] 要件分析と規模判定を実施してください"`
 - **[停止]**: 要件分析結果を確認し、質問事項に対応
 
 ### 2. 設計ドキュメント作成フェーズ
-規模判定に応じて適切な設計ドキュメントを作成：
-- Taskツールで **technical-designer-frontend** を呼び出し
+規模判定に応じて適切な設計ドキュメントを作成:
+- 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** を呼び出して整合性検証
+- Taskツールで**document-reviewer**を呼び出して整合性検証
   - `subagent_type: "document-reviewer"`, `description: "ドキュメントレビュー"`, `prompt: "[ドキュメントパス]の整合性と完成度をレビュー"`
 - **[停止]**: 設計の選択肢とトレードオフを提示し、ユーザー承認を取得
 

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

@@ -4,13 +4,17 @@ description: 設計ドキュメントからフロントエンド作業計画書
 
 **コマンドコンテキスト**: このコマンドはフロントエンド計画フェーズ専用です。
 
-subagents-orchestration-guideスキルの指針に従い、**オーケストレーター**として振る舞います。
+## オーケストレーター定義
+
+**Role**: オーケストレーター
 
 **実行方法**:
-- 作業計画書作成 → work-planner
+- 作業計画書作成 → work-plannerが実行
 
 オーケストレーターはサブエージェントを呼び出し、構造化JSONを渡します。
 
+## スコープ境界
+
 **実行内容**:
 - 設計書の選択
 - work-plannerによる作業計画書作成
@@ -18,7 +22,7 @@ subagents-orchestration-guideスキルの指針に従い、**オーケストレ
 
 **責務境界**: このコマンドは作業計画書承認で責務完了。
 
-以下のプロセスでフロントエンド作業計画書を作成：
+以下のプロセスでフロントエンド作業計画書を作成:
 
 ## 実行プロセス
 
@@ -28,13 +32,13 @@ subagents-orchestration-guideスキルの指針に従い、**オーケストレ
 - 複数ある場合は選択肢を提示（$ARGUMENTSで指定可能）
 
 ### 2. 作業計画書作成
-Taskツールで **work-planner** を呼び出し：
+Taskツールで**work-planner**を呼び出す:
 - `subagent_type: "work-planner"`
 - `description: "作業計画書作成"`
 - `prompt: "[パス]のDesign Docから作業計画を作成"`
 - ユーザーと対話して計画を完成させ、計画内容の承認を得る
 
-**深く考える** 選択された設計ドキュメントから作業計画を作成し、具体的な実装ステップとリスクを明確化。
+選択された設計ドキュメントから作業計画を作成し、具体的な実装ステップとリスクを明確化。
 
 **スコープ**: 作業計画書作成と計画内容の承認取得まで。
 

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

@@ -21,13 +21,13 @@ description: 設計書から作業計画書を作成し計画承認を取得
 
 **実行内容**:
 - 設計書の選択
-- acceptance-test-generatorによるテストスケルトン生成
+- E2Eテストスケルトン生成（オプション、ユーザー確認後）
 - work-plannerによる作業計画書作成
 - 計画承認の取得
 
 **責務境界**: このコマンドは作業計画書承認で責務完了。
 
-以下のプロセスで作業計画書を作成します：
+以下のプロセスで作業計画書を作成:
 
 ## 実行プロセス
 
@@ -46,16 +46,16 @@ description: 設計書から作業計画書を作成し計画承認を取得
    - 前工程の成果物を subagents-orchestration-guideスキル の連携仕様に従って活用
    - ユーザーと対話して計画を完成させ、計画内容の承認を得る
 
-**Think deeply** 選択された設計書から作業計画書を作成し、実装の具体的なステップとリスクを明確にします。
+選択された設計書から作業計画書を作成し、実装の具体的なステップとリスクを明確にします。
 
 **スコープ**: 作業計画書作成と計画内容の承認取得まで。
 
 ## 終了時の応答
-✅ **推奨**: 計画内容の承認後は以下の定型応答で終了
+✅ **必須**: 計画内容の承認後は以下の定型応答で終了
 ```
 計画フェーズが完了しました。
 - 作業計画書: docs/plans/[計画書名].md
 - 状態: 承認済み
 
 実装は別途ご指示ください。
-```
+```

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

@@ -4,20 +4,18 @@ description: Design Doc準拠検証と必要に応じた自動修正
 
 **コマンドコンテキスト**: 実装完了後の品質保証専用コマンド
 
-subagents-orchestration-guideスキルの指針に従い、**オーケストレーター**として振る舞います。
+## 実行方法
 
-**実行方法**:
-- Design Doc準拠検証 → code-reviewer
-- 修正の本質理解 → rule-advisor
-- 実装修正 → task-executor
-- 品質チェック → quality-fixer
-- 再検証 → code-reviewer
+- 準拠検証 → code-reviewerが実行
+- 修正実装 → task-executorが実行
+- 品質チェック → quality-fixerが実行
+- 再検証 → code-reviewerが実行
 
 オーケストレーターはサブエージェントを呼び出し、構造化JSONを渡します。
 
 Design Doc（省略時は直近のもの）: $ARGUMENTS
 
-**Think deeply** 準拠検証の本質を理解し、以下のステップで実行：
+準拠検証の本質を理解し、以下のステップで実行:
 
 ## 実行フロー
 
@@ -31,7 +29,7 @@ git diff --name-only main...HEAD
 ```
 
 ### 2. code-reviewer実行
-Design Doc準拠率を検証：
+Design Doc準拠率を検証:
 - 受入条件の充足確認
 - コード品質チェック
 - 実装完全性の評価
@@ -51,19 +49,18 @@ Design Doc準拠率を検証：
 未充足項目:
 - [項目リスト]
 
-修正を実行しますか？ (y/n): 
+修正を実行しますか？ (y/n):
 ```
 
 ユーザーが `y` を選択した場合:
 
-## 修正実行前のメタ認知
-**必須**: `rule-advisor → TodoWrite → task-executor → quality-fixer`
+#### 修正実行手順
+**必須**: `TodoWrite → task-executor → quality-fixer`
 
-1. **rule-advisor実行**: 修正の本質を理解（表面的な対症療法 vs 根本解決）
-2. **TodoWrite更新**: 作業ステップを登録。必ず含める: 最初に「スキル制約の確認」、最後に「スキル忠実度の検証」。タスクテンプレート（documentation-criteriaスキル参照）に従いタスクファイル作成 → `docs/plans/tasks/review-fixes-YYYYMMDD.md`
-3. **task-executor実行**: 自動修正を段階的実行（5ファイル超過で停止）
-4. **quality-fixer実行**: 品質ゲート通過を確認
-5. **再検証**: code-reviewerで改善度を測定
+1. **TodoWrite更新**: 作業ステップを登録。必ず含める: 最初に「スキル制約の確認」、最後に「スキル忠実度の検証」。タスクテンプレート（documentation-criteriaスキル参照）に従いタスクファイル作成 → `docs/plans/tasks/review-fixes-YYYYMMDD.md`
+2. **task-executor実行**: 自動修正を段階的実行（5ファイル超過で停止）
+3. **quality-fixer実行**: 品質ゲート通過を確認
+4. **再検証**: code-reviewerで改善度を測定
 
 ### 4. 最終レポート
 ```
@@ -86,4 +83,4 @@ Design Doc準拠率を検証：
 - アーキテクチャレベルの修正
 - Design Doc自体の不備
 
-**スコープ**: Design Doc準拠検証と自動修正まで。
+**スコープ**: Design Doc準拠検証と自動修正まで。

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-ai-project",
-  "version": "1.14.11",
+  "version": "1.14.12",
   "packageManager": "npm@10.8.2",
   "description": "TypeScript boilerplate with skills and sub-agents for Claude Code. Prevents context exhaustion through role-based task splitting.",
   "keywords": [