create-ai-project 1.20.7 → 1.20.9

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

@@ -76,33 +76,34 @@ Agentツールでtask-decomposerを呼び出す:
 **必須実行サイクル**: `task-executor → エスカレーションチェック → quality-fixer → commit`
 
 各タスクで必須：
-1. **TaskCreateでタスク登録**: 作業ステップを登録。必ず含める: 最初に「スキル制約の確認」、最後に「スキル忠実度の検証」
-2. **task-executor実行**: タスク実装を実行（レイヤー横断時: subagents-orchestration-guideのレイヤー別エージェントルーティング参照）
-3. **task-executorレスポンスチェック**:
+1. **TaskCreateでタスク登録**: 作業ステップを登録。必ず含める: 最初に「ロード済みスキルから具体ルールを抽出」、最後に「抽出ルールを最終JSON前に検証」
+2. **task-executor を呼び出す**: タスク実装を実行（レイヤー横断 の場合は subagents-orchestration-guide の レイヤー別エージェントルーティング 参照）
+3. **task-executor レスポンスをチェック**:
    - `status: "escalation_needed"` または `"blocked"` → 停止してユーザーにエスカレーション
-   - `requiresTestReview` が `true` → **integration-test-reviewer**を実行
-     - `needs_revision` → `requiredFixes`を添えてステップ2に戻る
-     - `approved` → ステップ4へ
-   - `readyForQualityCheck: true` → ステップ4へ
-4. **quality-fixer実行**: 全品質チェックと修正を実行（レイヤー横断時: レイヤー別エージェントルーティング参照）。**必ず**現在のタスクファイルパスを`task_file`として渡す
-5. **quality-fixerレスポンスチェック**:
-   - `stub_detected` → `incompleteImplementations[]`の詳細を添えてステップ2に戻す
+   - `requiresTestReview` が `true` → **integration-test-reviewer** を実行
+     - `needs_revision` → ステップ2 に戻り、同じ `task_file` と `requiredFixes[]` 配列を入力として task-executor を **Fix Mode** で再起動
+     - `approved` → ステップ4 へ
+   - `readyForQualityCheck: true` → ステップ4 へ
+4. **quality-fixer を呼び出す**: 全品質チェックと修正を実行（レイヤー横断 の場合は レイヤー別エージェントルーティング 参照）。`task_file` として現在のタスクファイルパス、`filesModified` として実装ステップの `filesModified` 配列を **必ず渡す**（未完成実装検出を当該タスクの実書き込み集合にスコープする。省略時は quality-fixer が `git diff HEAD` にフォールバック）
+5. **quality-fixer レスポンスをチェック**:
+   - `stub_detected` → ステップ2 に戻り、同じ `task_file` と `incompleteImplementations[]` 配列を入力として task-executor を **Fix Mode** で再起動
    - `blocked` → 停止してユーザーにエスカレーション
-   - `approved` → ステップ6へ
-6. **承認後コミット**: git commitを実行
+   - `approved` → ステップ6 へ
+6. **承認後コミット**: git commit を実行
 
-**重要**: 例外なく全ての構造化レスポンスを監視し、全ての品質ゲートが通過することを確保。quality-fixerが`approved`を返すまで次のタスクに進まない。
+**重要**: 全サブエージェントレスポンスの status フィールドをパースし、4ステップサイクルの対応ブランチを実行。quality-fixer が `approved` を返すまで次のタスクに進まない。
 
-## サブエージェント呼び出し時の制約
+## サブエージェントのスコープ境界
+
+本レシピから呼び出すサブエージェントプロンプトの末尾に以下のブロックを必ず付与する:
 
-**全サブエージェントプロンプトの末尾に必須追加**:
 ```
-【システム制約】
-このエージェントはbuildスキルのスコープ内で動作します。オーケストレーターが提供したルールのみを使用してください。
+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.
 ```
 
-自律的なサブエージェントの安定実行にはスコープ制約が必要です。全てのサブエージェントプロンプトにこの制約を必ず付加してください。
-
 承認確認後、自律実行モードを開始。要件変更を検知した場合は即座に停止。
 
 ## 実装後検証（全タスク完了後）
@@ -115,11 +116,15 @@ Agentツールでtask-decomposerを呼び出す:
 
 2. **結果の統合** — 合格/不合格の基準はsubagents-orchestration-guideの実装後検証セクション参照。統合検証レポートをユーザーに提示。
 
-3. **修正サイクル**（いずれかの検証エージェントが不合格の場合、最大2回）:
-   - 全ての対応可能な検出事項を1つのタスクファイルに統合
-   - task-executorで統合修正を実行 → quality-fixer
-   - 不合格の検証エージェントのみ再実行
-   - 2回のサイクル後も不合格が残る場合 → 残存する検出事項とともにユーザーにエスカレーション
+3. **修正サイクル**（いずれかの verifier が fail のとき、最大2サイクル）:
+   - task-template を用いて、統合修正タスクファイル（例: `docs/plans/tasks/post-impl-fixes-YYYYMMDD.md`）を作成。Target Files には全 verifier の `requiredFixes[].location` / `discrepancies[].codeLocation` が指すファイルパスの和集合を `file[:line]` として解釈してファイル部分のみ取り出して投入する。これにより、元タスクに依らず影響ファイルすべてが executor の File Scope Constraint に許可される。
+   - task-executor を起動する前に、**verifier 出力を正規化**して統一的な `requiredFixes[]` にする:
+     - `security-reviewer.requiredFixes[]`（既に `{location, issue, fix}` 形式）→ そのまま透過。
+     - `code-verifier.discrepancies[]` → 対応可能な各 discrepancy（status が `drift` / `gap` / `conflict`）を `{location: discrepancy.codeLocation, issue: discrepancy.claim, fix: "[Design Doc 整合性回復に必要な具体的修正。discrepancy.classification と evidence から導出]"}` に変換。
+     - `discrepancy.codeLocation` が `null`（主張が未実装）の場合は、`location` に予定された対象ファイルパスを設定し、そのファイルを統合タスクの Target Files にも追加する。対象ファイルが特定できない場合は、Fix Mode を起動する代わりにユーザーにエスカレーション。
+   - `task_file` には統合修正タスクファイルのパス、`requiredFixes` に正規化配列を設定して task-executor を **Fix Mode** で起動。
+   - 続いて quality-fixer、その後 fail した verifier のみ再実行。
+   - 2サイクル後も fail が残る場合 → 残存指摘事項を添えてユーザーにエスカレーション
 
 4. **全て合格** → 完了レポートへ
 

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

