create-ai-project 1.20.8 → 1.20.9

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/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/subagents-orchestration-guide/SKILL.md

@@ -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
 
@@ -243,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
@@ -271,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"

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から抽出）
 - **最終フェーズに品質保証を含む**（必須）
 - 進捗記録（チェックボックス形式）

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

@@ -1,54 +1,57 @@
-# タスク: [タスク名]
+# Task: [タスク名]
 
-メタデータ:
-- 依存関係: task-01 → 成果物: docs/plans/analysis/research-results.md
-- 提供物: docs/plans/analysis/api-spec.md（調査・設計タスクの場合）
-- サイズ: 小規模（1-2ファイル）
+Metadata:
+- Dependencies: task-01 -> Deliverable: docs/plans/analysis/research-results.md
+- Provides: docs/plans/analysis/api-spec.md（調査・設計タスクの場合）
+- Size: 小規模（1-2ファイル）
 
-## 実装内容
+## Implementation Content
 [このタスクで達成すること]
 *依存関係の成果物を参照する場合は明記
 
-## 対象ファイル
+## Target Files
 - [ ] [実装ファイルパス]
 - [ ] [テストファイルパス]
 
-## 調査対象
+## Investigation Targets
 実装開始前に読むべきファイル（ファイルパス、任意でサーチヒント付き）:
-- [例: src/orders/checkout (processOrder関数) — タスクの性質に基づきtask-decomposerが決定]
+- [例: src/orders/checkout (processOrder関数) — タスクの性質に基づきタスク分解時に決定]
 
-## 実装ステップ（TDD: Red-Green-Refactor）
-### 1. Redフェーズ
-- [ ] 全ての調査対象を読み、主要な所見を記録
-- [ ] 依存関係の成果物を確認（ある場合）
+## Investigation Notes
+（実装観察事項を実装開始前にここへ追記する。）
+
+## Implementation Steps (TDD: Red-Green-Refactor)
+### 1. Red Phase
+- [ ] 全ての Investigation Targets を読み、主要な所見を記録
+- [ ] Dependencies の成果物を確認（ある場合）
 - [ ] 契約定義を確認・作成
 - [ ] 失敗するテストを書く
 - [ ] テストを実行し失敗を確認
 
-### 2. Greenフェーズ
+### 2. Green Phase
 - [ ] テストをパスする最小限の実装を追加
 - [ ] 追加したテストのみ実行しパスを確認
 
-### 3. Refactorフェーズ
+### 3. Refactor Phase
 - [ ] コードを改善（テストはパス状態を維持）
 - [ ] 追加したテストが引き続きパスすることを確認
 
-## 品質保証メカニズム
-（作業計画書ヘッダーより — このタスクの対象ファイルに該当するメカニズム）
+## Quality Assurance Mechanisms
+（作業計画書ヘッダーより — このタスクの Target Files に該当するメカニズム）
 - [ツール/チェック名] — 検証内容: [何を担保するか] — 設定/出典: [パス] — 種別: `executable_check` | `passive_constraint`
 
-## 動作検証方法
-（作業計画書の検証戦略から導出）
-- **検証手法**: [何をどう検証するか — 例: 「新実装の出力をsrc/legacy/order_calcの既存実装と比較」「エンドポイントをテストDBに対して実行しレスポンスがコントラクトに一致することを確認」]
+## Operation Verification Methods
+（作業計画書の Verification Strategy から導出）
+- **検証手法**: [何をどう検証するか — 例: 「新実装の出力を src/legacy/order_calc の既存実装と比較」「エンドポイントをテストDBに対して実行しレスポンスがコントラクトに一致することを確認」]
 - **成功基準**: [正しさを証明する観察可能な成果 — 例: 「全入力パターンで既存実装と出力が一致」「APIが期待スキーマで200を返す」]
 - **失敗時の対応**: [検証失敗時の対処 — 例: 「続行前にアプローチを再評価」「ユーザーにエスカレーション」]
 - **検証レベル**: [L1: エンドユーザー機能としての動作確認 / L2: 新規テスト追加・パス / L3: ビルドエラーなし]
 
-## 完了条件
+## Completion Criteria
 - [ ] 追加した全テストがパス
-- [ ] 動作検証方法に基づく動作確認完了
+- [ ] Operation Verification Methods に基づく動作確認完了
 - [ ] 成果物作成完了（調査・設計タスクの場合）
 
-## 備考
+## Notes
 - 影響範囲: [変更が波及する可能性のある領域]
 - スコープ境界: [変更せず維持するファイル — パスと理由]

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

@@ -5,7 +5,7 @@
 [このUI仕様書の目的とスコープを2-3文で説明]
 
 ### 対象PRD
