create-ai-project 1.24.1 → 1.25.0

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 の決定**
@@ -159,9 +160,18 @@ implementation-approachスキルで決定された実装戦略パターンに基
 
 主張を実装する各タスクは Proof Obligations（task template参照）を持ち、下流のレビューがテストが主張を証明しているか（単に実行されるだけでないか）を判定できるようにする:
 
-1. **出所**: テストスケルトンがタスクをカバーしている場合、その「主要な故障モード」と「証明義務」の注釈をタスクの Proof Obligations に転記する。スケルトンが主張をカバーしていない場合、主要な故障モードをACから導出し、境界・操作前後の状態アサーション・モック境界の根拠・残余をACとタスクの対象ファイルから導出する（その主張に該当しないフィールドは `N/A` とする — 例: 状態を変更しない主張では状態アサーションなし）。
-2. **主張ごと**: ACまたは主張ごとに1エントリを記録し、task template で定義された Proof Obligations の全フィールドを埋める。
-3. **主張がある場合に適用**: 振る舞いの主張を持たないタスク（純粋な設定やスキャフォールディング等）は本セクションを省略する。
+1. **出所**: テストスケルトンがタスクをカバーしている場合、その「主要な故障モード」と「証明義務」の注釈をタスクの Proof Obligations に転記する。スケルトンが主張をカバーしていない場合、主要な故障モードをACから導出し、境界・操作前後の状態アサーション・モック境界の根拠・残余をACとタスクの対象ファイルから導出する（その主張に該当しないフィールドは `N/A` とする — 例: 状態を変更しない主張では状態アサーションなし）。このタスクにマッピングされた故障モードチェックリストのカテゴリも出所の一つである — 後述の「故障モード伝播」参照。
+2. **主張ごと**: AC・主張・マッピングされた故障モードカテゴリごとに1エントリを記録し、task template で定義された Proof Obligations の全フィールドを埋める。
+3. **主張がある場合に適用**: 振る舞いの主張も、マッピングされた故障モードチェックリストのカテゴリも持たないタスク（純粋な設定やスキャフォールディング等）は本セクションを省略する。
+
+## 故障モード伝播
+
+作業計画書に故障モードチェックリストが含まれる場合、該当する各カテゴリを、それがマッピングされるタスクに伝播する。これにより、故障モードは計画上の宣言にとどまらず、証明可能な義務として executor に届く:
+
+1. **タスクIDで照合**: 「該当?」列が yes と記された各チェックリスト行について、「カバーするタスク」列に記載されたタスクを特定する。
+2. **カテゴリごとに Proof Obligation を追加**: マッチした各タスクに、その `主要な故障モード` をそのカテゴリとする Proof Obligation を持たせ、タスクの対象に即して具体化する（例: `missing-sort-key ordering` → 「このタスクのリストで、ソートキーを持たない行が誤配置されるか非決定的に並び替わる」）。残りの Proof Obligations フィールドは上記「証明義務の伝播」に従いACと対象ファイルから埋める。そのカテゴリをカバーするACがない場合、`主張` をそのタスクが防ぐべき故障モード条件とし、`状態アサーション` はタスクが状態を変更しない限り `N/A` とする。
+3. **既存エントリへの統合**: AC由来の Proof Obligation が既にそのタスクの同じ故障モードをカバーしている場合、並行して追加せず単一エントリのまま保つ。
+4. **提供時のみ適用**: この伝播は、該当するカテゴリを持つ故障モードチェックリストが作業計画書に含まれる場合のみ実行する。
 
 ## UI Spec伝播
 
@@ -305,7 +315,7 @@ implementation-approachスキルで決定された実装戦略パターンに基
 
 ### リスクと対策
 - リスク: [想定されるリスク]
-  対策: [回避方法]
+  対策: [軽減方法]
 
 ### 影響範囲の管理
 - 変更が許可される範囲: [明確に定義]
