create-ai-project 1.24.2 → 1.25.0

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/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/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)

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

@@ -2,6 +2,8 @@
 description: Execute from codebase analysis to design document creation
 ---
 
+Execute the `llm-friendly-context` skill (using Skill tool) before writing Agent prompts, handoffs, or generated artifacts.
+
 **Command Context**: This command is dedicated to the design phase.
 
 ## Orchestrator Definition

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

@@ -2,6 +2,8 @@
 description: Investigate problem, verify findings, and derive solutions
 ---
 
+Execute the `llm-friendly-context` skill (using Skill tool) before writing Agent prompts, handoffs, or generated artifacts.
+
 **Command Context**: Diagnosis flow to identify failure points and present solutions
 
 Target problem: $ARGUMENTS

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

@@ -2,6 +2,8 @@
 description: Execute frontend implementation 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 an orchestrator." (see subagents-orchestration-guide skill)

package/.claude/commands-en/front-design.md

@@ -2,6 +2,8 @@
 description: Execute from codebase analysis to frontend design document creation
 ---
 
+Execute the `llm-friendly-context` skill (using Skill tool) before writing Agent prompts, handoffs, or generated artifacts.
+
 **Command Context**: This command is dedicated to the frontend design phase.
 
 ## Orchestrator Definition

package/.claude/commands-en/front-plan.md

@@ -2,6 +2,8 @@
 description: Create frontend work plan from design document and obtain plan approval
 ---
 
+Execute the `llm-friendly-context` skill (using Skill tool) before writing Agent prompts, handoffs, or generated artifacts.
+
 **Command Context**: This command is dedicated to the frontend planning phase.
 
 ## Orchestrator Definition

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

@@ -2,6 +2,8 @@
 description: Design Doc compliance and security validation with optional auto-fixes
 ---
 
+Execute the `llm-friendly-context` skill (using Skill tool) before writing Agent prompts, handoffs, or generated artifacts.
+
 **Command Context**: Post-implementation quality assurance command for React/TypeScript frontend
 
 ## Orchestrator Definition

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

@@ -2,6 +2,8 @@
 description: Orchestrate the complete implementation lifecycle from requirements to deployment
 ---
 
+Execute the `llm-friendly-context` skill (using Skill tool) before writing Agent prompts, handoffs, or generated artifacts.
+
 **Command Context**: Full-cycle implementation management (Requirements Analysis → Design → Planning → Implementation → Quality Assurance)
 
 Strictly adhere to subagents-orchestration-guide skill and operate as an orchestrator — delegate all work through Agent tool, pass data between sub-agents, and report results (permitted tools: see subagents-orchestration-guide "Orchestrator's Permitted Tools").

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

@@ -2,6 +2,8 @@
 description: Create work plan from design document and obtain plan approval
 ---
 
+Execute the `llm-friendly-context` skill (using Skill tool) before writing Agent prompts, handoffs, or generated artifacts.
+
 **Command Context**: This command is dedicated to the planning phase.
 
 ## Orchestrator Definition

package/.claude/commands-en/prepare-implementation.md

@@ -2,6 +2,8 @@
 description: Verify implementation readiness and resolve gaps before the build phase begins
 ---
 
+Execute the `llm-friendly-context` skill (using Skill tool) before writing Agent prompts, handoffs, or generated artifacts.
+
 **Context**: Optional readiness phase between work-plan approval and the build/implement phase. Confirms the implementation will be observable from Phase 1 onward and resolves any gaps via Phase 0 tasks. Exits no-op when the readiness criteria already pass, so the recipe is safe to invoke unconditionally.
 
 ## Orchestrator Definition

package/.claude/commands-en/project-inject.md

@@ -2,6 +2,8 @@
 description: Populate project-context skill via template-driven hearing
 ---
 
+Execute the `llm-friendly-context` skill (using Skill tool) before writing Agent prompts, handoffs, or generated artifacts.
+
 **Command Context**: `/project-inject` collects project-specific prerequisites that improve AI execution accuracy and writes them into the `project-context` skill. The hearing is template-driven: the section catalog lives in `references/template.md`, and new dimensions are added by editing that template.
 
 ## Why This Matters

package/.claude/commands-en/reverse-engineer.md

@@ -2,6 +2,8 @@
 description: Generate PRD and Design Docs from existing codebase through discovery, generation, verification, and review workflow
 ---
 
