create-ai-project 1.24.1 → 1.25.0

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.)
 
@@ -74,10 +89,10 @@ Each row is a DD-derived observable contract the implementation in this task mus
 - **Verification level**: [L1: Functional operation as end-user feature / L2: New tests added and passing / L3: Code builds without errors]
 
 ## Proof Obligations
-(One entry per AC or claim this task implements. Derived from test skeleton annotations when present, otherwise from the AC's primary failure mode. Each test must prove its claim. Repeat the block below once per claim; the heading carries the AC ID or claim ID so downstream review can resolve coverage per claim.)
+(One entry per AC, claim, or applicable Failure Mode Checklist category this task covers. Derived from test skeleton annotations when present, otherwise from the AC's primary failure mode or the mapped Failure Mode category. Each test must prove its claim. Repeat the block below once per claim; the heading carries the AC ID, claim ID, or `Failure Mode: <category>` so downstream review can resolve coverage per claim.)
 
-### Obligation: [AC ID or claim ID]
-- **Claim**: [the behavior the AC promises]
+### Obligation: [AC ID, claim ID, or Failure Mode category — e.g., `Failure Mode: missing-sort-key ordering`]
+- **Claim**: [the AC behavior, claim, or failure-mode condition this task must prove]
 - **Primary failure mode**: [the regression the test turns red on]
 - **Boundary to exercise**: [public/integration boundary the test traverses, or "in-process unit"]
 - **State assertion**: [observable state before → action → after for state-changing claims; "N/A" otherwise]
@@ -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/design-template.md

@@ -281,11 +281,13 @@ unknowns:
 
 ### クライアント状態設計（フロントエンド機能を含む場合）
 
-| 状態カテゴリ | 状態 | 管理方法 | 同期戦略 |
-|------------|------|---------|---------|
-| サーバー状態 | [取得データ] | [キャッシュライブラリ/カスタムフック] | [ポーリング/WebSocket/手動更新] |
-| UIローカル状態 | [モーダル開閉、タブ選択] | [useState/useReducer] | - |
-| 一時状態 | [フォーム入力、下書き] | [useState/フォームライブラリ] | [自動保存/手動保存] |
+| 状態カテゴリ | 状態 | 管理方法 | 同期戦略 | リセット/クリア時の振る舞い |
+|------------|------|---------|---------|--------------------------|
+| サーバー状態 | [取得データ] | [キャッシュライブラリ/カスタムフック] | [ポーリング/WebSocket/手動更新] | [全クリアで消去/保持] |
+| UIローカル状態 | [モーダル開閉、タブ選択] | [useState/useReducer] | - | [デフォルトにリセット/保持] |
+| 一時状態 | [フォーム入力、下書き] | [useState/フォームライブラリ] | [自動保存/手動保存] | [リセットで消去/永続化] |
+
+機能にリセットまたは全クリア操作がある場合、リセット/クリア時の振る舞い列を埋める。リセット時に未使用/デフォルト値へ戻らなければならない状態は state-lifecycle negative 契約（観測可能な契約: リセット後も状態は未使用のまま。Contract Type `state-lifecycle-negative`）であり、想定で済ませず検証されるよう記録する。
 
 ### UIアクション - APIコントラクトマッピング（フロントエンド機能を含む場合）
 

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

@@ -26,8 +26,8 @@
 - **失敗時の対応**: [Design Docから抽出]
 
 ### 証明戦略
-- **証明義務の出所**: [スケルトンが存在する場合はテストスケルトンの注釈（主要な故障モード、証明義務）。存在しない場合は各ACの主要な故障モード]
-- **タスクごとの伝播**: 主張を実装する各タスクは Proof Obligations（task template参照）を記録し、下流のレビューがテストが主張を証明しているか（単に実行されるだけでないか）を判定できるようにする
+- **証明義務の出所**: [スケルトンが存在する場合はテストスケルトンの注釈（主要な故障モード、証明義務）。存在しない場合は各ACの主要な故障モード。加えてタスクにマッピングされた該当する故障モードチェックリストのカテゴリ]
+- **タスクごとの伝播**: 主張を実装する、または該当する故障モードチェックリストのカテゴリをカバーする各タスクは Proof Obligations（task template参照）を記録し、下流のレビューがテストが主張を証明しているか（単に実行されるだけでないか）を判定できるようにする
 
 ## 品質保証メカニズム（Design Docより）
 
@@ -61,7 +61,7 @@ Design Docが、実装が正確に再現すべき**拘束的観測値**を指定
 
 ## 故障モードチェックリスト
 
-この実装が防ぐべきドメイン非依存の故障カテゴリ。8カテゴリすべてを列挙し、各カテゴリの該当列に yes/no を記入し、該当する各カテゴリにカバーするタスクを挙げる。エントリにはプロジェクト固有の名称を含めない。
+この実装が防ぐべきドメイン非依存の故障カテゴリ。9カテゴリすべてを列挙し、各カテゴリの該当列に yes/no を記入し、該当する各カテゴリにカバーするタスクを挙げる。エントリにはプロジェクト固有の名称を含めない。
 
 | カテゴリ | 該当? | カバーするタスク |
 |---|---|---|
@@ -73,6 +73,7 @@ Design Docが、実装が正確に再現すべき**拘束的観測値**を指定
 | unavailable boundary | yes/no | |
 | shared-state dependency | yes/no | |
 | rollback-only visibility | yes/no | |
+| missing-sort-key ordering | yes/no | |
 
 ## UI Specコンポーネント → タスクマッピング
 

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結果をここに記録する。）
 
@@ -74,10 +89,10 @@ Metadata:
 - **検証レベル**: [L1: エンドユーザー機能としての動作確認 / L2: 新規テスト追加・パス / L3: ビルドエラーなし]
 
 ## Proof Obligations
-（このタスクが実装するACまたは主張ごとに1エントリ。スケルトンの注釈がある場合はそこから、なければACの主要な故障モードから導出する。各テストは主張を証明すること。下記ブロックを主張ごとに繰り返し、見出しにAC IDまたは主張IDを記載して下流のレビューが主張ごとにカバレッジを解決できるようにする。）
+（このタスクがカバーするAC・主張・該当する故障モードチェックリストのカテゴリごとに1エントリ。スケルトンの注釈がある場合はそこから、なければACの主要な故障モードまたはマッピングされた故障モードカテゴリから導出する。各テストは主張を証明すること。下記ブロックを主張ごとに繰り返し、見出しにAC ID・主張ID・`Failure Mode: <category>` のいずれかを記載して下流のレビューが主張ごとにカバレッジを解決できるようにする。）
 
-### Obligation: [AC IDまたは主張ID]
-- **主張**: [ACが約束する振る舞い]
+### Obligation: [AC ID・主張ID・故障モードカテゴリのいずれか — 例: `Failure Mode: missing-sort-key ordering`]
+- **主張**: [このタスクが証明すべき、ACの振る舞い・主張・故障モード条件]
 - **主要な故障モード**: [テストがレッドになるリグレッション]
 - **検証する境界**: [テストが通過する公開/統合境界、または "in-process unit"]
 - **状態アサーション**: [状態変更を伴う主張では 操作前 → 操作 → 操作後 の観察可能な状態。それ以外は "N/A"]
@@ -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.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
+
+- **Failure-mode and spec-completeness coverage** (agents, skills) — added a ninth domain-independent failure category (`missing-sort-key ordering`), a mode × branch AC-expansion step in technical design, and reset/clear state captured as a `state-lifecycle-negative` contract. Failure Mode Checklist categories now propagate from the work plan to task Proof Obligations and are verified in review (`code-reviewer`, `integration-test-reviewer`), with a deterministic fallback when task files are absent so AC-less obligations are not silently treated as verified. Applied across en/ja.
+
 ## [1.24.1] - 2026-06-21
 
 ### Changed

package/package.json

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