@@ -340,47 +350,12 @@ implementation-approachスキルで決定された実装戦略パターンに基
 分解されたタスクを順序に従って実行する。
 ```
 
-## 重要な考慮事項
-
-### タスク分解の核心原則
-
-1. **成果物の明示的継承**
-   - 調査・検証タスクは必ず成果物を生成
-   - 後続タスクは依存タスクの成果物パスを明記
-
-2. **共通処理の事前識別**
-   - 重複実装を防ぐため先行タスクで共通化
-
-3. **影響範囲の境界設定**
-   - 各タスクの変更可能範囲を明確に定義
-
-### タスク分解時の基本考慮事項
-
-1. **品質保証の考慮**
-   - 全ての実装タスクにテストの作成・更新を含める
-   - 全体品質チェックは各タスク完了後に品質保証工程で別途実施（タスクの責務範囲外）
-
-2. **依存関係の明確化**
-   - タスク間の依存を明示
-   - 並列実行可能なタスクを識別
-
-3. **リスクの最小化**
-   - 大きな変更は段階的に分割
-   - 各段階で動作確認可能に
-
-4. **ドキュメントとの整合性**
-   - ADR/Design Docとの一貫性確認
-   - 設計決定事項の遵守
-
-5. **適切な粒度の維持**
-   - 小規模（1-2ファイル）、中規模（3-5ファイル）、大規模は分割必須（6ファイル以上）
-
 ## タスク分解チェックリスト
 
 - [ ] 前タスクの成果物パスを後続タスクに明記
 - [ ] 調査タスクには成果物ファイル名を指定
 - [ ] 共通処理の識別と共通化設計
-- [ ] タスク間の依存関係と実行順序の明確化
+- [ ] タスク間の依存関係・実行順序・並列実行可能なタスクの明確化
 - [ ] 各タスクの影響範囲と境界の定義
 - [ ] 適切な粒度（1-5ファイル/タスク）
 - [ ] 明確な完了条件の設定
@@ -390,7 +365,12 @@ implementation-approachスキルで決定された実装戦略パターンに基
 - [ ] 主張を実装する各タスクに Proof Obligations を記録（主要な故障モード + 検証する境界）
 - [ ] bug-fix / regression / state-change / boundary-change のタスクに Change Category を設定し、隣接する経路/境界のオーナーを Investigation Targets に追加済み
 - [ ] 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スキルで生成物・ハンドオフの明確さ（入力・決定事項・出力構造・成功基準の明示）を確保
 
 ## ドキュメント作成基準
 
@@ -349,7 +350,8 @@ UI Specが存在する場合（`docs/ui-spec/{feature-name}-ui-spec.md`）:
 
 1. **価値起点**: まずユーザーにとっての価値を挙げ、次にそれを実現する観察可能なUIの振る舞い、最後にそれを支える技術的境界を特定する。
 2. **境界への展開**（候補抽出 — 採否は下記のスコーピングルールが決定）: ある振る舞いはハッピーパスでは成立しつつ、別の状態で退行しうる。振る舞いを変えるACごとに、約束した振る舞いが成立すべき箇所すべてでACを検討する — 単一/最新/全件のリスト描画、隣接する Props やフィールド、ローディング/空/エラーおよび後続のインタラクション状態、stale または欠損データ、フェッチ失敗やフォールバックUI、権限/バリデーションのゲーティング、入力スコープと順序/選択、副作用、可視性やルートの境界（状態が別画面・別コンポーネント・ナビゲーション後に観察可能になる箇所）。
-3. **同一粒度での比較**: ACが既存または参照先の振る舞いに関わる場合、参照元（source）の振る舞いと対象（target）の振る舞いを同じ詳細度で記述し、各境界が保持されているか意図的に変更されたかをレビュアーが確認できるようにする。
+3. **mode × branch の組み合わせを展開**: 変更が既存の分岐（ソート・フィルタ・ビュー・表示）に重なる mode・トグル・バリアントを追加する場合、新しい値と各既存分岐の値との組み合わせを展開する — mode はある分岐では効きつつ、他の分岐では黙って no-op しうる。
+4. **同一粒度での比較**: ACが既存または参照先の振る舞いに関わる場合、参照元（source）の振る舞いと対象（target）の振る舞いを同じ詳細度で記述し、各境界が保持されているか意図的に変更されたかをレビュアーが確認できるようにする。
 
 ### 自律実装のためのACスコーピング（フロントエンド）
 

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スキルで生成物・ハンドオフの明確さ（入力・決定事項・出力構造・成功基準の明示）を確保
 
 ## ドキュメント作成基準
 
@@ -345,7 +346,8 @@ Design Doc作成時に必ず含める:
 
 1. **価値起点**: まずユーザー/オペレーター/保守者にとっての価値を挙げ、次にそれを実現する観測可能な振る舞い、最後にそれを支える技術的境界を特定する。
 2. **境界への展開**（候補抽出 — 採否は下記ルールが決定）: ある振る舞いはメインパスでは成立しつつ、別の次元で退行しうる。振る舞いを変えるACごとに、約束した振る舞いが成立すべき箇所すべてでACを検討する — 単一/最新/全件のコレクション、同一サーフェス上の隣接フィールド、後続のライフサイクル状態やリトライ、stale/欠損/空の値、リフレッシュ失敗やフォールバック不在、権限/バリデーション/ポリシーの境界、入力スコープと選択/順序/識別キー、副作用、公開・可視性の境界（状態が別プロセス・コンポーネント・ユーザー・後続ステップから観測可能になる箇所）。
-3. **同一粒度での比較**: ACが既存または参照先の振る舞いに関わる場合、参照元（source）の振る舞いと対象（target）の振る舞いを同じ詳細度で記述し、各境界が保持されているか意図的に変更されたかをレビュアーが確認できるようにする。
+3. **mode × branch の組み合わせを展開**: 変更が既存の分岐軸（選択・順序・フィルタリング・表示）に重なる mode・フラグ・バリアントを追加する場合、新しい値と各既存軸の値との組み合わせを展開する — mode はある分岐では効きつつ、他の分岐では黙って no-op しうる。
+4. **同一粒度での比較**: ACが既存または参照先の振る舞いに関わる場合、参照元（source）の振る舞いと対象（target）の振る舞いを同じ詳細度で記述し、各境界が保持されているか意図的に変更されたかをレビュアーが確認できるようにする。
 
 ### 測定可能なACの書き方
 

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スキルで生成物・ハンドオフの明確さ（入力・決定事項・出力構造・成功基準の明示）を確保
 
 ## 計画プロセス
 
@@ -38,9 +39,9 @@ Design Doc、UI Spec、PRD、ADR（提供されている場合）を読み込み
 **全アプローチ共通**:
 - **検証戦略の要約を作業計画書ヘッダーに記載**（後続タスクへの参照用）
 - **採用した品質保証メカニズムを作業計画書ヘッダーに記載**（後続タスクへの参照用） — 各メカニズムについてツール名、検証内容、設定パス、カバー範囲（Design Docのファイルパスまたはディレクトリプレフィックス、スコープが限定されない場合は "project-wide"）を記載
-- **証明戦略を作業計画書ヘッダーに記載**（plan template参照） — 証明義務の出所（スケルトンが提供される場合はテストスケルトンの注釈、なければ各ACの主要な故障モード）を明示し、振る舞いの主張を持つ各タスクが、下流のレビュー用に Proof Obligations を記録する旨を記載する
+- **証明戦略を作業計画書ヘッダーに記載**（plan template参照） — 証明義務の出所（スケルトンが提供される場合はテストスケルトンの注釈、なければ各ACの主要な故障モード、加えてタスクにマッピングされた該当する故障モードチェックリストのカテゴリ）を明示し、主張を実装する、または該当する故障モードチェックリストのカテゴリをカバーする各タスクが、下流のレビュー用に Proof Obligations を記録する旨を記載する
 - **レビュースコープを作業計画書ヘッダーに記録** — 実装前の新規計画では Design Doc とタスク対象ファイルから導出した変更予定ファイルの範囲、既存作業に対する改訂計画ではベースブランチと diff範囲を記録し、作業計画書レビューと下流検証が同一スコープを共有できるようにする
-- **故障モードチェックリストを作業計画書に含める**（plan template参照） — ドメイン非依存の8つの故障カテゴリ（same-value, no-op, empty input, invalid option, missing config, unavailable boundary, shared-state dependency, rollback-only visibility）をすべて列挙し、該当するものに印を付け、該当する各カテゴリをカバーするタスクにマッピングする。エントリにはプロジェクト固有の名称を含めない
+- **故障モードチェックリストを作業計画書に含める**（plan template参照） — ドメイン非依存の9つの故障カテゴリ（same-value, no-op, empty input, invalid option, missing config, unavailable boundary, shared-state dependency, rollback-only visibility, missing-sort-key ordering）をすべて列挙し、該当するものに印を付け、該当する各カテゴリをカバーするタスクにマッピングする。エントリにはプロジェクト固有の名称を含めない
 - 検証戦略の実行タイミングに対応するフェーズに検証タスクを配置
 - テストスケルトンが提供されている場合、統合テスト実装を対応するフェーズに配置し、E2Eテスト実行を最終フェーズに配置
 - テストスケルトンが提供されていない場合、Design DocのACに基づくテスト実装タスクを含める
@@ -92,7 +93,7 @@ service-integration-e2e gap:
 
 カバーするタスクがない項目はギャップステータスを`gap`とし、備考に理由を記載する。**トレーサビリティ表に`gap`が1件でも含まれる場合、計画書はドラフト状態とする。** ドラフトとして出力するが、ユーザーが各ギャップを確認するまで確定しない。理由なしのギャップ（備考が空）はエラーとして扱い、カバーするタスクを追加するか理由を記載してから進める。
 
-**拘束的観測値は逐語のまま転記する。** 拘束的観測値とは、列/ラベルの集合と順序（Contract Type は `structure-order`）、派生表示ルール（別フィールドから導出される表示値である `derived-display`）、または状態ライフサイクルの否定条件（状態が未使用のままでなければならない条件である `state-lifecycle-negative`）を指す。要約を経由すると正確な列/ラベルの順序や派生表示ルールが失われるため、これらは設計-計画トレーサビリティ表の要約されたDD項目からではなく、Design Docから直接特定する。各値はDesign Docから逐語でコピーして計画書の**Reference Contract Values**表（plan template参照）に記録し、値ごとに1行を、そのContract Typeトークンとともにカバーするタスクにマッピングする。値は全文を保持する。これにより、後続のタスクは要約を再構成するのではなく、この正確な値そのものと突き合わせて検証できる。本表が扱うのはDD由来の観測可能契約のみである。シリアライズ境界はConnection Map（ステップ5b）が、ADR由来の構造的決定はADR Bindings表が扱う。
+**拘束的観測値は逐語のまま転記する。** 拘束的観測値とは、列/ラベルの集合と順序（Contract Type は `structure-order`）、派生表示ルール（別フィールドから導出される表示値である `derived-display`）、または状態ライフサイクルの否定条件（状態が未使用のままでなければならない条件である `state-lifecycle-negative`）を指す。要約を経由すると正確な列/ラベルの順序や派生表示ルールが失われるため、これらは設計-計画トレーサビリティ表の要約されたDD項目からではなく、Design Docから直接特定する。各値はDesign Docから逐語でコピーして計画書の**Reference Contract Values**表（plan template参照）に記録し、値ごとに1行を、そのContract Typeトークンとともにカバーするタスクにマッピングする。値は全文を保持する。これにより、後続のタスクは要約を再構成するのではなく、この正確な値そのものと突き合わせて検証できる。Design Docがリセットまたはクリア操作を持つクライアント/セッション/UI状態を導入する場合、そのリセットで状態が未使用/デフォルト値に戻る条件はそれ自体が `state-lifecycle-negative` であり、他に拘束的観測値がなくても1行として記録する。本表が扱うのはDD由来の観測可能契約のみである。シリアライズ境界はConnection Map（ステップ5b）が、ADR由来の構造的決定はADR Bindings表が扱う。
 
 ### 5a. UI Specコンポーネントのタスクへのマッピング（UI Spec提供時）
 

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/design-template.md

@@ -281,11 +281,13 @@ A boundary here includes a **serialized boundary** — a value encoded on one si
 
 ### Client State Design (when feature includes frontend)
 
-| State Category | State | Management Method | Sync Strategy |
-|---------------|-------|-------------------|---------------|
-| Server state | [Fetched data] | [Cache library / custom hook] | [Polling / WebSocket / manual refresh] |
-| Local UI state | [Modal open, tab selection] | [useState / useReducer] | - |
-| Temporary state | [Form input, draft] | [useState / form library] | [Auto-save / manual save] |
+| State Category | State | Management Method | Sync Strategy | Reset/Clear Behavior |
+|---------------|-------|-------------------|---------------|----------------------|
+| Server state | [Fetched data] | [Cache library / custom hook] | [Polling / WebSocket / manual refresh] | [Cleared on clear-all / preserved] |
+| Local UI state | [Modal open, tab selection] | [useState / useReducer] | - | [Reset to default / preserved] |
+| Temporary state | [Form input, draft] | [useState / form library] | [Auto-save / manual save] | [Cleared on reset / persisted] |
+
+Fill the Reset/Clear Behavior column when the feature has a reset or clear-all operation. A state that must return to its unused/default value on reset is a state-lifecycle negative contract (the state stays unused/default after reset; Contract Type `state-lifecycle-negative`) — record it so it is verified rather than assumed.
 
 ### UI Action - API Contract Mapping (when feature includes frontend)
 

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

@@ -26,8 +26,8 @@ Review Scope: [planned-files scope derived from Design Doc and task targets; for
 - **Failure response**: [extracted from Design Doc]
 
 ### Proof Strategy
-- **Proof obligation source**: [test skeleton annotations (primary failure mode, proof obligation) when skeletons exist; otherwise each AC's primary failure mode]
-- **Per-task propagation**: every task that implements a claim records Proof Obligations (see task template) so downstream review can judge whether the tests prove the claim, not merely run
+- **Proof obligation source**: [test skeleton annotations (primary failure mode, proof obligation) when skeletons exist; otherwise each AC's primary failure mode; plus any applicable Failure Mode Checklist categories mapped to tasks]
+- **Per-task propagation**: every task that implements a claim or covers an applicable Failure Mode Checklist category records Proof Obligations (see task template) so downstream review can judge whether the tests prove the claim, not merely run
 
 ## Quality Assurance Mechanisms (from Design Doc)
 
@@ -61,7 +61,7 @@ Include this section when the Design Doc specifies a **binding observable value*
 
 ## Failure Mode Checklist
 
-Domain-independent failure categories this implementation must guard against. Enumerate all eight categories, mark each in the Applies? column as yes/no, and list a covering task for each that applies; keep entries free of project-specific names.
+Domain-independent failure categories this implementation must guard against. Enumerate all nine categories, mark each in the Applies? column as yes/no, and list a covering task for each that applies; keep entries free of project-specific names.
 
 | Category | Applies? | Covered By Task(s) |
 |---|---|---|
@@ -73,6 +73,7 @@ Domain-independent failure categories this implementation must guard against. En
 | unavailable boundary | yes/no | |
 | shared-state dependency | yes/no | |
 | rollback-only visibility | yes/no | |
+| missing-sort-key ordering | yes/no | |
 
 ## UI Spec Component → Task Mapping