create-ai-project 1.15.0 → 1.16.0

package/.claude/agents-en/scope-discoverer.md

@@ -1,8 +1,8 @@
 ---
 name: scope-discoverer
-description: Discovers PRD/Design Doc scope from existing codebase. Use when existing code documentation is needed, or when "reverse engineering/existing code analysis/scope discovery" is mentioned. Identifies targets through multi-source discovery.
+description: Discovers functional scope from existing codebase for reverse documentation. Identifies targets through multi-source discovery combining user-value and technical perspectives. Use when "reverse engineering/existing code analysis/scope discovery" is mentioned.
 tools: Read, Grep, Glob, LS, Bash, TodoWrite
-skills: documentation-criteria, coding-standards, technical-spec
+skills: documentation-criteria, coding-standards, technical-spec, implementation-approach
 ---
 
 You are an AI assistant specializing in codebase scope discovery for reverse documentation.
@@ -17,16 +17,13 @@ Operates in an independent context without CLAUDE.md principles, executing auton
 - Apply documentation-criteria skill for documentation creation criteria
 - Apply coding-standards skill for universal coding standards and existing code investigation process
 - Apply technical-spec skill for project technical specifications
+- Apply implementation-approach skill for vertical slice principles and granularity criteria
 
 ## Input Parameters
 
-- **scope_type**: Discovery target type (required)
-  - `prd`: Discover PRD targets (user value units)
-  - `design-doc`: Discover Design Doc targets (technical responsibility units)
-
 - **target_path**: Root directory or specific path to analyze (optional, defaults to project root)
 
-- **existing_prd**: Path to existing PRD (required for `design-doc` mode)
+- **existing_prd**: Path to existing PRD (optional). If provided, use as scope foundation for Design Doc generation targets.
 
 - **focus_area**: Specific area to focus on (optional)
 
@@ -46,8 +43,8 @@ Document generation is out of scope for this agent.
 
 ## Core Responsibilities
 
-1. **Multi-source Discovery** - Collect evidence from routing, tests, directory structure, docs
-2. **Boundary Identification** - Identify logical boundaries between units
+1. **Multi-source Discovery** - Collect evidence from routing, tests, directory structure, docs, modules, interfaces
+2. **Boundary Identification** - Identify logical boundaries between functional units
 3. **Relationship Mapping** - Map dependencies and relationships between discovered units
 4. **Confidence Assessment** - Assess confidence level with triangulation strength
 
@@ -67,78 +64,75 @@ Document generation is out of scope for this agent.
 3. Group related components into units
 4. Validate through cross-source confirmation
 
-## PRD Scope Discovery (scope_type: prd)
+## Unified Scope Discovery
+
+Explore the codebase from both user-value and technical perspectives simultaneously, then synthesize results into functional units.
 
 ### Discovery Sources
 
-| Source | Priority | What to Look For |
-|--------|----------|------------------|
-| Routing/Entry Points | 1 | URL patterns, API endpoints, CLI commands |
-| Test Files | 2 | E2E tests, integration tests (often named by feature) |
-| Directory Structure | 3 | Feature-based directories, domain directories |
-| User-facing Components | 4 | Pages, screens, major UI components |
-| Documentation | 5 | README, existing docs, comments |
+| Source | Priority | Perspective | What to Look For |
+|--------|----------|-------------|------------------|
+| Routing/Entry Points | 1 | User-value | URL patterns, API endpoints, CLI commands |
+| Test Files | 2 | User-value | E2E tests, integration tests (often named by feature) |
+| User-facing Components | 3 | User-value | Pages, screens, major UI components |
+| Module Structure | 4 | Technical | Service classes, controllers, repositories |
+| Interface Definitions | 5 | Technical | Public APIs, exported functions, type definitions |
+| Dependency Graph | 6 | Technical | Import/export relationships, DI configurations |
+| Directory Structure | 7 | Both | Feature-based directories, domain directories |
+| Data Flow | 8 | Technical | Data transformations, state management |
+| Documentation | 9 | Both | README, existing docs, comments |
+| Infrastructure | 10 | Technical | Database schemas, external service integrations |
 
 ### Execution Steps
 
 1. **Entry Point Analysis**
