create-ai-project 1.16.0 → 1.16.2

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

@@ -4,7 +4,7 @@ description: Orchestrate the complete implementation lifecycle from requirements
 
 **Command Context**: Full-cycle implementation management (Requirements Analysis → Design → Planning → Implementation → Quality Assurance)
 
-Strictly adhere to subagents-orchestration-guide skill and operate as an orchestrator.
+Strictly adhere to subagents-orchestration-guide skill and operate as an orchestrator — your role is to invoke sub-agents, pass data between them, and report results.
 
 ## Execution Decision Flow
 

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

@@ -9,7 +9,7 @@ description: Create work plan from design document and obtain plan approval
 **Core Identity**: "I am not a worker. I am an orchestrator." (see subagents-orchestration-guide skill)
 
 **Execution Protocol**:
-1. **Delegate all work** to sub-agents (NEVER create plans yourself)
+1. **Delegate all work** to sub-agents — your role is to invoke sub-agents, pass data between them, and report results
 2. **Follow subagents-orchestration-guide skill planning flow exactly**:
    - Execute steps defined below
    - **Stop and obtain approval** for plan content before completion

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

@@ -1,8 +1,8 @@
 ---
-description: Implement user skill change requests with maximum precision optimization
+description: Implement user skill change requests with optimization pattern evaluation
 ---
 
-**Command Context**: Workflow for understanding skill file change requests and implementing with maximum precision
+**Command Context**: Workflow for understanding skill file change requests and implementing with quality-assured optimization.
 
 Change request: $ARGUMENTS
 
@@ -38,37 +38,38 @@ Present before/after comparison of current state and proposed change:
 Proceed with this design? (y/n)
 ```
 
-**Design 9-Point Checklist**:
-1. Maximum accuracy with minimal description (context efficiency)
-2. Deduplication within and across skill files
-3. Group related content in single file (minimize read operations)
-4. Measurable decision criteria (if-then format)
-5. Transform NG examples to recommendation format (background: including NG examples)
-6. Consistent notation
-7. Make implicit prerequisites explicit
-8. Description order: most important first, exceptions last
-9. Clear scope boundaries: what's covered vs what's not
+**Design Checklist**: Evaluate proposal against the 9 editing principles defined in skill-optimization skill. Key focus areas:
+- Context efficiency: every added sentence must contribute to LLM decision-making
+- Measurability: all criteria use if-then format or concrete thresholds
+- Deduplication: verify no overlap with other skill files
+- Scope boundaries: confirm changes stay within this skill's responsibility
 
-### Step 3: Three-Pass Review Process
+### Step 3: Quality Review
 
-1. **Addition Mode**: Ambiguous expressions → measurable criteria, implicit prerequisites → explicit conditions, edge case definitions (minimum 5 additions)
-2. **Critical Modification Mode**: Consolidate duplicates, simplify excessive detail, replace overlap with other skills → references (record before/after diffs)
-3. **Restoration Decision Mode**: Deletions with accuracy risk → restore, valid deletions → keep
+Invoke skill-reviewer agent via Task tool:
+- Pass the modified SKILL.md content
+- Review mode: `modification`
 
-Final check: "Are necessary and sufficient conditions present for accurate implementation of user requirements?"
+**Review outcome handling:**
+- Grade A or B: proceed to Step 4
+- Grade C: revise changes based on reviewer's action items and re-review (max 2 iterations)
+- Reviewer identifies issues outside the change scope: report to user as separate improvement opportunities
 
 ### Step 4: Approval and Implementation
 
 1. Present before/after comparison to user and obtain approval
-2. Apply changes with appropriate tool
-3. Verify with git diff
-4. Suggest `/sync-skills` execution
+2. Include skill-reviewer's grade and any remaining action items
+3. Confirm user intent alignment: "Do the changes achieve what you originally requested?"
+4. Apply changes with appropriate tool
+4. Verify with git diff
+5. If reviewer flagged issues outside change scope, list them as optional follow-ups
+6. Suggest `/sync-skills` execution
 
 ## Completion Criteria
 
 - [ ] Identified target skill and understood current state
-- [ ] Reviewed design proposal against 9-point checklist
-- [ ] Completed three-pass review process
+- [ ] Reviewed design proposal against skill-optimization editing principles
+- [ ] skill-reviewer returned grade A or B
 - [ ] Obtained user approval
 - [ ] Applied changes and verified with git diff
 - [ ] Suggested /sync-skills execution
@@ -78,7 +79,9 @@ Final check: "Are necessary and sufficient conditions present for accurate imple
 | Error | Action |
 |-------|--------|
 | Skill not found | Display available skill list |
-| Large change detected (50%+) | Suggest phased implementation |
+| Large change detected (50%+ of file) | Suggest phased implementation |
 | Responsibility overlap with other skills | Confirm boundaries and defer to user judgment |
+| Grade C after 2 review iterations | Present changes with issues list, let user decide |
+| Reviewer identifies regression | Revert specific change causing regression, re-review |
 
-**Scope**: Understanding user change requests and implementing with maximum precision. Through /sync-skills coordination.
+**Scope**: Understanding user change requests and implementing with quality-assured optimization. Quality evaluation delegated to skill-reviewer agent. Metadata sync through /sync-skills.

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

@@ -6,6 +6,15 @@ description: Generate PRD and Design Docs from existing codebase through discove
 
 Target: $ARGUMENTS
 
+## Orchestrator Definition
+
+**Core Identity**: "I am not a worker. I am an orchestrator." (see subagents-orchestration-guide skill)
+
+**Execution Protocol**:
+1. **Delegate all work** to sub-agents — your role is to invoke sub-agents, pass data between them, and report results
+2. **Pass structured JSON** between steps using `$STEP_N_OUTPUT` placeholder notation
+3. **Never investigate code yourself** — all code reading is done by sub-agents
+
 **TodoWrite**: Register phases first, then steps within each phase as you enter it.
 
 ## Step 0: Initial Configuration
@@ -39,8 +48,6 @@ Phase 2: Design Doc Generation (if requested)
   ※ fullstack=Yes: units may produce backend + frontend Design Docs based on scope
 ```
 