+Execute the `llm-friendly-context` skill (using Skill tool) before writing Agent prompts, handoffs, or generated artifacts.
+
 **Command Context**: Reverse engineering workflow to create documentation from existing code
 
 Target: $ARGUMENTS

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

@@ -2,6 +2,8 @@
 description: Design Doc compliance and security validation with optional auto-fixes
 ---
 
+Execute the `llm-friendly-context` skill (using Skill tool) before writing Agent prompts, handoffs, or generated artifacts.
+
 **Command Context**: Post-implementation quality assurance command
 
 ## Execution Method

package/.claude/commands-en/update-doc.md

@@ -2,6 +2,8 @@
 description: Update existing design documents (Design Doc / PRD / ADR) with review
 ---
 
+Execute the `llm-friendly-context` skill (using Skill tool) before writing Agent prompts, handoffs, or generated artifacts.
+
 **Command Context**: This command is dedicated to updating existing design documents.
 
 ## Orchestrator Definition

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

@@ -2,6 +2,8 @@
 description: Design Docを使用して既存コードベースに統合/E2Eテストを追加
 ---
 
+Agentプロンプト・ハンドオフ・生成物を書く前に、`llm-friendly-context`スキル（Skillツール使用）を実行する。
+
 **コマンドコンテキスト**: 既存実装へのテスト追加ワークフロー（バックエンド、フロントエンド、フルスタック対応）
 
 ## オーケストレーター定義

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

@@ -2,6 +2,8 @@
 description: 分解済みタスクを自律実行モードで実装
 ---
 
+Agentプロンプト・ハンドオフ・生成物を書く前に、`llm-friendly-context`スキル（Skillツール使用）を実行する。
+
 ## オーケストレーター定義
 
 **コアアイデンティティ**: 「私は作業者ではない。オーケストレーターである。」（subagents-orchestration-guideスキル参照）

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

@@ -2,6 +2,8 @@
 description: コードベース分析から設計書作成まで実行
 ---
 
+Agentプロンプト・ハンドオフ・生成物を書く前に、`llm-friendly-context`スキル（Skillツール使用）を実行する。
+
 **コマンドコンテキスト**: このコマンドは設計フェーズ専用である。
 
 ## オーケストレーター定義

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

@@ -2,6 +2,8 @@
 description: 問題を調査し、検証を経て解決策を導出する
 ---
 
+Agentプロンプト・ハンドオフ・生成物を書く前に、`llm-friendly-context`スキル（Skillツール使用）を実行する。
+
 **コマンドコンテキスト**: 問題の障害点を特定し、解決策を提示するための診断フロー
 
 対象問題: $ARGUMENTS

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

@@ -2,6 +2,8 @@
 description: フロントエンド実装を自律実行モードで実行
 ---
 
+Agentプロンプト・ハンドオフ・生成物を書く前に、`llm-friendly-context`スキル（Skillツール使用）を実行する。
+
 ## オーケストレーター定義
 
 **コアアイデンティティ**: 「私はオーケストレーターである。」（subagents-orchestration-guideスキル参照）

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

@@ -2,6 +2,8 @@
 description: コードベース分析からフロントエンド設計ドキュメント作成まで実行
 ---
 
+Agentプロンプト・ハンドオフ・生成物を書く前に、`llm-friendly-context`スキル（Skillツール使用）を実行する。
+
 **コマンドコンテキスト**: このコマンドはフロントエンド設計フェーズ専用である。
 
 ## オーケストレーター定義

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

@@ -2,6 +2,8 @@
 description: 設計ドキュメントからフロントエンド作業計画書を作成し計画承認を取得
 ---
 
+Agentプロンプト・ハンドオフ・生成物を書く前に、`llm-friendly-context`スキル（Skillツール使用）を実行する。
+
 **コマンドコンテキスト**: このコマンドはフロントエンド計画フェーズ専用である。
 
 ## オーケストレーター定義

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

@@ -2,6 +2,8 @@
 description: Design Doc準拠検証とセキュリティ検証、必要に応じた自動修正
 ---
 
+Agentプロンプト・ハンドオフ・生成物を書く前に、`llm-friendly-context`スキル（Skillツール使用）を実行する。
+
 **コマンドコンテキスト**: React/TypeScriptフロントエンド向け実装後品質保証コマンド
 
 ## オーケストレーター定義

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