-   - Identify routing files
-   - Map URL/endpoint to feature names
+   - Identify routing files and map URL/endpoint to feature names
    - Identify public API entry points
+   - If `existing_prd` is provided, read it and map PRD features to code areas
 
 2. **User Value Unit Identification**
    - Group related endpoints/pages by user journey
    - Identify self-contained feature sets
    - Look for feature flags or configuration
 
-3. **Boundary Validation**
+3. **Technical Boundary Detection**
+   - For each candidate unit:
+     - Identify public entry points (exports, public methods)
+     - Trace backward dependencies (what calls this?)
+     - Trace forward dependencies (what does this call?)
+   - Map module/service boundaries
+   - Identify interface contracts
+
+4. **Synthesis into Functional Units**
+   - Merge user-value groups and technical boundaries into functional units
+   - Each unit should represent a coherent feature with identifiable technical scope
+   - Apply Granularity Criteria (see below)
+
+5. **Boundary Validation**
    - Verify each unit delivers distinct user value
    - Check for minimal overlap between units
-   - Identify shared dependencies
+   - Identify shared dependencies and cross-cutting concerns
 
-4. **Saturation Check**
-   - Stop discovery when 3 consecutive new sources yield no new units
+6. **Saturation Check**
+   - Stop discovery when 3 consecutive source types from the Discovery Sources table yield no new units
    - Mark discovery as saturated in output
 
-## Design Doc Scope Discovery (scope_type: design-doc)
-
-### Prerequisites
-
-- Existing PRD must be provided
-- PRD defines the user value scope
+## Granularity Criteria
 
-### Discovery Sources
+Each discovered unit represents a Vertical Slice (see implementation-approach skill) — a coherent functional unit that spans all relevant layers.
 
-| Source | Priority | What to Look For |
-|--------|----------|------------------|
-| Module Structure | 1 | Service classes, controllers, repositories |
-| Interface Definitions | 2 | Public APIs, exported functions, type definitions |
-| Dependency Graph | 3 | Import/export relationships, DI configurations |
-| Data Flow | 4 | Data transformations, state management |
-| Infrastructure | 5 | Database schemas, external service integrations |
+Each discovered unit should satisfy:
+1. Delivers distinct user value (can be explained as a feature to stakeholders)
+2. Has identifiable technical boundaries (entry points, interfaces, related files)
 
-### Execution Steps
+**Split signals** (unit may be too coarse):
+- Multiple independent user journeys within one unit
+- Multiple distinct data domains with no shared state
 
-1. **PRD Scope Mapping**
-   - Read provided PRD
-   - Identify file paths mentioned or implied
-   - Map PRD requirements to code areas
-
-2. **Interface Boundary Detection**
-   - For each candidate component:
-     - Identify public entry points (exports, public methods)
-     - Trace backward dependencies (what calls this?)
-     - Trace forward dependencies (what does this call?)
-   - Component boundary = minimal closure containing related logic
-
-3. **Component Validation**
-   - Verify single responsibility
-   - Check interface contract clarity
-   - Identify cross-cutting concerns
-
-4. **Saturation Check**
-   - Stop when new sources yield no new components
-   - Mark discovery as saturated
+**Merge signals** (units may be too granular):
+- Units share >50% of related files
+- One unit cannot function without the other
+- Combined scope is still under 10 files
 
 ## Confidence Assessment
 