-**Context Passing**: Pass structured JSON output between steps. Use `$STEP_N_OUTPUT` placeholder notation.
-
 ## Phase 1: PRD Generation
 
 **Register in TodoWrite**:
@@ -70,7 +77,7 @@ prompt: |
 
 ### Step 2-5: Per-Unit Processing
 
-**Complete Steps 2→3→4→5 for each unit before proceeding to the next unit.**
+**FOR** each unit in `$STEP_1_OUTPUT.discoveredUnits` **(sequential, one unit at a time):**
 
 #### Step 2: PRD Generation
 
@@ -96,6 +103,8 @@ prompt: |
 
 #### Step 3: Code Verification
 
+**Prerequisite**: $STEP_2_OUTPUT (PRD path from Step 2)
+
 **Task invocation**:
 ```
 subagent_type: code-verifier
@@ -158,10 +167,13 @@ prompt: |
   ## Review Feedback
   $STEP_4_OUTPUT
 
-  ## Discrepancies to Address
-  (Extract critical and major discrepancies from $STEP_3_OUTPUT)
+  ## Code Verification Results
+  $STEP_3_OUTPUT
 
-  Apply corrections and improvements.
+  Address each issue by severity:
+  - critical: Must fix — incorrect or missing core behavior
+  - important: Should fix — improves accuracy or completeness
+  - recommended: May fix — stylistic or minor improvements
 ```
 
 **Loop Control**: Maximum 2 revision cycles. After 2 cycles, flag for human review regardless of status.
@@ -195,13 +207,15 @@ Map `$STEP_1_OUTPUT` units to Design Doc generation targets, carrying forward:
 
 ### Step 7-10: Per-Unit Processing
 
-**Complete Steps 7→8→9→10 for each unit before proceeding to the next unit.**
+**FOR** each unit in `$STEP_6_OUTPUT.designDocTargets` **(sequential, one unit at a time):**
 
 #### Step 7: Design Doc Generation
 
 Generate Design Docs per unit based on `$STEP_6_OUTPUT` mapping.
 
-**Design Doc** (technical-designer):
+When fullstack=Yes, invoke 7a then 7b sequentially (7b depends on 7a output).
+
+**7a.** Backend Design Doc (technical-designer):
 
 When fullstack=Yes: append "Focus on: API contracts, data layer, business logic, service architecture." to the prompt.
 
@@ -226,7 +240,7 @@ prompt: |
 
 **Store output as**: `$STEP_7_OUTPUT`
 