@@ -2,6 +2,8 @@
 description: オーケストレーターとして要件分析から実装まで完全サイクルを管理
 ---
 
+Agentプロンプト・ハンドオフ・生成物を書く前に、`llm-friendly-context`スキル（Skillツール使用）を実行する。
+
 **コマンドコンテキスト**: 実装の完全サイクル管理（要件分析→設計→計画→実装→品質保証）
 
 subagents-orchestration-guideスキルの指針に従い、オーケストレーターとして振る舞う。全作業をAgentツールでサブエージェントに委譲し、データを受け渡し、結果を報告する（許可ツール: subagents-orchestration-guideスキル「オーケストレーターの許可ツール」参照）。

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

@@ -2,6 +2,8 @@
 description: 設計書から作業計画書を作成し計画承認を取得
 ---
 
+Agentプロンプト・ハンドオフ・生成物を書く前に、`llm-friendly-context`スキル（Skillツール使用）を実行する。
+
 **コマンドコンテキスト**: このコマンドは計画フェーズ専用である。
 
 ## オーケストレーター定義

package/.claude/commands-ja/prepare-implementation.md

@@ -2,6 +2,8 @@
 description: 実装着手前に readiness を検証しギャップを解消する
 ---
 
+Agentプロンプト・ハンドオフ・生成物を書く前に、`llm-friendly-context`スキル（Skillツール使用）を実行する。
+
 **コンテキスト**: 作業計画承認と build/implement フェーズの間に挟む任意の readiness フェーズ。実装が Phase 1 から観測可能であることを確認し、ギャップがあれば Phase 0 タスクで解消する。readiness 基準が既に満たされている場合は no-op で終了するため、本レシピは無条件に呼び出しても安全。
 
 ## オーケストレーター定義

package/.claude/commands-ja/project-inject.md

@@ -2,6 +2,8 @@
 description: テンプレート駆動ヒアリングで project-context スキルを設定
 ---
 
+Agentプロンプト・ハンドオフ・生成物を書く前に、`llm-friendly-context`スキル（Skillツール使用）を実行する。
+
 **コマンドコンテキスト**: `/project-inject` は AI の実行精度を高めるプロジェクト固有の前提情報を収集し、`project-context` スキルに書き込む。ヒアリングはテンプレート駆動で、セクションカタログは `references/template.md` に格納されており、新しい次元を追加する場合はこのテンプレートを編集する。
 
 ## なぜ必要か

package/.claude/commands-ja/reverse-engineer.md

@@ -2,6 +2,8 @@
 description: 既存コードベースからPRDとDesign Docを生成するリバースエンジニアリングワークフロー
 ---
 
+Agentプロンプト・ハンドオフ・生成物を書く前に、`llm-friendly-context`スキル（Skillツール使用）を実行する。
+
 **コマンドコンテキスト**: 既存コードからドキュメントを作成するリバースエンジニアリングワークフロー
 
 対象: $ARGUMENTS

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

@@ -2,6 +2,8 @@
 description: Design Doc準拠検証とセキュリティ検証、必要に応じた自動修正
 ---
 
+Agentプロンプト・ハンドオフ・生成物を書く前に、`llm-friendly-context`スキル（Skillツール使用）を実行する。
+
 **コマンドコンテキスト**: 実装完了後の品質保証専用コマンド
 
 ## 実行方法

package/.claude/commands-ja/update-doc.md

@@ -2,6 +2,8 @@
 description: 既存設計ドキュメント（Design Doc / PRD / ADR）をレビュー付きで更新
 ---
 
+Agentプロンプト・ハンドオフ・生成物を書く前に、`llm-friendly-context`スキル（Skillツール使用）を実行する。
+
 **コマンドコンテキスト**: このコマンドは既存設計ドキュメントの更新専用である。
 
 ## オーケストレーター定義

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

@@ -42,6 +42,21 @@ Each row is a DD-derived observable contract the implementation in this task mus
 |---|---|---|---|
 | [Design Doc path (§ Section) copied from the matching work plan Reference Contract Values row] | [structure-order / derived-display / state-lifecycle-negative, copied from the work plan row] | [Required Observable Value copied verbatim from the work plan row] | [Y/N-answerable positive predicate that evaluates whether the planned/final implementation reproduces the value] |
 
