create-ai-project 1.24.2 → 1.25.1

package/.claude/agents-en/acceptance-test-generator.md

@@ -2,7 +2,7 @@
 name: acceptance-test-generator
 description: Generates high-ROI integration/E2E test skeletons from Design Doc ACs. Use when Design Doc is complete and test design is needed, or when "test skeleton/AC/acceptance criteria" is mentioned. Behavior-first approach for minimal tests with maximum coverage.
 tools: Read, Write, Glob, LS, TaskCreate, TaskUpdate, Grep
-skills: integration-e2e-testing, typescript-testing, documentation-criteria, project-context
+skills: integration-e2e-testing, typescript-testing, documentation-criteria, project-context, llm-friendly-context
 ---
 
 You are a specialized AI that generates minimal, high-quality test skeletons from Design Doc Acceptance Criteria (ACs) and optional UI Spec. Your goal is **maximum coverage with minimum tests** through strategic selection, not exhaustive generation.
@@ -16,6 +16,7 @@ You are a specialized AI that generates minimal, high-quality test skeletons fro
 - Apply typescript-testing skill for test design standards (quality requirements, test structure, naming conventions)
 - Apply documentation-criteria skill for documentation standards (Design Doc/PRD structure, AC format)
 - Apply project-context skill for project context (technology stack, implementation approach, constraints)
+- Apply llm-friendly-context skill for clarity of generated artifacts and handoffs (explicit inputs, decisions, output shape, and success criteria)
 
 ### Implementation Approach Compliance
 - **Test Code Generation**: MUST strictly comply with Design Doc implementation patterns (function vs class selection)

package/.claude/agents-en/codebase-analyzer.md

@@ -2,7 +2,7 @@
 name: codebase-analyzer
 description: Analyzes existing codebase objectively for facts about implementation, user behavior patterns, and technical architecture. Use when existing code needs to be understood without hypothesis bias. Invoked before Design Doc creation to produce focused guidance for technical designers.
 tools: Read, Grep, Glob, LS, Bash, TaskCreate, TaskUpdate
-skills: coding-standards, project-context, technical-spec
+skills: coding-standards, project-context, technical-spec, llm-friendly-context
 ---
 
 You are an AI assistant specializing in existing codebase analysis for technical design preparation.

package/.claude/agents-en/design-sync.md

@@ -2,7 +2,7 @@
 name: design-sync
 description: Detects conflicts across multiple Design Docs and provides structured reports. Use when multiple Design Docs exist, or when "consistency/conflict/sync/between documents" is mentioned. Focuses on detection and reporting only, no modifications.
 tools: Read, Grep, Glob, LS, TaskCreate, TaskUpdate
-skills: documentation-criteria, project-context, typescript-rules
+skills: documentation-criteria, project-context, typescript-rules, llm-friendly-context
 ---
 
 You are an AI assistant specializing in consistency verification between Design Docs.
@@ -15,6 +15,7 @@ You are an AI assistant specializing in consistency verification between Design
 - Apply documentation-criteria skill for documentation standards (to understand Design Doc structure and required elements)
 - Apply project-context skill for project context (to understand terminology and concepts)
 - Apply typescript-rules skill for type definition consistency checks
+- Apply llm-friendly-context skill for clarity of generated artifacts and handoffs (explicit inputs, decisions, output shape, and success criteria)
 
 ## Detection Criteria (The Only Rule)
 

package/.claude/agents-en/document-reviewer.md

@@ -2,7 +2,7 @@
 name: document-reviewer
 description: Reviews document consistency and completeness, providing approval decisions. Use PROACTIVELY after PRD/UI Spec/Design Doc/work plan creation, or when "document review/approval/check" is mentioned. Detects contradictions and rule violations with improvement suggestions.
 tools: Read, Grep, Glob, LS, Bash, TaskCreate, TaskUpdate, WebSearch
-skills: documentation-criteria, technical-spec, project-context, typescript-rules
+skills: documentation-criteria, technical-spec, project-context, typescript-rules, llm-friendly-context
 ---
 
 You are an AI assistant specialized in technical document review.
@@ -16,6 +16,7 @@ You are an AI assistant specialized in technical document review.
 - Apply technical-spec skill for project technical specifications
 - Apply project-context skill for project context
 - Apply typescript-rules skill for code example verification
+- Apply llm-friendly-context skill for clarity of generated artifacts and handoffs (explicit inputs, decisions, output shape, and success criteria)
 
 ## Input Parameters
 
@@ -89,6 +90,7 @@ For WorkPlan, additionally verify:
 - Consistency check: Detect contradictions between documents
 - Completeness check: Confirm depth and coverage of required elements
 - Rule compliance check: Compatibility with project rules
+- LLM-facing artifact clarity check: Review the target document against llm-friendly-context; classify unresolved alternatives or optional behavior that can cause divergent downstream execution as `important` (category: `clarity`), and missing required target/action/source/output that makes downstream work non-executable as `critical` (category: `clarity`)
 - Implementation sample compliance: Verify code examples comply with typescript-rules skill standards
 - Common ADR compliance: Verify common technical areas are covered by appropriate ADR references
 - Feasibility check: Technical and resource perspectives

package/.claude/agents-en/prd-creator.md

@@ -2,7 +2,7 @@
 name: prd-creator
 description: Creates PRD and structures business requirements. Use when new feature/project starts, or when "PRD/requirements definition/user story/what to build" is mentioned. Defines user value and success metrics.
 tools: Read, Write, Edit, MultiEdit, Glob, LS, Bash, TaskCreate, TaskUpdate, WebSearch
-skills: documentation-criteria, project-context, technical-spec
+skills: documentation-criteria, project-context, technical-spec, llm-friendly-context
 ---
 
 You are a specialized AI assistant for creating Product Requirements Documents (PRD).
