create-ai-project 1.11.2

package/.claude/commands-en/refine-rule.md

@@ -0,0 +1,208 @@
+---
+description: Optimize rule changes for maximum AI execution accuracy
+---
+
+Change request: $ARGUMENTS
+
+**THINK DEEPLY AND SYSTEMATICALLY** Extract the TRUE INTENT behind user's change request and implement with MAXIMUM PRECISION to eliminate ALL ambiguity:
+
+## 9 Optimization Perspectives
+1. Context efficiency vs execution accuracy - Maximum accuracy with minimal description
+2. Deduplication - Consistency within and across rule files
+3. Proper responsibility aggregation - Group related content (minimize read operations)
+4. Clear decision criteria - Measurable standards
+5. Transform negatives to recommendations - Recommended format (background: including NG examples)
+6. Consistent notation - Unified expressions
+7. Explicit prerequisites - Make implicit assumptions visible
+8. Optimized description order - Most important first, exceptions last
+9. Clear scope boundaries - What's covered vs what's not
+
+## Execution Flow
+
+### 1. Understand the Request
+
+Question template when unspecified:
+```
+1. Which rule file to modify?
+   e.g.: typescript.md / ai-development-guide.md / documentation-criteria.md
+
+2. Select change type:
+   a) Add new rule (add new criteria)
+   b) Modify existing rule (clarify ambiguous descriptions)  
+   c) Delete rule (remove obsolete criteria)
+
+3. Specific changes:
+   e.g.: "Add rule prohibiting 'any' type usage"
+   e.g.: "Clarify error handling criteria"
+   [User input]
+```
+
+### 2. Create Design Proposal
+
+Target file identification and current state check:
+
+```
+# Tool selection criteria (measurable decisions)
+if file path is explicitly provided:
+  Read: Direct file read (background: Skip Glob to save context)
+else if partial filename known:
+  Glob: docs/rules/*{keyword}*.md search
+  Read: Check identified file's current state
+else:
+  Glob: docs/rules/*.md for full scan (background: comprehensive search when unclear)
+  Confirm target file selection with user
+```
+
+Design template:
+```
+【Current】
+"Handle errors appropriately" (ambiguous: "appropriately" undefined)
+
+【Understanding User Request】
+"Want stricter error handling" → Set measurable criteria
+
+【Proposal】
+"Error handling implementation criteria:
+1. try-catch required for:
+   - External API calls (fetch, axios, etc.)
+   - File I/O operations (fs.readFile, etc.)
+   - Parsing operations (JSON.parse, parseInt, etc.)
+2. Required error log items:
+   - error.name (error type)
+   - error.stack (location)
+   - Timestamp (ISO 8601 format)
+3. User notification criteria:
+   - No technical details (NG: stack trace display)
+   - Clear action items (recommended: "Please try again")"
+
+Proceed with this design? (y/n)
+```
+
+### 3. Three-Pass Review Process
+
+#### Pass 1: Add for Maximum Accuracy【Addition-Only Mode】
+**MANDATORY DECLARATION**: "Pass 1: Addition mode execution. Deletions are STRICTLY PROHIBITED."
+**REQUIRED ACTIONS**:
+- CONVERT all ambiguous expressions → measurable criteria
+  Example: "large" → "100+ lines" "5+ files"
+- MAKE all implicit prerequisites explicit
+  Example: "In TypeScript environment" "Within async functions"
+- DEFINE all exceptions and edge cases
+  Example: "When null/undefined" "For empty arrays"
+**MANDATORY REPORT**: Count added items (MINIMUM 5 items required)
+
+#### Pass 2: Critical Modification to Reduce Redundancy【Actual Modification Mode】
+**MANDATORY DECLARATION**: "Pass 2: Critical modification mode execution. ACTUALLY DELETE and CONSOLIDATE redundant parts."
+
+**REQUIRED MODIFICATION WORK**:
+1. CRITICALLY REVIEW all Pass 1 additions
+2. APPLY modifications using these EXACT criteria:
+   - Duplicate concepts → MUST consolidate
+   - Overly detailed explanations → MUST simplify
+   - Overlap with other rules → MUST replace with references
+3. RECORD complete before/after diff (deletion reasons REQUIRED)
+
+Report format:
+```
+Modified locations: X items
+Deleted/consolidated content:
+- [Before]: "Detailed description"
+  [After]: "Concise description"
+  [Reason]: Redundancy elimination
+```
+
+#### Pass 3: Accuracy Assurance via Diff Evaluation【Restoration Decision Mode】
+**MANDATORY DECLARATION**: "Pass 3: Diff evaluation mode execution. REVIEW all Pass 2 modifications and RESTORE if accuracy compromised."
+
+**REQUIRED VERIFICATION WORK**:
+1. EVALUATE EACH Pass 2 modification against these criteria:
+   - Does deletion create implementation ambiguity? YES = RESTORE
+   - Are ALL edge cases still covered? NO = RESTORE
+2. Action mapping:
+   - Deletions with accuracy risks → MUST restore
+   - Valid deletions → KEEP
+
+**MANDATORY FINAL CONFIRMATION** (MUST answer explicitly):
+"Are necessary and sufficient conditions present for accurate implementation of user requirements? YES/NO with justification"
+
+**MANDATORY REPORT**: Number of restored items AND final reduction percentage
+
+### 4. Get Approval
+
+Present before/after comparison for user approval.
+
+### 5. Implementation
+
+1. Apply changes with appropriate tool (after user approval)
+2. Final verification with git diff
+3. Suggest `/sync-rules` execution
+
+## Decision Criteria Checklist
+- [ ] Expressible in "if-then" format ("if X then Y")
+- [ ] Measurable by numbers/counts/states (eliminate subjective judgment)
+- [ ] Related content aggregated in single file (minimize read operations)
+- [ ] Relationships with other rules specified (dependencies/references/delegation)
+- [ ] NG examples included as background information
+- [ ] All prerequisites explicitly stated
+
+## Reduction Pattern Examples
+| Pattern | Before | After |
+|---------|--------|-------|
+| Emotional expressions | "must always" | "execute when (background: build error if skipped)" |
+| Time expressions | "immediately" | "execute first after error detection" |
+| Implicit prerequisites | "implement error handling" | "TypeScript async function error handling" |
+| Unclear order | "consider: A, B, C" | "Priority: 1.A (required), 2.B (recommended), 3.C (optional)" |
+| Redundant explanation | "ensure type safety by defining types, checking types, and preventing type errors" | "type safety (define・check・prevent errors)" |
+| Ambiguous scope | "write tests" | "write unit tests (see test-guide for E2E tests)" |
+
+## Output Example
+
+```
+=== Change Implementation Complete ===
+
+【User Request】
+"Strengthen TypeScript error handling rules"
+
+【Changes】
+Target: docs/rules/typescript.md
+Section: ## Error Handling
+
+Before: 
+"Handle errors appropriately"
+
+After (3-pass review complete):
+"Error handling implementation criteria:
+1. try-catch block required for:
+   - External API calls (fetch, axios, etc.)
+   - File I/O operations (fs.readFile, fs.writeFile, etc.)
+   - Exception-prone operations (JSON.parse, parseInt, etc.)
+2. Required error log items:
+   - error.name (error type)
+   - error.stack (location)
+   - new Date().toISOString() (timestamp)
+3. User-facing messages:
+   - No technical details (NG: stack trace display)
+   - Clear action items (recommended: "Please try again")"
+
+【Improvement Metrics】
+- Decision clarity: 0% → 100% (all measurable)
+- Ambiguous expressions: 1 → 0
+- NG examples included as background
+
+Run /sync-rules for metadata synchronization.
+```
+
+## Execution Order
+1. Understand user request
+2. Analyze current state
+3. Design changes with 9 perspectives
+4. 3-pass review process
+5. User approval
+6. Apply changes
+7. Suggest sync-rules
+
+**Scope**: Understanding user change requests and implementing with maximum accuracy
+
+## Error Handling
+- **File not found**: Display available rule list
+- **Large change detected**: Suggest phased implementation for 50%+ changes

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