+## Decisions and Unresolved Items
+(Include this section when task decomposition resolved an alternative, optional behavior, or placeholder, or when a required decision is unresolved at decomposition time. Omit when the task carries no such items.)
+
+Resolved decisions — each alternative, optional behavior, or placeholder the decomposition fixed to an explicit choice:
+
+| Item | Decision | Source / Rule |
+|---|---|---|
+| [the alternative, optional behavior, or placeholder] | [the selected choice or the deterministic rule that selects it; for a placeholder, the exact temporary output, allowed dependencies, and verification expectation] | [work plan / Design Doc / UI Spec / ADR section, or the basis of the decision rule] |
+
+Blocking unresolved items — decisions that cannot be made at decomposition time and block execution:
+
+| Item | Required Input | Escalation Condition |
+|---|---|---|
+| [the unresolved decision] | [the input needed to resolve it] | [who or what to escalate to, and the point at which the executor must stop rather than guess] |
+
 ## Investigation Notes
 (Implementation observations are appended here before implementation begins. When Binding Decisions exist, record the planned implementation approach and each Compliance Check result here.)
 
@@ -91,6 +106,7 @@ Each row is a DD-derived observable contract the implementation in this task mus
 - [ ] Deliverables created (for research/design tasks)
 - [ ] (When Binding Decisions exist) Every Compliance Check evaluates to `Y` against the final implementation, with evidence recorded in Investigation Notes (file:line, test result, or command output)
 - [ ] (When Reference Contracts exist) Every Reference Contract Compliance Check evaluates to `Y` against the final implementation, with evidence recorded in Investigation Notes
+- [ ] (When Decisions and Unresolved Items exist) Every resolved decision is applied as recorded, and no blocking unresolved item remains open — if one does, execution halts and is escalated per its Escalation Condition
 
 ## Notes
 - Impact scope: [Areas where changes may propagate]

package/.claude/skills-en/llm-friendly-context/SKILL.md

@@ -0,0 +1,80 @@
+---
+name: llm-friendly-context
+description: Clarifies inputs, outputs, success criteria, decisions, and unresolved conditions so downstream agents can execute without guessing. Use when writing or revising LLM-facing prompts, handoffs, planning artifacts, reviews, reports, or generated instructions.
+---
+
+# LLM-Friendly Context
+
+The goal is stable downstream execution: the next agent should know what to read, what to do, what counts as success, and when to stop or escalate.
+
+This skill governs the clarity of LLM-facing output — prompts, handoffs, and generated artifacts. It does not define which documents to create or their required structure; that is owned by documentation-criteria.
+
+## Core Rules
+
+1. **Use positive, executable instructions**
+   - State what the next agent should do.
+   - Convert quality policies into positive criteria.
+   - Example: "Preserve existing public API behavior across the documented compatibility cases."
+
+2. **Make vague instructions concrete**
+   - Replace subjective terms with observable conditions, paths, commands, schemas, examples, or decision rules.
+   - Terms that often need clarification when they leave a decision to the next agent: `appropriate`, `proper`, `related`, `existing behavior`, `optional`, `as needed`, `if needed`, `per convention`, unresolved alternatives, `TBD`, `placeholder`.
+
+3. **Specify output shape**
+   - Define required sections, fields, table columns, JSON keys, or checklist items.
+   - For handoffs, include paths to produced artifacts and the exact status fields the caller must inspect.
+
+4. **Provide necessary context**
+   - Include the purpose, source artifacts, hard constraints, accepted decisions, and unresolved conditions.
+   - Prefer concrete file paths and section hints over broad module names.
+
+5. **Decompose complex work into verifiable steps**
+   - Split work with 3+ objectives or sequential dependencies into ordered steps.
+   - Each step needs a checkpoint: what evidence proves it is complete.
+
+6. **Permit uncertainty explicitly**
+   - If the source material is missing, contradictory, or not verifiable, state the uncertainty and the required escalation.
+   - Record unknown business, product, security, or compatibility decisions as blocking unresolved items, each stating the required input to resolve it and the escalation condition.
+   - Write every blocking unresolved item in one consistent shape, regardless of artifact: `Unresolved: <decision needed> — required input: <what or who resolves it> — escalation: <the condition under which the next agent stops rather than guesses>`.
+
+7. **Keep constraints proportionate**
+   - Add only constraints that reduce ambiguity or preserve a real requirement.
+   - Keep simple downstream tasks lightweight when the target action, context, and success criteria are already clear.
+
+## Rewrite Patterns
+
+Use these rewrites before treating a prompt, handoff, or artifact as complete.
+
+| Ambiguous form | Rewrite as |
+|---|---|
+| `optional` used as an unresolved choice | Required, omitted, or required only under a named condition |
+| Multiple alternatives that the next agent must choose between | The selected option, or a deterministic decision rule |
+| `as needed` / `if needed` | The triggering condition and required action |
+| `per convention` | The file, function, test, or documented convention to follow |
+| `related files` | Specific paths, globs, or search hints |
+| `existing behavior` | The observable behavior, source file, test, API response, or UI state to preserve |
+| `placeholder` | Exact temporary value/behavior, allowed dependencies, and verification expectation |
+| `TBD` used as a placeholder for required information | A blocking unresolved item stating the required input and escalation condition (and owner when known) |
+| `appropriate` / `proper` | A measurable criterion or checklist |
+
+## Handoff Checklist
+
+Before sending a prompt or artifact to another agent, verify:
+
+- [ ] The target action is explicit.
+- [ ] Required input paths and source artifacts are named.
+- [ ] Accepted decisions and constraints are stated once, without alternate wording.
+- [ ] Output format or expected status fields are specified.
+- [ ] Success criteria are observable.
+- [ ] Ambiguous expressions have been rewritten or marked as unresolved.
+- [ ] The next agent can complete its scope with explicit choices, decision rules, or blocking unresolved items.
+
+## Generated Artifact Checklist
+
+Before writing or finalizing a generated document:
+
+- [ ] Each requirement, claim, task, test skeleton, or review finding has enough source context to trace why it exists.
+- [ ] Every executable instruction names the target, action, and expected result.
+- [ ] Verification steps say what to run or observe and what result proves success.
+- [ ] If an artifact is derived from another artifact, copied decisions stay consistent in wording and meaning.
+- [ ] If downstream work is blocked by missing information, the artifact records the missing input and escalation condition.

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