-**Frontend Design Doc** (fullstack, units with frontend scope):
+**7b.** Frontend Design Doc (fullstack, units with frontend scope):
 
 ```
 subagent_type: technical-designer-frontend
@@ -299,7 +313,54 @@ prompt: |
 
 #### Step 10: Revision (conditional)
 
-Same logic as Step 5, using the corresponding technical-designer / technical-designer-frontend with update mode.
+**Trigger Conditions** (any one of the following):
+- Review status is "Needs Revision" or "Rejected"
+- Critical discrepancies exist in `$STEP_8_OUTPUT`
+- consistencyScore < 70
+
+**Backend Design Doc revision** (technical-designer):
+```
+subagent_type: technical-designer
+prompt: |
+  Update Design Doc based on review feedback.
+
+  Operation Mode: update
+  Existing Document: $STEP_7_OUTPUT
+
+  ## Review Feedback
+  $STEP_9_OUTPUT
+
+  ## Code Verification Results
+  $STEP_8_OUTPUT
+
+  Address each issue by severity:
+  - critical: Must fix — incorrect or missing core behavior
+  - important: Should fix — improves accuracy or completeness
+  - recommended: May fix — stylistic or minor improvements
+```
+
+**Frontend Design Doc revision** (fullstack, technical-designer-frontend):
+```
+subagent_type: technical-designer-frontend
+prompt: |
+  Update frontend Design Doc based on review feedback.
+
+  Operation Mode: update
+  Existing Document: $STEP_7_FRONTEND_OUTPUT
+
+  ## Review Feedback
+  $STEP_9_OUTPUT
+
+  ## Code Verification Results
+  $STEP_8_OUTPUT
+
+  Address each issue by severity:
+  - critical: Must fix — incorrect or missing core behavior
+  - important: Should fix — improves accuracy or completeness
+  - recommended: May fix — stylistic or minor improvements
+```
+
+**Loop Control**: Maximum 2 revision cycles. After 2 cycles, flag for human review regardless of status.
 
 #### Unit Completion
 

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

@@ -34,6 +34,8 @@ Validate Design Doc compliance:
 - Code quality check
 - Implementation completeness assessment
 
+**Store output as**: `$STEP_2_OUTPUT`
+
 ### 3. Verdict and Response
 
 **Criteria (considering project stage)**:
@@ -60,7 +62,7 @@ If user selects `y`:
 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. **Re-validate**: Re-validate Design Doc compliance after fixes. Prior compliance issues: $STEP_2_OUTPUT. Verify each prior issue is resolved.
 
 ### 4. Final Report
 ```

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

@@ -11,7 +11,7 @@ description: Update existing design documents (Design Doc / PRD / ADR) with revi
 **First Action**: Register Steps 1-6 to TodoWrite before any execution.
 
 **Execution Protocol**:
-1. **Delegate all work** to sub-agents (NEVER edit documents yourself)
+1. **Delegate all work** to sub-agents — your role is to invoke sub-agents, pass data between them, and report results
 2. **Execute update flow**:
    - Identify target → Clarify changes → Update document → Review → Consistency check
    - **Stop at every `[Stop: ...]` marker** → Wait for user approval before proceeding