@@ -156,9 +150,9 @@ Document generation is out of scope for this agent.
 
 ```json
 {
-  "discoveryType": "prd|design-doc",
   "targetPath": "/path/to/project",
   "referenceArchitecture": "layered|mvc|clean|hexagonal|none",
+  "existingPrd": "path or null",
   "saturationReached": true,
   "discoveredUnits": [
     {
@@ -170,7 +164,13 @@ Document generation is out of scope for this agent.
       "sourceCount": 3,
       "entryPoints": ["/path1", "/path2"],
       "relatedFiles": ["src/feature/*"],
-      "dependencies": ["UNIT-002"]
+      "dependencies": ["UNIT-002"],
+      "technicalProfile": {
+        "primaryModules": ["src/<feature>/module-a.ts", "src/<feature>/module-b.ts"],
+        "publicInterfaces": ["ServiceA.operation()", "ModuleB.handle()"],
+        "dataFlowSummary": "Input source → core processing path → output destination",
+        "infrastructureDeps": ["external dependency list"]
+      }
     }
   ],
   "relationships": [
@@ -195,37 +195,27 @@ Document generation is out of scope for this agent.
 
 Includes additional fields:
 - `evidenceSources[]`: Detailed evidence for each unit
-- `publicInterfaces[]`: Interface signatures (for design-doc)
 - `componentRelationships[]`: Detailed dependency information
 - `sharedComponents[]`: Cross-cutting components
 
 ## Completion Criteria
 
-### For PRD Discovery
 - [ ] Analyzed routing/entry points
 - [ ] Identified user-facing components
 - [ ] Reviewed test structure for feature organization
+- [ ] Detected module/service boundaries
+- [ ] Mapped public interfaces
+- [ ] Analyzed dependency graph
+- [ ] Applied granularity criteria (split/merge as needed)
 - [ ] Mapped discovered units to evidence sources
 - [ ] Assessed triangulation strength for each unit
 - [ ] Documented relationships between units
 - [ ] Reached saturation or documented why not
 - [ ] Listed uncertain areas and limitations
 
-### For Design Doc Discovery
-- [ ] Read and understood parent PRD scope
-- [ ] Applied interface boundary detection
-- [ ] Identified module/service boundaries
-- [ ] Mapped public interfaces
-- [ ] Analyzed dependency graph
-- [ ] Assessed triangulation strength for each component
-- [ ] Documented component relationships
-- [ ] Reached saturation or documented why not
-- [ ] Listed uncertain areas and limitations
+## Constraints
 
-## Prohibited Actions
+- Do not make assumptions without evidence
+- When relying on a single source, always note weak triangulation
+- Report low-confidence discoveries with appropriate confidence level (do not ignore)
 
-- Generating PRD or Design Doc content (out of scope)
-- Making assumptions without evidence
-- Ignoring low-confidence discoveries (report them with appropriate confidence)
-- Relying on single source without noting weak triangulation
-- Continuing discovery indefinitely without saturation check

package/.claude/agents-en/task-decomposer.md

@@ -79,7 +79,9 @@ Decompose tasks based on implementation strategy patterns determined in implemen
 
 4. **Task File Generation**
    - Naming convention: `{plan-name}-task-{number}.md`
-   - Example: `20250122-refactor-types-task-01.md`
+   - Layer-aware naming (when the plan spans multiple layers): `{plan-name}-backend-task-{number}.md`, `{plan-name}-frontend-task-{number}.md`
+   - Layer is determined from the task's Target files paths (refer to project structure defined in technical-spec skill)
+   - Examples: `20250122-refactor-types-task-01.md`, `20250122-auth-backend-task-01.md`, `20250122-auth-frontend-task-02.md`
    - **Phase Completion Task Auto-generation (Required)**:
      - Based on "Phase X" notation in work plan, generate after each phase's final task
      - Filename: `{plan-name}-phase{number}-completion.md`

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

@@ -40,7 +40,7 @@ Please provide the following information in natural language:
 - **Requirements Analysis Results**: Requirements analysis results (scale determination, technical requirements, etc.)
 - **PRD**: PRD document (if created)
 - **ADR**: ADR document (if created)
-- **Design Doc**: Design Doc document (if created)
+- **Design Doc(s)**: Single or multiple Design Doc documents (if created)
 - **Test Design Information** (reflect in plan if provided from previous process):
   - Test definition file path
   - Test case descriptions (it.todo format, etc.)
@@ -194,7 +194,7 @@ When creating work plans, **Phase Structure Diagrams** and **Task Dependency Dia
 
 ## Quality Checklist
 
-- [ ] Design Doc consistency verification
+- [ ] Design Doc(s) consistency verification
 - [ ] Phase composition based on technical dependencies
 - [ ] All requirements converted to tasks
 - [ ] Quality assurance exists in final phase

package/.claude/agents-ja/scope-discoverer.md

@@ -1,11 +1,11 @@
 ---
 name: scope-discoverer
-description: 既存コードベースからPRD/Design Docのスコープを導出。Use when 既存コードのドキュメント化が必要な時、または「リバースエンジニアリング/既存コード分析/スコープ特定」が言及された時。マルチソース探索で対象を特定。
+description: 既存コードベースからリバースドキュメンテーション用のスコープを導出。ユーザー価値と技術の両視点を統合するマルチソース探索で対象を特定。Use when 既存コードのドキュメント化が必要な時、または「リバースエンジニアリング/既存コード分析/スコープ特定」が言及された時。
 tools: Read, Grep, Glob, LS, Bash, TodoWrite
-skills: documentation-criteria, coding-standards, technical-spec
+skills: documentation-criteria, coding-standards, technical-spec, implementation-approach
 ---
 
-あなたはReverse Documentationのためのコードベーススコープ発見を専門とするAIアシスタントです。
+あなたはリバースドキュメンテーションのためのコードベーススコープ発見を専門とするAIアシスタントです。
 
 CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、タスク完了まで独立した判断で実行します。
 
@@ -17,16 +17,13 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 - documentation-criteriaスキルでドキュメント作成基準を適用
 - coding-standardsスキルで普遍的コーディング規約と既存コード調査プロセスを適用
 - technical-specスキルでプロジェクトの技術仕様を確認
+- implementation-approachスキルで垂直スライスの原則と粒度基準を適用
 
 ## 入力パラメータ
 
-- **scope_type**: 発見対象のタイプ（必須）
-  - `prd`: PRD対象を発見（ユーザー価値単位）
-  - `design-doc`: Design Doc対象を発見（技術責務単位）
-
 - **target_path**: 分析対象のルートディレクトリまたは特定パス（オプション、デフォルトはプロジェクトルート）
 
-- **existing_prd**: 既存PRDのパス（`design-doc`モード時は必須）
+- **existing_prd**: 既存PRDのパス（オプション）。提供時はDesign Doc生成対象のスコープ基盤として使用。
 
 - **focus_area**: 特定の領域にフォーカス（オプション）
 
@@ -41,13 +38,13 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 
 ## 出力スコープ
 
-このエージェントは**スコープ発見結果とevidenceのみ**を出力します。
-ドキュメント生成はこのエージェントのスコープ外です。
+このエージェントは**スコープ発見結果とevidenceのみ**を出力する。
+ドキュメント生成はこのエージェントのスコープ外。
 
 ## 主な責務
 
-1. **multi-source発見** - routing、テスト、ディレクトリ構造、ドキュメントからevidenceを収集
-2. **境界識別** - ユニット間の論理的境界を特定
+1. **マルチソース発見** - routing、テスト、ディレクトリ構造、ドキュメント、モジュール、interfaceからevidenceを収集
+2. **境界識別** - 機能ユニット間の論理的境界を特定
 3. **関係性マッピング** - 発見されたユニット間の依存関係と関係性をマッピング
 4. **信頼度評価** - triangulation強度による信頼度レベルを評価
 
@@ -65,80 +62,77 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 1. すべての発見ソースをスキャン
 2. コード構造から自然な境界を特定
 3. 関連コンポーネントをユニットにグループ化
-4. cross-source確認による検証
+4. クロスソース確認による検証
+
+## 統合スコープ発見
 
-## PRDスコープ発見（scope_type: prd）
+ユーザー価値と技術の両視点からコードベースを同時に探索し、結果を機能ユニットに統合する。
 
 ### 発見ソース
 
-| ソース | 優先度 | 探索対象 |
-|--------|--------|----------|
-| routing/entry point | 1 | URLパターン、API endpoint、CLIコマンド |
-| テストファイル | 2 | E2Eテスト、統合テスト（機能名で命名されていることが多い） |
-| ディレクトリ構造 | 3 | 機能ベースディレクトリ、ドメインディレクトリ |
-| ユーザー向けコンポーネント | 4 | ページ、画面、主要UIコンポーネント |
-| ドキュメント | 5 | README、既存ドキュメント、コメント |
+| ソース | 優先度 | 視点 | 探索対象 |
+|--------|--------|------|----------|
+| routing/entry point | 1 | ユーザー価値 | URLパターン、APIエンドポイント、CLIコマンド |
+| テストファイル | 2 | ユーザー価値 | E2Eテスト、統合テスト（機能名で命名されていることが多い） |
+| ユーザー向けコンポーネント | 3 | ユーザー価値 | ページ、画面、主要UIコンポーネント |
+| モジュール構造 | 4 | 技術 | Service、Controller、Repository |
+| interface定義 | 5 | 技術 | public API、export関数、型定義 |
+| 依存グラフ | 6 | 技術 | import/export関係、DI設定 |
+| ディレクトリ構造 | 7 | 両方 | 機能ベースディレクトリ、ドメインディレクトリ |
+| データフロー | 8 | 技術 | データ変換、状態管理 |
+| ドキュメント | 9 | 両方 | README、既存ドキュメント、コメント |
+| infrastructure | 10 | 技術 | データベーススキーマ、外部サービス統合 |
 
 ### 実行ステップ
 
-1. **entry point分析**
-   - routingファイルを特定
-   - URL/endpointを機能名にマッピング
-   - public API entry pointを特定
+1. **エントリーポイント分析**
+   - routingファイルを特定し、URL/エンドポイントを機能名にマッピング
+   - public APIエントリーポイントを特定
+   - `existing_prd`提供時はPRDを読み込み、PRD機能をコード領域にマッピング
 
-2. **ユーザー価値単位の識別**
-   - 関連endpoint/ページをユーザージャーニーでグループ化
+2. **ユーザー価値ユニットの識別**
+   - 関連エンドポイント/ページをユーザージャーニーでグループ化
    - 自己完結型の機能セットを特定
    - feature flagや設定を探索
 
-3. **境界検証**
+3. **技術的境界検出**
+   - 各候補ユニットについて:
+     - publicエントリーポイント（export、publicメソッド）を特定
+     - 後方依存関係をトレース（何がこれを呼び出すか？）
+     - 前方依存関係をトレース（これは何を呼び出すか？）
+   - モジュール/サービス境界をマッピング
+   - interfaceコントラクトを特定
+
+4. **機能ユニットへの統合**
+   - ユーザー価値グループと技術的境界を機能ユニットに統合
+   - 各ユニットは一貫した機能と特定可能な技術スコープを持つこと
+   - 粒度基準（後述）を適用
+
+5. **境界検証**
    - 各ユニットが明確なユーザー価値を提供することを確認
    - ユニット間の重複が最小限であることを確認
-   - 共有依存関係を特定
+   - 共有依存関係と横断的関心事を特定
 
-4. **飽和チェック**
-   - 連続3つの新規ソースで新規ユニットが発見されない場合に発見を停止
+6. **飽和チェック**
+   - 発見ソーステーブルの連続3種のソースタイプを探索しても新規ユニットが発見されない場合に発見を停止
    - 出力で発見が飽和したことをマーク
 
-## Design Docスコープ発見（scope_type: design-doc）
-
-### 前提条件
-
-- 既存PRDの提供が必須
-- PRDがユーザー価値スコープを定義
-
-### 発見ソース
-
-| ソース | 優先度 | 探索対象 |
-|--------|--------|----------|
-| モジュール構造 | 1 | Service、Controller、Repository |
-| interface定義 | 2 | public API、export関数、型定義 |
-| 依存グラフ | 3 | import/export関係、DI設定 |
-| データフロー | 4 | データ変換、状態管理 |
-| infrastructure | 5 | database schema、外部サービス統合 |
-
-### 実行ステップ
+## 粒度基準
 
-1. **PRDスコープマッピング**
-   - 提供されたPRDを読み込み
-   - 言及または暗示されているファイルパスを特定
-   - PRD要件をコード領域にマッピング
+発見された各ユニットは垂直スライス（implementation-approachスキル参照）で表現する — 関連する全レイヤーにまたがる一貫した機能単位。
 
-2. **interface境界検出**
-   - 各候補componentについて:
-     - public entry point（export、public method）を特定
-     - 後方依存関係をトレース（何がこれを呼び出すか？）
-     - 前方依存関係をトレース（これは何を呼び出すか？）
-   - component境界 = 関連ロジックを含む最小closure
+各ユニットが満たすべき条件:
+1. 明確なユーザー価値を提供する（ステークホルダーに機能として説明できる）
+2. 特定可能な技術的境界を持つ（エントリーポイント、interface、関連ファイル）
 
-3. **component検証**
-   - 単一責任の確認
-   - interface契約の明確性を確認
-   - 横断的関心事を特定
+**分割シグナル**（ユニットが粗すぎる可能性）:
+- 1つのユニット内に複数の独立したユーザージャーニーが存在
+- 共有状態のない複数の異なるデータドメイン
 
-4. **飽和チェック**
-   - 新規ソースで新規componentが発見されない場合に停止
-   - 発見が飽和したことをマーク
+**統合シグナル**（ユニットが細かすぎる可能性）:
+- ユニット間で関連ファイルの50%以上を共有
+- 一方のユニットが他方なしでは機能しない
+- 統合しても10ファイル以内
 
 ## 信頼度評価
 
@@ -156,9 +150,9 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 
 ```json
 {
-  "discoveryType": "prd|design-doc",
   "targetPath": "/path/to/project",
   "referenceArchitecture": "layered|mvc|clean|hexagonal|none",
+  "existingPrd": "パスまたはnull",
   "saturationReached": true,
   "discoveredUnits": [
     {
@@ -170,7 +164,13 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
       "sourceCount": 3,
       "entryPoints": ["/path1", "/path2"],
       "relatedFiles": ["src/feature/*"],
-      "dependencies": ["UNIT-002"]
+      "dependencies": ["UNIT-002"],
+      "technicalProfile": {
+        "primaryModules": ["src/<feature>/module-a.ts", "src/<feature>/module-b.ts"],
+        "publicInterfaces": ["ServiceA.operation()", "ModuleB.handle()"],
+        "dataFlowSummary": "入力元 → 主要処理経路 → 出力先",
+        "infrastructureDeps": ["外部依存リスト"]
+      }
     }
   ],
   "relationships": [
@@ -195,37 +195,26 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 
 追加フィールドを含む:
 - `evidenceSources[]`: 各ユニットの詳細evidence
-- `publicInterfaces[]`: interface signature（design-doc用）
 - `componentRelationships[]`: 詳細な依存関係情報
-- `sharedComponents[]`: 横断的component
+- `sharedComponents[]`: 横断的コンポーネント
 
 ## 完了条件
 
-### PRD発見の場合
-- [ ] routing/entry pointを分析
-- [ ] ユーザー向けcomponentを特定
+- [ ] routing/エントリーポイントを分析
+- [ ] ユーザー向けコンポーネントを特定
 - [ ] 機能構成のテスト構造をレビュー
-- [ ] 発見されたユニットをevidence sourceにマッピング
+- [ ] モジュール/サービス境界を特定
+- [ ] publicインターフェースをマッピング
+- [ ] 依存グラフを分析
+- [ ] 粒度基準を適用（必要に応じて分割/統合）
+- [ ] 発見されたユニットをevidenceソースにマッピング
 - [ ] 各ユニットのtriangulation強度を評価
 - [ ] ユニット間の関係性を文書化
 - [ ] 飽和に到達、または到達しなかった理由を文書化
 - [ ] 不確実な領域と制限事項を列挙
 
-### Design Doc発見の場合
-- [ ] 親PRDスコープを読み込み理解
-- [ ] interface境界検出を適用
-- [ ] module/service境界を特定
-- [ ] public interfaceをマッピング
-- [ ] 依存グラフを分析
-- [ ] 各componentのtriangulation強度を評価
-- [ ] component関係を文書化
-- [ ] 飽和に到達、または到達しなかった理由を文書化
-- [ ] 不確実な領域と制限事項を列挙
-
-## 禁止事項
+## 制約
 
-- PRDまたはDesign Docコンテンツの生成（スコープ外）
-- evidenceなしの仮定
-- 低信頼度の発見を無視（適切な信頼度で報告する）
-- 弱いtriangulationを注記せずに単一ソースに依存
-- 飽和チェックなしで発見を無限に継続
+- evidenceなしの仮定を行わない
+- 単一ソースに依存する場合は弱いtriangulationである旨を必ず注記する
+- 低信頼度の発見も適切な信頼度レベルで報告する（無視しない）

package/.claude/agents-ja/task-decomposer.md

@@ -79,7 +79,9 @@ implementation-approachスキルで決定された実装戦略パターンに基
 
 4. **タスクファイルの生成**
    - 命名規則: `{計画書名}-task-{番号}.md`
-   - 例: `20250122-refactor-types-task-01.md`
+   - レイヤー別命名（計画が複数レイヤーにまたがる場合）: `{計画書名}-backend-task-{番号}.md`, `{計画書名}-frontend-task-{番号}.md`
+   - レイヤーはタスクの対象ファイルパスから判定（technical-specスキルのプロジェクト構造定義を参照）
+   - 例: `20250122-refactor-types-task-01.md`, `20250122-auth-backend-task-01.md`, `20250122-auth-frontend-task-02.md`
    - **フェーズ完了タスクの自動生成（必須）**:
      - 作業計画書の「Phase X」表記を基準に、各フェーズ最終タスクの後に生成
      - ファイル名: `{計画書名}-phase{番号}-completion.md`

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

@@ -38,7 +38,7 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 - **要件分析結果**: 要件分析の結果（規模判定、技術要件等）
 - **PRD**: PRDドキュメント（作成されていれば）
 - **ADR**: ADRドキュメント（作成されていれば）
-- **Design Doc**: Design Docドキュメント（作成されていれば）
+- **Design Doc**: 単一または複数Design Docドキュメント（作成されていれば）
 - **テスト設計情報**（前工程から提供された場合は計画に反映）:
   - テスト定義ファイルパス
   - テストケース記述（it.todo形式等）
@@ -191,7 +191,7 @@ Design Docの統合ポイントごとの動作確認手順を、対応するフ
 
 ## 品質チェックリスト
 
-- [ ] Design Doc整合性確認
+- [ ] Design Doc（複数時は各Doc）の整合性確認
 - [ ] 技術的依存関係に基づくフェーズ構成
 - [ ] 全要件のタスク化
 - [ ] 最終フェーズに品質保証の存在

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

@@ -57,9 +57,9 @@ Invoke task-decomposer using Task tool:
 
 ## 🧠 Task Execution Flow
 Following "Autonomous Execution Task Management" in subagents-orchestration-guide skill, manage 4 steps with TodoWrite. Always include: first "Confirm skill constraints", final "Verify skill fidelity":
-1. task-executor execution
+1. task-executor execution (cross-layer: see Layer-Aware Agent Routing)
 2. Escalation judgment and follow-up
-3. quality-fixer execution
+3. quality-fixer execution (cross-layer: see Layer-Aware Agent Routing)
 4. git commit
 
 After approval confirmation, start autonomous execution mode. Stop immediately when requirement changes detected.

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

@@ -40,19 +40,19 @@ If the following are unclear, **ask with AskUserQuestion** before proceeding:
 Invoke rule-advisor using Task tool:
 - `subagent_type`: "rule-advisor"
 - `description`: "Identify problem essence"
-- `prompt`: "Identify the essence and required rules for this problem: [Problem reported by user]"
+- `prompt`: "Identify the essence and required skills for this problem: [Problem reported by user]"
 
 Confirm from rule-advisor output:
 - `taskAnalysis.mainFocus`: Primary focus of the problem
 - `mandatoryChecks.taskEssence`: Root problem beyond surface symptoms
-- `selectedRules`: Applicable rule sections
+- `selectedSkills`: Applicable skill sections
 - `warningPatterns`: Patterns to avoid
 
 ### 0.4 Reflecting in investigator Prompt
 
 **Include the following in investigator prompt**:
 1. Problem essence (taskEssence)
-2. Key applicable rules summary (from selectedRules)
+2. Key applicable skills summary (from selectedSkills)
 3. Investigation focus (investigationFocus): Convert warningPatterns to "points prone to confusion or oversight in this investigation"
 4. **For change failures, additionally include**:
    - Detailed analysis of the change content

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

@@ -26,18 +26,22 @@ When continuing existing flow, verify:
 - Current phase position (Requirements/Design/Planning/Implementation/QA)
 - Identify next step in subagents-orchestration-guide skill corresponding flow
 
-### 3. After requirement-analyzer [Stop]
+### 3. Design Phase
+
+When requirement-analyzer's `crossLayerScope` indicates cross-layer scope (backend + frontend), follow the Cross-Layer Orchestration section in subagents-orchestration-guide skill for Design Doc creation per layer.
+
+### 4. After requirement-analyzer [Stop]
 
 When user responds to questions:
 - If response matches any `scopeDependencies.question` → Check `impact` for scale change
 - If scale changes → Re-execute requirement-analyzer with updated context
 - If `confidence: "confirmed"` or no scale change → Proceed to next step
 
-### 4. After Scale Determination: Register All Flow Steps to TodoWrite (Required)
+### 5. After Scale Determination: Register All Flow Steps to TodoWrite (Required)
 
 After scale determination, **register all steps of the applicable subagents-orchestration-guide skill flow to TodoWrite**. Always include: first "Confirm skill constraints", final "Verify skill fidelity". After registration, proceed through the flow referencing TodoWrite.
 
-### 5. Execute Next Action
+### 6. Execute Next Action
 
 **Execute the next pending task in TodoWrite**.
 
@@ -63,9 +67,9 @@ Include the following at the end of prompts when invoking sub-agents, as rule-ad
 
 ### Task Execution Flow
 Following "Autonomous Execution Task Management" in subagents-orchestration-guide skill, manage these 4 steps with TodoWrite:
-1. task-executor execution
+1. task-executor execution (cross-layer: see Layer-Aware Agent Routing)
 2. Escalation judgment and follow-up
-3. quality-fixer execution
+3. quality-fixer execution (cross-layer: see Layer-Aware Agent Routing)
 4. git commit
 
 ### Test Information Communication