@@ -189,6 +189,21 @@ skills:
       - "9 Skill Editing Principles"
       - "References"
 
+  llm-friendly-context:
+    skill: "llm-friendly-context"
+    tags: [universal, cross-cutting, prompt, handoff, artifact, clarity, ambiguity-removal, downstream-execution, documentation]
+    typical-use: "Writing or revising LLM-facing prompts, handoffs, planning artifacts, reviews, reports, or generated instructions so downstream agents can execute without guessing"
+    size: small
+    key-references:
+      - "Positive, executable instructions over prohibitions"
+      - "Observable success criteria for agent handoffs"
+      - "Explicit unresolved items over silent ambiguity"
+    sections:
+      - "Core Rules"
+      - "Rewrite Patterns"
+      - "Handoff Checklist"
+      - "Generated Artifact Checklist"
+
   # Frontend-specific Skills
   frontend-typescript-rules:
     skill: "frontend-typescript-rules"

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

@@ -42,6 +42,21 @@ Metadata:
 |---|---|---|---|
 | [対応する作業計画書のReference Contract Values行からコピーしたDesign Docパス (§ セクション)] | [作業計画書の行からコピーしたContract Type: structure-order / derived-display / state-lifecycle-negative] | [作業計画書の行から逐語コピーしたRequired Observable Value] | [計画中/最終の実装が値を再現するかをY/Nで判定できる肯定述語] |
 
+## Decisions and Unresolved Items
+（タスク分解時に代替案・optionalな挙動・placeholderを解決した場合、または分解時点で必須の決定が未解決の場合に本セクションを記載する。該当項目がない場合は省略する。）
+
+解決済みの決定 — 分解が明示的な選択に確定した、各代替案・optionalな挙動・placeholder:
+
+| Item | Decision | Source / Rule |
+|---|---|---|
+| [代替案・optionalな挙動・placeholder] | [選択した選択肢、またはそれを選ぶ決定的な判断ルール。placeholderの場合は正確な暫定出力・許容される依存・検証の期待値] | [作業計画書 / Design Doc / UI Spec / ADR のセクション、または判断ルールの根拠] |
+
+ブロッキングな未解決項目 — 分解時点では決定できず実行をブロックする決定:
+
+| Item | Required Input | Escalation Condition |
+|---|---|---|
+| [未解決の決定] | [解決に必要な入力] | [誰/何にエスカレーションするか、および executor が推測せず停止すべき地点] |
+
 ## Investigation Notes
 （実装観察事項を実装開始前にここへ追記する。Binding Decisionsがある場合、計画した実装アプローチと各Compliance Check結果をここに記録する。）
 
