create-ai-project 1.20.7 → 1.20.9

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

@@ -1,17 +1,15 @@
 ---
 name: verifier
-description: 調査結果を批判的に評価しパスカバレッジを検証。Devil's Advocate手法で各障害点を独立評価し結論を導出。Use when 調査が完了した後、または「検証/妥当性確認/ダブルチェック/調査結果の確認」が言及された時。
+description: 調査結果を批判的に評価しパスカバレッジを検証。Devil's Advocate手法で各障害点を独立評価し結論を導出。使用するシーン: 調査が完了した後、または「検証/妥当性確認/ダブルチェック/調査結果の確認」が言及された時。
 tools: Read, Grep, Glob, LS, Bash, WebSearch, TaskCreate, TaskUpdate
 skills: project-context, technical-spec, coding-standards
 ---
 
 あなたは調査結果の検証を専門とするAIアシスタントです。
 
-CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、タスク完了まで独立した判断で実行します。
-
 ## 初回必須タスク
 
-**タスク登録**: TaskCreateで作業ステップを登録。必ず最初に「スキル制約の確認」、最後に「スキル忠実度の検証」を含める。各完了時にTaskUpdateで更新。
+**タスク登録**: TaskCreateで作業ステップを登録。必ず最初に「ロード済みスキルから具体ルールを抽出」、最後に「抽出ルールを最終JSON前に検証」を含める。各完了時にTaskUpdateで更新。
 
 **現在日時の確認**: 作業開始前に`date`コマンドで現在年月日を確認し、最新情報の判断基準とする。
 
@@ -59,13 +57,13 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 - 調査で参照されていない技術ドキュメント
 
 ### ステップ4: 調査カバレッジチェック
-investigatorのpathMapの完全性を検証する:
+入力の`pathMap`の完全性を検証する:
 
-1. **未トレースパス**: 症状が到達しうるのにinvestigatorがトレースしていないコードパスはないか（例: エラーハンドリング分岐、非同期フォーク、フォールバックパス）
+1. **未トレースパス**: 症状が到達しうるのに調査でトレースされていないコードパスはないか（例: エラーハンドリング分岐、非同期フォーク、フォールバックパス）
 2. **未チェックノード**: トレース済みパス上でチェックされていないノードはないか
 3. **追加の障害点**: 未トレースパスや未チェックノードから新たな障害が見つかった場合は記録する
 
-目的は、investigatorのパスカバレッジが十分であるかを検証すること。
+目的は、調査のパスカバレッジが十分であるかを検証すること。
 
 ### ステップ5: Devil's Advocate評価と批判的検証
 各障害点について批判的に評価：
@@ -95,10 +93,6 @@ investigatorのpathMapの完全性を検証する:
 
 **結論**: 各障害点を個別に評価する。複数の障害点が同時に有効でありうる — 単一の根本原因への収束を強制しない。確認された障害点のペアごとにその関係性（independent / dependent / same_chain）を判定し、`failurePointRelationships`に記録する
 
-### ステップ7: JSON結果の返却
-
-最終レスポンスとしてJSONを返却する。スキーマは出力フォーマットを参照。
-
 ## カバレッジ評価基準
 
 | カバレッジ | 条件 |
@@ -109,7 +103,9 @@ investigatorのpathMapの完全性を検証する:
 
 ## 出力フォーマット
 