-- PRDパス: [docs/prd/xxx-prd.md | "N/A — requirement-analyzerの出力に基づく"]
+- PRDパス: [docs/prd/xxx-prd.md | "N/A — 要件分析の出力に基づく"]
 - 機能スコープ: [このUI SpecがカバーするPRD要件 | 分析済み要件の概要]
 
 ### 設計ソース

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

@@ -114,7 +114,7 @@ description: サブエージェントのタスク分担と連携を調整。規
 
 | 規模 | ファイル数 | PRD | ADR | Design Doc | 作業計画書 |
 |------|-----------|-----|-----|------------|-----------|
-| 小規模 | 1-2 | 更新※1 | 不要 | 不要 | 簡易版 |
+| 小規模 | 1-2 | 更新※1 | 不要 | 不要 | task-template 形式の単一タスクファイル（`docs/plans/tasks/` 直下、計画書ファイルは別途作成しない） |
 | 中規模 | 3-5 | 更新※1 | 条件付き※2 | **必須** | **必須** |
 | 大規模 | 6以上 | **必須**※3 | 条件付き※2 | **必須** | **必須** |
 
@@ -131,13 +131,13 @@ description: サブエージェントのタスク分担と連携を調整。規
 | requirement-analyzer | scale, confidence, adrRequired, crossLayerScope, scopeDependencies, questions | scaleでフローを選択。adrRequiredでADRステップ要否を判断 |
 | codebase-analyzer | analysisScope.categoriesDetected, dataModel.detected, qualityAssurance (mechanisms[], domainConstraints[]), focusAreas[], existingElements count, limitations | focusAreasをtechnical-designerにコンテキストとして渡す |
 | code-verifier | status (consistent/mostly_consistent/needs_review/inconsistent), consistencyScore, discrepancies[], reverseCoverage (dataOperationsInCode, testBoundariesSectionPresent). 実装前: Design Docの主張を既存コードに対して検証。実装後: 実装のDesign Doc整合性を検証（`code_paths`で変更ファイルにスコープ） | discrepanciesを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 | escalation_needed時: escalation_type別に対応 |
-| quality-fixer | 入力: `task_file`（現在のタスクファイルパス — オーケストレーションフローでは常に渡す）。Status: approved/stub_detected/blocked。`stub_detected` → task-executorに`incompleteImplementations[]`の詳細を添えて差し戻し、本実装完了後にquality-fixerを再実行。`blocked` → 下記quality-fixer blockedハンドリング参照 | stub_detected: task-executorを再実行。blocked: 下記参照 |
+| task-executor | 入力: `task_file`（オーケストレーションフローでは必須）; 任意の Fix Mode シグナル `requiredFixes` または `incompleteImplementations` — いずれかが非空の場合、`task_already_completed` チェックをスキップし、各項目の `file_path` / `location`（`location` は `file[:line]` として解釈）で許可リストを拡張する。出力: 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} | escalation_needed時: escalation_type別に対応 |
+| quality-fixer | 入力: `task_file`（現在のタスクファイルパス — オーケストレーションフローでは常に渡す）、`filesModified`（上流の実装ステップのレスポンスから抽出 — 当該タスクの書き込み集合を未完成実装検出の主要スコープとして渡す。省略時は `git diff HEAD` にフォールバック）。Status: approved/stub_detected/blocked。`stub_detected` → 上流の実装ステップに `incompleteImplementations[]` の詳細を添えて差し戻し、本実装完了後にquality-fixerを再実行。`blocked` → 下記quality-fixer blockedハンドリング参照 | stub_detected: 実装ステップを再実行。blocked: 下記参照 |
 | document-reviewer | approvalReady (true/false) | trueで次ステップへ。falseで修正を依頼 |
 | design-sync | sync_status (NO_CONFLICTS/CONFLICTS_FOUND) | CONFLICTS_FOUND時: 矛盾をユーザーに提示してから進む |
-| integration-test-reviewer | status (approved/needs_revision/blocked), requiredFixes | needs_revision時: requiredFixesをtask-executorに戻す |
-| security-reviewer | status (approved/approved_with_notes/needs_revision/blocked), findings, notes, requiredFixes | needs_revision時: requiredFixesをtask-executorに戻す |
-| acceptance-test-generator | status, generatedFiles { integration: string, e2e: string | null }, e2eAbsenceReason: string | null | generatedFiles.integrationとgeneratedFiles.e2e（nullable）をwork-plannerに渡す。e2eがnullの場合、e2eAbsenceReasonが妥当であればエラーではない |
+| integration-test-reviewer | status (approved/needs_revision/blocked), requiredFixes | needs_revision時: 同じ task_file と requiredFixes[] を渡してルーティング先の executor を Fix Mode で再実行 |
+| security-reviewer | status (approved/approved_with_notes/needs_revision/blocked), findings, notes, requiredFixes | needs_revision時: 影響ファイルをTarget Filesに含めた統合修正タスクファイルを作成し、その task_file と requiredFixes[] を渡してexecutor を Fix Mode で起動（build/implementレシピ参照） |
+| acceptance-test-generator | status, generatedFiles (integration: path\|null, e2e: path\|null), budgetUsage, e2eAbsenceReason (E2E 出力時は null。それ以外は no_multi_step_journey \| below_threshold_user_confirmed) | ファイルの存在を確認し、不在理由（e2eAbsenceReason）を添えて work-planner に渡す |
 
 ### quality-fixer blockedハンドリング
 