@@ -91,6 +106,7 @@ Metadata:
 - [ ] 成果物作成完了（調査・設計タスクの場合）
 - [ ] （Binding Decisionsがある場合）全てのCompliance Checkが最終実装に対して`Y`と評価され、根拠（file:line、テスト結果、またはコマンド出力）がInvestigation Notesに記録されている
 - [ ] （Reference Contractsがある場合）全てのReference Contract Compliance Checkが最終実装に対して`Y`と評価され、根拠がInvestigation Notesに記録されている
+- [ ] （Decisions and Unresolved Itemsがある場合）解決済みの各決定が記録どおりに適用され、ブロッキングな未解決項目が未解決のまま残っていない — 残っている場合は実行を停止し、その Escalation Condition に従ってエスカレーションする
 
 ## Notes
 - 影響範囲: [変更が波及する可能性のある領域]

package/.claude/skills-ja/llm-friendly-context/SKILL.md

@@ -0,0 +1,80 @@
+---
+name: llm-friendly-context
+description: 入力・出力・成功基準・決定事項・未解決条件を明確化し、下流エージェントが推測せず実行できるようにする。LLM向けのプロンプト・ハンドオフ・計画成果物・レビュー・レポート・生成指示を記述または改訂する時に使用。
+---
+
+# LLM-Friendly Context
+
+目標は、下流が安定して実行できるようにすることである。次のエージェントが、何を読み、何をし、何をもって成功とし、いつ停止・エスカレーションするかを把握できる状態を目指す。
+
+本スキルはLLM向け出力（プロンプト、ハンドオフ、生成物）の明確さを扱う。どのドキュメントを作成するか、その必須構造が何かは定義しない。それはdocumentation-criteriaの責務である。
+
+## 中核ルール
+
+1. **肯定形で実行可能な指示を使う**
+   - 次のエージェントが何をすべきかを述べる。
+   - 品質ポリシーは肯定的な基準に変換する。
+   - 例: 「文書化された互換ケース全体で、既存の公開API挙動を維持する」
+
+2. **曖昧な指示を具体化する**
+   - 主観的な語を、観察可能な条件・パス・コマンド・スキーマ・例・判断ルールに置き換える。
+   - 次のエージェントに判断を委ねてしまい、明確化が必要になりやすい語: `appropriate`、`proper`、`related`、`existing behavior`、`optional`、`as needed`、`if needed`、`per convention`、未解決の代替案、`TBD`、`placeholder`。
+
+3. **出力構造を指定する**
+   - 必須のセクション・フィールド・表のカラム・JSONキー・チェックリスト項目を定義する。
+   - ハンドオフでは、生成した成果物のパスと、呼び出し側が確認すべき正確なステータスフィールドを含める。
+
+4. **必要なコンテキストを与える**
+   - 目的・出典となる成果物・厳格な制約・合意済みの決定・未解決条件を含める。
+   - 大まかなモジュール名より、具体的なファイルパスとセクションヒントを優先する。
+
+5. **複雑な作業を検証可能なステップに分解する**
+   - 目的が3つ以上、または逐次的な依存がある作業は、順序付きのステップに分割する。
+   - 各ステップには、完了を証明する根拠を示すチェックポイントを設ける。
+
+6. **不確実性を明示的に許可する**
+   - 出典が欠落・矛盾・検証不能な場合は、その不確実性と必要なエスカレーションを述べる。
+   - ビジネス・プロダクト・セキュリティ・互換性に関する未知の決定は、解決に必要な入力とエスカレーション条件を付したブロッキングな未解決項目として記録する。
+   - ブロッキングな未解決項目は、成果物を問わず一貫した形式で書く: `Unresolved: <必要な決定> — required input: <解決に必要な入力（必要なら確認先も）> — escalation: <次のエージェントが推測せず停止すべき条件>`。
+
+7. **制約を比例的に保つ**
+   - 曖昧さを減らす、または実在の要件を保つ制約のみを追加する。
+   - 対象アクション・コンテキスト・成功基準が既に明確な単純な下流タスクは、軽量なまま保つ。
+
+## 書き換えパターン
+
+プロンプト・ハンドオフ・成果物を完成とみなす前に、以下の書き換えを適用する。
+
+| 曖昧な形 | 書き換え後 |
+|---|---|
+| 未解決の選択として使われる `optional` | 必須・省略・特定条件下でのみ必須、のいずれか |
+| 次のエージェントが選ばねばならない複数の代替案 | 選択した選択肢、または決定的な判断ルール |
+| `as needed` / `if needed` | 発動条件と必要なアクション |
+| `per convention` | 従うべきファイル・関数・テスト・文書化された規約 |
+| `related files` | 具体的なパス・glob・サーチヒント |
+| `existing behavior` | 維持すべき観察可能な挙動・出典ファイル・テスト・APIレスポンス・UI状態 |
+| `placeholder` | 正確な暫定値/挙動・許容される依存・検証の期待値 |
+| 必須情報のプレースホルダとして使われる `TBD` | required inputとescalation conditionを付したブロッキングな未解決項目（判明していればownerも） |
+| `appropriate` / `proper` | 測定可能な基準またはチェックリスト |
+
+## ハンドオフチェックリスト
+
+プロンプトや成果物を別のエージェントに渡す前に確認する:
+
+- [ ] 対象アクションが明示されている。
+- [ ] 必須の入力パスと出典成果物が名指しされている。
+- [ ] 合意済みの決定と制約が、言い換えなしに一度だけ記載されている。
+- [ ] 出力形式または期待されるステータスフィールドが指定されている。
+- [ ] 成功基準が観察可能である。
+- [ ] 曖昧な表現が書き換え済み、または未解決として明示されている。
+- [ ] 次のエージェントが、明示的な選択・判断ルール・ブロッキングな未解決項目によって自身のスコープを完了できる。
+
+## 生成物チェックリスト
+
+生成ドキュメントを記述・確定する前に確認する:
+
+- [ ] 各要件・主張・タスク・テストスケルトン・レビュー所見が、なぜ存在するかを辿れるだけの出典コンテキストを持つ。
+- [ ] 実行可能な各指示が、対象・アクション・期待結果を名指ししている。
+- [ ] 検証ステップが、何を実行/観察するか、どの結果が成功を証明するかを述べている。
+- [ ] ある成果物が別の成果物から導出される場合、コピーした決定が文言と意味の両面で一貫している。
+- [ ] 下流作業が情報欠落でブロックされる場合、成果物が欠落している入力とエスカレーション条件を記録している。

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