-**JSONフォーマット必須**
+### 出力プロトコル
+
+最終メッセージ: 下記スキーマに一致する JSON オブジェクトを正確に1個（`{` で始まり `}` で終わる、コードフェンス禁止）。進捗テキストは最終メッセージより前のメッセージにのみ出現してよい。
 
 ```json
 {
@@ -134,7 +130,7 @@ investigatorのpathMapの完全性を検証する:
     }
   ],
   "coverageCheck": {
-    "missingPaths": ["investigatorがトレースしていないパス"],
+    "missingPaths": ["調査入力でトレースされていないパス"],
     "uncheckedNodes": ["トレース済みパス上の未チェックノード"],
     "additionalFailurePoints": [
       {
@@ -161,7 +157,7 @@ investigatorのpathMapの完全性を検証する:
     {
       "failurePointId": "FP1またはAFP1",
       "description": "障害点の記述",
-      "originalCheckStatus": "investigatorのcheckStatus（verifier発見のAFPはnull）",
+      "originalCheckStatus": "調査入力のcheckStatus（検証段階で発見されたAFPはnull）",
       "finalStatus": "supported|weakened|blocked|not_reached",
       "statusChangeReason": "ステータスが変更された理由（変更があった場合）",
       "remainingUncertainty": ["残る不確実性"]
@@ -210,9 +206,10 @@ investigatorのpathMapの完全性を検証する:
 - [ ] ユーザー報告との整合性を検証した
 - [ ] 各障害点を独立に評価した（単一の勝者を選んでいない）
 - [ ] 全体のカバレッジを評価した（sufficient/partial/insufficient）
-- [ ] 最終レスポンスがJSONであること
 
-## 出力セルフチェック
+## 自己検証 [BLOCKING — 出力前]
+
+最終 JSON 出力前に下記の各項目を実行する。未充足の項目があれば、該当 Step に戻り完了させてから JSON を出力すること。
 
 - [ ] 公式ドキュメントを含む全ての発見証拠がfinalStatusに反映されている
 - [ ] ユーザーの因果関係ヒントが評価に組み込まれている

package/.claude/agents-ja/work-planner.md

@@ -1,17 +1,15 @@
 ---
 name: work-planner
-description: Design Docから作業計画書を作成し実装タスクを構造化。Use when Design Doc完成後に実装計画が必要な時、または「作業計画/計画書/plan/スケジュール」が言及された時。進捗追跡可能な実行計画を立案。
+description: Design Docから作業計画書を作成し実装タスクを構造化。使用するシーン: Design Doc完成後に実装計画が必要な時、または「作業計画/計画書/plan/スケジュール」が言及された時。進捗追跡可能な実行計画を立案。
 tools: Read, Write, Edit, MultiEdit, Glob, LS, TaskCreate, TaskUpdate
 skills: documentation-criteria, project-context, technical-spec, implementation-approach, typescript-testing, typescript-rules
 ---
 
 あなたは作業計画書を作成する専門のAIアシスタントです。
 
-CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、タスク完了まで独立した判断で実行します。
-
 ## 初回必須タスク
 
-**タスク登録**: TaskCreateで作業ステップを登録。必ず最初に「スキル制約の確認」、最後に「スキル忠実度の検証」を含める。各完了時にTaskUpdateで更新。
+**タスク登録**: TaskCreateで作業ステップを登録。必ず最初に「ロード済みスキルから具体ルールを抽出」、最後に「抽出ルールを最終出力前に検証」を含める。各完了時にTaskUpdateで更新。
 
 ### 実装への反映
 - documentation-criteriaスキルでドキュメント作成基準を適用
@@ -55,11 +53,11 @@ IF E2Eテストスケルトンファイルが提供されていない
 THEN 作業計画書ヘッダーに追記:
   ⚠ E2E Gap: この機能にはユーザー向けマルチステップジャーニーが含まれますが、
   E2Eテストスケルトンが提供されていません。最終フェーズ前に
-  acceptance-test-generatorでE2Eテスト候補を評価することを検討してください。
+  受入テスト生成へ差し戻してE2Eテスト候補を評価する。
   検出されたジャーニー: [ジャーニーの説明とAC参照のリスト]
 ```
 
-`e2eAbsenceReason`が提供されている場合（acceptance-test-generatorのGeneration Reportで生成される。例: `no_multi_step_journey`, `below_threshold_user_confirmed`）、E2E不在は意図的 — このギャップチェックをスキップする。
+`e2eAbsenceReason`が提供されている場合（受入テストのGeneration Reportで生成される。例: `no_multi_step_journey`, `below_threshold_user_confirmed`）、E2E不在は意図的 — このギャップチェックをスキップする。
 
 このチェックは戦略AまたはBのどちらが選択されていても適用される。統合テストスケルトンのみの提供はE2Eカバレッジを意味しない。サービス内部ジャーニー（非同期パイプライン、サービス間saga）はここではフラグしない — 通常のROIパスでE2Eが必要な場合はそちらで対応。
 
@@ -84,25 +82,37 @@ THEN 作業計画書ヘッダーに追記:
 ### 6. 完了条件付きタスクの定義
 各タスクについて、Design Docの受入条件から完了条件を導出。3要素の完了定義（実装完了、品質完了、統合完了）を適用。
 
-### 7. 作業計画書の作成
-documentation-criteriaスキルの計画テンプレートに従って作業計画書を記述。フェーズ構成図とタスク依存関係図（mermaid）を含める。
+### 7. 出力の生成（scale 別のテンプレート選択）
+
+- **`scale: medium` / `scale: large`**: documentation-criteria スキルの **plan-template** に従って作業計画書を記述。フェーズ構成図とタスク依存関係図（mermaid）を含める。
+- **`scale: small`**: documentation-criteria スキルの **task-template** に従って単一タスクファイルを出力（後述「scale 別の出力モード」を参照）。フェーズ構成図・タスク依存関係図はスキップ。タスクファイルの `## Implementation Steps` セクションが実行を駆動する。
 
 ## Input Parameters
 
 - **mode**: `create`（デフォルト）| `update`
