create-ai-project 1.20.0 → 1.20.2

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

@@ -16,12 +16,9 @@ description: サブエージェントのタスク分担と連携を調整。規
 - フロー実行中: 規模判定に基づくフローを厳守
 - 各フェーズ: 適切なサブエージェントに委譲
 - 停止ポイント: 必ずユーザー承認を待つ
-
-### 避ける行為
-- Grep/Glob/Readで自分で調査を始める
-- 自分で分析や設計を考え始める
-- 「まず調べてみます」と言って作業を開始する
-- requirement-analyzerを後回しにする
+- **調査**: すべての調査はrequirement-analyzerまたはcodebase-analyzerに委譲（Grep/Glob/Readはサブエージェント内部のツール）
+- **分析・設計**: 該当するサブエージェントに委譲
+- **初動**: ユーザー要件はrequirement-analyzerに渡してから他のステップへ進む
 
 **初動アクション規則**: ユーザー要件を正確に分析するため、requirement-analyzerに直接渡し、その分析結果に基づいてワークフローを決定する。
 
@@ -34,6 +31,8 @@ graph TD
     Scale --> Flow[規模に応じたフロー実行]
 ```
 
+**フロー実行中は規模判定表に従って次のサブエージェントを決定する**
+
 ### フロー実行中の要件変更検知
 
 **フロー実行中**にユーザーレスポンスで以下を検知したら、フローを停止してrequirement-analyzerへ：
@@ -66,6 +65,36 @@ graph TD
 
 ## オーケストレーション原則
 
+### 委譲の境界: What vs How
+
+「何を達成するか」「どこで作業するか」を渡す。各サブエージェントは「どう実行するか」を自律的に決定する。
+
+**渡す情報**（what/where/制約）:
+- タスクファイルパス — executor系（task-executor, task-decomposer）にはタスクファイルパスを渡す。より広いスコープはユーザーの明示的な要求がある場合のみ
+- ディレクトリまたはパッケージスコープ — discovery/review系（codebase-analyzer, code-verifier, security-reviewer, integration-test-reviewer）向け
+- ユーザーまたは設計成果物からの受入条件とハード制約
+
+**サブエージェントに委ねる判断**（how）:
+- 実行するコマンド（プロジェクト設定やリポジトリの規約からサブエージェントが判断）
+- 実行順序やツールフラグ
+- Executor/fixer系: スコープ内で調査・変更するファイルの選択
+- Review/discovery系: スコープ内で調査するファイルの選択（読み取り専用）
+
+| | Bad（howを指定） | Good（whatを指定） |
+|---|---|---|
+| quality-fixer | 「lint → test の順でチェックして」 | 「品質チェックと修正をすべて実行して」 |
+| task-executor | 「ファイルXにハンドラYを追加して」 | 「タスクファイル: docs/plans/tasks/003-feature.md」 |
+
+**出力が矛盾した場合の優先順位**:
+1. ユーザー指示（明示的な要求や制約）
+2. タスクファイルと設計成果物（Design Doc, PRD, 作業計画書）
+3. リポジトリの客観的状態（git status、ファイルシステム、プロジェクト設定）
+4. サブエージェントの判断
+
+サブエージェント同士の判断が衝突した場合、またはサブエージェントの出力が期待と異なる場合、上記の優先順位を適用する。リポジトリの客観的状態（3）で検証し、1・2と整合する出力に従う。矛盾がある場合はユーザー指示、次いで設計成果物に従う。
+
+サブエージェントがリポジトリの状態や成果物から実行方法を判断できない場合、blockedステータスでエスカレーションする。その詳細をユーザーに伝える。
+
 ### 責務分離を意識した振り分け
 
 **task-executorの責務**:
@@ -105,16 +134,25 @@ graph TD
 ## 構造化レスポンス仕様
 
 サブエージェントはJSON形式で応答。オーケストレーター判断に必要なフィールド：
-- **requirement-analyzer**: scale, confidence, adrRequired, crossLayerScope, scopeDependencies, questions
-- **codebase-analyzer**: analysisScope.categoriesDetected, dataModel.detected, focusAreas[], existingElements count, limitations
-- **code-verifier**:（設計フロー時）consistencyScore, discrepancies[], reverseCoverage（dataOperationsInCode, testBoundariesSectionPresent含む）
-- **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), testsAdded, requiresTestReview
-- **quality-fixer**: status (approved/blocked)。blockedタイプは`reason`フィールドで判別: `"Cannot determine due to unclear specification"` → `blockingIssues[]`で仕様詳細を参照; `"Execution prerequisites not met"` → `missingPrerequisites[]`の`resolutionSteps`を参照し、ユーザーにアクション可能なステップとして提示
-- **document-reviewer**: approvalReady (true/false)
-- **design-sync**: sync_status (synced/conflicts_found)
-- **integration-test-reviewer**: status (approved/needs_revision/blocked), requiredFixes
-- **security-reviewer**: status (approved/approved_with_notes/needs_revision/blocked), findings, notes, requiredFixes
-- **acceptance-test-generator**: status, generatedFiles
+
+| Agent | 主要フィールド | 判断ロジック |
+|-------|---------------|-------------|
+| requirement-analyzer | scale, confidence, adrRequired, crossLayerScope, scopeDependencies, questions | scaleでフローを選択。adrRequiredでADRステップ要否を判断 |
+| codebase-analyzer | analysisScope.categoriesDetected, dataModel.detected, focusAreas[], existingElements count, limitations | focusAreasをtechnical-designerにコンテキストとして渡す |
+| code-verifier | consistencyScore, discrepancies[], reverseCoverage (dataOperationsInCode, testBoundariesSectionPresent) | discrepanciesをdocument-reviewerに連携 |
+| task-executor | status (escalation_needed/completed), escalation_type, testsAdded, requiresTestReview | escalation_needed時: escalation_type別に対応（design_compliance_violation, similar_function_found, similar_component_found, investigation_target_not_found, out_of_scope_file） |
+| quality-fixer | status (approved/blocked), reason, blockingIssues[], missingPrerequisites[] | blocked時: 下記quality-fixer blockedハンドリング参照 |
+| document-reviewer | approvalReady (true/false) | trueで次ステップへ。falseで修正を依頼 |
+| design-sync | sync_status (synced/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 | generatedFilesをwork-plannerに渡す |
+
+### quality-fixer blockedハンドリング
+
+quality-fixerが `status: "blocked"` を返した場合、`reason`で判別：
+- `"Cannot determine due to unclear specification"` → `blockingIssues[]`で仕様詳細を確認
+- `"Execution prerequisites not met"` → `missingPrerequisites[]`の`resolutionSteps`をユーザーにアクション可能なステップとして提示
 
 ## 作業計画時の基本フロー
 
@@ -266,6 +304,10 @@ requirement-analyzerが複数レイヤー（backend + frontend）にまたがる
    **code-verifierへの入力**: Design Docパス（doc_type: design-doc）。`code_paths`は意図的に未指定 — verifierがドキュメントからコードスコープを独自に発見する。
    **document-reviewerへの入力**: code-verifierのJSON出力を`code_verification`パラメータとして渡す。
 
+   #### technical-designer → work-planner
+
+   **work-plannerへの入力**: Design Docパス。work-plannerがDesign Docから検証戦略を抽出し、作業計画書ヘッダーに記載する。
+
    #### *1 acceptance-test-generator → work-planner
 
    **acceptance-test-generatorへの入力**:
@@ -291,7 +333,7 @@ requirement-analyzerが複数レイヤー（backend + frontend）にまたがる
 - **構造化レスポンス必須**: サブエージェント間の情報伝達はJSON形式
 - **承認管理**: ドキュメント作成→document-reviewer実行→ユーザー承認を得てから次へ進む
 - **フロー確認**: 承認取得後は必ず作業計画フロー（大規模/中規模/小規模）で次のステップを確認
-- **整合性検証**: サブエージェント判定に矛盾がある場合はガイドラインを優先
+- **整合性検証**: サブエージェントの出力が矛盾した場合、優先順位に従って解決（委譲の境界セクション参照）
 
 ## 人間との必須対話ポイント
 

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

@@ -93,7 +93,7 @@ skills:
 
   documentation-criteria:
     skill: "documentation-criteria"
-    tags: [documentation, decision-making, adr, prd, ui-spec, design-doc, planning, process]
+    tags: [documentation, decision-making, adr, prd, ui-spec, design-doc, planning, process, verification-strategy]
     typical-use: "実装開始時の規模判定、ドキュメント作成判定、ADR/PRD/Design Doc/作業計画書の作成基準"
     size: medium
     key-references:
@@ -110,11 +110,12 @@ skills:
       - "AI自動化ルール"
       - "図表作成要件"
       - "共通ADRとの関係性"
+      - "フェーズ分割基準"
       - "テンプレート"
 
   implementation-approach:
     skill: "implementation-approach"
-    tags: [architecture, implementation, task-decomposition, strategy-patterns, strangler-pattern, facade-pattern, design, planning, confirmation-levels]
+    tags: [architecture, implementation, task-decomposition, strategy-patterns, strangler-pattern, facade-pattern, design, planning, verification-levels]
     typical-use: "実装戦略の選択、タスク分解、設計判断、大規模変更の計画"
     size: medium
     key-references:
@@ -124,7 +125,7 @@ skills:
       - "Facade Pattern - Gang of Four"
     sections:
       - "メタ認知的戦略選択プロセス"
-      - "確認レベル定義"
+      - "検証レベル定義"
       - "統合ポイントの定義"
       - "アンチパターン"
       - "メタ認知的実行のための指針"

package/CHANGELOG.md

@@ -5,6 +5,41 @@ All notable changes to this project will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [1.20.2] - 2026-04-03
+
+### Added
+
+- **Delegation Boundary: What vs How** (subagents-orchestration-guide): Orchestrator lacked a definition of what granularity to pass to specialists vs what to let them decide autonomously. Added what/where/constraints vs how separation, Bad/Good comparison table, 4-tier decision precedence for conflict resolution, and escalation rule for undeterminable execution methods
+- **Scope granularity per agent type**: Executor agents receive task file paths by default (broader scope requires explicit user request); discovery/review agents receive directory or package scope with read-only access
+- **quality-fixer blocked handling subsection** (Structured Response Specifications): Moved quality-fixer's multi-branch decision logic from an overloaded table cell into a dedicated subsection for scannability
+
+### Changed
+
+- **Prohibited Actions → positive-form Required Actions**: Negative instructions ("don't investigate directly", "don't skip requirement-analyzer") caused Pink Elephant Problem. Converted to affirmative delegation instructions ("Delegate all investigation to requirement-analyzer or codebase-analyzer")
+- **Structured Response Specifications table format**: Bullet list with mixed-length entries replaced with Agent / Key Fields / Decision Logic table. Each agent's response-to-action mapping is now explicit
+- **Consistency verification constraint**: Vague "prioritize these guidelines" replaced with reference to Decision precedence in the Delegation Boundary section
+- **Remaining negative-form instructions cleaned**: "no modification" → "read-only access", "instead of guessing" removed, "higher-precedence source" → explicit "user instructions first, then design artifacts"
+- **Japanese version: missing operational line added**: "フロー実行中は規模判定表に従って次のサブエージェントを決定する" was present in English but missing in Japanese
+
+## [1.20.1] - 2026-04-02
+
+### Added
+
+- **Verification Strategy flow**: Design Doc → Work Plan → Task pipeline now propagates how correctness is proven. Design template includes Correctness Proof Method and Early Verification Point sections. Work Plan template carries the strategy summary. Task template includes Operation Verification Methods derived from the strategy.
+- **Adaptive Phase Division Criteria**: Work Plan phase structure now adapts to implementation approach — vertical slice produces value-unit phases, horizontal slice retains Foundation → Core → Integration → QA, hybrid uses vertical as base with horizontal foundation phases. Plan template provides Option A/B with explicit instruction to delete the unused option.
+- **Verification Strategy review gates**: document-reviewer Gate 0 checks existence; Gate 1 checks quality (measurability, risk coverage, early verification concreteness, timing alignment with approach)
+- **Verification Strategy propagation in task-decomposer**: New section derives per-task Operation Verification Methods from the work plan's strategy, with concrete instantiation rules for early verification and per-task verification
+- **technical-designer → work-planner bridging**: Orchestration guide documents Verification Strategy handoff between design and planning phases
+
+### Changed
+
+- **Agent cross-references removed**: Agent definitions no longer reference other agents by name. `requirement-analyzer` → `requirement analysis`, `code-verifier` → `code verification`, `codebase-analyzer` → `codebase analysis phase`, etc. Orchestration layers own routing decisions.
+- **Acceptance criteria format**: technical-designer and technical-designer-frontend checklist item updated from "concrete trigger, action, and expected result" to "user-observable behaviors, integration/E2E oriented, CI-isolatable"
+- **testSkeletons input contract**: work-planner now describes format expectations (comment-based skeletons, not implemented tests) instead of naming the producer agent
+- **Command self-references removed**: update-doc no longer redirects to other commands; out-of-scope items stated without naming alternatives
+- **Japanese terminology unified**: `確認レベル` (confirmation level) → `検証レベル` (verification level) across all agents, skills, and skills-index to match English `Verification Level Definitions`
+- **skills-index.yaml updated**: `confirmation-levels` tag → `verification-levels`; `verification-strategy` tag and `Phase Division Criteria` section added to documentation-criteria
+
 ## [1.20.0] - 2026-04-01
 
 ### Added

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-ai-project",
-  "version": "1.20.0",
+  "version": "1.20.2",
   "packageManager": "npm@10.8.2",
   "description": "TypeScript boilerplate with skills and sub-agents for Claude Code. Prevents context exhaustion through role-based task splitting.",
   "keywords": [