@@ -76,33 +76,34 @@ Agentツールでtask-decomposerを呼び出す:
 **必須実行サイクル**: `task-executor-frontend → エスカレーションチェック → quality-fixer-frontend → commit`
 
 各タスクで必須：
-1. **TaskCreateでタスク登録**: 作業ステップを登録。必ず含める: 最初に「スキル制約の確認」、最後に「スキル忠実度の検証」
-2. **Agent tool** (subagent_type: "task-executor-frontend") → タスクファイルパスをpromptに渡し、構造化レスポンスを受け取る
-3. **task-executor-frontendレスポンスチェック**:
+1. **TaskCreateでタスク登録**: 作業ステップを登録。必ず含める: 最初に「ロード済みスキルから具体ルールを抽出」、最後に「抽出ルールを最終JSON前に検証」
+2. **Agent tool** (subagent_type: "task-executor-frontend") → タスクファイルパスを prompt に渡し、構造化レスポンスを受け取る
+3. **task-executor-frontend レスポンスをチェック**:
    - `status: "escalation_needed"` または `"blocked"` → 停止してユーザーにエスカレーション
-   - `requiresTestReview` が `true` → **integration-test-reviewer**を実行
-     - `needs_revision` → `requiredFixes`を添えてステップ2に戻る
-     - `approved` → ステップ4へ
-   - `readyForQualityCheck: true` → ステップ4へ
-4. **quality-fixer-frontend実行**: 全品質チェックと修正を実行（レイヤー横断時: レイヤー別エージェントルーティング参照）。**必ず**現在のタスクファイルパスを`task_file`として渡す
-5. **quality-fixer-frontendレスポンスチェック**:
-   - `stub_detected` → `incompleteImplementations[]`の詳細を添えてステップ2に戻す
+   - `requiresTestReview` が `true` → **integration-test-reviewer** を実行
+     - `needs_revision` → ステップ2 に戻り、同じ `task_file` と `requiredFixes[]` 配列を入力として task-executor-frontend を **Fix Mode** で再起動
+     - `approved` → ステップ4 へ
+   - `readyForQualityCheck: true` → ステップ4 へ
+4. **quality-fixer-frontend を呼び出す**: 全品質チェックと修正を実行。`task_file` として現在のタスクファイルパス、`filesModified` として実装ステップの `filesModified` 配列を **必ず渡す**（未完成実装検出を当該タスクの実書き込み集合にスコープする。省略時は quality-fixer が `git diff HEAD` にフォールバック）
+5. **quality-fixer-frontend レスポンスをチェック**:
+   - `stub_detected` → ステップ2 に戻り、同じ `task_file` と `incompleteImplementations[]` 配列を入力として task-executor-frontend を **Fix Mode** で再起動
    - `blocked` → 停止してユーザーにエスカレーション
-   - `approved` → ステップ6へ
-6. **承認後コミット**: git commitを実行
+   - `approved` → ステップ6 へ
+6. **承認後コミット**: git commit を実行
 
-**重要**: 全てのサブエージェントレスポンスのstatusフィールドをパースし、4ステップサイクルの対応ブランチを実行。quality-fixer-frontendが`approved`を返すまで次のタスクに進まない。
+**重要**: 全サブエージェントレスポンスの status フィールドをパースし、4ステップサイクルの対応ブランチを実行。quality-fixer-frontend が `approved` を返すまで次のタスクに進まない。
 
-## サブエージェント呼び出し時の制約
+## サブエージェントのスコープ境界
+
+本レシピから呼び出すサブエージェントプロンプトの末尾に以下のブロックを必ず付与する:
 
-**全サブエージェントプロンプトの末尾に必須追加**:
 ```
-【システム制約】
-このエージェントはbuildスキルのスコープ内で動作します。オーケストレーターが提供したルールのみを使用してください。
+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.
 ```
 