-- **designDoc**: Design Docのパス（クロスレイヤー機能の場合は複数）
+- **scale**: `small` | `medium` | `large`（requirement-analyzer の判定結果。下記「scale 別の出力モード」で出力形式を切り替える）
+- **designDoc**: Design Docのパス（クロスレイヤー機能の場合は複数）。`scale: small` では Design Doc が存在しない場合があり、その際は requirement-analyzer の出力と PRD 更新メモから直接タスクを導出する。
 - **uiSpec**（オプション）: UI Specificationのパス（フロントエンド/フルスタック機能）
 - **prd**（オプション）: PRDドキュメントのパス
 - **adr**（オプション）: ADRドキュメントのパス
 - **testSkeletons**（オプション）: 統合/E2Eテストスケルトンファイルパス（コメントベースのテスト意図記述。実装済みテストではない）
 - **updateContext**（updateモード時のみ）: 既存計画書のパス、変更理由
 
-## 作業計画書出力形式
+## scale 別の出力モード
+
+| scale | 出力 | 保存先 | 理由 |
+|---|---|---|---|
+| `small` | **task-template 形式**の単一タスクファイル（documentation-criteria スキル参照） | `docs/plans/tasks/{feature-name}-task-YYYYMMDD.md` | 1-2 ファイル規模ではタスク分解ステップを分けず、オーケストレーターが task-executor に `task_file` として渡すパスを本エージェントが直接生成する |
+| `medium` / `large` | **plan-template 形式**の作業計画書 | `docs/plans/{feature-name}-plan.md` | 個別タスクファイルへの分解は下流の task-decomposer が実施する |
+
+`small` モードではフェーズ構成（Step 4）と設計-計画トレーサビリティ表（Step 5）をスキップし、タスクファイルに `## Target Files`、`## Investigation Targets`、`## Investigation Notes`、`## Implementation Steps (TDD: Red-Green-Refactor)`、`## Quality Assurance Mechanisms`、`## Operation Verification Methods`、`## Completion Criteria` の各セクションと、`Metadata:` ブロック（`Dependencies:`、`Provides:`、`Size:`）を出力する。本スケールでは作業計画書ファイルを別途出力しない。
+
+## 作業計画書出力形式（medium / large のみ）
 
 - 保存場所と命名規則はdocumentation-criteriaスキルに従って作成
 - チェックボックスで進捗追跡可能な形式
 
-## 作業計画書の運用フロー
+## 作業計画書の運用フロー（medium / large のみ）
 
 1. **作成時期**: 中規模以上の変更開始時に作成
 2. **更新**: 各フェーズ完了時に進捗更新（チェックボックス）

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

@@ -67,7 +67,12 @@ For each Design Doc from Step 1:
 
 ### Step 3: Create Task Files [GATE]
 
-Create one task file per layer, using the monorepo-flow.md naming convention for deterministic agent routing:
+**Pre-check**: For each Step 2 invocation result, inspect `generatedFiles.integration`:
+- When `integration` is a path → proceed to task creation for that layer
+- When `integration` is `null` → skip task creation for that layer; record the layer and the generator's `e2eAbsenceReason` (when applicable) for the final report
+- When all layers return `integration: null` → skip Steps 4–7 entirely, report "No integration test skeletons generated for any layer" with each layer's reason, and exit
+
+Create one task file per layer that has a non-null `integration` path, using the monorepo-flow.md naming convention for deterministic agent routing:
 - Backend Design Doc → `docs/plans/tasks/integration-tests-backend-task-YYYYMMDD.md`
 - Frontend Design Doc → `docs/plans/tasks/integration-tests-frontend-task-YYYYMMDD.md`
 - Single-layer confirmed as backend → `docs/plans/tasks/integration-tests-backend-task-YYYYMMDD.md`
@@ -87,7 +92,13 @@ Implement test cases defined in skeleton files.
 ## Target Files
 
 - Skeleton: [layer-specific paths from Step 2 generatedFiles]
-- Design Doc: [layer-specific Design Doc from Step 1]
+
+## Investigation Targets
+
+- Design Doc: [layer-specific Design Doc from Step 1] — reference for AC mapping and contract definitions
+
+## Investigation Notes
+(Implementation observations are appended here before implementation begins.)
 
 ## Tasks
 
@@ -129,13 +140,13 @@ Invoke integration-test-reviewer using Agent tool:
 
 Check Step 5 result:
 - `status: approved` → Mark complete, proceed to Step 7
-- `status: needs_revision` → Invoke task-executor with requiredFixes, then return to Step 5
+- `status: needs_revision` → Re-invoke the routed task-executor in **Fix Mode** with the same `task_file` and `requiredFixes[]` (see prompt detail below), then return to Step 5
 
 Invoke task-executor routed by task filename pattern:
 - `*-backend-task-*` → `subagent_type`: "task-executor"
 - `*-frontend-task-*` → `subagent_type`: "task-executor-frontend"
 - `description`: "Fix review findings"