@@ -125,9 +125,29 @@ prompt: |
   - Completeness of change history
 ```
 
+**Store output as**: `$STEP_5_OUTPUT`
+
 **On review result**:
 - Approved → Proceed to Step 6
-- Needs revision → Return to Step 4 with reviewer feedback (max 2 iterations)
+- Needs revision → Return to Step 4 with the following prompt:
+  ```
+  subagent_type: [Update Agent from Step 2]
+  description: "Revise [Type] based on review feedback"
+  prompt: |
+    Operation Mode: update
+    Existing Document: [path from Step 1]
+
+    ## Prior Review Feedback
+    $STEP_5_OUTPUT
+
+    Address each issue by severity:
+    - critical: Must fix
+    - important: Should fix
+    - recommended: May fix
+
+    Apply corrections and update change history.
+  ```
+  (max 2 iterations)
 - **After 2 rejections** → Flag for human review, present accumulated feedback to user and end
 
 Present review result to user for approval.

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

@@ -2,7 +2,7 @@
 description: 分解済みタスクを自律実行モードで実装
 ---
 
-subagents-orchestration-guideスキルの指針に従い、**オーケストレーター**として振る舞います。
+subagents-orchestration-guideスキルの指針に従い、**オーケストレーター**として振る舞います — 役割はサブエージェントの呼び出し、データの受け渡し、結果の報告。
 
 作業計画書: $ARGUMENTS
 

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

@@ -0,0 +1,93 @@
+---
+description: 対話的にユーザーの知識を収集し、最適化されたスキルを作成
+---
+
+**コマンドコンテキスト**: 対話を通じてユーザーの知識を収集し、最適化されたスキルファイルを生成・レビューするワークフロー。
+
+スキルのトピック: $ARGUMENTS
+
+## 実行プロセス
+
+以下のステップをTodoWriteに登録し、順番に進行する。
+
+### Step 1: 事前確認
+
+1. 既存スキルをGlob: `.claude/skills/*/SKILL.md`
+2. `$ARGUMENTS`が既存スキル名と一致する場合: `/refine-skill`を提案して終了
+3. 既存スキル名の一覧をユーザーに提示
+
+### Step 2: スキル知識の収集
+
+AskUserQuestionで3ラウンドに分けて情報を収集する。
+
+**ラウンド1: スキルの本質**
+- このスキルはどのドメイン知識を体系化するか？（1-2文）
+- スキル適用時の主な目的は？（例: 「型安全性の確保」「テストパターンの標準化」）
+
+**ラウンド2: スコープと使用場面**
+- どのような場面でこのスキルを有効化すべきか？ 具体的なシナリオを3-5個（例: 「ユニットテスト作成時」「セキュリティ観点でのPRレビュー時」）
+- このスキルが明示的に扱わない範囲は？（スコープ境界）
+
+**ラウンド3: 判断基準とコンテンツ**
+- 具体的なルールや基準は？（体系化すべき中核知識）
+- 良い/悪いパターンの具体例は？
+- このスキルが準拠する外部参照や標準は？
+
+### Step 3: スキル名と構造の決定
+
+1. 既存の命名規則に従い名詞/動名詞形式のスキル名を導出:
+   - `coding-standards`, `typescript-rules`, `implementation-approach`（名詞/動名詞の複合語）
+2. 収集した内容量からサイズを見積もり
+3. スキル名と構造をAskUserQuestionで確認
+
+### Step 4: スキルコンテンツの生成
+
+収集した情報を渡してskill-creatorエージェントをTask toolで起動:
+- ラウンド3の生の知識
+- Step 3のスキル名
+- ラウンド2の使用場面
+- ラウンド2のスコープ
+- ラウンド3の判断基準
+
+### Step 5: 生成コンテンツのレビュー
+
+skill-reviewerエージェントをTask toolで起動:
+- skill-creatorの生成コンテンツを渡す
+- レビューモード: `creation`
+
+グレードC: reviewerの修正提案に基づき修正し再レビュー（最大2回）。
+グレードAまたはB: Step 6へ進行。
+
+### Step 6: ユーザー確認と書き込み
+
+1. 生成したSKILL.mdの内容をユーザーに提示し最終承認を取得
+2. 意図の整合性を確認: 「このスキルは説明いただいた知識と基準を正しく反映していますか？」
+3. 修正要望がある場合: 変更を適用しskill-reviewerを再実行
+4. 承認後、`.claude/skills/{スキル名}/SKILL.md`に書き込み
+5. `/sync-skills`の実行を提案
+
+## 完了条件
+
+- [ ] 既存スキルとの名前衝突がない
+- [ ] 3ラウンドの対話でスキル知識を収集済み
+- [ ] スキル名をユーザーが確認済み
+- [ ] skill-creatorが有効なJSON出力を返却
+- [ ] skill-reviewerがグレードAまたはBを返却
+- [ ] ユーザーが最終コンテンツを承認済み
+- [ ] `.claude/skills/{スキル名}/SKILL.md`に書き込み済み
+- [ ] `/sync-skills`の実行を提案済み
+
+## エラーハンドリング
+
+| エラー | アクション |
+|--------|-----------|
+| スキル名が既存と重複 | `/refine-skill {スキル名}`を提案 |
+| 3ラウンドで知識が不足 | 対象を絞った追加質問（最大2問） |
+| skill-creatorが無効なJSONを返却 | 入力を簡素化して1回再試行 |
+| 2回のレビューでもグレードC | 現在の内容と問題リストを提示し、ユーザーに判断を委ねる |
+| ユーザーが生成内容を却下 | 具体的なフィードバックを収集し、調整してskill-creatorを再実行 |
+
+## スコープ境界
+
+**このコマンドが担当**: 対話による知識収集、creatorとreviewerエージェントの連携、ファイル書き込み。
+**このコマンドは担当しない**: スキルコンテンツの最適化ロジック（skill-creatorに委譲）、品質評価ロジック（skill-reviewerに委譲）、メタデータ同期（`/sync-skills`に委譲）。

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

@@ -9,7 +9,7 @@ description: 要件分析から設計書作成まで実行
 **コアアイデンティティ**: 「私は作業者ではない。オーケストレーターである。」（subagents-orchestration-guideスキル参照）
 
 **実行プロトコル**:
-1. **全作業をサブエージェントに委譲**（自分で調査・分析しない）
+1. **全作業をサブエージェントに委譲** — 役割はサブエージェントの呼び出し、データの受け渡し、結果の報告
 2. **subagents-orchestration-guideスキルの設計フローに厳密に従う**:
    - 実行: requirement-analyzer → technical-designer → document-reviewer → design-sync
    - **`[停止: ...]`マーカーで必ず停止** → 次に進む前にユーザー承認を待つ

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

@@ -4,7 +4,7 @@ description: オーケストレーターとして要件分析から実装まで
 
 **コマンドコンテキスト**: 実装の完全サイクル管理（要件分析→設計→計画→実装→品質保証）
 
-subagents-orchestration-guideスキルの指針に従い、オーケストレーターとして振る舞います。
+subagents-orchestration-guideスキルの指針に従い、オーケストレーターとして振る舞います — 役割はサブエージェントの呼び出し、データの受け渡し、結果の報告。
 
 ## 実行判断フロー
 

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

@@ -9,7 +9,7 @@ description: 設計書から作業計画書を作成し計画承認を取得
 **コアアイデンティティ**: 「私は作業者ではない。オーケストレーターである。」（subagents-orchestration-guideスキル参照）
 
 **実行プロトコル**:
-1. **全作業をサブエージェントに委譲**（自分で計画を作成しない）
+1. **全作業をサブエージェントに委譲** — 役割はサブエージェントの呼び出し、データの受け渡し、結果の報告
 2. **subagents-orchestration-guideスキルの計画フローに厳密に従う**:
    - 以下のステップを実行
    - **完了前に計画承認を取得**

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

@@ -1,8 +1,8 @@
 ---
-description: ユーザーのスキル変更要求を精度最大化して実装
+description: ユーザーのスキル変更要求を最適化パターン評価付きで実装
 ---
 
-**コマンドコンテキスト**: スキルファイルの変更要求を理解し、精度最大化して実装するワークフロー
+**コマンドコンテキスト**: スキルファイルの変更要求を理解し、品質評価を伴う最適化で実装するワークフロー。
 
 変更要求: $ARGUMENTS
 
@@ -38,37 +38,38 @@ description: ユーザーのスキル変更要求を精度最大化して実装
 この設計で進めますか？ (y/n)
 ```
 
-**設計の9観点チェックリスト**:
-1. 最小記述で最大精度（コンテキスト効率）
-2. スキルファイル内・間の重複排除
-3. 関連内容は1ファイルに集約（読み込み回数最小化）
-4. 測定可能な判断基準（if-then形式）
-5. NG例は背景情報として推奨形式に変換
-6. 一貫した表記
-7. 暗黙前提を明示化
-8. 記述順序: 冒頭＝最重要、末尾＝例外
-9. スコープ境界: 扱う/扱わない範囲を明示
+**設計チェックリスト**: skill-optimizationスキルの9つの編集原則に照らして設計案を評価。重点項目：
+- コンテキスト効率: 追加する全文がLLMの判断に寄与するか
+- 測定可能性: 全基準がif-then形式または具体的閾値か
+- 重複排除: 他スキルファイルとの重複がないか
+- スコープ境界: 変更内容がこのスキルの責務範囲内か
 
-### Step 3: 3回見直しプロセス
+### Step 3: 品質レビュー
 
-1. **追記モード**: 曖昧表現→測定可能基準、暗黙前提→明示条件、エッジケース定義（最低5項目追記）
-2. **批判的修正モード**: 重複統合、過度な詳細を簡潔化、他スキルとの重複→参照に置換（修正前後の差分を記録）
-3. **復元判定モード**: 精度低下リスクがある削除→復元、妥当な削除→維持
+skill-reviewerエージェントをTask toolで起動:
+- 変更後のSKILL.md全文を渡す
+- レビューモード: `modification`
 
-最終確認：「ユーザーの変更要求を正確に実装するための必要十分条件が揃っているか？」
+**レビュー結果の処理:**
+- グレードAまたはB: Step 4へ進行
+- グレードC: reviewerの修正提案に基づき修正し再レビュー（最大2回）
+- 変更スコープ外の問題を検出: 別の改善機会としてユーザーに報告
 
 ### Step 4: 承認取得と実装
 
 1. 変更前後の比較をユーザーに提示し承認を取得
-2. 適切なツールで変更適用
-3. git diffで変更内容を最終確認
-4. `/sync-skills` 実行を提案
+2. skill-reviewerのグレードと残存する修正提案を提示
+3. 意図の整合性を確認: 「この変更は当初の要求を正しく反映していますか？」
+4. 適切なツールで変更適用
+5. git diffで変更内容を最終確認
+6. 変更スコープ外の問題があれば、任意の改善事項として提示
+7. `/sync-skills`実行を提案
 
 ## 完了条件
 
 - [ ] 対象スキルを特定し現状を把握した
-- [ ] 変更設計案を9観点でレビューした
-- [ ] 3回見直しプロセスを完了した
+- [ ] skill-optimizationの編集原則に照らして設計案をレビューした
+- [ ] skill-reviewerがグレードAまたはBを返却した
 - [ ] ユーザー承認を取得した
 - [ ] 変更を適用しgit diffで確認した
 - [ ] /sync-skills実行を提案した
@@ -78,7 +79,9 @@ description: ユーザーのスキル変更要求を精度最大化して実装
 | エラー | アクション |
 |--------|-----------|
 | スキル未発見 | 利用可能なスキル一覧を表示 |
-| 大規模変更検出（50%以上） | 段階的実施を提案 |
+| 大規模変更検出（ファイルの50%以上） | 段階的実施を提案 |
 | 他スキルとの責務重複 | 責務境界を確認しユーザーに判断を委ねる |
+| 2回のレビューでもグレードC | 変更内容と問題リストを提示し、ユーザーに判断を委ねる |
+| reviewerが退行を検出 | 退行原因の変更を取り消し、再レビュー |
 
-**スコープ**: ユーザーの変更要求理解と精度最大化実装。/sync-skills連携まで。
+**スコープ**: ユーザーの変更要求理解と品質評価付き最適化実装。品質評価はskill-reviewerエージェントに委譲。メタデータ同期は/sync-skills連携。

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

@@ -6,6 +6,15 @@ description: 既存コードベースからPRDとDesign Docを生成するリバ
 
 対象: $ARGUMENTS
 
+## オーケストレーター定義
+
+**コアアイデンティティ**: 「私は作業者ではない。オーケストレーターである。」（subagents-orchestration-guideスキル参照）
+
+**実行プロトコル**:
+1. **全作業をサブエージェントに委譲** — 役割はサブエージェントの呼び出し、データの受け渡し、結果の報告
+2. **ステップ間で構造化JSONを受け渡す** — `$STEP_N_OUTPUT`プレースホルダー記法を使用
+3. **コード読解はすべてサブエージェントが実施**
+
 **TodoWrite登録**: まずフェーズをTodoWriteに登録し、各フェーズ開始時に詳細ステップを追加登録する。
 
 ## ステップ0: 初期設定
@@ -39,8 +48,6 @@ AskUserQuestionで以下を確認:
   ※ fullstack=Yes: ユニットのスコープに応じてbackend + frontend Design Docを生成
 ```
 
-**コンテキスト伝達**: ステップ間で構造化JSON出力を受け渡す。`$STEP_N_OUTPUT`プレースホルダー記法を使用。
-
 ## フェーズ1: PRD生成
 
 **TodoWrite登録**:
@@ -70,7 +77,7 @@ prompt: |
 
 ### ステップ2-5: ユニット毎の処理
 
-**各ユニットについてステップ2→3→4→5を完了してから次のユニットへ進む。**
+**FOR** `$STEP_1_OUTPUT.discoveredUnits`の各ユニット **（逐次実行、1ユニットずつ）**:
 
 #### ステップ2: PRD生成
 
@@ -96,6 +103,8 @@ prompt: |
 
 #### ステップ3: コード検証
 
+**前提条件**: $STEP_2_OUTPUT（ステップ2のPRDパス）
+
 **Task呼び出し**:
 ```
 subagent_type: code-verifier
@@ -158,10 +167,13 @@ prompt: |
   ## レビューフィードバック
   $STEP_4_OUTPUT
 
-  ## 対処すべき不整合
-  （$STEP_3_OUTPUTからcriticalとmajorの不整合を抽出）
+  ## コード検証結果
+  $STEP_3_OUTPUT
 
-  修正と改善を適用する。
+  severity別に対処する:
+  - critical: 必須修正 — 中核的な振る舞いの誤りまたは欠落
+  - important: 推奨修正 — 正確性や完全性の向上
+  - recommended: 任意修正 — 文体や軽微な改善
 ```
 
 **ループ制御**: 最大2回の修正サイクル。2サイクル後はステータスに関わらず人間レビュー用にフラグ。
@@ -195,13 +207,15 @@ prompt: |
 
 ### ステップ7-10: ユニット毎の処理
 
-**各ユニットについてステップ7→8→9→10を完了してから次のユニットへ進む。**
+**FOR** `$STEP_6_OUTPUT.designDocTargets`の各ユニット **（逐次実行、1ユニットずつ）**:
 
 #### ステップ7: Design Doc生成
 
 `$STEP_6_OUTPUT`のマッピング結果に基づき、ユニット毎に必要なDesign Docを生成する。
 
-**Design Doc**（technical-designer）:
+fullstack=Yesの場合、7aの後に7bを逐次実行する（7bは7aの出力に依存）。
+
+**7a.** バックエンドDesign Doc（technical-designer）:
 
 fullstack=Yes時: promptに「対象: APIコントラクト、データ層、ビジネスロジック、サービスアーキテクチャ。」を追加する。
 
@@ -226,7 +240,7 @@ prompt: |
 
 **出力を保存**: `$STEP_7_OUTPUT`
 
-**フロントエンドDesign Doc**（fullstack、フロントエンドスコープを含むユニット）:
+**7b.** フロントエンドDesign Doc（fullstack、フロントエンドスコープを含むユニット）:
 
 ```
 subagent_type: technical-designer-frontend
@@ -299,7 +313,54 @@ prompt: |
 
 #### ステップ10: 修正（条件付き）
 
-ステップ5と同様のロジック。updateモードで対応するtechnical-designer / technical-designer-frontendを使用。
+**トリガー条件**（以下のいずれか）:
+- レビューステータスが「Needs Revision」または「Rejected」
+- `$STEP_8_OUTPUT`にクリティカルな不整合が存在
+- consistencyScore < 70
+
+**バックエンドDesign Doc修正**（technical-designer）:
+```
+subagent_type: technical-designer
+prompt: |
+  レビューフィードバックに基づきDesign Docを更新する。
+
+  動作モード: update
+  既存ドキュメント: $STEP_7_OUTPUT
+
+  ## レビューフィードバック
+  $STEP_9_OUTPUT
+
+  ## コード検証結果
+  $STEP_8_OUTPUT
+
+  severity別に対処する:
+  - critical: 必須修正 — 中核的な振る舞いの誤りまたは欠落
+  - important: 推奨修正 — 正確性や完全性の向上
+  - recommended: 任意修正 — 文体や軽微な改善
+```
+
+**フロントエンドDesign Doc修正**（fullstack、technical-designer-frontend）:
+```
+subagent_type: technical-designer-frontend
+prompt: |
+  レビューフィードバックに基づきフロントエンドDesign Docを更新する。
+
+  動作モード: update
+  既存ドキュメント: $STEP_7_FRONTEND_OUTPUT
+
+  ## レビューフィードバック
+  $STEP_9_OUTPUT
+
+  ## コード検証結果
+  $STEP_8_OUTPUT
+
+  severity別に対処する:
+  - critical: 必須修正 — 中核的な振る舞いの誤りまたは欠落
+  - important: 推奨修正 — 正確性や完全性の向上
+  - recommended: 任意修正 — 文体や軽微な改善
+```
+
+**ループ制御**: 最大2回の修正サイクル。2サイクル後はステータスに関わらず人間レビュー用にフラグ。
 
 #### ユニット完了