@@ -0,0 +1,78 @@
+---
+description: Design Doc compliance validation with optional auto-fixes
+---
+
+**Command Context**: Post-implementation quality assurance command
+
+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 → quality-fixer`
+
+1. **Execute rule-advisor**: Understand fix essence (symptomatic treatment vs root solution)
+2. **Update TodoWrite**: Structure fix tasks → `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
+
+### 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
+- Type 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/sync-rules.md

@@ -0,0 +1,116 @@
+---
+description: Synchronize rule metadata and optimize rule-advisor precision after rule edits
+---
+
+**Command Context**: Post-editing maintenance workflow for rule files
+
+**Think deeply** Maximize rule-advisor execution precision through systematic synchronization:
+
+## Execution Flow
+
+### 1. Scan Rule Files
+```bash
+# Runtime rules directory
+RULES_DIR="docs/rules"
+INDEX_FILE="${RULES_DIR}/rules-index.yaml"
+
+# Analyze all rule files
+find "${RULES_DIR}" -name "*.md" -type f | sort
+```
+
+### 2. Synchronize and Optimize Metadata
+
+#### Automatic Section Synchronization
+- Extract `## ` sections from each file
+- Update sections in rules-index.yaml automatically
+
+#### Tag Optimization
+- Analyze file content for relevant keywords
+- Propose addition of missing tags
+- Suggest removal of obsolete tags
+
+#### Typical-Use Enhancement
+- Infer usage scenarios from file changes
+- Propose more specific and actionable descriptions
+
+#### Key-References Completion
+- Detect newly introduced concepts or methodologies
+- Suggest relevant reference additions
+
+### 3. Rule-Advisor Precision Optimization
+
+Enhance metadata quality to enable accurate rule selection by rule-advisor:
+
+```
+=== Rule Metadata Synchronization ===
+Target: docs/rules
+
+Updates executed:
+✅ Sections synchronized
+  - typescript-testing.md: 2 sections added
+  - ai-development-guide.md: 1 section updated
+
+✅ Tags optimized
+  - typescript.md: Suggest adding [functional-programming]
+  - technical-spec.md: Suggest removing [deprecated]
+
+✅ Typical-use improved
+  - 3 files updated with more specific descriptions
+
+Final result: Rule-advisor precision optimization complete
+```
+
+## 🧠 Metacognitive Points
+
+**Essential Purpose**:
+- Not mere consistency maintenance, but rule-advisor selection accuracy enhancement
+- Metadata optimization as the final step of rule editing workflow
+
+**Quality Criteria**:
+- Sections must achieve 100% synchronization
+- Tags must accurately reflect content
+- Typical-use must specify concrete usage scenarios
+- Key-references must cover current methodologies
+
+## Change Necessity Evaluation
+
+**EVALUATION SEQUENCE**:
+- IF sections achieve 100% synchronization → OUTPUT "Synchronization verified. No updates required." THEN TERMINATE
+- IF content-to-tag mapping shows zero mismatches → DETERMINE no_changes_needed = true THEN TERMINATE  
+- IF AND ONLY IF measurable improvements exist → GENERATE specific modification proposals WITH exact before/after values
+
+**NOTE**: You MUST NOT force changes. When no improvements are detected, you SHALL report "No modifications necessary" and STOP execution.
+
+## Execution Timing
+
+- After rule file edits (mandatory)
+- When adding new rule files
+- After major rule revisions
+- When rule-advisor selection accuracy appears degraded
+
+## Example Output
+
+```
+=== Rule Metadata Synchronization Started ===
+Target: docs/rules (9 files)
+
+[1/9] typescript.md
+  ✅ sections: 7 synchronized
+  💡 tags proposed: +[functional-programming, dependency-injection]
+  💡 typical-use: "General TypeScript implementation" → "Type-safe implementation with modern TypeScript features"
+
+[2/9] typescript-testing.md
+  ✅ sections: 2 added (Test Granularity Principles, Mock Type Safety Enforcement)
+  ✅ tags: No changes needed
+  ✅ typical-use: Maintained
+
+...
+
+=== Synchronization Complete ===
+Updated: 3 files
+Proposals: 5 items (approval required)
+
+Rule-advisor precision improvement: Estimated 15% enhancement
+```
+
+**Scope**: Post-edit rule metadata synchronization and rule-advisor precision optimization.

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