-- `prompt`: "Fix the following issues in test files: [requiredFixes from Step 5]"
+- `prompt`: "task_file: [the same task file path used in Step 4]. requiredFixes: [the requiredFixes array from Step 5]. Apply Fix Mode (the task's checkboxes are already `[x]` from Step 4)."
 
 ### Step 7: Quality Check
 
@@ -143,12 +154,12 @@ Invoke quality-fixer routed by task filename pattern:
 - `*-backend-task-*` → `subagent_type`: "quality-fixer"
 - `*-frontend-task-*` → `subagent_type`: "quality-fixer-frontend"
 - `description`: "Final quality assurance"
-- `prompt`: "Final quality assurance for test files added in this workflow. Run all tests and verify coverage."
+- `prompt`: "Final quality assurance for test files added in this workflow. Run all tests and verify coverage. task_file: [task file path]. filesModified: [extract from the most recent implementation step's response — Step 4 normally, or the union of Step 4 and Step 6 when a fix re-execution ran]."
 
 **Expected output**: `status` (approved/stub_detected/blocked)
 
 Check quality-fixer response:
-- `stub_detected` → Return to Step 4 with `incompleteImplementations[]` details, then re-execute Steps 4→5→6→7
+- `stub_detected` → Return to Step 4 and re-invoke task-executor in **Fix Mode** by passing the same `task_file` and the `incompleteImplementations[]` array, then re-execute Steps 4→5→6→7
 - `blocked` → Escalate to user
 - `approved` → Proceed to Step 8
 
@@ -156,3 +167,15 @@ Check quality-fixer response:
 
 On `approved` from quality-fixer:
 - Commit test files with appropriate message using Bash
+
+## Scope Boundary for Subagents
+
+Append the following block to every subagent prompt invoked from this recipe:
+
+```
+Scope boundary for subagents:
+Operate within the task scope and referenced files in the prompt.
+New files derived from the requested deliverable are in scope (e.g., test skeleton files specified by the recipe).
+Use loaded skills to execute that scope.
+Escalate when the required fix or investigation falls outside that scope.
+```

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

@@ -76,33 +76,34 @@ Invoke task-decomposer using Agent tool:
 **MANDATORY EXECUTION CYCLE**: `task-executor → escalation check → quality-fixer → commit`
 
 For EACH task, YOU MUST:
-1. **Register tasks using TaskCreate**: Register work steps. Always include: first "Confirm skill constraints", final "Verify skill fidelity"
+1. **Register tasks using TaskCreate**: Register work steps. Always include first task "Map preloaded skills to applicable concrete rules" and final task "Verify the mapped rules before final JSON"
 2. **INVOKE task-executor**: Execute the task implementation (cross-layer: see Layer-Aware Agent Routing in subagents-orchestration-guide)
 3. **CHECK task-executor response**:
    - `status: "escalation_needed"` or `"blocked"` → STOP and escalate to user
    - `requiresTestReview` is `true` → Execute **integration-test-reviewer**
-     - `needs_revision` → Return to step 2 with `requiredFixes`
+     - `needs_revision` → Return to step 2 and re-invoke task-executor in **Fix Mode** by passing the same `task_file` and the `requiredFixes[]` array as input
      - `approved` → Proceed to step 4
    - `readyForQualityCheck: true` → Proceed to step 4
-4. **INVOKE quality-fixer**: Execute all quality checks and fixes (cross-layer: see Layer-Aware Agent Routing). **Always pass** the current task file path as `task_file`
+4. **INVOKE quality-fixer**: Execute all quality checks and fixes (cross-layer: see Layer-Aware Agent Routing). **Always pass** the current task file path as `task_file` and the implementation step's `filesModified` array as `filesModified` (this scopes the stub-detection step to the task's actual write set; without it, quality-fixer falls back to `git diff HEAD`)
 5. **CHECK quality-fixer response**:
-   - `stub_detected` → Return to step 2 with `incompleteImplementations[]` details
+   - `stub_detected` → Return to step 2 and re-invoke task-executor in **Fix Mode** by passing the same `task_file` and the `incompleteImplementations[]` array as input
    - `blocked` → STOP and escalate to user
    - `approved` → Proceed to step 6
 6. **COMMIT on approval**: Execute git commit
 
 **CRITICAL**: Parse every sub-agent response for status fields. Execute the matching branch in the 4-step cycle. Proceed to next task only after quality-fixer returns `approved`.
 
-## Sub-agent Invocation Constraints
+## Scope Boundary for Subagents
+
+Append the following block to every subagent prompt invoked from this recipe:
 
-**MANDATORY suffix for ALL sub-agent prompts**:
 ```
-[SYSTEM CONSTRAINT]
-This agent operates within build skill scope. Use orchestrator-provided rules only.
+Scope boundary for subagents:
+Operate within the task scope and referenced files in the prompt.
+Use loaded skills to execute that scope.
+Escalate when the required fix or investigation falls outside that scope.
 ```
 
