create-ai-project 1.14.7 → 1.14.9

package/.claude/agents-en/code-verifier.md

@@ -121,6 +121,8 @@ For each claim with collected evidence:
 
 ## Output Format
 
+**JSON format is mandatory.**
+
 ### Essential Output (default)
 
 ```json

package/.claude/agents-en/investigator.md

@@ -88,6 +88,8 @@ Information source priority:
 
 ## Output Format
 
+**JSON format is mandatory.**
+
 ```json
 {
   "problemSummary": {

package/.claude/agents-en/scope-discoverer.md

@@ -150,6 +150,8 @@ Document generation is out of scope for this agent.
 
 ## Output Format
 
+**JSON format is mandatory.**
+
 ### Essential Output
 
 ```json

package/.claude/agents-en/task-decomposer.md

@@ -101,46 +101,7 @@ Decompose tasks based on implementation strategy patterns determined in implemen
 
 ## Task File Template
 
-```markdown
-# Task: [Task Name]
-
-Metadata:
-- Dependencies: task-01 → Deliverable: docs/plans/analysis/research-results.md
-- Provides: docs/plans/analysis/api-spec.md (for research/design tasks)
-- Size: Small (1-2 files)
-
-## Implementation Content
-[What this task will achieve]
-*Reference dependency deliverables if applicable
-
-## Target Files
-- [ ] [Implementation file path]
-- [ ] [Test file path]
-
-## Implementation Steps (TDD: Red-Green-Refactor)
-### 1. Red Phase
-- [ ] Review dependency deliverables (if any)
-- [ ] Verify/create type definitions
-- [ ] Write failing tests
-- [ ] Run tests and confirm failure
-
-### 2. Green Phase
-- [ ] Add minimal implementation to pass tests
-- [ ] Run only added tests and confirm they pass
-
-### 3. Refactor Phase
-- [ ] Improve code (maintain passing tests)
-- [ ] Confirm added tests still pass
-
-## Completion Criteria
-- [ ] All added tests pass
-- [ ] Operation verified (select L1/L2/L3, per implementation-approach.md)
-- [ ] Deliverables created (for research/design tasks)
-
-## Notes
-- Impact scope: [Areas where changes may propagate]
-- Constraints: [Areas not to be modified]
-```
+See task template in documentation-criteria skill for details.
 
 ## Overall Design Document Template
 

package/.claude/agents-en/verifier.md

@@ -109,6 +109,8 @@ Classify each hypothesis by the following levels:
 
 ## Output Format
 
+**JSON format is mandatory.**
+
 ```json
 {
   "investigationReview": {

package/.claude/agents-ja/code-verifier.md

@@ -121,6 +121,8 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 
 ## 出力フォーマット
 
+**JSONフォーマット必須**
+
 ### 基本出力（デフォルト）
 
 ```json

package/.claude/agents-ja/investigator.md

@@ -88,6 +88,8 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 
 ## 出力フォーマット
 
+**JSONフォーマット必須**
+
 ```json
 {
   "problemSummary": {

package/.claude/agents-ja/scope-discoverer.md

@@ -150,6 +150,8 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 
 ## 出力フォーマット
 
+**JSONフォーマット必須**
+
 ### 基本出力
 
 ```json

package/.claude/agents-ja/task-decomposer.md

@@ -101,46 +101,7 @@ implementation-approachスキルで決定された実装戦略パターンに基
 
 ## タスクファイルテンプレート
 
-```markdown
-# タスク: [タスク名]
-
-メタ情報:
-- 依存: task-01 → 成果物: docs/plans/analysis/調査結果.md
-- 提供: docs/plans/analysis/api-spec.md（調査・設計タスクの場合）
-- サイズ: 小規模（1-2ファイル）
-
-## 実装内容
-[このタスクで実現すること]
-※依存成果物がある場合、その内容を参照して実装
-
-## 対象ファイル
-- [ ] [実装ファイルパス]
-- [ ] [テストファイルパス]
-
-## 実装手順（TDD: Red-Green-Refactor）
-### 1. Red Phase
-- [ ] 依存成果物の確認（ある場合）
-- [ ] 型定義の確認/作成
-- [ ] 失敗するテストを作成
-- [ ] テスト実行して失敗を確認
-
-### 2. Green Phase  
-- [ ] テストが通る最小限の実装
-- [ ] 追加したテストのみ実行して通ることを確認
-
-### 3. Refactor Phase
-- [ ] コード改善（テストが通る状態を維持）
-- [ ] 追加したテストが引き続き通ることを確認
-
-## 完了条件
-- [ ] 追加したテストが全てパス
-- [ ] 動作確認完了（L1/L2/L3から選択、implementation-approach.md準拠）
-- [ ] 成果物作成完了（調査・設計タスクの場合）
-
-## 注意事項
-- 影響範囲: [変更が波及する箇所]
-- 制約: [変更禁止箇所]
-```
+詳細はdocumentation-criteriaスキルのタスクテンプレートを参照。
 
 ## 全体設計書テンプレート
 

package/.claude/agents-ja/verifier.md

@@ -109,6 +109,8 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 
 ## 出力フォーマット
 
+**JSONフォーマット必須**
+
 ```json
 {
   "investigationReview": {

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

@@ -0,0 +1,74 @@
+---
+name: add-integration-tests
+description: Add integration/E2E tests to existing backend codebase using Design Doc
+---
+
+**Command Context**: Test addition workflow for existing backend implementations
+
+**Scope**: Backend only (acceptance-test-generator supports backend only)
+
+## Execution Method
+
+- Skeleton generation -> performed by acceptance-test-generator
+- Task file creation -> following task template (see documentation-criteria skill)
+- Test implementation -> performed by task-executor
+- Test review -> performed by integration-test-reviewer
+- Quality checks -> performed by quality-fixer
+
+Orchestrator invokes sub-agents and passes structured JSON between them.
+
+Design Doc path: $ARGUMENTS
+
+**Think deeply** Understand the essence of test addition and execute:
+
+## Prerequisites
+- Design Doc must exist (created manually or via reverse-engineer)
+- Existing implementation to test
+
+## Execution Flow
+
+### 1. Validate Design Doc
+```bash
+# Verify Design Doc exists
+ls $ARGUMENTS || ls docs/design/*.md | grep -v template | tail -1
+```
+
+### 2. Execute acceptance-test-generator
+Generate test skeletons from Design Doc:
+- Extract Acceptance Criteria (AC)
+- Generate integration test skeletons (`*.int.test.ts`)
+- Generate E2E test skeletons if applicable (`*.e2e.test.ts`)
+
+### 3. Create Task File
+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 in Target Files section
+
+### 4. Execute task-executor
+Implement tests following the task file:
+- Follow TDD principles (Red-Green-Refactor)
+- Implement each skeleton test case
+- Run tests and verify they pass
+
+### 5. Execute integration-test-reviewer
+Review test quality:
+- Verify skeleton compliance
+- Check test coverage
+- If `needs_revision` -> Return to step 4 with `requiredFixes`
+- If `approved` -> Proceed to quality check
+
+### 6. Execute quality-fixer
+Final quality assurance:
+- Run all tests
+- Verify coverage meets requirements
+- Fix any quality issues
+
+### 7. Commit
+Commit test files with appropriate message.
+
+## Delegation
+- acceptance-test-generator: Skeleton generation
+- task-executor: Test implementation
+- integration-test-reviewer: Test quality review
+- quality-fixer: Final quality check

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

@@ -0,0 +1,183 @@
+---
+name: front-reverse-design
+description: Generate frontend Design Docs from existing codebase using existing PRD
+---
+
+**Command Context**: Reverse engineering workflow to create frontend Design Docs from existing code
+
+**Prerequisites**: PRD must exist (created via reverse-engineer or manually)
+
+Target PRD: $ARGUMENTS
+
+**TodoWrite**: Register phases first, then steps within each phase as you enter it.
+
+## Step 0: Initial Configuration
+
+### 0.1 Scope Confirmation
+
+Use AskUserQuestion to confirm:
+1. **PRD path**: Which PRD to use as basis
+2. **Target path**: Which frontend directory/module to document
+3. **Human review**: Yes (recommended) / No (fully autonomous)
+
+### 0.2 Output Configuration
+
+- Design Doc output: `docs/design/` or existing design directory
+- Verify directories exist, create if needed
+
+## Workflow Overview
+
+```
+Step 1: Scope Discovery (all frontend components per PRD)
+Step 2-5: Per-component loop (Generation -> Verification -> Review -> Revision)
+```
+
+**Context Passing**: Pass structured JSON output between steps. Use `$STEP_N_OUTPUT` placeholder notation.
+
+## Step 1: Design Doc Scope Discovery
+
+**Task invocation**:
+```
+subagent_type: scope-discoverer
+prompt: |
+  Discover frontend Design Doc targets within PRD scope.
+
+  scope_type: design-doc
+  existing_prd: $USER_PRD_PATH
+  target_path: $USER_TARGET_PATH
+  focus: frontend (React/TypeScript components, hooks, state management)
+```
+
+**Store output as**: `$STEP_1_OUTPUT`
+
+**Quality Gate**:
+- At least one component discovered -> proceed
+- No components -> ask user for hints
+
+**Human Review Point** (if enabled): Present discovered components for confirmation.
+
+## Step 2-5: Per-Component Processing
+
+**Complete Steps 2->3->4->5 for each component before proceeding to the next component.**
+
+### Step 2: Design Doc Generation
+
+**Task invocation**:
+```
+subagent_type: technical-designer-frontend
+prompt: |
+  Create Design Doc for the following frontend component based on existing code.
+
+  Operation Mode: create
+
+  Component: $COMPONENT_NAME (from $STEP_1_OUTPUT)
+  Responsibility: $COMPONENT_RESPONSIBILITY
+  Primary Files: $COMPONENT_PRIMARY_FILES
+  Public Interfaces: $COMPONENT_PUBLIC_INTERFACES
+  Dependencies: $COMPONENT_DEPENDENCIES
+
+  Parent PRD: $USER_PRD_PATH
+
+  Document current architecture. Do not propose changes.
+```
+
+**Store output as**: `$STEP_2_OUTPUT`
+
+### Step 3: Code Verification
+
+**Task invocation**:
+```
+subagent_type: code-verifier
+prompt: |
+  Verify consistency between Design Doc and code implementation.
+
+  doc_type: design-doc
+  document_path: $STEP_2_OUTPUT
+  code_paths: $COMPONENT_PRIMARY_FILES
+  verbose: false
+```
+
+**Store output as**: `$STEP_3_OUTPUT`
+
+**Quality Gate**:
+- consistencyScore >= 70 -> proceed to review
+- consistencyScore < 70 -> flag for detailed review
+
+### Step 4: Review
+
+**Required Input**: $STEP_3_OUTPUT (verification JSON from Step 3)
+
+**Task invocation**:
+```
+subagent_type: document-reviewer
+prompt: |
+  Review the following Design Doc considering code verification findings.
+
+  doc_type: DesignDoc
+  target: $STEP_2_OUTPUT
+  mode: composite
+
+  ## Code Verification Results
+  $STEP_3_OUTPUT
+
+  ## Parent PRD
+  $USER_PRD_PATH
+
+  ## Additional Review Focus
+  - Technical accuracy of documented interfaces
+  - Consistency with parent PRD scope
+  - Completeness of component boundary definitions
+```
+
+**Store output as**: `$STEP_4_OUTPUT`
+
+### Step 5: Revision (conditional)
+
+**Trigger Conditions** (any one of the following):
+- Review status is "Needs Revision" or "Rejected"
+- Critical discrepancies exist in `$STEP_3_OUTPUT`
+- consistencyScore < 70
+
+**Task invocation**:
+```
+subagent_type: technical-designer-frontend
+prompt: |
+  Update Design Doc based on review feedback.
+
+  Operation Mode: update
+  Existing Design Doc: $STEP_2_OUTPUT
+
+  ## Review Feedback
+  $STEP_4_OUTPUT
+
+  ## Discrepancies to Address
+  (Extract critical and major discrepancies from $STEP_3_OUTPUT)
+
+  Apply corrections and improvements.
+```
+
+**Loop Control**: Maximum 2 revision cycles. After 2 cycles, flag for human review regardless of status.
+
+### Component Completion
+
+- [ ] Review status is "Approved" or "Approved with Conditions"
+- [ ] Human review passed (if enabled in Step 0)
+
+**Next**: Proceed to next component. After all components -> Final Report.
+
+## Final Report
+
+Output summary including:
+- Generated documents table (Component, Design Doc Path, Consistency Score, Review Status)
+- Action items (critical discrepancies, undocumented features, flagged items)
+- Next steps checklist
+
+## Error Handling
+
+| Error | Action |
+|-------|--------|
+| PRD not found | Ask user for correct PRD path |
+| Discovery finds nothing | Ask user for project structure hints |
+| Generation fails | Log failure, continue with other components, report in summary |
+| consistencyScore < 50 | Flag for mandatory human review, do not auto-approve |
+| Review rejects after 2 revisions | Stop loop, flag for human intervention |

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

@@ -0,0 +1,89 @@
+---
+name: front-review
+description: Design Doc compliance validation with optional auto-fixes
+---
+
+**Command Context**: Post-implementation quality assurance command for React/TypeScript frontend
+
+## Execution Method
+
+- Compliance validation -> performed by code-reviewer
+- Rule analysis -> performed by rule-advisor
+- Fix implementation -> performed by task-executor-frontend
+- Quality checks -> performed by quality-fixer-frontend
+- Re-validation -> performed by code-reviewer
+
+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:
+
+## Execution Flow
+
+### 1. Prerequisite Check
+```bash
+# Identify Design Doc
+ls docs/design/*.md | grep -v template | tail -1
+
+# Check implementation files
+git diff --name-only main...HEAD
+```
+
+### 2. Execute code-reviewer
+Validate Design Doc compliance:
+- Acceptance criteria fulfillment
+- Code quality check
+- Implementation completeness assessment
+
+### 3. Verdict and Response
+
+**Criteria (considering project stage)**:
+- Prototype: Pass at 70%+
+- Production: 90%+ recommended
+- Critical items (security, etc.): Required regardless of rate
+
+**Compliance-based response**:
+
+For low compliance (production <90%):
+```
+Validation Result: [X]% compliance
+Unfulfilled items:
+- [item list]
+
+Execute fixes? (y/n):
+```
+
+If user selects `y`:
+
+## Pre-fix Metacognition
+**Required**: `rule-advisor -> TodoWrite -> task-executor-frontend -> quality-fixer-frontend`
+
+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-frontend**: Staged auto-fixes (stops at 5 files)
+4. **Execute quality-fixer-frontend**: Confirm quality gate passage
+5. **Re-validate**: Measure improvement with code-reviewer
+
+### 4. Final Report
+```
+Initial compliance: [X]%
+Final compliance: [Y]% (if fixes executed)
+Improvement: [Y-X]%
+
+Remaining issues:
+- [items requiring manual intervention]
+```
+
+## Auto-fixable Items
+- Simple unimplemented acceptance criteria
+- Error handling additions
+- Contract definition fixes
+- Function splitting (length/complexity improvements)
+
+## Non-fixable Items
+- Fundamental business logic changes
+- Architecture-level modifications
+- Design Doc deficiencies
+
+**Scope**: Design Doc compliance validation and auto-fixes.

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

@@ -59,7 +59,7 @@ If user selects `y`:
 **Required**: `rule-advisor → 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". Structure fix tasks → `docs/plans/tasks/review-fixes-YYYYMMDD.md`
+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

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

@@ -0,0 +1,74 @@
+---
+name: add-integration-tests
+description: Design Docを使用して既存バックエンドコードベースに統合/E2Eテストを追加
+---
+
+**コマンドコンテキスト**: 既存バックエンド実装へのテスト追加ワークフロー
+
+**スコープ**: バックエンドのみ（acceptance-test-generatorはバックエンドのみ対応）
+
+## 実行方法
+
+- スケルトン生成 → acceptance-test-generatorが実行
+- タスクファイル作成 → タスクテンプレートに従う（documentation-criteriaスキル参照）
+- テスト実装 → task-executorが実行
+- テストレビュー → integration-test-reviewerが実行
+- 品質チェック → quality-fixerが実行
+
+オーケストレーターがサブエージェントを呼び出し、構造化JSONを受け渡す。
+
+Design Docパス: $ARGUMENTS
+
+**Think deeply** テスト追加の本質を理解して実行:
+
+## 前提条件
+- Design Docが存在すること（手動またはreverse-engineerで作成）
+- テスト対象の既存実装があること
+
+## 実行フロー
+
+### 1. Design Doc検証
+```bash
+# Design Docの存在確認
+ls $ARGUMENTS || ls docs/design/*.md | grep -v template | tail -1
+```
+
+### 2. acceptance-test-generator実行
+Design Docからテストスケルトンを生成:
+- 受入条件（AC）を抽出
+- 統合テストスケルトン生成（`*.int.test.ts`）
+- 該当する場合はE2Eテストスケルトン生成（`*.e2e.test.ts`）
+
+### 3. タスクファイル作成
+タスクテンプレートに従ってタスクファイルを作成（documentation-criteriaスキル参照）:
+- パス: `docs/plans/tasks/integration-tests-YYYYMMDD.md`
+- 内容: 生成されたスケルトンに基づくテスト実装タスク
+- 対象ファイルセクションにスケルトンファイルパスを含める
+
+### 4. task-executor実行
+タスクファイルに従ってテストを実装:
+- TDD原則に従う（Red-Green-Refactor）
+- 各スケルトンテストケースを実装
+- テストを実行してパスを確認
+
+### 5. integration-test-reviewer実行
+テスト品質をレビュー:
+- スケルトン準拠を確認
+- テストカバレッジをチェック
+- `needs_revision`の場合 → `requiredFixes`と共にステップ4に戻る
+- `approved`の場合 → 品質チェックに進む
+
+### 6. quality-fixer実行
+最終品質保証:
+- 全テストを実行
+- カバレッジが要件を満たすことを確認
+- 品質問題を修正
+
+### 7. コミット
+適切なメッセージでテストファイルをコミット。
+
+## 委譲先
+- acceptance-test-generator: スケルトン生成
+- task-executor: テスト実装
+- integration-test-reviewer: テスト品質レビュー
+- quality-fixer: 最終品質チェック

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

@@ -0,0 +1,183 @@
+---
+name: front-reverse-design
+description: 既存PRDを使用して既存コードベースからフロントエンドDesign Docを生成
+---
+
+**コマンドコンテキスト**: 既存コードからフロントエンドDesign Docを作成するリバースエンジニアリングワークフロー
+
+**前提条件**: PRDが存在すること（reverse-engineerまたは手動で作成）
+
+対象PRD: $ARGUMENTS
+
+**TodoWrite登録**: まずフェーズを登録し、各フェーズ開始時にステップを登録。
+
+## ステップ0: 初期設定
+
+### 0.1 スコープ確認
+
+AskUserQuestionを使用して確認:
+1. **PRDパス**: どのPRDを基準にするか
+2. **対象パス**: どのフロントエンドディレクトリ/モジュールをドキュメント化するか
+3. **人間レビュー**: Yes（推奨）/ No（完全自律）
+
+### 0.2 出力設定
+
+- Design Doc出力先: `docs/design/` または既存の設計ディレクトリ
+- ディレクトリの存在確認、必要に応じて作成
+
+## ワークフロー概要
+
+```
+ステップ1: スコープ発見（PRDに基づく全フロントエンドコンポーネント）
+ステップ2-5: コンポーネントごとのループ（生成 → 検証 → レビュー → 修正）
+```
+
+**コンテキスト伝達**: ステップ間で構造化JSON出力を受け渡す。`$STEP_N_OUTPUT`プレースホルダー記法を使用。
+
+## ステップ1: Design Docスコープ発見
+
+**Task呼び出し**:
+```
+subagent_type: scope-discoverer
+prompt: |
+  PRDスコープ内のフロントエンドDesign Doc対象を発見。
+
+  scope_type: design-doc
+  existing_prd: $USER_PRD_PATH
+  target_path: $USER_TARGET_PATH
+  focus: frontend (React/TypeScriptコンポーネント、フック、状態管理)
+```
+
+**出力を保存**: `$STEP_1_OUTPUT`
+
+**品質ゲート**:
+- 少なくとも1つのコンポーネントが発見された → 続行
+- コンポーネントなし → ユーザーにヒントを求める
+
+**人間レビューポイント**（ステップ0.1でYesの場合）: 発見されたコンポーネントを確認用に提示。
+
+## ステップ2-5: コンポーネントごとの処理
+
+**次のコンポーネントに進む前に、各コンポーネントでステップ2→3→4→5を完了する。**
+
+### ステップ2: Design Doc生成
+
+**Task呼び出し**:
+```
+subagent_type: technical-designer-frontend
+prompt: |
+  既存コードに基づいて以下のフロントエンドコンポーネントのDesign Docを作成。
+
+  Operation Mode: create
+
+  Component: $COMPONENT_NAME (from $STEP_1_OUTPUT)
+  Responsibility: $COMPONENT_RESPONSIBILITY
+  Primary Files: $COMPONENT_PRIMARY_FILES
+  Public Interfaces: $COMPONENT_PUBLIC_INTERFACES
+  Dependencies: $COMPONENT_DEPENDENCIES
+
+  Parent PRD: $USER_PRD_PATH
+
+  現在のアーキテクチャをドキュメント化。変更提案は不要。
+```
+
+**出力を保存**: `$STEP_2_OUTPUT`
+
+### ステップ3: コード検証
+
+**Task呼び出し**:
+```
+subagent_type: code-verifier
+prompt: |
+  Design Docとコード実装間の整合性を検証。
+
+  doc_type: design-doc
+  document_path: $STEP_2_OUTPUT
+  code_paths: $COMPONENT_PRIMARY_FILES
+  verbose: false
+```
+
+**出力を保存**: `$STEP_3_OUTPUT`
+
+**品質ゲート**:
+- consistencyScore >= 70 → レビューに進む
+- consistencyScore < 70 → 詳細レビュー対象としてフラグ
+
+### ステップ4: レビュー
+
+**必須入力**: $STEP_3_OUTPUT（ステップ3の検証JSON）
+
+**Task呼び出し**:
+```
+subagent_type: document-reviewer
+prompt: |
+  コード検証結果を考慮して以下のDesign Docをレビュー。
+
+  doc_type: DesignDoc
+  target: $STEP_2_OUTPUT
+  mode: composite
+
+  ## コード検証結果
+  $STEP_3_OUTPUT
+
+  ## 親PRD
+  $USER_PRD_PATH
+
+  ## 追加レビュー重点
+  - ドキュメント化されたインターフェースの技術的正確性
+  - 親PRDスコープとの整合性
+  - コンポーネント境界定義の完全性
+```
+
+**出力を保存**: `$STEP_4_OUTPUT`
+
+### ステップ5: 修正（条件付き）
+
+**トリガー条件**（いずれか1つ）:
+- レビューステータスが「Needs Revision」または「Rejected」
+- `$STEP_3_OUTPUT`に重大な不整合が存在
+- consistencyScore < 70
+
+**Task呼び出し**:
+```
+subagent_type: technical-designer-frontend
+prompt: |
+  レビューフィードバックに基づいてDesign Docを更新。
+
+  Operation Mode: update
+  Existing Design Doc: $STEP_2_OUTPUT
+
+  ## レビューフィードバック
+  $STEP_4_OUTPUT
+
+  ## 対処すべき不整合
+  （$STEP_3_OUTPUTから重大・主要な不整合を抽出）
+
+  修正と改善を適用。
+```
+
+**ループ制御**: 最大2回の修正サイクル。2サイクル後、ステータスに関わらず人間レビュー対象としてフラグ。
+
+### コンポーネント完了
+
+- [ ] レビューステータスが「Approved」または「Approved with Conditions」
+- [ ] 人間レビュー通過（ステップ0で有効な場合）
+
+**次へ**: 次のコンポーネントに進む。全コンポーネント完了後 → 最終レポート。
+
+## 最終レポート
+
+以下を含むサマリーを出力:
+- 生成ドキュメント表（コンポーネント、Design Docパス、整合性スコア、レビューステータス）
+- アクション項目（重大な不整合、未ドキュメント化機能、フラグ項目）
+- 次ステップチェックリスト
+
+## エラーハンドリング
+
+| エラー | アクション |
+|-------|---------|
+| PRDが見つからない | ユーザーに正しいPRDパスを確認 |
+| 発見で何も見つからない | ユーザーにプロジェクト構造のヒントを確認 |
+| 生成失敗 | 失敗をログ、他コンポーネントで続行、サマリーで報告 |
+| consistencyScore < 50 | 必須人間レビュー対象としてフラグ、自動承認不可 |
+| 2回修正後もレビュー却下 | ループ停止、人間介入対象としてフラグ |

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

@@ -0,0 +1,89 @@
+---
+name: front-review
+description: Design Doc準拠検証と必要に応じた自動修正
+---
+
+**コマンドコンテキスト**: React/TypeScriptフロントエンド向け実装後品質保証コマンド
+
+## 実行方法
+
+- 準拠検証 → code-reviewerが実行
+- ルール分析 → rule-advisorが実行
+- 修正実装 → task-executor-frontendが実行
+- 品質チェック → quality-fixer-frontendが実行
+- 再検証 → code-reviewerが実行
+
+オーケストレーターがサブエージェントを呼び出し、構造化JSONを受け渡す。
+
+Design Doc（省略時は直近のもの）: $ARGUMENTS
+
+**Think deeply** 準拠検証の本質を理解し、以下のステップで実行:
+
+## 実行フロー
+
+### 1. 前提条件チェック
+```bash
+# Design Docを特定
+ls docs/design/*.md | grep -v template | tail -1
+
+# 実装ファイルをチェック
+git diff --name-only main...HEAD
+```
+
+### 2. code-reviewer実行
+Design Doc準拠を検証:
+- 受入条件の充足確認
+- コード品質チェック
+- 実装完全性の評価
+
+### 3. 判定と対応
+
+**基準（プロジェクト段階を考慮）**:
+- プロトタイプ: 70%以上で合格
+- 本番: 90%以上推奨
+- 重要項目（セキュリティ等）: 率に関わらず必須
+
+**準拠率に基づく対応**:
+
+準拠率が低い場合（本番で90%未満）:
+```
+検証結果: 準拠率 [X]%
+未充足項目:
+- [項目リスト]
+
+修正を実行しますか？ (y/n):
+```
+
+ユーザーが`y`を選択した場合:
+
+## 修正実行前のメタ認知
+**必須**: `rule-advisor → TodoWrite → task-executor-frontend → quality-fixer-frontend`
+
+1. **rule-advisor実行**: 修正の本質を理解（表面的な対症療法 vs 根本解決）
+2. **TodoWrite更新**: 作業ステップを登録。必ず含める: 最初に「スキル制約の確認」、最後に「スキル忠実度の検証」。タスクテンプレートに従ってタスクファイル作成（documentation-criteriaスキル参照） → `docs/plans/tasks/review-fixes-YYYYMMDD.md`
+3. **task-executor-frontend実行**: 段階的自動修正（5ファイルで停止）
+4. **quality-fixer-frontend実行**: 品質ゲート通過を確認
+5. **再検証**: code-reviewerで改善を測定
+
+### 4. 最終レポート
+```
+初期準拠率: [X]%
+最終準拠率: [Y]%（修正実行時）
+改善: [Y-X]%
+
+残存課題:
+- [手動対応が必要な項目]
+```
+
+## 自動修正可能な項目
+- 単純な未実装受入条件
+- エラーハンドリング追加
+- 契約定義の修正
+- 関数分割（長さ/複雑性改善）
+
+## 自動修正不可な項目
+- 根本的なビジネスロジック変更
+- アーキテクチャレベルの修正
+- Design Doc自体の不備
+
+**スコープ**: Design Doc準拠検証と自動修正。

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

@@ -37,7 +37,7 @@ AskUserQuestionで以下を確認:
   ステップ7-10: component毎ループ（生成 → 検証 → レビュー → 修正）
 ```
 
-**コンテキスト受け渡し**: ステップ間で構造化JSON出力を受け渡す。`$STEP_N_OUTPUT`プレースホルダー記法を使用。
+**コンテキスト伝達**: ステップ間で構造化JSON出力を受け渡す。`$STEP_N_OUTPUT`プレースホルダー記法を使用。
 
 ## フェーズ1: PRD生成
 

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

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

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

@@ -145,6 +145,7 @@ description: Guides PRD, ADR, Design Doc, and Work Plan creation with templates
 | ADR | `docs/adr/` | `ADR-[4-digits]-[title].md` | See adr-template.md |
 | 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 |
 
 *Note: Work plans are excluded by `.gitignore`
 
@@ -180,3 +181,4 @@ Templates are available in the `references/` directory:
 - [Product Requirements Document template](references/prd-template.md)
 - [Work Plan template](references/plan-template.md)
 - [Architecture Decision Record template](references/adr-template.md)
+- [Task File template](references/task-template.md)

package/.claude/skills-en/documentation-criteria/references/task-template.md

@@ -0,0 +1,38 @@
+# Task: [Task Name]
+
+Metadata:
+- Dependencies: task-01 -> Deliverable: docs/plans/analysis/research-results.md
+- Provides: docs/plans/analysis/api-spec.md (for research/design tasks)
+- Size: Small (1-2 files)
+
+## Implementation Content
+[What this task will achieve]
+*Reference dependency deliverables if applicable
+
+## Target Files
+- [ ] [Implementation file path]
+- [ ] [Test file path]
+
+## Implementation Steps (TDD: Red-Green-Refactor)
+### 1. Red Phase
+- [ ] Review dependency deliverables (if any)
+- [ ] Verify/create contract definitions
+- [ ] Write failing tests
+- [ ] Run tests and confirm failure
+
+### 2. Green Phase
+- [ ] Add minimal implementation to pass tests
+- [ ] Run only added tests and confirm they pass
+
+### 3. Refactor Phase
+- [ ] Improve code (maintain passing tests)
+- [ ] Confirm added tests still pass
+
+## Completion Criteria
+- [ ] All added tests pass
+- [ ] Operation verified (select L1/L2/L3, per implementation-approach skill)
+- [ ] Deliverables created (for research/design tasks)
+
+## Notes
+- Impact scope: [Areas where changes may propagate]
+- Constraints: [Areas not to be modified]

package/.claude/skills-en/subagents-orchestration-guide/SKILL.md

@@ -100,6 +100,15 @@ I repeat this cycle for each task to ensure quality.
 [^2]: Required when: architecture changes, new technology introduction, OR data flow changes
 [^3]: Create new PRD, update existing PRD, or create reverse PRD (when no existing PRD)
 
+## Structured Response Specifications
+
+Each subagent responds in JSON format:
+- **task-executor**: status, filesModified, testsAdded, readyForQualityCheck
+- **integration-test-reviewer**: status, verdict (approved/needs_revision), requiredFixes
+- **quality-fixer**: status, checksPerformed, fixesApplied, approved
+- **document-reviewer**: status, reviewsPerformed, issues, recommendations, approvalReady
+- **design-sync**: sync_status, total_conflicts, conflicts (severity, type, source_file, target_file)
+
 ## My Basic Flow for Work Planning
 
 When receiving new features or change requests, I first request requirement analysis from requirement-analyzer.
@@ -136,31 +145,11 @@ According to scale determination:
 - task-executor: Implementation authority (can use Edit/Write)
 - quality-fixer: Fix authority (automatic quality error fixes)
 
-### Definition of Autonomous Execution Mode
-After "batch approval for entire implementation phase" with work-planner, autonomously execute the following processes without human approval:
-
-```mermaid
-graph TD
-    START[Batch approval for entire implementation phase] --> AUTO[Start autonomous execution mode]
-    AUTO --> TD[task-decomposer: Task decomposition]
-    TD --> PHASE[Register phase management Todo]
-    PHASE --> PSTART[Phase start: Expand task Todo]
-    PSTART --> TE[task-executor: Implementation]
-    TE --> ESC{Escalation judgment}
-    ESC -->|No issue| FOLLOW[Follow-up processing]
-    ESC -->|Issue found| STOP[Escalate to user]
-    FOLLOW --> QF[quality-fixer: Quality check and fixes]
-    QF --> COMMIT[Execute git commit]
-    COMMIT --> TCHECK{Tasks remaining?}
-    TCHECK -->|Yes| TE
-    TCHECK -->|No| PCHECK{Phases remaining?}
-    PCHECK -->|Yes| PSTART
-    PCHECK -->|No| REPORT[Completion report]
-
-    TE --> INTERRUPT{User input?}
-    INTERRUPT -->|Requirement change| STOP2[Stop autonomous execution]
-    STOP2 --> RA[Re-analyze with requirement-analyzer]
-```
+### Step 2 Execution Details
+- `status: escalation_needed` or `status: blocked` -> Escalate to user
+- `testsAdded` contains `*.int.test.ts` or `*.e2e.test.ts` -> Execute **integration-test-reviewer**
+  - If verdict is `needs_revision` -> Return to task-executor with `requiredFixes`
+  - If verdict is `approved` -> Proceed to quality-fixer
 
 ### Conditions for Stopping Autonomous Execution
 Stop autonomous execution and escalate to user in the following cases:
@@ -217,8 +206,3 @@ Stop autonomous execution and escalate to user in the following cases:
   - On user rejection: Main AI (me) updates Status to Rejected
 - **After Design Doc creation -> document-reviewer execution**: Confirm design content and consistency
 - **After work plan creation**: Batch approval for entire implementation phase (confirm with plan summary)
-
-### Stop Points During Autonomous Execution
-- **When requirement change detected**: Match in requirement change checklist -> Return to requirement-analyzer
-- **When critical error occurs**: Report error content -> Wait for response instructions
-- **When user interrupts**: Explicit stop instruction -> Confirm situation

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

@@ -156,6 +156,7 @@ description: PRD、ADR、Design Doc、作業計画書の作成を支援。テン
 | ADR | `docs/adr/` | `ADR-[4桁]-[タイトル].md` | `adr-template.md` |
 | Design Doc | `docs/design/` | `[機能名]-design.md` | `design-template.md` |
 | 作業計画書 | `docs/plans/` | `YYYYMMDD-{type}-{description}.md` | `plan-template.md` |
+| タスクファイル | `docs/plans/tasks/` | `{plan-name}-task-{number}.md` | `task-template.md` |
 
 ※作業計画書は`.gitignore`で除外
 
@@ -191,3 +192,4 @@ description: PRD、ADR、Design Doc、作業計画書の作成を支援。テン
 - [PRDテンプレート](references/prd-template.md)
 - [作業計画書テンプレート](references/plan-template.md)
 - [ADRテンプレート](references/adr-template.md)
+- [タスクファイルテンプレート](references/task-template.md)

package/.claude/skills-ja/documentation-criteria/references/task-template.md

@@ -0,0 +1,38 @@
+# タスク: [タスク名]
+
+メタデータ:
+- 依存関係: task-01 → 成果物: docs/plans/analysis/research-results.md
+- 提供物: docs/plans/analysis/api-spec.md（調査・設計タスクの場合）
+- サイズ: 小規模（1-2ファイル）
+
+## 実装内容
+[このタスクで達成すること]
+*依存関係の成果物を参照する場合は明記
+
+## 対象ファイル
+- [ ] [実装ファイルパス]
+- [ ] [テストファイルパス]
+
+## 実装ステップ（TDD: Red-Green-Refactor）
+### 1. Redフェーズ
+- [ ] 依存関係の成果物を確認（ある場合）
+- [ ] 契約定義を確認・作成
+- [ ] 失敗するテストを書く
+- [ ] テストを実行し失敗を確認
+
+### 2. Greenフェーズ
+- [ ] テストをパスする最小限の実装を追加
+- [ ] 追加したテストのみ実行しパスを確認
+
+### 3. Refactorフェーズ
+- [ ] コードを改善（テストはパス状態を維持）
+- [ ] 追加したテストが引き続きパスすることを確認
+
+## 完了条件
+- [ ] 追加した全テストがパス
+- [ ] 動作確認完了（L1/L2/L3を選択、implementation-approachスキル参照）
+- [ ] 成果物作成完了（調査・設計タスクの場合）
+
+## 備考
+- 影響範囲: [変更が波及する可能性のある領域]
+- 制約: [変更してはいけない領域]

package/.claude/skills-ja/subagents-orchestration-guide/SKILL.md

@@ -108,18 +108,20 @@ graph TD
 ## 作業計画時の基本フロー
 
 ### 大規模（6ファイル以上）
-1. requirement-analyzer → 要件分析 **[停止: 要件確認]**
+1. requirement-analyzer → 要件分析 + 既存PRD確認 **[停止: 要件確認/質問対応]**
 2. prd-creator → PRD作成 → document-reviewer **[停止: 要件確認]**
 3. technical-designer → ADR作成（必要な場合） → document-reviewer **[停止: 技術方針決定]**
 4. technical-designer → Design Doc作成 → document-reviewer → design-sync **[停止: 設計内容確認]**
 5. acceptance-test-generator → テストスケルトン生成
+   → メインAI: 生成を検証し、work-plannerに情報を渡す
 6. work-planner → 作業計画書作成 **[停止: 実装フェーズ全体の一括承認]**
 7. **自律実行モード開始**: task-decomposer → 全タスク実行 → 完了報告
 
 ### 中規模（3-5ファイル）
-1. requirement-analyzer → 要件分析 **[停止: 要件確認]**
+1. requirement-analyzer → 要件分析 **[停止: 要件確認/質問対応]**
 2. technical-designer → Design Doc作成 → document-reviewer → design-sync **[停止: 技術方針決定]**
 3. acceptance-test-generator → テストスケルトン生成
+   → メインAI: 生成を検証し、work-plannerに情報を渡す
 4. work-planner → 作業計画書作成 **[停止: 実装フェーズ全体の一括承認]**
 5. **自律実行モード開始**: task-decomposer → 全タスク実行 → 完了報告
 
@@ -136,6 +138,12 @@ graph TD
 - task-executor：実装権限（Edit/Write使用可）
 - quality-fixer：修正権限（品質エラー自動修正）
 
+### Step 2 実行詳細
+- `status: escalation_needed` または `status: blocked` → ユーザーにエスカレーション
+- `testsAdded` に `*.int.test.ts` または `*.e2e.test.ts` が含まれる → **integration-test-reviewer** を実行
+  - verdict が `needs_revision` → `requiredFixes` と共に task-executor に戻る
+  - verdict が `approved` → quality-fixer へ進む
+
 ### 自律実行の停止条件
 
 以下の場合に自律実行を停止し、ユーザーにエスカレーション：
@@ -155,35 +163,15 @@ graph TD
 4. **ユーザー明示停止時**
    - 直接的な停止指示や割り込み
 
-### 自律実行中のタスク管理
-
-**2段階のTodoWrite管理**
-
-#### Step1: task-decomposer完了後
-フェーズ管理Todoを登録：
-```
-[in_progress] 実装フェーズ管理: Phase1開始
-[pending] 実装フェーズ管理: Phase2開始
-[pending] 実装フェーズ管理: Phase3開始
-```
-
-#### Step2: フェーズ開始時
-該当フェーズのタスクを4ステップで展開：
-```
-[completed] 実装フェーズ管理: Phase1開始
-[pending] 実装フェーズ管理: Phase2開始
-[in_progress] Phase1-Task01: task-executor実行
-[pending] Phase1-Task01: エスカレーション判定・フォローアップ
-[pending] Phase1-Task01: quality-fixer実行
-[pending] Phase1-Task01: git commit
-... （同パターンで繰り返し）
-[pending] Phase1: 完了チェック
-```
-
 ## オーケストレーターの主な役割
 
 1. **状態管理**: 現在のフェーズ、各サブエージェントの状態、次のアクションを把握
 2. **情報の橋渡し**: サブエージェント間のデータ変換と伝達
+   - 各サブエージェントの出力を次のサブエージェントの入力形式に変換
+   - **前工程の成果物は必ず次のエージェントに渡す**
+   - 構造化レスポンスから必要な情報を抽出
+   - changeSummaryからコミットメッセージを作成 → **Bashでgit commit実行**
+   - 要件変更時は初期要件と追加要件を明示的に統合
 3. **品質保証とコミット実行**: approved=true確認後、即座にgit commit実行
 4. **自律実行モード管理**: 承認後の自律実行開始・停止・エスカレーション判断
 5. **ADRステータス管理**: ユーザー判断後のADRステータス更新（Accepted/Rejected）

package/README.ja.md

@@ -123,12 +123,15 @@ Claude Codeで利用できる主要なコマンド：
 | `/design` | 設計書の作成 | アーキテクチャの計画時（Backend） |
 | `/plan` | 設計書から作業計画書を作成 | 設計承認後（Backend） |
 | `/build` | 既存の計画から実行 | 作業の再開時（Backend） |
-| `/review` | コードの準拠性確認 | 実装完了後 |
+| `/review` | コードの準拠性確認 | 実装完了後（Backend） |
 | `/front-design` | フロントエンド設計書の作成 | React/Viteアーキテクチャ計画時 |
 | `/front-plan` | フロントエンド作業計画書を作成 | フロントエンド設計承認後 |
 | `/front-build` | フロントエンド実装の実行 | Reactコンポーネント開発 |
+| `/front-review` | フロントエンドコードの準拠性確認 | 実装完了後（Frontend） |
 | `/diagnose` | 根本原因分析ワークフロー | デバッグ、トラブルシューティング |
-| `/reverse-engineer` | コードからPRD/Design Docを生成 | 既存システムのドキュメント化 |
+| `/reverse-engineer` | コードからPRD/Design Docを生成 | 既存システムのドキュメント化（Backend） |
+| `/front-reverse-design` | フロントエンドDesign Docを生成 | 既存フロントエンドコードのドキュメント化 |
+| `/add-integration-tests` | 統合/E2Eテストの追加 | Design Doc存在時のテスト追加 |
 
 [コマンドの詳細はこちら →](docs/guides/ja/use-cases.md)
 

package/README.md

@@ -129,12 +129,15 @@ Essential commands for Claude Code:
 | `/design` | Create design docs only | Architecture planning (Backend) |
 | `/plan` | Create work plan from design | After design approval (Backend) |
 | `/build` | Execute from existing plan | Resume work (Backend) |
-| `/review` | Check code compliance | Post-implementation |
+| `/review` | Check code compliance | Post-implementation (Backend) |
 | `/front-design` | Create frontend design docs | React/Vite architecture planning |
 | `/front-plan` | Create frontend work plan | After frontend design approval |
 | `/front-build` | Execute frontend implementation | React component development |
+| `/front-review` | Check frontend code compliance | Post-implementation (Frontend) |
 | `/diagnose` | Root cause analysis workflow | Debugging, troubleshooting |
-| `/reverse-engineer` | Generate PRD/Design Docs from code | Legacy system documentation |
+| `/reverse-engineer` | Generate PRD/Design Docs from code | Legacy system documentation (Backend) |
+| `/front-reverse-design` | Generate frontend Design Docs | Existing frontend code documentation |
+| `/add-integration-tests` | Add integration/E2E tests | When Design Doc exists but tests missing |
 
 [Full command reference →](docs/guides/en/use-cases.md)
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-ai-project",
-  "version": "1.14.7",
+  "version": "1.14.9",
   "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": [