create-ai-project 1.16.1 → 1.16.2

package/.claude/agents-en/document-reviewer.md

@@ -92,6 +92,7 @@ For DesignDoc, additionally verify:
 - Technical information verification: When sources exist, verify with WebSearch for latest information and validate claim validity
 - Failure scenario review: Identify failure scenarios across normal usage, high load, and external failures; specify which design element becomes the bottleneck
 - Code inspection evidence review: Verify inspected files are relevant to design scope; flag if key related files are missing
+- **As-is implementation document review**: When code verification results are provided and the document describes existing implementation (not future requirements), verify that code-observable behaviors are stated as facts; speculative language about deterministic behavior → `important` issue
 
 **Perspective-specific Mode**:
 - Implement review based on specified mode and focus

package/.claude/agents-en/prd-creator.md

@@ -181,6 +181,7 @@ When external scope is NOT provided:
 - Investigate until code implementation is fully understood
 - Comprehensively confirm related files, tests, and configurations
 - Write specifications with confidence (minimize speculation and assumptions)
+- **Language Standard**: Code is the single source of truth. Describe observable behavior in definitive form. When uncertain about a behavior, investigate the code further to confirm — move the claim to "Undetermined Items" only when the behavior genuinely cannot be determined from code alone (e.g., business intent behind a design choice).
 
 ### Confidence Gating
 
@@ -196,6 +197,7 @@ Before documenting any claim, assess confidence level:
 - Never document Unverified claims as facts
 - Inferred claims require explicit rationale
 - Prioritize Verified claims in core requirements
+- Before classifying as Inferred, attempt to verify by reading the relevant code — classify as Inferred only after confirming the code is inaccessible or ambiguous
 
 ### Reverse PRD Process
 1. **Investigation Phase** (skip if External Scope Provided)

package/.claude/agents-ja/document-reviewer.md

@@ -92,6 +92,7 @@ DesignDocの場合、追加で以下を確認:
 - 技術情報検証：出典がある場合はWebSearchで最新情報を確認、主張の妥当性を検証
 - 失敗シナリオ検証：正常系・高負荷・外部障害の失敗シナリオを特定し、どの設計要素がボトルネックになるか指摘
 - コード調査エビデンス検証：調査ファイルが設計スコープに関連するか確認、主要な関連ファイルの漏れを指摘
+- **既存実装ドキュメント検証**: コード検証結果が提供され、ドキュメントが既存実装を記述している場合（将来の要件ではなく）、コードから観察可能な振る舞いが事実として記述されていることを検証する。確定的な振る舞いに対する推測的な表現 → `important`
 
 **観点特化モード**:
 - 指定されたmodeとfocusに基づいてレビューを実施

package/.claude/agents-ja/prd-creator.md

@@ -181,6 +181,7 @@ PRD作成時は**ユーザージャーニー図**と**スコープ境界図**を
 - コード実装を完全に理解するまで調査
 - 関連ファイル、テスト、設定を網羅的に確認
 - 自信を持って仕様を記述（推測や仮定を最小化）
+- **記述基準**: コードがsingle source of truth(SSoT)である。観察可能な振る舞いを断定形で記述する。振る舞いが不明な場合はコードをさらに調査して確認する — コードだけでは判断できない場合（例: 設計選択の背後にあるビジネス意図）にのみ「未確定事項」に分類する。
 
 ### 信頼度ゲーティング
 
@@ -196,6 +197,7 @@ PRD作成時は**ユーザージャーニー図**と**スコープ境界図**を
 - Unverifiedな主張を事実として文書化しない
 - Inferredな主張には明示的な根拠を記載
 - コア要件ではVerifiedな主張を優先
+- Inferredに分類する前に、関連コードを読んで検証を試みる — コードがアクセス不能または曖昧であることを確認した場合にのみInferredに分類する
 
 ### リバースPRDプロセス
 1. **調査フェーズ**（External Scope Provided時はスキップ）

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

@@ -2,7 +2,7 @@
 description: Execute decomposed tasks in autonomous execution mode
 ---
 
-Follow subagents-orchestration-guide skill strictly and act as the **orchestrator**.
+Follow subagents-orchestration-guide skill strictly and act as the **orchestrator** — your role is to invoke sub-agents, pass data between them, and report results.
 
 Work plan: $ARGUMENTS
 

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

@@ -9,7 +9,7 @@ description: Execute from requirement analysis to design document creation
 **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 investigate/analyze 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 design flow exactly**:
    - Execute: requirement-analyzer → technical-designer → document-reviewer → design-sync
    - **Stop at every `[Stop: ...]` marker** → Wait for user approval before proceeding

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/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/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/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サイクル後はステータスに関わらず人間レビュー用にフラグ。
 
 #### ユニット完了
 

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

@@ -34,6 +34,8 @@ Design Doc準拠率を検証:
 - コード品質チェック
 - 実装完全性の評価
 
