create-ai-project 1.24.2 → 1.25.1

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,18 @@ 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.1] - 2026-06-29
+
+### Added
+
+- **Unimplemented-dependency handling** (agents) — `task-executor` / `-frontend` gain a rule for a dependency the task requires that is absent or unimplemented: it is a stop condition only when preserving the required contract needs it and no local, reversible construct (a vertical slice, or a contract-preserving stub/adapter scoped to the Target Files) can stand in. The required contract is established from an already-read source first — a missing `Dependencies:` deliverable whose contract no read source defines escalates as `design_compliance_violation`; one or more interchangeable constructs proceed with the integration handoff recorded in Investigation Notes; no viable construct, or constructs that differ on an architectural trade-off, escalate (reusing the existing escalation type, no new enum). Applied across en/ja.
+
+## [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/README.ja.md

@@ -183,6 +183,7 @@ Claude Codeで利用できる主要なコマンド
 | `frontend-typescript-rules` | Reactコンポーネント設計、Props駆動パターン |
 | `frontend-typescript-testing` | React Testing Library、MSW、Playwright E2E（fixture / service-integrationパターン） |
 | `frontend-technical-spec` | Reactアーキテクチャ、環境設定、データフロー |
+| `llm-friendly-context` | LLM向け出力（プロンプト、ハンドオフ、生成物）の明確さ |
 | `project-context` | AIの実行精度のためのプロジェクト前提情報（`/project-inject`で設定） |
 
 👉 [スキルの仕組みについて（Claude Code docs）](https://code.claude.com/docs/ja/skills)

package/README.md

@@ -183,6 +183,7 @@ This boilerplate provides the principles used in agentic implementation workflow
 | `frontend-typescript-rules` | React component design, Props-driven patterns |
 | `frontend-typescript-testing` | React Testing Library, MSW, Playwright E2E (fixture and service-integration patterns) |
 | `frontend-technical-spec` | React architecture, environment, data flow |
+| `llm-friendly-context` | Clarity of LLM-facing output — prompts, handoffs, and generated artifacts |
 | `project-context` | Project-specific prerequisites for AI accuracy (set via `/project-inject`) |
 
 👉 [Learn how Skills work (Claude Code docs)](https://code.claude.com/docs/en/skills)

package/package.json

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