@@ -0,0 +1,13 @@
+---
+description: Execute tasks following appropriate rules
+---
+
+Task: $ARGUMENTS
+
+**Pre-execution Checklist** (MUST clarify BEFORE starting):
+
+1. **Applicable Rules**: Which development rules apply to this task?
+2. **Initial Action**: Based on the rules, what is the FIRST step?
+3. **Scope Boundary**: What are the completion criteria and scope of responsibility?
+
+Proceed with the task ONLY AFTER making the above explicit.

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

@@ -0,0 +1,75 @@
+---
+description: 分解済みタスクを自律実行モードで実装
+---
+
+@docs/guides/sub-agents.md を厳守し、**オーケストレーター**として振る舞います。
+
+作業計画書: $ARGUMENTS
+
+## 📋 実行前の前提確認
+
+### タスクファイル存在チェック
+```bash
+# 計画書の確認
+! ls -la docs/plans/*.md | grep -v template | tail -5
+
+# タスクファイルの確認
+! ls docs/plans/tasks/*.md 2>/dev/null || echo "⚠️ タスクファイルが見つかりません"
+```
+
+### タスク生成判定フロー
+
+**Think deeply** タスクファイルの存在状態を確認し、適切な対応を決定：
+
+| 状態 | 判定基準 | 次のアクション |
+|------|---------|--------------|
+| タスク存在 | tasks/ディレクトリに.mdファイルあり | 自律実行モードへ移行 |
+| タスクなし＋計画書あり | 計画書は存在するがタスクファイルなし | ユーザーに確認 → task-decomposer実行 |
+| 両方なし | 計画書もタスクファイルもなし | エラー：実行条件を満たさない |
+
+## 🔄 タスク分解フェーズ（条件付き実行）
+
+タスクファイルが存在しない場合の処理：
+
+### 1. ユーザー確認
+```
+タスクファイルが見つかりません。
+作業計画書: docs/plans/[計画書名].md
+
+計画書からタスクを分解して生成しますか？ (y/n): 
+```
+
+### 2. タスク分解実行（承認時）
+```
+@task-decomposer 作業計画書を読み込み、1コミット粒度の独立したタスクに分解：
+- 入力: docs/plans/[計画書名].md
+- 出力: docs/plans/tasks/配下に個別タスクファイル生成
+- 粒度: 1タスク = 1コミット = 独立して実行可能
+```
+
+### 3. 生成確認
+```bash
+# 生成されたタスクファイルを確認
+! ls -la docs/plans/tasks/*.md | head -10
+```
+
+✅ **推奨**: タスク生成完了後、自動的に自律実行モードへ移行
+❌ **避ける**: タスク未生成のまま実装を開始
+
+## 🧠 タスク実行フロー
+sub-agents.mdの「自律実行中のタスク管理」に従い、TodoWriteで4ステップを管理：
+1. task-executor実行
+2. エスカレーション判定・フォローアップ
+3. quality-fixer実行
+4. git commit
+
+承認確認後、自律実行モードを開始。要件変更検知時は即座に停止。
+
+## 出力例
+実装フェーズが完了しました。
+- タスク分解: docs/plans/tasks/ 配下に生成（実行時のみ）
+- 実装されたタスク: [タスク数]件
+- 品質チェック: すべて通過
+- コミット: [コミット数]件作成
+
+**責務境界**: 本コマンドはタスク分解から実装完了まで担当。

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