@@ -181,8 +181,10 @@ quality-fixerが `status: "blocked"` を返した場合、`reason`で判別：
 
 ### 小規模（1-2ファイル） - 2ステップ
 
-1. work-planner → 簡易作業計画書を作成 **[停止: 一括承認]**
-2. 直接実装 → 完了報告
+1. work-planner → 簡易作業計画作成。本スケールでは作業計画書とタスク分解ステップを分けず、`docs/plans/tasks/` 直下に task-template 形式の単一タスクファイルを直接出力する。task-executor にはそのパスを `task_file` として渡す **[停止: 一括承認]**
+2. task-executor → quality-fixer → commit（タスクごと）→ 完了報告
+
+注: 小規模スケールでも実装ステップは task-executor を介して標準の4ステップサイクル（`task-executor → エスカレーション判定 → quality-fixer → commit`）で実行する。オーケストレーターによる直接編集は行わない。
 
 ## レイヤー横断オーケストレーション
 
@@ -238,7 +240,7 @@ requirement-analyzerが複数レイヤー（backend + frontend）にまたがる
 ### Step 2 実行詳細
 - `status: escalation_needed` または `status: blocked` → ユーザーにエスカレーション
 - `requiresTestReview` が `true` → **integration-test-reviewer** を実行
-  - verdict が `needs_revision` → `requiredFixes` と共に task-executor に戻る
+  - verdict が `needs_revision` → ルーティング先の executor（レイヤー別エージェントルーティング 参照、task-executor または task-executor-frontend）を **Fix Mode** で再実行（同じ `task_file` と `requiredFixes[]` を渡す）
   - verdict が `approved` → quality-fixer へ進む
 
 ### 自律実行の停止条件
@@ -267,6 +269,10 @@ requirement-analyzerが複数レイヤー（backend + frontend）にまたがる
 
 エージェントのInput Parametersセクションと、フロー内のその時点で利用可能な成果物からプロンプトを構成する。
 
+追加の2つのルール:
+- サブエージェントは Agent prompt と自身が読み込んだファイルしか参照できない。必須のパス、先行 JSON、パラメータ、スコープ制約をプロンプトに明示的に注入する。
+- 以下の例の `[placeholder]` は Agent ツール呼び出し前にすべて具体値へ置換する。
+
 ### Call Example (codebase-analyzer)
 - subagent_type: "codebase-analyzer"
 - description: "コードベース分析"

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

@@ -23,6 +23,7 @@ skills:
       - "コメント記述ルール"
       - "エラーハンドリングの基本原則"
       - "Rule of Three - コード重複の判断基準"
+      - "参照の代表性"
       - "よくある失敗パターンと回避方法"
       - "デバッグ手法"
       - "型安全性の基礎"
@@ -32,7 +33,7 @@ skills:
       - "Red-Green-Refactorプロセス（テストファースト開発）"
       - "テスト設計原則"
       - "テストの粒度原則"
-      - "Security Principles (Secure Defaults, Input and Output Boundaries, Access Control, Knowledge Cutoff Supplement)"
+      - "Security Principles"
 
   typescript-rules:
     skill: "typescript-rules"
@@ -110,7 +111,6 @@ skills:
       - "AI自動化ルール"
       - "図表作成要件"
       - "共通ADRとの関係性"
-      - "フェーズ分割基準"
       - "テンプレート"
 
   implementation-approach:
@@ -146,6 +146,7 @@ skills:
       - "テスト種別と上限"
       - "振る舞い優先の原則"
       - "スケルトン仕様"
+      - "マルチステップユーザージャーニーの定義"
       - "実装ルール"
       - "レビュー基準"
 

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

@@ -172,7 +172,7 @@ const sdkMock = {
 - AI生成のデータアクセスコードはスキーマのhallucinationリスクが高い
 - 生成されたクエリは正しい構文でも、存在しないスキーマ要素を参照する場合がある
 - モックベースのテストはスキーマの正確性に関わらずパスする
-- 緩和策: Design Docに明示的なスキーマ参照を含めること。逆方向カバレッジ検証でドキュメント化されたスキーマに対するデータ操作を検証する
+- 緩和策: Design Docに明示的なスキーマ参照を含めることで、レビュー時にドキュメント化されたスキーマとデータアクセスコードを照合可能にする
 
 ## Vitestの基本例