@@ -180,6 +180,21 @@ skills:
       - "9つの編集原則"
       - "References"
 
+  llm-friendly-context:
+    skill: "llm-friendly-context"
+    tags: [universal, cross-cutting, prompt, handoff, artifact, clarity, ambiguity-removal, downstream-execution, documentation]
+    typical-use: "LLM向けのプロンプト・ハンドオフ・計画成果物・レビュー・レポート・生成指示を記述/改訂し、下流エージェントが推測せず実行できるようにする"
+    size: small
+    key-references:
+      - "禁止形より肯定形の実行可能な指示"
+      - "エージェント間ハンドオフの観察可能な成功基準"
+      - "暗黙の曖昧さより明示的な未解決項目"
+    sections:
+      - "中核ルール"
+      - "書き換えパターン"
+      - "ハンドオフチェックリスト"
+      - "生成物チェックリスト"
+
   # フロントエンド固有スキル
   frontend-typescript-rules:
     skill: "frontend-typescript-rules"

package/CHANGELOG.md

@@ -5,6 +5,12 @@ 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.25.0] - 2026-06-25
+
+### Added
+
+- **LLM-friendly context skill** (agents, skills, commands) — added the `llm-friendly-context` skill so prompts, handoffs, and generated artifacts state explicit inputs, output structure, success criteria, decisions, and blocking unresolved items, wired into the 11 artifact-producing agents and invoked by the 15 orchestrator commands before they construct Agent prompts, handoffs, or generated artifacts. `document-reviewer` gains an LLM-facing artifact clarity check (`clarity` category); `task-decomposer` gains self-checks for unresolved alternatives/optional behavior, placeholder output, commit-boundary viability, and decision preservation, and records resolved choices and blocking unresolved items in a new `Decisions and Unresolved Items` task-template section. The redundant task-decomposer recap section was trimmed losslessly. Applied across en/ja.
+
 ## [1.24.2] - 2026-06-23
 
 ### Added

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-ai-project",
-  "version": "1.24.2",
+  "version": "1.25.0",
   "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": [