-自律的なサブエージェントの安定実行にはスコープ制約が必要です。全てのサブエージェントプロンプトにこの制約を必ず付加してください。
-
 ! ls -la docs/plans/*.md | head -10
 
 承認ステータスを確認してから進む。確認後、自律実行モードを開始。要件変更を検出したら即座に停止。
@@ -117,11 +118,15 @@ Agentツールでtask-decomposerを呼び出す:
 
 2. **結果の統合** — 合格/不合格の基準はsubagents-orchestration-guideの実装後検証セクション参照。統合検証レポートをユーザーに提示。
 
-3. **修正サイクル**（いずれかの検証エージェントが不合格の場合、最大2回）:
-   - 全ての対応可能な検出事項を1つのタスクファイルに統合
-   - task-executor-frontendで統合修正を実行 → quality-fixer-frontend
-   - 不合格の検証エージェントのみ再実行
-   - 2回のサイクル後も不合格が残る場合 → 残存する検出事項とともにユーザーにエスカレーション
+3. **修正サイクル**（いずれかの verifier が fail のとき、最大2サイクル）:
+   - task-template を用いて、統合修正タスクファイル（例: `docs/plans/tasks/post-impl-fixes-YYYYMMDD.md`）を作成。Target Files には全 verifier の `requiredFixes[].location` / `discrepancies[].codeLocation` が指すファイルパスの和集合を `file[:line]` として解釈してファイル部分のみ取り出して投入する。これにより、元タスクに依らず影響ファイルすべてが executor の File Scope Constraint に許可される。
+   - task-executor-frontend を起動する前に、**verifier 出力を正規化**して統一的な `requiredFixes[]` にする:
+     - `security-reviewer.requiredFixes[]`（既に `{location, issue, fix}` 形式）→ そのまま透過。
+     - `code-verifier.discrepancies[]` → 対応可能な各 discrepancy（status が `drift` / `gap` / `conflict`）を `{location: discrepancy.codeLocation, issue: discrepancy.claim, fix: "[Design Doc 整合性回復に必要な具体的修正。discrepancy.classification と evidence から導出]"}` に変換。
+     - `discrepancy.codeLocation` が `null`（主張が未実装）の場合は、`location` に予定された対象ファイルパスを設定し、そのファイルを統合タスクの Target Files にも追加する。対象ファイルが特定できない場合は、Fix Mode を起動する代わりにユーザーにエスカレーション。
+   - `task_file` には統合修正タスクファイルのパス、`requiredFixes` に正規化配列を設定して task-executor-frontend を **Fix Mode** で起動。
+   - 続いて quality-fixer-frontend、その後 fail した verifier のみ再実行。
+   - 2サイクル後も fail が残る場合 → 残存指摘事項を添えてユーザーにエスカレーション
 
 4. **全て合格** → 完了レポートへ
 

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

@@ -106,7 +106,7 @@ Agent toolでtask-executor-frontendを呼び出す:
 Agent toolでquality-fixer-frontendを呼び出す:
 - `subagent_type`: "quality-fixer-frontend"
 - `description`: "品質ゲートチェック"
-- `prompt`: "修正ファイルの品質ゲート通過を確認。"
+- `prompt`: "修正ファイルの品質ゲート通過を確認。task_file: docs/plans/tasks/review-fixes-YYYYMMDD.md。filesModified: [直前の実装ステップのレスポンスから抽出]。"
 
 ### Step 9: code-reviewer再検証
 
@@ -151,3 +151,14 @@ Security Review:
 - コミット済みシークレット（blocked → 人間の判断が必要）
 
 **スコープ**: Design Doc準拠検証、セキュリティレビュー、自動修正。
+
+## サブエージェントのスコープ境界
+
+本レシピから呼び出すサブエージェントプロンプトの末尾に以下のブロックを必ず付与する:
+
+```
+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/implement.md

@@ -39,7 +39,7 @@ requirement-analyzerの`crossLayerScope`がレイヤー横断（backend + fronte
 
 ### 5. 規模判定後：TaskCreateでフロー全ステップを登録（必須）
 
-規模判定完了後、**subagents-orchestration-guideスキルの該当フロー全ステップをTaskCreateで登録**。最初に「スキル制約の確認」、最後に「スキル忠実度の検証」を必ず含める。登録後、TaskListを参照してフローを進める。
+規模判定完了後、**subagents-orchestration-guideスキルの該当フロー全ステップをTaskCreateで登録**。最初に「ロード済みスキルから具体ルールを抽出」、最後に「抽出ルールを最終JSON前に検証」を必ず含める。登録後、TaskListを参照してフローを進める。
 
 ### 6. 次のアクション実行
 
@@ -58,29 +58,38 @@ requirement-analyzerの`crossLayerScope`がレイヤー横断（backend + fronte
 
 **フロー厳守**: subagents-orchestration-guideスキルの「自律実行中のタスク管理」に従い、TaskCreate/TaskUpdateで4ステップを管理する
 
-## 🚨 サブエージェント呼び出し時の制約
+## サブエージェントのスコープ境界
 
-サブエージェントからrule-advisorを呼び出すとシステムクラッシュが発生するため、プロンプト末尾に以下を含める：
+本レシピから呼び出すサブエージェントプロンプトの末尾に以下のブロックを必ず付与する:
+
+```
+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.
+```
+
+加えて、サブエージェントから rule-advisor を呼び出すとシステムクラッシュを引き起こすため、全サブエージェントプロンプトの末尾に以下の制約も含める:
 ```
-【制約】rule-advisorはメインAIのみが使用可能です
+[Constraint] rule-advisor can only be used by Main AI
 ```
 
 ## 🎯 オーケストレーターとしての必須責務
 
 ### タスク実行品質サイクル
 subagents-orchestration-guideスキルの「自律実行中のタスク管理」に従い、TaskCreate/TaskUpdateで以下のステップを管理：
-1. **task-executor実行**: 実装を実行（レイヤー横断時: レイヤー別エージェントルーティング参照）
-2. **task-executorレスポンスチェック**:
+1. **task-executor を呼び出す**: 実装を実行（レイヤー横断 の場合は レイヤー別エージェントルーティング 参照）
+2. **task-executor レスポンスをチェック**:
    - `status: "escalation_needed"` または `"blocked"` → 停止してユーザーにエスカレーション
-   - `requiresTestReview` が `true` → **integration-test-reviewer**を実行
-     - `needs_revision` → `requiredFixes`を添えてステップ1に戻る
-     - `approved` → ステップ3へ
-   - それ以外 → ステップ3へ
-3. **quality-fixer実行**: 全品質チェックと修正を実行（レイヤー横断時: レイヤー別エージェントルーティング参照）。**必ず**現在のタスクファイルパスを`task_file`として渡す
-   - `stub_detected` → `incompleteImplementations[]`の詳細を添えてステップ1に戻す
+   - `requiresTestReview` が `true` → **integration-test-reviewer** を実行
+     - `needs_revision` → ステップ1 に戻り、同じ `task_file` と `requiredFixes[]` 配列を入力として task-executor を **Fix Mode** で再起動
+     - `approved` → ステップ3 へ
+   - それ以外 → ステップ3 へ
+3. **quality-fixer を呼び出す**: 全品質チェックと修正を実行（レイヤー横断 の場合は レイヤー別エージェントルーティング 参照）。`task_file` として現在のタスクファイルパス、`filesModified` として実装ステップの `filesModified` 配列を **必ず渡す**（未完成実装検出を当該タスクの実書き込み集合にスコープする。省略時は quality-fixer が `git diff HEAD` にフォールバック）
+   - `stub_detected` → ステップ1 に戻り、同じ `task_file` と `incompleteImplementations[]` 配列を入力として task-executor を **Fix Mode** で再起動
    - `blocked` → ユーザーにエスカレーション
-   - `approved` → ステップ4へ
-4. **承認後コミット**: `approved`確認後 → git commitを実行
+   - `approved` → ステップ4 へ
+4. **承認後コミット**: `approved` 確認後 → git commit を実行
 
 ### Security Review（全タスク完了後）
 
@@ -88,7 +97,7 @@ subagents-orchestration-guideスキルの「自律実行中のタスク管理」
 1. **Agent tool** (subagent_type: "security-reviewer") → Design Docパスと実装ファイルリストを渡す
 2. レスポンスを確認:
    - `approved` または `approved_with_notes` → 完了レポートへ（notesがあれば含める）
-   - `needs_revision` → task-executorで`requiredFixes`を実行、quality-fixer実行後、security-reviewerを再実行
+   - `needs_revision` → task-template を用いて、統合修正タスクファイル（`docs/plans/tasks/security-fixes-YYYYMMDD.md`）を作成。Target Files には `requiredFixes[].location` を `file[:line]` として解釈してファイル部分のみ取り出した和集合を投入する（元タスクに依らず影響ファイルすべてが executor の File Scope Constraint に許可される）。続いて、`task_file` には新しい統合修正タスクファイルのパス、`requiredFixes` には `security-reviewer.requiredFixes[]` を設定して task-executor を **Fix Mode** で起動。その後 quality-fixer を実行し、最後に security-reviewer を再起動する。
    - `blocked` → ユーザーにエスカレーション
 
 ### テスト情報の伝達

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

@@ -106,7 +106,7 @@ Agent toolでtask-executorを呼び出す:
 Agent toolでquality-fixerを呼び出す:
 - `subagent_type`: "quality-fixer"
 - `description`: "品質ゲートチェック"
-- `prompt`: "修正ファイルの品質ゲート通過を確認。"
+- `prompt`: "修正ファイルの品質ゲート通過を確認。task_file: docs/plans/tasks/review-fixes-YYYYMMDD.md。filesModified: [直前の実装ステップのレスポンスから抽出]。"
 
 ### 9. code-reviewer再検証
 
@@ -152,3 +152,14 @@ Security Review:
 - コミット済みシークレット（blocked → 人間の判断が必要）
 
 **スコープ**: Design Doc準拠検証、セキュリティレビュー、自動修正まで。
+
+## サブエージェントのスコープ境界
+
+本レシピから呼び出すサブエージェントプロンプトの末尾に以下のブロックを必ず付与する:
+
+```
+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/skills-en/documentation-criteria/SKILL.md

@@ -14,7 +14,7 @@ description: Guides PRD, ADR, Design Doc, UI Spec, and Work Plan creation. Use w
 | ADR Conditions Met (see below) | ADR -> Design Doc -> Work Plan | Start immediately |
 | 6+ Files | ADR -> Design Doc -> Work Plan (Required) | Start immediately |
 | 3-5 Files | Design Doc -> Work Plan (Recommended) | Start immediately |
-| 1-2 Files | None | Direct implementation |
+| 1-2 Files | None | Implementation cycle without work plan |
 
 ## ADR Creation Conditions (Required if Any Apply)
 
@@ -87,7 +87,7 @@ description: Guides PRD, ADR, Design Doc, UI Spec, and Work Plan creation. Use w
 - Visual acceptance criteria (golden states, layout constraints)
 - Accessibility requirements (keyboard, screen reader, contrast)
 
-**Scope**: Screen structure, transitions, component decomposition, interaction design, and visual acceptance criteria only. Technical implementation and API contracts belong in Design Doc, test implementation in acceptance-test-generator skeletons, schedule in Work Plan.
+**Scope**: Screen structure, transitions, component decomposition, interaction design, and visual acceptance criteria only. Technical implementation and API contracts belong in Design Doc, test implementation in test skeleton generation output, schedule in Work Plan.
 
 **Required Structural Elements**:
 - At least one component with state x display matrix and interaction table

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

@@ -110,6 +110,20 @@ Each AC is written in EARS format. Keywords determine test type.
 ### Code Inspection Evidence
 - [path:function] — [relevance: similar functionality / integration point / pattern reference]
 
+### Fact Disposition Table
+
+One row per codebase analysis `focusAreas` entry. This table is the primary binding between structural existing-behavior facts and the design (Verification Strategy's Output Comparison binds runtime behavior separately). Other sections that describe existing behavior reference the row by `fact_id` value.
+
+| Fact ID | Focus Area | Disposition | Rationale | Evidence | Related Files |
+|---------|------------|-------------|-----------|----------|---------------|
+| [fact_id from focusAreas] | [area name from focusAreas] | preserve / transform / remove / out-of-scope | [preserve: confirmation-only language, e.g., "existing behavior retained without modification" — Rationale asserting a behavior change is flagged as preserve mismatch; transform: state new observable outcome, e.g., "branch X now returns 404 instead of 410" — Rationale asserting no change at all is flagged as transform mismatch; remove: state reason with PRD/UI Spec citation when policy-driven — Rationale asserting production-code retention is flagged as remove mismatch (test/migration retention stated explicitly is acceptable); out-of-scope: cite the scope-defining section and prefer preserve when behavior continues unchanged] | [evidence value carried verbatim from focusAreas] | [comma-separated path list carried verbatim from focusAreas.relatedFiles, e.g., `src/auth/createUser.ts, src/api/routes/users.ts`] |
+
+### Cross-Layer Assumptions (cross-layer flow only)
+
+When this Design Doc depends on unverified claims from a prior-layer Design Doc (see Prior-Layer Verification), list each with justification and downstream verification target:
+
+- [claim]: [justification]; verify at [step or artifact]
+
 ## Design
 
 ### Change Impact Map
@@ -299,7 +313,7 @@ Mark as N/A with brief rationale when the feature has no data layer dependencies
 
 ## Verification Strategy
 
-Verification Strategy defines what correctness means and how to prove it at design time. L1/L2/L3 (from implementation-approach skill) define completion verification granularity at task execution time.
+Verification Strategy defines what correctness means and how to prove it at design time. L1/L2/L3 (verification granularity tiers) define completion verification granularity at task execution time.
 
 ### Correctness Proof Method
 

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

@@ -69,7 +69,7 @@ Maps each Design Doc technical requirement to the covering task(s). One row per
 
 Select ONE phase structure based on implementation approach from Design Doc.
 See documentation-criteria skill for detailed Phase Division Criteria.
-All quality checks follow Quality Check Workflow from coding-standards skill.
+All quality checks follow the project's standard Quality Check Workflow.
 **Delete the unused Option entirely from the final plan.** For hybrid approach, use Option C.
 
 ### Option A: Vertical Slice Phase Structure

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

@@ -15,7 +15,10 @@ Metadata:
 
 ## Investigation Targets
 Files to read before starting implementation (file path, with optional search hint):
-- [e.g., src/orders/checkout (processOrder function) — determined by task-decomposer based on task nature]
+- [e.g., src/orders/checkout (processOrder function) — determined during task decomposition based on task nature]
+
+## Investigation Notes
+(Implementation observations are appended here before implementation begins.)
 
 ## Implementation Steps (TDD: Red-Green-Refactor)
 ### 1. Red Phase

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

@@ -5,7 +5,7 @@
 [Purpose and scope of this UI Specification in 2-3 sentences]
 
 ### Target PRD
-- PRD path: [docs/prd/xxx-prd.md | "N/A — based on requirement-analyzer output"]
+- PRD path: [docs/prd/xxx-prd.md | "N/A — based on requirements analysis output"]
 - Feature scope: [Which PRD requirements this UI Spec covers | Summary of analyzed requirements]
 
 ### Design Source

package/.claude/skills-en/frontend-typescript-rules/SKILL.md

@@ -7,7 +7,7 @@ description: Applies React/TypeScript type safety, component design, and state m
 
 ## Frontend-Specific Anti-patterns
 
-In addition to universal anti-patterns in coding-standards skill, watch for these Frontend-specific issues:
+In addition to universal anti-patterns, watch for these Frontend-specific issues:
 
 - **Prop drilling through 3+ levels** - Should use Context API or state management
 - **Massive components (300+ lines)** - Split into smaller components

package/.claude/skills-en/skill-optimization/SKILL.md

@@ -136,7 +136,7 @@ Measurable quality criteria for skill content. Each principle includes a pass/fa
 | # | Principle | Pass Criteria | Fail Example |
 |---|-----------|---------------|--------------|
 | 1 | Context efficiency | Every sentence contributes to LLM decision-making. No filler. | "This is an important skill that helps with..." |
-| 2 | Deduplication | No concept explained twice at the same abstraction level within the skill or across skills. Mentions at different structural roles (e.g., classification framework vs execution detail) are not duplicates, provided the re-mention adds new constraints or criteria | Same error handling rules in both coding-standards and typescript-rules |
+| 2 | Deduplication | No concept explained twice at the same abstraction level within the skill or across skills. Mentions at different structural roles (e.g., classification framework vs execution detail) are not duplicates, provided the re-mention adds new constraints or criteria | Same error handling rules restated at the same abstraction level in multiple related skills |
 | 3 | Grouping | Related criteria in single section (minimize read operations) | Scattered error handling rules across 4 sections |
 | 4 | Measurability | All criteria use if-then format or concrete thresholds | "Write clean code" without definition of clean |
 | 5 | Positive form | Instructions state what to do (BP-001 applied) | "Don't use any" instead of "Use only X" |

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

@@ -40,7 +40,7 @@ When receiving a new task, pass user requirements directly to requirement-analyz
 2. **task-decomposer**: Appropriate task decomposition of work plans
 3. **task-executor**: Individual task execution and structured response
 4. **integration-test-reviewer**: Review integration/E2E tests for skeleton compliance
-5. **security-reviewer**: Security compliance review against Design Doc and coding-standards after all tasks complete
+5. **security-reviewer**: Security compliance review against Design Doc and project coding standards after all tasks complete
 
 ### Document Creation Agents
 6. **requirement-analyzer**: Requirement analysis and work scale determination (WebSearch enabled, latest technical information research)
@@ -116,7 +116,7 @@ I repeat this cycle for each task to ensure quality.
 
 | Scale | File Count | PRD | ADR | Design Doc | Work Plan |
 |-------|------------|-----|-----|------------|-----------|
-| Small | 1-2 | Update[^1] | Not needed | Not needed | Simplified (inline comments only) |
+| Small | 1-2 | Update[^1] | Not needed | Not needed | Single task file in task-template format under `docs/plans/tasks/` (no separate plan document) |
 | Medium | 3-5 | Update[^1] | Conditional[^2] | **Required** | **Required** |
 | Large | 6+ | **Required**[^3] | Conditional[^2] | **Required** | **Required** |
 
@@ -133,12 +133,12 @@ Subagents respond in JSON format. Key fields for orchestrator decisions:
 | requirement-analyzer | scale, confidence, adrRequired, crossLayerScope, scopeDependencies, questions | Select flow by scale; check adrRequired for ADR step |
 | codebase-analyzer | analysisScope.categoriesDetected, dataModel.detected, qualityAssurance (mechanisms[], domainConstraints[]), focusAreas[], existingElements count, limitations | Pass focusAreas to technical-designer as context |
 | code-verifier | status (consistent/mostly_consistent/needs_review/inconsistent), consistencyScore, discrepancies[], reverseCoverage (dataOperationsInCode, testBoundariesSectionPresent). Pre-implementation: verifies Design Doc claims against existing codebase. Post-implementation: verifies implementation consistency against Design Doc (pass `code_paths` scoped to changed files) | Flag discrepancies for document-reviewer |
-| task-executor | status (escalation_needed/completed), escalation_type (design_compliance_violation/similar_function_found/similar_component_found/investigation_target_not_found/out_of_scope_file/dependency_version_uncertain), testsAdded, requiresTestReview | On escalation_needed: handle by escalation_type |
-| quality-fixer | Input: `task_file` (path to current task file — always pass this in orchestrated flows). Status: approved/stub_detected/blocked. `stub_detected` → route back to task-executor with `incompleteImplementations[]` details for completion, then re-run quality-fixer. `blocked` → see quality-fixer blocked handling below | On stub_detected: re-invoke task-executor. On blocked: see handling below |
+| task-executor | Input: `task_file` (required in orchestrated flows); optional Fix Mode signals `requiredFixes` or `incompleteImplementations` — when either is non-empty, skip `task_already_completed` and extend allowed list with each item's `file_path` / `location` (parse `location` as `file[:line]`). Output: status (escalation_needed/completed), filesModified[], testsAdded, requiresTestReview, escalation_type ∈ {task_file_not_found, task_already_completed, target_files_missing, design_compliance_violation, similar_function_found, similar_component_found, investigation_target_not_found, out_of_scope_file, dependency_version_uncertain}. | On escalation_needed: handle by escalation_type |
+| quality-fixer | Input: `task_file` (path to current task file — always pass this in orchestrated flows), `filesModified` (extract from the upstream implementation step's response — passes the task's write set as the primary scope for stub-detection; falls back to `git diff HEAD` when omitted). Status: approved/stub_detected/blocked. `stub_detected` → route back to the implementation step with `incompleteImplementations[]` details for completion, then re-run quality-fixer. `blocked` → see quality-fixer blocked handling below | On stub_detected: re-invoke the implementation step. On blocked: see handling below |
 | document-reviewer | approvalReady (true/false) | Proceed to next step on true; request fixes on false |
 | design-sync | sync_status (NO_CONFLICTS/CONFLICTS_FOUND) | On CONFLICTS_FOUND: present conflicts to user before proceeding |
-| integration-test-reviewer | status (approved/needs_revision/blocked), requiredFixes | On needs_revision: pass requiredFixes back to task-executor |
-| security-reviewer | status (approved/approved_with_notes/needs_revision/blocked), findings, notes, requiredFixes | On needs_revision: pass requiredFixes back to task-executor |
+| integration-test-reviewer | status (approved/needs_revision/blocked), requiredFixes | On needs_revision: re-invoke the routed executor in Fix Mode with the same task_file and requiredFixes[] |
+| security-reviewer | status (approved/approved_with_notes/needs_revision/blocked), findings, notes, requiredFixes | On needs_revision: create a consolidated fix task file with affected files in Target Files, then invoke executor in Fix Mode with that task_file and requiredFixes[] (see build/implement recipes) |
 | acceptance-test-generator | status, generatedFiles (integration: path\|null, e2e: path\|null), budgetUsage, e2eAbsenceReason (null when E2E emitted, otherwise: no_multi_step_journey\|below_threshold_user_confirmed) | Verify files exist, pass to work-planner with absence reason |
 
 ### quality-fixer Blocked Handling
@@ -147,7 +147,7 @@ When quality-fixer returns `status: "blocked"`, discriminate by `reason`:
 - `"Cannot determine due to unclear specification"` → read `blockingIssues[]` for specification details
 - `"Execution prerequisites not met"` → read `missingPrerequisites[]` with `resolutionSteps` and present to user as actionable next steps
 
-## My Basic Flow for Work Planning
+## My Basic Flow: Planning and Implementation
 
 When receiving new features or change requests, I first request requirement analysis from requirement-analyzer.
 According to scale determination:
@@ -186,8 +186,10 @@ According to scale determination:
 
 ### Small Scale (1-2 Files) - 2 Steps
 
-1. work-planner → Simplified work plan creation **[Stop: Batch approval]**
-2. Direct implementation → Completion report
+1. work-planner → Simplified work plan creation. At this scale, work-planner emits a single task-template-format task file directly under `docs/plans/tasks/` instead of a separate work plan + decomposition; that path is what task-executor receives as `task_file`. **[Stop: Batch approval]**
+2. task-executor → quality-fixer → commit (per task) → Completion report
+
+Note: At Small scale the implementation step still runs through task-executor with the standard 4-step cycle (`task-executor → escalation judgment → quality-fixer → commit`). Direct orchestrator edits are not used.
 
 ## Cross-Layer Orchestration
 
@@ -200,17 +202,19 @@ Replace the standard Design Doc creation step with per-layer creation:
 | Step | Agent | Purpose |
 |------|-------|---------|
 | 8 | codebase-analyzer ×2 | Codebase analysis per layer (pass req-analyzer output, filtered to layer) |
-| 9a | technical-designer | Backend Design Doc (with backend codebase-analyzer context) |
-| 9b | technical-designer-frontend | Frontend Design Doc (with frontend codebase-analyzer context + backend Integration Points) |
-| 10 | code-verifier ×2 | Verify each Design Doc against existing code |
-| 11 | document-reviewer ×2 | Review each Design Doc (with code-verifier results as code_verification) |
-| 12 | design-sync | Cross-layer consistency verification **[Stop]** |
+| 9 | technical-designer | Backend Design Doc (with backend codebase-analyzer context) |
+| 10 | code-verifier | Verify Backend Design Doc against existing code (its result JSON becomes `prior_layer_verification` for step 12) |
+| 11 | document-reviewer | Review Backend Design Doc (pass step-10 result as `code_verification` and backend codebase-analyzer JSON as `codebase_analysis`). **[Stop on critical issues]** — structural defects here block step 12. |
+| 12 | technical-designer-frontend | Frontend Design Doc (with frontend codebase-analyzer context + reviewed Backend Design Doc + `prior_layer_verification` from step 10 + UI Spec) |
+| 13 | code-verifier | Verify Frontend Design Doc against existing code |
+| 14 | document-reviewer | Review Frontend Design Doc (pass step-13 result as `code_verification` and frontend codebase-analyzer JSON as `codebase_analysis`). **[Stop on critical issues]** — structural defects here block step 15. |
+| 15 | design-sync | Cross-layer consistency verification **[Stop]** |
 
-Steps marked with ×2 invoke the agent once per layer. These invocations are independent and can run in parallel when the orchestrator supports concurrent Agent tool calls.
+The `codebase-analyzer ×2` invocations can run in parallel. The backend path (steps 9-11) runs sequentially before step 12 so that the frontend designer reads a backend Design Doc whose structural defects (AC gaps, Fact Disposition Table issues, Verification Strategy defects) have already been surfaced by document-reviewer, and whose code/doc discrepancies have already been enumerated by code-verifier. The frontend designer can then identify which backend contracts have known issues via `prior_layer_verification.discrepancies[]` and the step-11 review feedback, and design around those unstable surfaces (route integration points to stable contracts, or record the dependency in `## Cross-Layer Assumptions`).
 
 **Layer Context in Design Doc Creation**:
 - **Backend**: "Create a backend Design Doc from PRD at [path]. Codebase analysis: [JSON from codebase-analyzer for backend layer]. Focus on: API contracts, data layer, business logic, service architecture."
-- **Frontend**: "Create a frontend Design Doc from PRD at [path]. Codebase analysis: [JSON from codebase-analyzer for frontend layer]. Reference backend Design Doc at [path] for API contracts and Integration Points. Focus on: component hierarchy, state management, UI interactions, data fetching."
+- **Frontend**: "Create a frontend Design Doc from PRD at [path]. Codebase analysis: [JSON from codebase-analyzer for frontend layer]. Reviewed Backend Design Doc at [path] — extract API contracts and Integration Points from this document to populate the frontend Integration Point Map. Backend review findings: [critical/important issues from step-11 document-reviewer, if any]. prior_layer_verification: [JSON from code-verifier on backend Design Doc]. Identify unstable backend contracts via `prior_layer_verification.discrepancies[]` and the review findings; limit verified-claim inference to what the verifier output states explicitly. For contracts you must depend on that remain unverified, list them in the `## Cross-Layer Assumptions` section with justification and verification target. Reference UI Spec at [path] for component structure. Focus on: component hierarchy, state management, UI interactions, data fetching."
 
 **design-sync**: Use frontend Design Doc as source. design-sync auto-discovers other Design Docs in `docs/design/` for comparison.
 
@@ -241,7 +245,7 @@ During autonomous execution, route agents by task filename pattern:
 ### Step 2 Execution Details
 - `status: escalation_needed` or `status: blocked` -> Escalate to user
 - `requiresTestReview` is `true` -> Execute **integration-test-reviewer**
-  - If verdict is `needs_revision` -> Return to task-executor with `requiredFixes`
+  - If verdict is `needs_revision` -> Re-invoke the routed executor (task-executor or task-executor-frontend per Layer-Aware Agent Routing) in **Fix Mode** with the same `task_file` and the `requiredFixes[]` array
   - If verdict is `approved` -> Proceed to quality-fixer
 
 ### Conditions for Stopping Autonomous Execution
@@ -269,6 +273,10 @@ Every subagent prompt must include:
 
 Construct the prompt from the agent's Input Parameters section and the deliverables available at that point in the flow.
 
+Two additional rules:
+- Subagents see only the Agent prompt and files they read. Include required paths, prior JSON, parameters, and scope constraints explicitly.
+- Replace every `[placeholder]` in examples below with concrete values before invoking the Agent tool.
+
 ### Call Example (codebase-analyzer)
 - subagent_type: "codebase-analyzer"
 - description: "Codebase analysis"
@@ -292,12 +300,18 @@ Construct the prompt from the agent's Input Parameters section and the deliverab
    #### codebase-analyzer → technical-designer
 
    **Pass to codebase-analyzer**: requirement-analyzer JSON output, PRD path (if exists), original user requirements
-   **Pass to technical-designer**: codebase-analyzer JSON output as additional context in the Design Doc creation prompt. The designer uses `focusAreas`, `dataModel`, `dataTransformationPipelines`, and `qualityAssurance` to inform the Existing Codebase Analysis, Verification Strategy, and Quality Assurance Mechanisms sections.
+   **Pass to technical-designer**: codebase-analyzer JSON output as additional context in the Design Doc creation prompt. Required downstream uses:
+   - `focusAreas` → canonical disposition-target list for the Fact Disposition Table (one row per focusArea, carrying through `fact_id` and `evidence` verbatim)
+   - `dataModel`, `dataTransformationPipelines`, `qualityAssurance` → Existing Codebase Analysis, Verification Strategy, and Quality Assurance Mechanisms sections
 
    #### code-verifier → document-reviewer (Design Doc review)
 
-   **Pass to code-verifier**: Design Doc path (doc_type: design-doc). `code_paths` is intentionally omitted — the verifier independently discovers code scope from the document.
-   **Pass to document-reviewer**: code-verifier JSON output as `code_verification` parameter.
+   **Pass to code-verifier**: Design Doc path (doc_type: design-doc). Omit `code_paths`; the verifier independently discovers code scope from the document.
+   **Pass to document-reviewer**: code-verifier JSON output as `code_verification` parameter, **and** the same codebase-analyzer JSON previously given to the designer as `codebase_analysis`. The reviewer uses `codebase_analysis.focusAreas` to verify Fact Disposition Table coverage.
+
+   #### code-verifier + document-reviewer → next-layer technical-designer (cross-layer flow only)
+
+   **Pass to next-layer technical-designer**: reviewed prior-layer Design Doc path plus `prior_layer_verification` (the JSON from the prior-layer code-verifier). See Cross-Layer Orchestration section for sequencing. Use `prior_layer_verification.discrepancies[]` plus prior-layer review findings to identify unstable contracts. Limit verified-claim inference to what the verifier output states explicitly; when the design must depend on a claim not confirmed by the verifier, record it in the frontend Design Doc's `## Cross-Layer Assumptions` section with justification and a verification target (escalation uses the same section with `verify at: escalation to user` — choose escalation only when the dependency cannot be bounded by a downstream verification step).
 
    #### technical-designer → work-planner
 

package/.claude/skills-en/task-analyzer/references/skills-index.yaml

@@ -21,6 +21,7 @@ skills:
       - "Comment Writing Rules"
       - "Error Handling Fundamentals"
       - "Rule of Three - Criteria for Code Duplication"
+      - "Reference Representativeness"
       - "Common Failure Patterns and Avoidance Methods"
       - "Debugging Techniques"
       - "Type Safety Fundamentals"
@@ -119,7 +120,6 @@ skills:
       - "AI Automation Rules"
       - "Diagram Requirements"
       - "Common ADR Relationships"
-      - "Phase Division Criteria"
       - "Templates"
 
   implementation-approach:
@@ -155,6 +155,7 @@ skills:
       - "Test Types and Limits"
       - "Behavior-First Principle"
       - "Skeleton Specification"
+      - "Multi-Step User Journey Definition"
       - "Implementation Rules"
       - "Review Criteria"
 
@@ -173,7 +174,7 @@ skills:
       - "Constraints Between Subagents"
       - "Scale Determination and Document Requirements"
       - "Structured Response Specifications"
-      - "My Basic Flow for Work Planning"
+      - "My Basic Flow: Planning and Implementation"
       - "Cross-Layer Orchestration"
       - "Autonomous Execution Mode"
       - "My Main Roles as Orchestrator"

package/.claude/skills-en/typescript-testing/SKILL.md

@@ -172,7 +172,7 @@ The appropriate approach depends on project environment and CI/CD capabilities.
 - AI-generated data access code has heightened schema hallucination risk
 - Generated queries may use correct syntax but reference nonexistent schema elements
 - Mock-based tests pass regardless of schema accuracy
-- Mitigation: Design Docs should include explicit schema references; code-verifier reverse coverage verifies data operations against documented schemas
+- Mitigation: Design Docs should include explicit schema references so that documented schemas can be cross-checked against data access code during review
 
 ## Basic Vitest Example
 

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

@@ -14,7 +14,7 @@ description: PRD、ADR、Design Doc、UI Spec、作業計画書の作成を支
 | ADR条件該当（下記参照） | ADR → Design Doc → 作業計画書 | 即座に開始 |
 | 6ファイル以上 | ADR → Design Doc → 作業計画書（必須） | 即座に開始 |
 | 3-5ファイル | Design Doc → 作業計画書（推奨） | 即座に開始 |
-| 1-2ファイル | なし | 直接実装 |
+| 1-2ファイル | なし | 作業計画書なしの実装サイクル |
 
 ## ADR作成条件（いずれか該当で必須）
 
@@ -87,7 +87,7 @@ description: PRD、ADR、Design Doc、UI Spec、作業計画書の作成を支
 - ビジュアル受入条件(AC)（ゴールデンステート、レイアウト制約）
 - アクセシビリティ要件（キーボード、スクリーンリーダー、コントラスト）
 
-**スコープ**: 画面構造、遷移、コンポーネント分解、インタラクション設計、ビジュアル受入条件のみ。技術実装とAPIコントラクトはDesign Doc、テスト実装はacceptance-test-generatorスケルトン、スケジュールは作業計画書に記載。
+**スコープ**: 画面構造、遷移、コンポーネント分解、インタラクション設計、ビジュアル受入条件のみ。技術実装とAPIコントラクトはDesign Doc、テスト実装はテストスケルトン生成出力、スケジュールは作業計画書に記載。
 
 **必須構造要素**:
 - 状態×表示マトリクスとインタラクション表を含むコンポーネントが1つ以上
@@ -151,7 +151,7 @@ description: PRD、ADR、Design Doc、UI Spec、作業計画書の作成を支
 - **フェーズ構成**（Design Docの技術的依存関係を基に作成）
 - タスク分解と依存関係（最大2階層まで）
 - スケジュールと期間見積もり
-- **テストスケルトンファイルパスを配置**（統合テスト・E2E）
+- **本作業計画用に生成されたテストスケルトンファイルパスを配置**（統合テスト・E2E）
 - **検証戦略の要約**（Design Docから抽出）
 - **最終フェーズに品質保証を含む**（必須）
 - 進捗記録（チェックボックス形式）