-Autonomous sub-agents require scope constraints for stable execution. ALWAYS append this constraint to every sub-agent prompt.
-
 After approval confirmation, start autonomous execution mode. STOP IMMEDIATELY upon detecting ANY requirement changes.
 
 ## Post-Implementation Verification (After All Tasks Complete)
@@ -116,9 +117,13 @@ After all task cycles finish, run verification agents **in parallel** before the
 2. **Consolidate results** — pass/fail criteria per subagents-orchestration-guide Post-Implementation Verification section. Present unified verification report to user.
 
 3. **Fix cycle** (when any verifier failed, max 2 cycles):
-   - Consolidate all actionable findings into a single task file
-   - Execute task-executor with consolidated fixes → quality-fixer
-   - Re-run only the failed verifiers
+   - Create a consolidated fix task file (e.g., `docs/plans/tasks/post-impl-fixes-YYYYMMDD.md`) using the task-template; populate Target Files with the union of file paths referenced by all verifiers' `requiredFixes[].location` / `discrepancies[].codeLocation` (parse as `file[:line]`, take only the file part) so the executor's File Scope Constraint admits all affected files regardless of which original task introduced them.
+   - **Normalize verifier outputs** into a unified `requiredFixes[]` before invoking task-executor:
+     - `security-reviewer.requiredFixes[]` (already `{location, issue, fix}`) → pass through as-is.
+     - `code-verifier.discrepancies[]` → convert each actionable discrepancy (status `drift` / `gap` / `conflict`) to `{location: discrepancy.codeLocation, issue: discrepancy.claim, fix: "[specific correction needed to restore Design Doc consistency, derived from discrepancy.classification and evidence]"}`.
+     - When a `discrepancy.codeLocation` is `null` (claim is unimplemented), set `location` to the planned target file path and add that file to the consolidated task's Target Files. If no target file can be determined, escalate to user instead of invoking Fix Mode.
+   - Invoke task-executor in **Fix Mode** with `task_file` set to the consolidated path and `requiredFixes` set to the normalized array.
+   - Then quality-fixer, then re-run only the failed verifiers.
    - If still failing after 2 cycles → Escalate to user with remaining findings
 
 4. **All passed** → Proceed to completion report

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

@@ -76,33 +76,34 @@ Invoke task-decomposer using Agent tool:
 **MANDATORY EXECUTION CYCLE**: `task-executor-frontend → escalation check → quality-fixer-frontend → commit`
 
 For EACH task, YOU MUST:
-1. **Register tasks using TaskCreate**: Register work steps. Always include: first "Confirm skill constraints", final "Verify skill fidelity"
+1. **Register tasks using TaskCreate**: Register work steps. Always include first task "Map preloaded skills to applicable concrete rules" and final task "Verify the mapped rules before final JSON"
 2. **Agent tool** (subagent_type: "task-executor-frontend") → Pass task file path in prompt, receive structured response
 3. **CHECK task-executor-frontend response**:
    - `status: "escalation_needed"` or `"blocked"` → STOP and escalate to user
    - `requiresTestReview` is `true` → Execute **integration-test-reviewer**
-     - `needs_revision` → Return to step 2 with `requiredFixes`
+     - `needs_revision` → Return to step 2 and re-invoke task-executor-frontend in **Fix Mode** by passing the same `task_file` and the `requiredFixes[]` array as input
      - `approved` → Proceed to step 4
    - `readyForQualityCheck: true` → Proceed to step 4
-4. **INVOKE quality-fixer-frontend**: Execute all quality checks and fixes. **Always pass** the current task file path as `task_file`
+4. **INVOKE quality-fixer-frontend**: Execute all quality checks and fixes. **Always pass** the current task file path as `task_file` and the implementation step's `filesModified` array as `filesModified` (this scopes the stub-detection step to the task's actual write set; without it, quality-fixer falls back to `git diff HEAD`)
 5. **CHECK quality-fixer-frontend response**:
-   - `stub_detected` → Return to step 2 with `incompleteImplementations[]` details
+   - `stub_detected` → Return to step 2 and re-invoke task-executor-frontend in **Fix Mode** by passing the same `task_file` and the `incompleteImplementations[]` array as input
    - `blocked` → STOP and escalate to user
    - `approved` → Proceed to step 6
 6. **COMMIT on approval**: Execute git commit
 
 **CRITICAL**: Parse every sub-agent response for status fields. Execute the matching branch in the 4-step cycle. Proceed to next task only after quality-fixer-frontend returns `approved`.
 
-## Sub-agent Invocation Constraints
+## Scope Boundary for Subagents
+
+Append the following block to every subagent prompt invoked from this recipe:
 
-**MANDATORY suffix for ALL sub-agent prompts**:
 ```
-[SYSTEM CONSTRAINT]
-This agent operates within build skill scope. Use orchestrator-provided rules only.
+Scope boundary for subagents:
+Operate within the task scope and referenced files in the prompt.
+Use loaded skills to execute that scope.
+Escalate when the required fix or investigation falls outside that scope.
 ```
 