@@ -0,0 +1,37 @@
+---
+description: 要件分析から設計書作成まで実行
+---
+
+**コマンドコンテキスト**: このコマンドは設計フェーズ専用です。
+
+@docs/guides/sub-agents.md の設計フローに従い、**requirement-analyzer から設計書作成・承認まで**を実行します。
+
+要件: $ARGUMENTS
+
+**Think harder** 設計への影響を深く考慮し、まず要件の背景と目的を理解するため対話を行い：
+- どのような問題を解決したいか
+- 期待される成果と成功基準
+- 既存システムとの関係性
+
+適度に要件が明確になったら、requirement-analyzerで分析し、規模に応じた適切な設計書を作成します。
+
+設計の代替案とトレードオフを明確に提示します。
+
+**スコープ**: 設計書（ADR/Design Doc）承認＋Design Doc間整合性確認まで。作業計画以降は本コマンドの責務外。
+
+## 実行フロー
+
+1. requirement-analyzer → 要件分析
+2. technical-designer → Design Doc作成
+3. document-reviewer → 単一ドキュメント品質チェック
+4. ユーザー承認
+5. design-sync → Design Doc間整合性検証
+   - 矛盾あり → ユーザーに報告 → 修正指示待ち → technical-designer(update)で修正
+   - 矛盾なし → 終了
+
+## 出力例
+設計フェーズが完了しました。
+- 設計書: docs/design/[ドキュメント名].md
+- 整合性: 他Design Docと矛盾なし（または修正完了）
+
+**重要**: 本コマンドは設計承認＋整合性確認で終了。次フェーズへの移行提案は行わない。

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