+**出力を保存**: `$STEP_2_OUTPUT`
+
 ### 3. 判定と対応
 
 **判定基準（プロジェクト段階を考慮）**:
@@ -60,7 +62,7 @@ Design Doc準拠率を検証:
 1. **TodoWrite更新**: 作業ステップを登録。必ず含める: 最初に「スキル制約の確認」、最後に「スキル忠実度の検証」。タスクテンプレート（documentation-criteriaスキル参照）に従いタスクファイル作成 → `docs/plans/tasks/review-fixes-YYYYMMDD.md`
 2. **task-executor実行**: 自動修正を段階的実行（5ファイル超過で停止）
 3. **quality-fixer実行**: 品質ゲート通過を確認
-4. **再検証**: code-reviewerで改善度を測定
+4. **再検証**: 修正後のDesign Doc準拠率を再検証する。前回の準拠問題: $STEP_2_OUTPUT。各問題が解決されたことを確認する。
 
 ### 4. 最終レポート
 ```

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

@@ -11,7 +11,7 @@ description: 既存設計ドキュメント（Design Doc / PRD / ADR）をレビ
 **初期アクション**: 実行前にステップ1-6をTodoWriteに登録する。
 
 **実行プロトコル**:
-1. **全作業をサブエージェントに委譲**（自分でドキュメントを編集しない）
+1. **全作業をサブエージェントに委譲** — 役割はサブエージェントの呼び出し、データの受け渡し、結果の報告
 2. **更新フローを実行**:
    - 対象特定 → 変更内容確認 → ドキュメント更新 → レビュー → 整合性チェック
    - **`[停止: ...]`マーカーで必ず停止** → 次に進む前にユーザー承認を待つ
@@ -125,9 +125,29 @@ prompt: |
   - 変更履歴の完全性
 ```
 
+**出力を保存**: `$STEP_5_OUTPUT`
+
 **レビュー結果に基づく対応**:
 - 承認 → ステップ6へ進む
-- 要修正 → レビュアーフィードバックを持ってステップ4に戻る（最大2回）
+- 要修正 → 以下のプロンプトでステップ4に戻る:
+  ```
+  subagent_type: [ステップ2の更新エージェント]
+  description: "レビューフィードバックに基づき[タイプ]を修正"
+  prompt: |
+    動作モード: update
+    既存ドキュメント: [ステップ1のパス]
+
+    ## 前回のレビューフィードバック
+    $STEP_5_OUTPUT
+
+    severity別に対処する:
+    - critical: 必須修正
+    - important: 推奨修正
+    - recommended: 任意修正
+
+    修正を適用し変更履歴を更新する。
+  ```
+  （最大2回）
 - **2回のリジェクト後** → 人間レビュー用にフラグ、蓄積されたフィードバックをユーザーに提示して終了
 
 レビュー結果をユーザーに提示して承認を得る。

package/CHANGELOG.md

@@ -5,6 +5,35 @@ All notable changes to this project will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [1.16.2] - 2026-03-03
+
+### Changed
+
+#### Orchestrator Role Clarity (en/ja)
+- Replace prohibition-style delegation ("NEVER investigate yourself") with positive role definition across build, design, implement, plan, update-doc commands: "your role is to invoke sub-agents, pass data between them, and report results"
+
+#### reverse-engineer (en/ja) — Execution Accuracy
+- Add Orchestrator Definition section with structured JSON passing and code-reading delegation
+- Replace prose loop headers with explicit `FOR ... (sequential, one unit at a time)` notation (Steps 2-5, 7-10)
+- Add prerequisite annotation to Step 3 (dependency on Step 2 output)
+- Expand Step 5 revision prompt: replace vague "apply corrections" with severity-based handling (critical/important/recommended)
+- Expand Step 10 from single-line reference to full backend + frontend revision prompts with severity-based handling
+- Add `7a.`/`7b.` labels and sequential execution note for fullstack Design Doc generation
+- Remove redundant "Context Passing" line (moved to Orchestrator Definition)
+
+#### review (en/ja)
+- Add `$STEP_2_OUTPUT` storage for code-reviewer results
+- Replace vague re-validation ("measure improvement") with prior-issue-tracking re-validation using `$STEP_2_OUTPUT`
+
+#### update-doc (en/ja)
+- Add `$STEP_5_OUTPUT` storage for document-reviewer results
+- Expand revision loop: replace single-line description with full sub-agent prompt including severity-based handling and `$STEP_5_OUTPUT` reference
+
+#### Agents — Reverse Engineering Accuracy (en/ja)
+- document-reviewer: add as-is implementation document review rule — verify code-observable behaviors are stated as facts, flag speculative language on deterministic behavior
+- prd-creator: add Language Standard rule — code as SSoT, definitive form for observable behavior, "Undetermined Items" only for genuinely undeterminable claims
+- prd-creator: add Inferred verification rule — attempt code reading before classifying claims as Inferred
+
 ## [1.16.1] - 2026-02-23
 
 ### Added

package/package.json

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