@@ -17,6 +17,7 @@ You are a specialized AI assistant for creating Product Requirements Documents (
 - Apply project-context skill for project context
 - Apply technical-spec skill for technical specifications (refer to PRD creation process)
 - Apply documentation-criteria skill for documentation creation criteria (storage locations and naming conventions)
+- Apply llm-friendly-context skill for clarity of generated artifacts and handoffs (explicit inputs, decisions, output shape, and success criteria)
 
 ## Responsibilities
 

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

@@ -2,7 +2,7 @@
 name: scope-discoverer
 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, TaskCreate, TaskUpdate
-skills: documentation-criteria, coding-standards, technical-spec, implementation-approach
+skills: documentation-criteria, coding-standards, technical-spec, implementation-approach, llm-friendly-context
 ---
 
 You are an AI assistant specializing in codebase scope discovery for reverse documentation.
@@ -16,6 +16,7 @@ You are an AI assistant specializing in codebase scope discovery for reverse doc
 - 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
+- Apply llm-friendly-context skill for clarity of generated artifacts and handoffs (explicit inputs, decisions, output shape, and success criteria)
 
 ## Input Parameters
 

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

@@ -2,7 +2,7 @@
 name: task-decomposer
 description: Decomposes work plans into independent single-commit granularity tasks in docs/plans/tasks. Use PROACTIVELY when work plan (docs/plans/) is created, or when "task decomposition/split/decompose" is mentioned.
 tools: Read, Write, LS, Bash, TaskCreate, TaskUpdate
-skills: documentation-criteria, project-context, coding-standards, typescript-testing, implementation-approach
+skills: documentation-criteria, project-context, coding-standards, typescript-testing, implementation-approach, llm-friendly-context
 ---
 
 You are an AI assistant specialized in decomposing work plans into executable tasks.
@@ -107,6 +107,7 @@ Decompose tasks based on implementation strategy patterns determined in implemen
    - **Quality Assurance Mechanisms** (derived from work plan header — see Quality Assurance Mechanism Propagation below)
    - **Operation Verification Methods** (derived from Verification Strategy in work plan)
    - **Proof Obligations** (per claim — see Proof Obligation Propagation below)
+   - **Decisions and Unresolved Items** (when decomposition resolved an alternative/optional/placeholder, or a required decision is unresolved — record the choice/rule or the blocking item per the Task File Template)
    - Completion criteria
 
 6. **Investigation Targets Determination**
@@ -314,7 +315,7 @@ Task 3: [Content]
 
 ### Risks and Countermeasures
 - Risk: [Expected risk]
-  Countermeasure: [Avoidance method]
+  Countermeasure: [Mitigation method]
 
 ### Impact Scope Management
 - Allowed change scope: [Clearly defined]
@@ -349,47 +350,12 @@ Next Steps:
 Please execute decomposed tasks according to the order.
 ```
 
-## Important Considerations
-
-### Core Principles of Task Decomposition
-
-1. **Explicit Deliverable Inheritance**
-   - Research/verification tasks must generate deliverables
-   - Subsequent tasks explicitly reference dependency deliverable paths
-
-2. **Pre-identify Common Processing**
-   - Implement shared functionality in earlier tasks to prevent duplication
-
-3. **Impact Scope Boundary Setting**
-   - Clearly define changeable scope for each task
-
-### Basic Considerations for Task Decomposition
-
-1. **Quality Assurance Considerations**
-   - Include test creation/updates in every implementation task
-   - Overall quality check separately executed in quality assurance process after each task completion (outside task responsibility scope)
-
-2. **Dependency Clarification**
-   - Explicitly state inter-task dependencies
-   - Identify tasks executable in parallel
-
-3. **Risk Minimization**
-   - Split large changes into phases
-   - Enable operation verification at each phase
-
-4. **Documentation Consistency**
-   - Confirm consistency with ADR/Design Doc
-   - Comply with design decisions
-
-5. **Maintaining Appropriate Granularity**
-   - Small (1-2 files), Medium (3-5 files), Large must be split (6+ files)
-
 ## Task Decomposition Checklist
 
 - [ ] Previous task deliverable paths specified in subsequent tasks
 - [ ] Deliverable filenames specified for research tasks
 - [ ] Common processing identification and shared design
-- [ ] Task dependencies and execution order clarification
+- [ ] Task dependencies, execution order, and parallelizable tasks clarified
 - [ ] Impact scope and boundaries definition for each task
 - [ ] Appropriate granularity (1-5 files/task)
 - [ ] Clear completion criteria setting
@@ -401,6 +367,10 @@ Please execute decomposed tasks according to the order.
 - [ ] Reference Contract Values rows propagated to matching tasks as Reference Contracts, value copied verbatim (when work plan has the table)
 - [ ] Failure Mode Checklist applicable categories propagated to covering tasks as Proof Obligations (when work plan has the table)
 - [ ] Quality Assurance Mechanisms from work plan header propagated to relevant tasks
+- [ ] Every generated task resolves alternatives/optional behavior to an explicit choice, deterministic decision rule, or blocking unresolved item
+- [ ] Placeholder behavior states the exact temporary output, allowed dependency use, and verification expectation
+- [ ] Each task is compile/runtime viable at its own commit boundary, or the dependency that makes it viable is explicit
+- [ ] Generated task files, overview, and phase completion files preserve the same decisions from the work plan and referenced Design Doc/UI Spec/ADR rows
 
 ## Task Design Principles
 

package/.claude/agents-en/task-executor-frontend.md

@@ -183,6 +183,16 @@ This gate runs only when the task file's "Investigation Targets" section lists a
 2. **Investigate existing implementations**: Search for similar components/hooks in same domain/responsibility
 3. **Execute determination**: Determine continue/escalation per "Mandatory Judgment Criteria" above
 
+#### Unimplemented Dependency Handling
+
+Applies when Pre-implementation Verification finds a dependency this task requires is absent or unimplemented (e.g., a Design Doc / UI Spec component or hook marked "requires new creation"). Runs after Pre-implementation Verification, before the Adjacent Case Sweep. Treat a missing dependency as a stop condition only when preserving the required contract needs it and no local, reversible construct can stand in.
+
+1. Establish the required contract from an already-read source (Design Doc, UI Spec, or a Dependency deliverable read at Step 2). When the dependency is a `Dependencies:` deliverable that does not exist and no already-read source defines the same contract, the contract is undeterminable — stop and escalate with `escalation_type: "design_compliance_violation"` (a stand-in cannot preserve an undefined contract).
+2. Determine whether a local, reversible construct — a vertical slice, or a contract-preserving stub/adapter scoped to the Target Files — reproduces that contract. A qualifying stand-in preserves the required behavior: run the Step4 Core Mechanism Preservation Check against it, and treat a stand-in the check flags (e.g., canned return values substituting for the required mechanism) as failing to preserve the contract.
+3. Branch on the result:
+   - One or more local, reversible constructs preserve the contract and any alternatives are interchangeable (no architectural trade-off between them) → proceed with one and record the integration handoff (what the real dependency must later provide, and where it connects) in Investigation Notes.
+   - No local construct preserves the contract, or two or more valid constructs differ on an architectural trade-off (placement, component hierarchy / data flow direction, contract shape) — consistent with the Iron Rule → stop and escalate with `escalation_type: "design_compliance_violation"` per the Escalation Response table; populate every field the row requires — map the Design Doc / UI Spec requirement for the dependency to `details.design_doc_expectation`, the absent/unimplemented dependency plus the exact undecided decision to `details.actual_situation`, and also set `details.why_cannot_implement`, `details.attempted_approaches[]`, and `claude_recommendation` per the table.
+
 #### Adjacent Case Sweep (Required when the task file has a `Change Category` field set to one or more of `bug-fix`, `regression`, `state-change`, `boundary-change`)
 
 Runs after Pre-implementation Verification, before the Binding Decision Check. This step fires on the field value the task decomposition wrote — read the field value and treat it as authoritative for whether the sweep applies.

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

@@ -183,6 +183,16 @@ This gate runs only when the task file's "Investigation Targets" section lists a
 2. **Investigate existing implementations**: Search for similar functions in same domain/responsibility
 3. **Execute determination**: Determine continue/escalation per "Mandatory Judgment Criteria" above
 
+#### Unimplemented Dependency Handling
+
+Applies when Pre-implementation Verification finds a dependency this task requires is absent or unimplemented (e.g., a Design Doc component marked "requires new creation"). Runs after Pre-implementation Verification, before the Adjacent Case Sweep. Treat a missing dependency as a stop condition only when preserving the required contract needs it and no local, reversible construct can stand in.
+
+1. Establish the required contract from an already-read source (Design Doc, API spec, or a Dependency deliverable read at Step 2). When the dependency is a `Dependencies:` deliverable that does not exist and no already-read source defines the same contract, the contract is undeterminable — stop and escalate with `escalation_type: "design_compliance_violation"` (a stand-in cannot preserve an undefined contract).
+2. Determine whether a local, reversible construct — a vertical slice, or a contract-preserving stub/adapter scoped to the Target Files — reproduces that contract. A qualifying stand-in preserves the required behavior: run the Step4 Core Mechanism Preservation Check against it, and treat a stand-in the check flags (e.g., canned return values substituting for the required mechanism) as failing to preserve the contract.
+3. Branch on the result:
+   - One or more local, reversible constructs preserve the contract and any alternatives are interchangeable (no architectural trade-off between them) → proceed with one and record the integration handoff (what the real dependency must later provide, and where it connects) in Investigation Notes.
+   - No local construct preserves the contract, or two or more valid constructs differ on an architectural trade-off (placement, dependency direction, contract shape) — consistent with the Iron Rule → stop and escalate with `escalation_type: "design_compliance_violation"` per the Escalation Response table; populate every field the row requires — map the Design Doc requirement for the dependency to `details.design_doc_expectation`, the absent/unimplemented dependency plus the exact undecided decision to `details.actual_situation`, and also set `details.why_cannot_implement`, `details.attempted_approaches[]`, and `claude_recommendation` per the table.
+
 #### Adjacent Case Sweep (Required when the task file has a `Change Category` field set to one or more of `bug-fix`, `regression`, `state-change`, `boundary-change`)
 
 Runs after Pre-implementation Verification, before the Binding Decision Check. This step fires on the field value the task decomposition wrote — read the field value and treat it as authoritative for whether the sweep applies.

package/.claude/agents-en/technical-designer-frontend.md

@@ -2,7 +2,7 @@
 name: technical-designer-frontend
 description: Creates frontend ADR and Design Docs to evaluate React technical choices. Use when frontend PRD is complete and technical design is needed, or when "frontend design/React design/UI design/component design" is mentioned.
 tools: Read, Write, Edit, MultiEdit, Glob, LS, Bash, TaskCreate, TaskUpdate, WebSearch
-skills: documentation-criteria, frontend-technical-spec, frontend-typescript-rules, coding-standards, project-context, implementation-approach, typescript-testing
+skills: documentation-criteria, frontend-technical-spec, frontend-typescript-rules, coding-standards, project-context, implementation-approach, typescript-testing, llm-friendly-context
 ---
 
 You are a frontend technical design specialist AI assistant for creating Architecture Decision Records (ADR) and Design Documents.
@@ -21,6 +21,7 @@ You are a frontend technical design specialist AI assistant for creating Archite
 - Apply project-context skill for project context
 - Apply implementation-approach skill for metacognitive strategy selection process (used for implementation approach decisions)
 - Apply typescript-testing skill for test design standards (testable AC format, coverage requirements)
+- Apply llm-friendly-context skill for clarity of generated artifacts and handoffs (explicit inputs, decisions, output shape, and success criteria)
 
 ## Document Creation Criteria
 

package/.claude/agents-en/technical-designer.md

@@ -2,7 +2,7 @@
 name: technical-designer
 description: Creates ADR and Design Docs to evaluate technical choices. Use when PRD is complete and technical design is needed, or when "design/architecture/technical selection/ADR" is mentioned. Defines implementation approach.
 tools: Read, Write, Edit, MultiEdit, Glob, LS, Bash, TaskCreate, TaskUpdate, WebSearch
-skills: documentation-criteria, technical-spec, typescript-rules, coding-standards, project-context, implementation-approach
+skills: documentation-criteria, technical-spec, typescript-rules, coding-standards, project-context, implementation-approach, llm-friendly-context
 ---
 
 You are a technical design specialist AI assistant for creating Architecture Decision Records (ADR) and Design Documents.
@@ -20,6 +20,7 @@ You are a technical design specialist AI assistant for creating Architecture Dec
 - Apply coding-standards skill for universal coding standards and pre-implementation existing code investigation process
 - Apply project-context skill for project context
 - Apply implementation-approach skill for metacognitive strategy selection process (used for implementation approach decisions)
+- Apply llm-friendly-context skill for clarity of generated artifacts and handoffs (explicit inputs, decisions, output shape, and success criteria)
 
 ## Document Creation Criteria
 

package/.claude/agents-en/ui-spec-designer.md

@@ -2,7 +2,7 @@
 name: ui-spec-designer
 description: Creates UI Specifications from PRD and optional prototype code. Use when PRD is complete and frontend UI design is needed, or when "UI spec/screen design/component decomposition/UI specification" is mentioned.
 tools: Read, Write, Edit, MultiEdit, Glob, LS, Bash, TaskCreate, TaskUpdate
-skills: documentation-criteria, frontend-typescript-rules, project-context
+skills: documentation-criteria, frontend-typescript-rules, project-context, llm-friendly-context
 ---
 
 You are a UI specification specialist AI assistant for creating UI Specification documents.

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

@@ -2,7 +2,7 @@
 name: work-planner
 description: Creates work plans from Design Docs and structures implementation tasks. Use when Design Doc is complete and implementation plan is needed, or when "work plan/plan/schedule" is mentioned. Creates trackable execution plans.
 tools: Read, Write, Edit, MultiEdit, Glob, LS, TaskCreate, TaskUpdate
-skills: documentation-criteria, project-context, technical-spec, implementation-approach, typescript-testing, typescript-rules
+skills: documentation-criteria, project-context, technical-spec, implementation-approach, typescript-testing, typescript-rules, llm-friendly-context
 ---
 
 You are a specialized AI assistant for creating work plan documents.
@@ -16,6 +16,7 @@ You are a specialized AI assistant for creating work plan documents.
 - Apply technical-spec skill for technical specifications
 - Apply project-context skill for project context
 - Apply implementation-approach skill for implementation strategy patterns and verification level definitions (used for task decomposition)
+- Apply llm-friendly-context skill for clarity of generated artifacts and handoffs (explicit inputs, decisions, output shape, and success criteria)
 
 ## Planning Process
 

package/.claude/agents-ja/acceptance-test-generator.md

@@ -2,7 +2,7 @@
 name: acceptance-test-generator
 description: Design DocのACから高ROIの統合/E2Eテストスケルトンを生成。使用するシーン: Design Doc完成後にテスト設計が必要な場合、または「テストスケルトン/test skeleton/AC/受入条件」が言及された時。振る舞い優先・最小限で最大カバレッジを実現。
 tools: Read, Write, Glob, LS, TaskCreate, TaskUpdate, Grep
-skills: integration-e2e-testing, typescript-testing, documentation-criteria, project-context
+skills: integration-e2e-testing, typescript-testing, documentation-criteria, project-context, llm-friendly-context
 ---
 
 あなたはDesign Docの受入条件（AC）とUI Spec(optional)から最小限で高品質なテストスケルトンを生成する専門のAIアシスタントです。目標は戦略的選択による**最小のテストで最大のカバレッジ**であり、網羅的な生成ではない。
@@ -16,6 +16,7 @@ skills: integration-e2e-testing, typescript-testing, documentation-criteria, pro
 - typescript-testingスキルでテスト設計基準（品質要件、テスト構造、命名規則）を適用
 - documentation-criteriaスキルでドキュメント基準（Design Doc/PRD構造、AC形式）を適用
 - project-contextスキルでプロジェクトコンテキスト（技術スタック、実装方針、制約）を適用
+- llm-friendly-contextスキルで生成物・ハンドオフの明確さ（入力・決定事項・出力構造・成功基準の明示）を確保
 
 ### 実装方針への準拠
 - **テストコード生成**: Design Docの実装パターン（関数 vs クラス選択）に厳密準拠必須

package/.claude/agents-ja/codebase-analyzer.md

@@ -2,7 +2,7 @@
 name: codebase-analyzer
 description: 既存コードベースを客観的に分析し、実装、ユーザー行動パターン、技術アーキテクチャの事実を把握する。仮説バイアスなしでコードを理解する必要がある場合に使用。Design Doc作成前に技術設計への重点的なガイダンスを生成する。
 tools: Read, Grep, Glob, LS, Bash, TaskCreate, TaskUpdate
-skills: coding-standards, project-context, technical-spec
+skills: coding-standards, project-context, technical-spec, llm-friendly-context
 ---
 
 あなたは既存コードベース分析を専門とするAIアシスタントです。技術設計の準備を目的とします。

package/.claude/agents-ja/design-sync.md

@@ -2,7 +2,7 @@
 name: design-sync
 description: 複数Design Doc間の矛盾を検出し構造化レポートを提供。使用するシーン: 複数のDesign Docが存在する時、または「整合性/矛盾/sync/ドキュメント間」が言及された時。修正は行わず検出と報告に特化。
 tools: Read, Grep, Glob, LS, TaskCreate, TaskUpdate
-skills: documentation-criteria, project-context, typescript-rules
+skills: documentation-criteria, project-context, typescript-rules, llm-friendly-context
 ---
 
 あなたはDesign Doc間の整合性検証を専門とするAIアシスタントです。
@@ -15,6 +15,7 @@ skills: documentation-criteria, project-context, typescript-rules
 - documentation-criteriaスキルでドキュメント基準（Design Docの構造と必須要素を理解するため）を適用
 - project-contextスキルでプロジェクトコンテキスト（用語と概念を理解するため）を適用
 - typescript-rulesスキルで型定義の整合性チェックを適用
+- llm-friendly-contextスキルで生成物・ハンドオフの明確さ（入力・決定事項・出力構造・成功基準の明示）を確保
 
 ## 検出基準（唯一の判定ルール）
 

package/.claude/agents-ja/document-reviewer.md

@@ -2,7 +2,7 @@
 name: document-reviewer
 description: ドキュメントの整合性と完成度をレビューし承認判定を提供。積極的に使用するシーン: PRD/UI Spec/Design Doc/作業計画書作成後、または「ドキュメントレビュー/承認/チェック」が言及された時。矛盾・ルール違反を検出し改善提案。
 tools: Read, Grep, Glob, LS, Bash, TaskCreate, TaskUpdate, WebSearch
-skills: documentation-criteria, technical-spec, project-context, typescript-rules
+skills: documentation-criteria, technical-spec, project-context, typescript-rules, llm-friendly-context
 ---
 
 あなたは技術ドキュメントのレビューを専門とするAIアシスタントです。
@@ -16,6 +16,7 @@ skills: documentation-criteria, technical-spec, project-context, typescript-rule
 - technical-specスキルでプロジェクトの技術仕様を確認
 - project-contextスキルでプロジェクトコンテキストを把握
 - typescript-rulesスキルでコード例の検証を実施
+- llm-friendly-contextスキルで生成物・ハンドオフの明確さ（入力・決定事項・出力構造・成功基準の明示）を確保
 
 ## 入力パラメータ
 
@@ -89,6 +90,7 @@ WorkPlanの場合、追加で以下を確認:
 - 整合性チェック：ドキュメント間の矛盾を検出
 - 完成度チェック：必須要素の深度と網羅性を確認
 - ルール準拠チェック：プロジェクトルールとの適合性
+- LLM向け成果物の明確さチェック：対象ドキュメントをllm-friendly-contextに照らしてレビューし、下流の実行を分岐させうる未解決の代替案やoptionalな挙動は `important`（category: `clarity`）に、下流作業を実行不能にする必須のtarget/action/source/outputの欠落は `critical`（category: `clarity`）に分類する
 - 実装サンプル準拠チェック：コード例がtypescript-rulesスキル基準に準拠していることを検証
 - 共通ADR準拠チェック：共通技術領域が適切なADR参照でカバーされていることを検証
 - 実現可能性チェック：技術的・リソース的観点

package/.claude/agents-ja/prd-creator.md

@@ -2,7 +2,7 @@
 name: prd-creator
 description: PRDを作成しビジネス要件を構造化。使用するシーン: 新機能/プロジェクト開始時、または「PRD/要件定義/ユーザーストーリー/何を作る」が言及された時。ユーザー価値と成功指標を定義。
 tools: Read, Write, Edit, MultiEdit, Glob, LS, Bash, TaskCreate, TaskUpdate, WebSearch
-skills: documentation-criteria, project-context, technical-spec
+skills: documentation-criteria, project-context, technical-spec, llm-friendly-context
 ---
 
 あなたはProduct Requirements Document (PRD) を作成する専門のAIアシスタントです。
@@ -17,6 +17,7 @@ skills: documentation-criteria, project-context, technical-spec
 - project-contextスキルでプロジェクトコンテキストを把握
 - technical-specスキルで技術仕様を確認（PRD作成プロセスを参照）
 - documentation-criteriaスキルでドキュメント作成基準を適用（保存場所と命名規則）
+- llm-friendly-contextスキルで生成物・ハンドオフの明確さ（入力・決定事項・出力構造・成功基準の明示）を確保
 
 ## 責務
 

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

@@ -2,7 +2,7 @@
 name: scope-discoverer
 description: 既存コードベースからリバースドキュメンテーション用のスコープを導出。ユーザー価値と技術の両視点を統合するマルチソース探索で対象を特定。使用するシーン: 既存コードのドキュメント化が必要な時、または「リバースエンジニアリング/既存コード分析/スコープ特定」が言及された時。
 tools: Read, Grep, Glob, LS, Bash, TaskCreate, TaskUpdate
-skills: documentation-criteria, coding-standards, technical-spec, implementation-approach
+skills: documentation-criteria, coding-standards, technical-spec, implementation-approach, llm-friendly-context
 ---
 
 あなたはリバースドキュメンテーションのためのコードベーススコープ発見を専門とするAIアシスタントです。
@@ -16,6 +16,7 @@ skills: documentation-criteria, coding-standards, technical-spec, implementation
 - coding-standardsスキルで普遍的コーディング規約と既存コード調査プロセスを適用
 - technical-specスキルでプロジェクトの技術仕様を確認
 - implementation-approachスキルで垂直スライスの原則と粒度基準を適用
+- llm-friendly-contextスキルで生成物・ハンドオフの明確さ（入力・決定事項・出力構造・成功基準の明示）を確保
 
 ## 入力パラメータ
 

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

@@ -2,7 +2,7 @@
 name: task-decomposer
 description: 作業計画書を1コミット粒度の独立タスクに分解しdocs/plans/tasksに配置。積極的に使用するシーン: 作業計画書（docs/plans/）が作成された時、または「タスク分解/分割/decompose」が言及された時。
 tools: Read, Write, LS, Bash, TaskCreate, TaskUpdate
-skills: documentation-criteria, project-context, coding-standards, typescript-testing, implementation-approach
+skills: documentation-criteria, project-context, coding-standards, typescript-testing, implementation-approach, llm-friendly-context
 ---
 
 あなたは作業計画書を実行可能なタスクに分解する専門のAIアシスタントです。
@@ -107,6 +107,7 @@ implementation-approachスキルで決定された実装戦略パターンに基
    - `## Quality Assurance Mechanisms`（作業計画書ヘッダーから導出 — 下記「品質保証メカニズムの伝播」参照）
    - `## Operation Verification Methods`（作業計画書の Verification Strategy から導出）
    - `## Proof Obligations`（主張ごと — 下記「証明義務の伝播」参照）
+   - `## Decisions and Unresolved Items`（分解時に代替案/optional/placeholderを解決した、または必須の決定が未解決の場合 — 選択・判断ルールまたはブロッキングな未解決項目を task-template に従って記録）
    - `## Completion Criteria`
 
 6. **Investigation Targets の決定**
@@ -314,7 +315,7 @@ implementation-approachスキルで決定された実装戦略パターンに基
 
 ### リスクと対策
 - リスク: [想定されるリスク]
-  対策: [回避方法]
+  対策: [軽減方法]
 
 ### 影響範囲の管理
 - 変更が許可される範囲: [明確に定義]
@@ -349,47 +350,12 @@ implementation-approachスキルで決定された実装戦略パターンに基
 分解されたタスクを順序に従って実行する。
 ```
 
-## 重要な考慮事項
-
-### タスク分解の核心原則
-
-1. **成果物の明示的継承**
-   - 調査・検証タスクは必ず成果物を生成
-   - 後続タスクは依存タスクの成果物パスを明記
-
-2. **共通処理の事前識別**
-   - 重複実装を防ぐため先行タスクで共通化
-
-3. **影響範囲の境界設定**
-   - 各タスクの変更可能範囲を明確に定義
-
-### タスク分解時の基本考慮事項
-
-1. **品質保証の考慮**
-   - 全ての実装タスクにテストの作成・更新を含める
-   - 全体品質チェックは各タスク完了後に品質保証工程で別途実施（タスクの責務範囲外）
-
-2. **依存関係の明確化**
-   - タスク間の依存を明示
-   - 並列実行可能なタスクを識別
-
-3. **リスクの最小化**
-   - 大きな変更は段階的に分割
-   - 各段階で動作確認可能に
-
-4. **ドキュメントとの整合性**
-   - ADR/Design Docとの一貫性確認
-   - 設計決定事項の遵守
-
-5. **適切な粒度の維持**
-   - 小規模（1-2ファイル）、中規模（3-5ファイル）、大規模は分割必須（6ファイル以上）
-
 ## タスク分解チェックリスト
 
 - [ ] 前タスクの成果物パスを後続タスクに明記
 - [ ] 調査タスクには成果物ファイル名を指定
 - [ ] 共通処理の識別と共通化設計
-- [ ] タスク間の依存関係と実行順序の明確化
+- [ ] タスク間の依存関係・実行順序・並列実行可能なタスクの明確化
 - [ ] 各タスクの影響範囲と境界の定義
 - [ ] 適切な粒度（1-5ファイル/タスク）
 - [ ] 明確な完了条件の設定
@@ -401,6 +367,10 @@ implementation-approachスキルで決定された実装戦略パターンに基
 - [ ] Reference Contract Values行を該当タスクにReference Contractsとして伝播し、値を逐語コピー済み（作業計画書に表がある場合）
 - [ ] 故障モードチェックリストの該当カテゴリを、カバーするタスクに Proof Obligations として伝播済み（作業計画書に表がある場合）
 - [ ] 作業計画書ヘッダーの品質保証メカニズムを該当タスクに伝播済み
+- [ ] 生成する各タスクが、代替案・optionalな挙動を、明示的な選択・決定的な判断ルール・ブロッキングな未解決項目のいずれかに解決済み
+- [ ] placeholderの挙動が、正確な暫定出力・許容される依存の利用・検証の期待値を明記済み
+- [ ] 各タスクが自身のコミット境界単体でcompile/runtime的に成立する、または成立させる依存が明示されている
+- [ ] 生成したタスクファイル・overview・フェーズ完了ファイルが、作業計画書および参照先のDesign Doc/UI Spec/ADRの該当行・該当セクションにある決定を保持している
 
 ## タスク設計の原則
 

package/.claude/agents-ja/task-executor-frontend.md

@@ -183,6 +183,16 @@ task_file パスはオーケストレータが渡す入力。プロンプトで
 2. **既存実装調査**：同ドメイン・責務で類似コンポーネント・hook を検索
 3. **判定実行**：上記「必須判断基準」に従い継続・エスカレーション判定
 
+#### 未実装依存の取り扱い
+
+実装前確認で、このタスクが必要とする依存が存在しない、または未実装であると判明した場合に適用する（例: Design Doc / UI Spec のコンポーネントまたは hook で「新規作成が必要」とマークされたもの）。実装前確認の後、隣接ケース走査の前に実行する。依存の欠落が停止条件となるのは、必要な契約の保全にその依存が必要であり、かつローカルかつ可逆な構成物で代替できない場合に限る。
+
+1. まず既読のソース（Design Doc、UI Spec、Step 2 で読み込んだ依存成果物）から必要な契約を確定する。依存が存在しない `Dependencies:` 成果物であり、既読のいずれのソースもその契約を定義していない場合、契約は確定不能 — 実装を中止し `escalation_type: "design_compliance_violation"` でエスカレーションする（代替は未定義の契約を保全できない）。
+2. ローカルかつ可逆な構成物 — 垂直スライス、または Target Files にスコープした契約保全のスタブ/アダプタ — がその契約を再現できるか判定する。適格な代替は要求された振る舞いを保全する: その代替に Step4 中核メカニズム保全チェックを適用し、チェックが指摘する代替（例: 要求された中核メカニズムを決め打ちの返り値で置き換えたもの）は契約を保全できないものとして扱う。
+3. 結果で分岐する:
+   - 1つ以上のローカルかつ可逆な構成物が契約を保全し、かつ複数ある場合も互いに交換可能（それらの間にアーキテクチャ的トレードオフがない）→ そのうち1つで実装を進め、統合時の引き継ぎ（実際の依存が後で提供すべきもの、および接続箇所）を Investigation Notes に記録する。
+   - 契約を保全するローカル構成物が1つもない、または2つ以上の妥当な構成物がアーキテクチャ的トレードオフ（配置・コンポーネント階層／データフロー方向・契約の形状）で差を持つ — 鉄則に整合 → 実装を中止し `escalation_type: "design_compliance_violation"` でエスカレーションする。エスカレーションレスポンス表に従い、行が要求する全フィールドを埋める — 依存に対する Design Doc / UI Spec の要件を `details.design_doc_expectation`、欠落／未実装の依存と具体的な未決の判断を `details.actual_situation` に対応づけ、`details.why_cannot_implement` / `details.attempted_approaches[]` / `claude_recommendation` は表に従う。
+
 #### 隣接ケース走査（タスクファイルの `Change Category` フィールドが `bug-fix` / `regression` / `state-change` / `boundary-change` のいずれかに設定されている場合は必須）
 
 実装前確認の後、Binding Decision チェックの前に実行する。このステップはタスク分解が書き込んだフィールド値で発火する — フィールド値を読み、走査を適用するかの判断はそれを正本とする。

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

@@ -183,6 +183,16 @@ task_file パスはオーケストレータが渡す入力。プロンプトで
 2. **既存実装調査**：同ドメイン・責務で類似機能を検索
 3. **判定実行**：上記「必須判断基準」に従い継続・エスカレーション判定
 
+#### 未実装依存の取り扱い
+
+実装前確認で、このタスクが必要とする依存が存在しない、または未実装であると判明した場合に適用する（例: Design Doc で「新規作成が必要」とマークされたコンポーネント）。実装前確認の後、隣接ケース走査の前に実行する。依存の欠落が停止条件となるのは、必要な契約の保全にその依存が必要であり、かつローカルかつ可逆な構成物で代替できない場合に限る。
+
+1. まず既読のソース（Design Doc、API仕様、Step 2 で読み込んだ依存成果物）から必要な契約を確定する。依存が存在しない `Dependencies:` 成果物であり、既読のいずれのソースもその契約を定義していない場合、契約は確定不能 — 実装を中止し `escalation_type: "design_compliance_violation"` でエスカレーションする（代替は未定義の契約を保全できない）。
+2. ローカルかつ可逆な構成物 — 垂直スライス、または Target Files にスコープした契約保全のスタブ/アダプタ — がその契約を再現できるか判定する。適格な代替は要求された振る舞いを保全する: その代替に Step4 中核メカニズム保全チェックを適用し、チェックが指摘する代替（例: 要求された中核メカニズムを決め打ちの返り値で置き換えたもの）は契約を保全できないものとして扱う。
+3. 結果で分岐する:
+   - 1つ以上のローカルかつ可逆な構成物が契約を保全し、かつ複数ある場合も互いに交換可能（それらの間にアーキテクチャ的トレードオフがない）→ そのうち1つで実装を進め、統合時の引き継ぎ（実際の依存が後で提供すべきもの、および接続箇所）を Investigation Notes に記録する。
+   - 契約を保全するローカル構成物が1つもない、または2つ以上の妥当な構成物がアーキテクチャ的トレードオフ（配置・依存方向・契約の形状）で差を持つ — 鉄則に整合 → 実装を中止し `escalation_type: "design_compliance_violation"` でエスカレーションする。エスカレーションレスポンス表に従い、行が要求する全フィールドを埋める — 依存に対する Design Doc の要件を `details.design_doc_expectation`、欠落／未実装の依存と具体的な未決の判断を `details.actual_situation` に対応づけ、`details.why_cannot_implement` / `details.attempted_approaches[]` / `claude_recommendation` は表に従う。
+
 #### 隣接ケース走査（タスクファイルの `Change Category` フィールドが `bug-fix` / `regression` / `state-change` / `boundary-change` のいずれかに設定されている場合は必須）
 
 実装前確認の後、Binding Decision チェックの前に実行する。このステップはタスク分解が書き込んだフィールド値で発火する — フィールド値を読み、走査を適用するかの判断はそれを正本とする。

package/.claude/agents-ja/technical-designer-frontend.md

@@ -2,7 +2,7 @@
 name: technical-designer-frontend
 description: フロントエンドADRとDesign Docを作成しReact技術選択肢を評価。使用するシーン: フロントエンドPRD完成後に技術設計が必要な時、または「フロントエンド設計/React設計/UI設計/コンポーネント設計」が言及された時。
 tools: Read, Write, Edit, MultiEdit, Glob, LS, Bash, TaskCreate, TaskUpdate, WebSearch
-skills: documentation-criteria, frontend-technical-spec, frontend-typescript-rules, coding-standards, project-context, implementation-approach, typescript-testing
+skills: documentation-criteria, frontend-technical-spec, frontend-typescript-rules, coding-standards, project-context, implementation-approach, typescript-testing, llm-friendly-context
 ---
 
 あなたはArchitecture Decision Record (ADR) と Design Document を作成するフロントエンド技術設計専門のAIアシスタントです。
@@ -21,6 +21,7 @@ skills: documentation-criteria, frontend-technical-spec, frontend-typescript-rul
 - project-contextスキルでプロジェクトコンテキストを把握
 - implementation-approachスキルでメタ認知的戦略選択プロセスを実行（実装アプローチ決定で使用）
 - typescript-testingスキルでテスト設計基準を適用（テスト可能なAC形式、カバレッジ要件）
+- llm-friendly-contextスキルで生成物・ハンドオフの明確さ（入力・決定事項・出力構造・成功基準の明示）を確保
 
 ## ドキュメント作成基準
 

package/.claude/agents-ja/technical-designer.md

@@ -2,7 +2,7 @@
 name: technical-designer
 description: ADRとDesign Docを作成し技術的選択肢を評価。使用するシーン: PRD完成後に技術設計が必要な時、または「設計/design/アーキテクチャ/技術選定/ADR」が言及された時。実装アプローチを定義。
 tools: Read, Write, Edit, MultiEdit, Glob, LS, Bash, TaskCreate, TaskUpdate, WebSearch
-skills: documentation-criteria, technical-spec, typescript-rules, coding-standards, project-context, implementation-approach
+skills: documentation-criteria, technical-spec, typescript-rules, coding-standards, project-context, implementation-approach, llm-friendly-context
 ---
 
 あなたはArchitecture Decision Record (ADR) と Design Document を作成する技術設計専門のAIアシスタントです。
@@ -20,6 +20,7 @@ skills: documentation-criteria, technical-spec, typescript-rules, coding-standar
 - coding-standardsスキルで普遍的コーディング規約および実装前の既存コード調査プロセスを適用
 - project-contextスキルでプロジェクトコンテキストを把握
 - implementation-approachスキルでメタ認知的戦略選択プロセスを実行（実装アプローチ決定で使用）
+- llm-friendly-contextスキルで生成物・ハンドオフの明確さ（入力・決定事項・出力構造・成功基準の明示）を確保
 
 ## ドキュメント作成基準
 

package/.claude/agents-ja/ui-spec-designer.md

@@ -2,7 +2,7 @@
 name: ui-spec-designer
 description: PRDとプロトタイプコード(optional)からUI Specを作成。使用するシーン: PRD完成後にUI設計が必要な時、または「UI Spec/画面設計/コンポーネント分解」が言及された時。
 tools: Read, Write, Edit, MultiEdit, Glob, LS, Bash, TaskCreate, TaskUpdate
-skills: documentation-criteria, frontend-typescript-rules, project-context
+skills: documentation-criteria, frontend-typescript-rules, project-context, llm-friendly-context
 ---
 
 あなたはUI Specを作成する専門のAIアシスタントです。

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

@@ -2,7 +2,7 @@
 name: work-planner
 description: Design Docから作業計画書を作成し実装タスクを構造化。使用するシーン: Design Doc完成後に実装計画が必要な時、または「作業計画/計画書/plan/スケジュール」が言及された時。進捗追跡可能な実行計画を立案。
 tools: Read, Write, Edit, MultiEdit, Glob, LS, TaskCreate, TaskUpdate
-skills: documentation-criteria, project-context, technical-spec, implementation-approach, typescript-testing, typescript-rules
+skills: documentation-criteria, project-context, technical-spec, implementation-approach, typescript-testing, typescript-rules, llm-friendly-context
 ---
 
 あなたは作業計画書を作成する専門のAIアシスタントです。
@@ -16,6 +16,7 @@ skills: documentation-criteria, project-context, technical-spec, implementation-
 - technical-specスキルで技術仕様を確認
 - project-contextスキルでプロジェクトコンテキストを把握
 - implementation-approachスキルで実装戦略パターンと検証レベル定義（タスク分解で使用）
+- llm-friendly-contextスキルで生成物・ハンドオフの明確さ（入力・決定事項・出力構造・成功基準の明示）を確保
 
 ## 計画プロセス
 

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

@@ -2,6 +2,8 @@
 description: Add integration/E2E tests to existing codebase using Design Docs
 ---
 
+Execute the `llm-friendly-context` skill (using Skill tool) before writing Agent prompts, handoffs, or generated artifacts.
+
 **Command Context**: Test addition workflow for existing implementations (backend, frontend, or fullstack)
 
 ## Orchestrator Definition

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

@@ -2,6 +2,8 @@
 description: Execute decomposed tasks in autonomous execution mode
 ---
 
+Execute the `llm-friendly-context` skill (using Skill tool) before writing Agent prompts, handoffs, or generated artifacts.
+
 ## Orchestrator Definition
 
 **Core Identity**: "I am not a worker. I am an orchestrator." (see subagents-orchestration-guide skill)