@@ -0,0 +1,103 @@
+---
+description: フロントエンド実装を自律実行モードで実行
+---
+
+**コマンドコンテキスト**: オーケストレーターとして、フロントエンド実装の自律実行モードの完遂を自己完結します。
+
+作業計画: $ARGUMENTS
+
+## 📋 実行前提条件
+
+### タスクファイル存在チェック
+```bash
+# 作業計画書を確認
+! ls -la docs/plans/*.md | grep -v template | tail -5
+
+# タスクファイルを確認
+! ls docs/plans/tasks/*.md 2>/dev/null || echo "⚠️ タスクファイルが見つかりません"
+```
+
+### タスク生成判定フロー
+
+**THINK DEEPLY AND SYSTEMATICALLY**: タスクファイルの存在状態を分析し、必要な正確なアクションを決定：
+
+| 状態 | 基準 | 次のアクション |
+|------|------|--------------|
+| タスク存在 | tasks/ディレクトリに.mdファイルあり | 自律実行へ進む |
+| タスクなし+計画あり | 計画書は存在するがタスクファイルなし | ユーザー確認 → task-decomposer実行 |
+| どちらもなし | 計画書もタスクファイルもなし | エラー: 前提条件未達成 |
+
+## 🔄 タスク分解フェーズ（条件付き）
+
+タスクファイルが存在しない場合：
+
+### 1. ユーザー確認
+```
+タスクファイルが見つかりません。
+作業計画: docs/plans/[plan-name].md
+
+作業計画からタスクを生成しますか？ (y/n):
+```
+
+### 2. タスク分解（承認された場合）
+```
+@task-decomposer 作業計画を読み込み、アトミックなタスクに分解：
+- 入力: docs/plans/[plan-name].md
+- 出力: docs/plans/tasks/ 配下の個別タスクファイル
+- 粒度: 1タスク = 1コミット = 独立実行可能
+```
+
+### 3. 生成確認
+```bash
+# 生成されたタスクファイルを確認
+! ls -la docs/plans/tasks/*.md | head -10
+```
+
+✅ **必須**: タスク生成後、自動的に自律実行へ進む
+❌ **禁止**: タスク生成なしで実装開始
+
+## 🧠 各タスクのメタ認知 - フロントエンド特化
+
+**必須実行サイクル**: `task-executor-frontend → quality-fixer-frontend → commit`
+
+### サブエージェント呼び出し方法
+Taskツールを使用してサブエージェントを呼び出す：
+- `subagent_type`: エージェント名
+- `description`: タスクの簡潔な説明（3-5語）
+- `prompt`: 具体的な指示内容
+
+### 構造化レスポンス仕様
+各サブエージェントはJSON形式で応答：
+- **task-executor-frontend**: status, filesModified, testsAdded, readyForQualityCheck
+- **quality-fixer-frontend**: status, checksPerformed, fixesApplied, approved
+
+### 各タスクの実行フロー
+
+各タスクで実行：
+
+1. **task-executor-frontend使用**: フロントエンド実装を実行
+   - 呼び出し例: `subagent_type: "task-executor-frontend"`, `description: "タスク実行"`, `prompt: "タスクファイル: docs/plans/tasks/[ファイル名].md 実装を実行"`
+2. **構造化レスポンス処理**: `readyForQualityCheck: true` 検出時 → 即座にquality-fixer-frontend実行
+3. **quality-fixer-frontend使用**: 全品質チェック実行（Biome、TypeScriptビルド、テスト）
+   - 呼び出し例: `subagent_type: "quality-fixer-frontend"`, `description: "品質チェック"`, `prompt: "全てのフロントエンド品質チェックと修正を実行"`
+4. **コミット実行**: `approved: true`確認後、即座にgit commitを実行
+
+### 自律実行中の品質保証（詳細）
+- task-executor-frontend実行 → quality-fixer-frontend実行 → **私（メインAI）がコミット実行**（Bashツール使用）
+- quality-fixer-frontendの`approved: true`確認後、即座にgit commitを実行
+- changeSummaryをコミットメッセージに使用
+
+**THINK DEEPLY**: 例外なく全ての構造化レスポンスを監視し、全ての品質ゲートが通過することを確保。
+
+! ls -la docs/plans/*.md | head -10
+
+承認ステータスを確認してから進む。確認後、自律実行モードを開始。要件変更を検出したら即座に停止。
+
+## 出力例
+フロントエンド実装フェーズ完了。
+- タスク分解: docs/plans/tasks/ 配下に生成
+- 実装タスク: [件数] タスク
+- 品質チェック: 全てパス（Biome、TypeScriptビルド、テスト）
+- コミット: [件数] コミット作成
+
+**重要**: このコマンドは、タスク分解から完了までのフロントエンド実装全体の自律実行フローを管理します。フロントエンド特化エージェント（task-executor-frontend、quality-fixer-frontend）を自動使用します。

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

@@ -0,0 +1,42 @@
+---
+description: 要件分析からフロントエンド設計ドキュメント作成まで実行
+---
+
+**コマンドコンテキスト**: このコマンドはフロントエンド設計フェーズ専用です。
+
+**要件分析からフロントエンド設計ドキュメント作成・承認まで**を実行します。
+
+要件: $ARGUMENTS
+
+## 実行フロー
+
+### 1. 要件分析フェーズ
+**Think harder**: 設計への影響が深いことを考慮し、まず対話により要件の背景と目的を理解：
+- 何の問題を解決したいか
+- 期待する成果と成功基準
+- 既存システムとの関係
+
+要件がある程度明確になったら：
+- Taskツールで **requirement-analyzer** を呼び出し
+  - `subagent_type: "requirement-analyzer"`
+  - `description: "要件分析"`
+  - `prompt: "要件: [ユーザー要件] 要件分析と規模判定を実施してください"`
+- **[停止]**: 要件分析結果を確認し、質問事項に対応
+
+### 2. 設計ドキュメント作成フェーズ
+規模判定に応じて適切な設計ドキュメントを作成：
+- 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** を呼び出して整合性検証
+  - `subagent_type: "document-reviewer"`, `description: "ドキュメントレビュー"`, `prompt: "[ドキュメントパス]の整合性と完成度をレビュー"`
+- **[停止]**: 設計の選択肢とトレードオフを提示し、ユーザー承認を取得
+
+**スコープ**: フロントエンド設計ドキュメント（ADR/Design Doc）の承認まで。作業計画以降はこのコマンドの範囲外。
+
+## 出力例
+フロントエンド設計フェーズ完了。
+- 設計ドキュメント: docs/design/[ドキュメント名].md または docs/adr/[ドキュメント名].md
+- 承認ステータス: ユーザー承認済み
+
+**重要**: このコマンドは設計承認で終了。次フェーズへの移行は提案しません。