-Autonomous sub-agents require scope constraints for stable execution. ALWAYS append this constraint to every sub-agent prompt.
-
 ! ls -la docs/plans/*.md | head -10
 
 VERIFY approval status before proceeding. Once confirmed, INITIATE autonomous execution mode. STOP IMMEDIATELY upon detecting ANY requirement changes.
@@ -118,9 +119,13 @@ After all task cycles finish, run verification agents **in parallel** before the
 2. **Consolidate results** — pass/fail criteria per subagents-orchestration-guide Post-Implementation Verification section. Present unified verification report to user.
 
 3. **Fix cycle** (when any verifier failed, max 2 cycles):
-   - Consolidate all actionable findings into a single task file
-   - Execute task-executor-frontend with consolidated fixes → quality-fixer-frontend
-   - Re-run only the failed verifiers
+   - Create a consolidated fix task file (e.g., `docs/plans/tasks/post-impl-fixes-YYYYMMDD.md`) using the task-template; populate Target Files with the union of file paths referenced by all verifiers' `requiredFixes[].location` / `discrepancies[].codeLocation` (parse as `file[:line]`, take only the file part) so the executor's File Scope Constraint admits all affected files regardless of which original task introduced them.
+   - **Normalize verifier outputs** into a unified `requiredFixes[]` before invoking task-executor-frontend:
+     - `security-reviewer.requiredFixes[]` (already `{location, issue, fix}`) → pass through as-is.
+     - `code-verifier.discrepancies[]` → convert each actionable discrepancy (status `drift` / `gap` / `conflict`) to `{location: discrepancy.codeLocation, issue: discrepancy.claim, fix: "[specific correction needed to restore Design Doc consistency, derived from discrepancy.classification and evidence]"}`.
+     - When a `discrepancy.codeLocation` is `null` (claim is unimplemented), set `location` to the planned target file path and add that file to the consolidated task's Target Files. If no target file can be determined, escalate to user instead of invoking Fix Mode.
+   - Invoke task-executor-frontend in **Fix Mode** with `task_file` set to the consolidated path and `requiredFixes` set to the normalized array.
+   - Then quality-fixer-frontend, then re-run only the failed verifiers.
    - If still failing after 2 cycles → Escalate to user with remaining findings
 
 4. **All passed** → Proceed to completion report

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

@@ -106,7 +106,7 @@ Invoke task-executor-frontend using Agent tool:
 Invoke quality-fixer-frontend using Agent tool:
 - `subagent_type`: "quality-fixer-frontend"
 - `description`: "Quality gate check"
-- `prompt`: "Confirm quality gate passage for fixed files."
+- `prompt`: "Confirm quality gate passage for fixed files. task_file: docs/plans/tasks/review-fixes-YYYYMMDD.md. filesModified: [extract from the prior implementation step's response]."
 
 ### Step 9: Re-validate code-reviewer
 
@@ -151,3 +151,14 @@ Remaining issues:
 - Committed secrets (blocked → human intervention)
 
 **Scope**: Design Doc compliance validation, security review, and auto-fixes.
+
+## Scope Boundary for Subagents
+
+Append the following block to every subagent prompt invoked from this recipe:
+
+```
+Scope boundary for subagents:
+Operate within the task scope and referenced files in the prompt.
+Use loaded skills to execute that scope.
+Escalate when the required fix or investigation falls outside that scope.
+```

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

@@ -39,7 +39,7 @@ When user responds to questions:
 
 ### 5. After Scale Determination: Register All Flow Steps with TaskCreate (Required)
 
-After scale determination, **register all steps of the applicable subagents-orchestration-guide skill flow with TaskCreate**. Always include: first "Confirm skill constraints", final "Verify skill fidelity". After registration, proceed through the flow referencing TaskList.
+After scale determination, **register all steps of the applicable subagents-orchestration-guide skill flow with TaskCreate**. Always include first task "Map preloaded skills to applicable concrete rules" and final task "Verify the mapped rules before final JSON". After registration, proceed through the flow referencing TaskList.
 
 ### 6. Execute Next Action
 
@@ -58,9 +58,18 @@ After scale determination, **register all steps of the applicable subagents-orch
 
 **Flow Adherence**: Follow "Autonomous Execution Task Management" in subagents-orchestration-guide skill, managing 4 steps with TaskCreate/TaskUpdate
 
-## 🚨 Sub-agent Invocation Constraints
+## Scope Boundary for Subagents
 
-Include the following at the end of prompts when invoking sub-agents, as rule-advisor invocation from sub-agents causes system crash:
+Append the following block to every subagent prompt invoked from this recipe:
+
+```
+Scope boundary for subagents:
+Operate within the task scope and referenced files in the prompt.
+Use loaded skills to execute that scope.
+Escalate when the required fix or investigation falls outside that scope.
+```
+
+Additionally, include the following constraint at the end of every sub-agent prompt, as rule-advisor invocation from sub-agents causes system crash:
 ```
 [Constraint] rule-advisor can only be used by Main AI
 ```
@@ -73,11 +82,11 @@ Following "Autonomous Execution Task Management" in subagents-orchestration-guid
 2. **CHECK task-executor response**:
    - `status: "escalation_needed"` or `"blocked"` → STOP and escalate to user
    - `requiresTestReview` is `true` → Execute **integration-test-reviewer**
-     - `needs_revision` → Return to step 1 with `requiredFixes`
+     - `needs_revision` → Return to step 1 and re-invoke task-executor in **Fix Mode** by passing the same `task_file` and the `requiredFixes[]` array as input
      - `approved` → Proceed to step 3
    - Otherwise → Proceed to step 3
-3. **INVOKE quality-fixer**: Execute all quality checks and fixes (cross-layer: see Layer-Aware Agent Routing). **Always pass** the current task file path as `task_file`
-   - `stub_detected` → Return to step 1 with `incompleteImplementations[]` details
+3. **INVOKE quality-fixer**: Execute all quality checks and fixes (cross-layer: see Layer-Aware Agent Routing). **Always pass** the current task file path as `task_file` and the implementation step's `filesModified` array as `filesModified` (this scopes the stub-detection step to the task's actual write set; without it, quality-fixer falls back to `git diff HEAD`)
+   - `stub_detected` → Return to step 1 and re-invoke task-executor in **Fix Mode** by passing the same `task_file` and the `incompleteImplementations[]` array as input
    - `blocked` → Escalate to user
    - `approved` → Proceed to step 4
 4. **COMMIT on approval**: Execute git commit
@@ -88,7 +97,7 @@ After all task cycles finish, invoke security-reviewer before the completion rep
 1. **Agent tool** (subagent_type: "security-reviewer") → Pass Design Doc path and implementation file list
 2. Check response:
    - `approved` or `approved_with_notes` → Proceed to completion report (include notes if present)
-   - `needs_revision` → Execute task-executor with `requiredFixes`, then quality-fixer, then re-invoke security-reviewer
+   - `needs_revision` → Create a consolidated fix task file (`docs/plans/tasks/security-fixes-YYYYMMDD.md`) using the task-template; populate Target Files with the union of file paths referenced by `requiredFixes[].location` (parsed as `file[:line]`, take only the file part) so the executor's File Scope Constraint admits all affected files regardless of which original task introduced them. Then invoke task-executor in **Fix Mode** with `task_file` set to the new consolidated path and `requiredFixes` set to the security-reviewer array, followed by quality-fixer, then re-invoke security-reviewer.
    - `blocked` → Escalate to user
 
 ### Test Information Communication

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

@@ -106,7 +106,7 @@ Invoke task-executor using Agent tool:
 Invoke quality-fixer using Agent tool:
 - `subagent_type`: "quality-fixer"
 - `description`: "Quality gate check"
-- `prompt`: "Confirm quality gate passage for fixed files."
+- `prompt`: "Confirm quality gate passage for fixed files. task_file: docs/plans/tasks/review-fixes-YYYYMMDD.md. filesModified: [extract from the prior implementation step's response]."
 
 ### 9. Re-validate code-reviewer
 
@@ -152,3 +152,14 @@ Remaining issues:
 - Committed secrets (blocked → human intervention)
 
 **Scope**: Design Doc compliance validation, security review, and auto-fixes.
+
+## Scope Boundary for Subagents
+
+Append the following block to every subagent prompt invoked from this recipe:
+
+```
+Scope boundary for subagents:
+Operate within the task scope and referenced files in the prompt.
+Use loaded skills to execute that scope.
+Escalate when the required fix or investigation falls outside that scope.
+```

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

@@ -67,7 +67,12 @@ ls docs/ui-spec/*.md 2>/dev/null
 
 ### ステップ3: タスクファイル作成 [GATE]
 
-レイヤーごとに1つのタスクファイルを作成。monorepo-flow.mdの命名規則に従い、エージェントルーティングを決定的にする:
+**事前確認**: ステップ2 の各呼び出し結果について `generatedFiles.integration` を検査する:
+- `integration` がパス → 該当レイヤーのタスク作成へ進む
+- `integration` が `null` → 該当レイヤーのタスク作成をスキップし、レイヤー名と生成エージェントの `e2eAbsenceReason`（該当時）を最終レポート用に記録
+- 全レイヤーが `integration: null` を返した → ステップ4〜7 を完全にスキップし、「どのレイヤーでも統合テストスケルトンは生成されなかった」と各レイヤーの理由を添えて報告して終了
+
+`integration` パスが非nullのレイヤーごとに1つのタスクファイルを作成。monorepo-flow.mdの命名規則に従い、エージェントルーティングを決定的にする:
 - バックエンドのDesign Doc → `docs/plans/tasks/integration-tests-backend-task-YYYYMMDD.md`
 - フロントエンドのDesign Doc → `docs/plans/tasks/integration-tests-frontend-task-YYYYMMDD.md`
 - 単一レイヤー（バックエンド確定） → `docs/plans/tasks/integration-tests-backend-task-YYYYMMDD.md`
@@ -80,22 +85,28 @@ name: [機能名]の[レイヤー]統合テスト実装
 type: test-implementation
 ---
 
-## 目的
+## Implementation Content
 
 スケルトンファイルに定義されたテストケースを実装する。
 
-## 対象ファイル
+## Target Files
 
 - スケルトン: [ステップ2のgeneratedFilesからレイヤー別パス]
-- Design Doc: [ステップ1のレイヤー別Design Doc]
 
-## タスク
+## Investigation Targets
+
+- Design Doc: [ステップ1のレイヤー別Design Doc] — AC マッピングと契約定義の参照用
+
+## Investigation Notes
+（実装観察事項を実装開始前にここへ追記する。）
+
+## Implementation Steps
 
 - [ ] スケルトンの各テストケースを実装
 - [ ] 全テストがパスすることを確認
 - [ ] カバレッジが要件を満たすことを確認
 
-## 受入条件
+## Completion Criteria
 
 - 全スケルトンテストケースが実装済み
 - 全テストがパス
@@ -129,13 +140,13 @@ Agentツールでintegration-test-reviewerを呼び出す:
 
 ステップ5の結果を確認:
 - `status: approved` → 完了としてマーク、ステップ7へ進む
-- `status: needs_revision` → requiredFixesでtask-executorを呼び出し、ステップ5に戻る
+- `status: needs_revision` → ルーティング先の task-executor を **Fix Mode** で再起動。同じ `task_file` と `requiredFixes[]` を渡す（プロンプト詳細は下記）。その後ステップ5に戻る
 
 タスクファイル名パターンでルーティングしてtask-executorを呼び出す:
 - `*-backend-task-*` → `subagent_type`: "task-executor"
 - `*-frontend-task-*` → `subagent_type`: "task-executor-frontend"
 - `description`: "レビュー指摘の修正"
-- `prompt`: "テストファイルの以下の問題を修正: [ステップ5のrequiredFixes]"
+- `prompt`: "task_file: [ステップ4で使用したのと同じタスクファイルパス]。requiredFixes: [ステップ5の requiredFixes 配列]。Fix Mode を適用（タスクのチェックボックスはステップ4で既に `[x]` になっている）。"
 
 ### ステップ7: 品質チェック
 
@@ -143,16 +154,28 @@ Agentツールでintegration-test-reviewerを呼び出す:
 - `*-backend-task-*` → `subagent_type`: "quality-fixer"
 - `*-frontend-task-*` → `subagent_type`: "quality-fixer-frontend"
 - `description`: "最終品質保証"
-- `prompt`: "このワークフローで追加されたテストファイルの最終品質保証。全テストを実行しカバレッジを確認。"
+- `prompt`: "このワークフローで追加されたテストファイルの最終品質保証。全テストを実行しカバレッジを確認。task_file: [タスクファイルパス]。filesModified: [直近の実装ステップのレスポンスから抽出 — 通常はステップ4、修正再実行が走った場合はステップ4とステップ6の和集合]。"
 
 **期待される出力**: `status` (approved/stub_detected/blocked)
 
-quality-fixerレスポンスチェック:
-- `stub_detected` → `incompleteImplementations[]`の詳細を添えてStep 4に戻し、Steps 4→5→6→7を再実行
+quality-fixer レスポンスをチェック:
+- `stub_detected` → ステップ4 に戻り、同じ `task_file` と `incompleteImplementations[]` 配列を入力として task-executor を **Fix Mode** で再起動し、ステップ4→5→6→7 を再実行
 - `blocked` → ユーザーにエスカレーション
-- `approved` → Step 8へ
+- `approved` → ステップ8 へ
 
 ### ステップ8: コミット
 
-quality-fixerから`approved`の場合:
-- Bashで適切なメッセージを付けてテストファイルをコミット
+quality-fixer から `approved` の場合:
+- Bash で適切なメッセージを付けてテストファイルをコミット
+
+## サブエージェントのスコープ境界
+
+本レシピから呼び出すサブエージェントプロンプトの末尾に以下のブロックを必ず付与する:
+
+```
+Scope boundary for subagents:
+Operate within the task scope and referenced files in the prompt.
+New files derived from the requested deliverable are in scope (e.g., test skeleton files specified by the recipe).
+Use loaded skills to execute that scope.
+Escalate when the required fix or investigation falls outside that scope.
+```