create-ai-project 1.23.0 → 1.23.1

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

@@ -15,8 +15,12 @@ skills: typescript-rules, typescript-testing, coding-standards, project-context,
 
 ### モード選択
 
-- **Fresh Implementation Mode**（既定 — `requiredFixes` も `incompleteImplementations` も渡されていない場合）: タスクファイルの `[ ]` チェックボックスを駆動源にする。残りがなければ `task_already_completed` でエスカレーション。
-- **Fix Mode**（`requiredFixes` または `incompleteImplementations` のいずれかが非空）: 修正項目を駆動源にする。未完了チェックボックスゲートをスキップ。許可ファイルリストには各項目の `file_path`（パスそのもの）または `location`（`file[:line]` として解釈し、ファイル部分のみを使用）を加える。タスクのチェックボックスは変更せず、結果は `changeSummary` に記録する。
+- **Fresh Implementation Mode**（既定 — `requiredFixes` も `incompleteImplementations` も渡されていない場合）: タスクファイルの `[ ]` チェックボックスを起点として作業を進める。残りがなければ `task_already_completed` でエスカレーション。
+- **Fix Mode**（`requiredFixes` または `incompleteImplementations` のいずれかが非空）: 修正項目を起点として作業を進める。未完了チェックボックスゲートをスキップ。許可ファイルリストには各項目の `file_path`（パスそのもの）または `location`（`file[:line]` として解釈し、ファイル部分のみを使用）を加える。タスクのチェックボックスは変更せず、結果は `changeSummary` に記録する。
+  - `incompleteImplementations[]` の各エントリは、`type` フィールドで修正アクションを分岐する:
+    - `type: "missing_logic"` — 指定されたファイル・位置に欠落しているロジックを実装し、関数が意図された値を返却・生成するようにする
+    - `type: "hollow_test"` — hollow なテスト本体を、AC の観測可能な振る舞いを検証するアサーション（少なくとも1つ）に置き換える。実行されるべきテストへの `skip`/`xit` マーカーは外す。テスト対象の実装本体は、欠落していたアサーションが実装バグを露呈する場合を除き変更しない
+    - `type` が未指定の場合は `description` のテキストから推測する。曖昧な場合は `missing_logic` をデフォルトとする
 
 ## フェーズ開始ゲート [BLOCKING]
 
@@ -73,25 +77,22 @@ package.json の `packageManager` フィールドに従って実行コマンド
 ### Step2: 品質基準違反チェック（以下1つでもYES → 即エスカレーション）
 □ 型システム回避が必要？（型キャスト、動的型付け強制、型検証無効化）
 □ エラーハンドリング回避が必要？（例外無視、エラー握りつぶし）
-□ テスト空洞化が必要？（テストスキップ、無意味な検証、必ず成功のテスト）
+□ テストを実質的でない状態にする変更が必要？（skip 追加、無意味な検証、常に成功するテスト）
 □ 既存テスト変更・削除が必要？
 
 ### Step3: 類似機能重複チェック
-**以下の重複度評価でエスカレーション判定**
 
-**高重複（エスカレーション必須）** - 3項目以上該当：
-□ 同一ドメイン・責務（ビジネス領域、処理対象エンティティが同一）
-□ 同一入出力パターン（引数・戻り値の型・構造が同一または高類似）
-□ 同一処理内容（CRUD操作、バリデーション、変換、計算ロジックが同一）
-□ 同一配置（同一ディレクトリまたは機能的に関連するモジュール内）
-□ 命名類似（関数名・クラス名に共通のキーワード・パターン）
+同一ドメイン・責務の既存実装と照合し、以下5つの指標を評価する:
+- (a) 同一ドメイン・責務（ビジネス領域、処理対象エンティティ）
+- (b) 同一入出力パターン（引数・戻り値の型・構造）
+- (c) 同一処理内容（CRUD操作、バリデーション、変換、計算ロジック）
+- (d) 同一配置（同一ディレクトリまたは機能的に関連するモジュール）
+- (e) 命名類似（関数名・クラス名に共通のキーワード・パターン）
 
-**中重複（条件付きエスカレーション）** - 2項目該当:
-- ドメイン・責務が同一 + 処理内容が同一 → エスカレーション
-- 入出力パターン同一 + 処理内容が同一 → エスカレーション
-- その他の2項目組み合わせ → 継続実装
-
-**低重複（継続実装）** - 1項目以下該当
+エスカレーション閾値:
+- 3項目以上一致 → エスカレーション
+- 一致したのが (a+c) または (b+c) の組み合わせのみ → エスカレーション。その他の2項目組み合わせ → 継続実装
+- 1項目以下一致 → 継続実装
 
 ### 境界ケースと鉄則
 
@@ -162,6 +163,15 @@ task_file パスはオーケストレータが渡す入力。プロンプトで
 **強制**: ゲートが発動し、いずれかが未チェックの場合、構造化レスポンス仕様で定義される JSON 形式で `status: "escalation_needed"` を返却。
 
 ### 3. 実装実行
+
+#### テスト環境チェック
+**TDDサイクル開始前**: **このタスクのテストが依存する**コンポーネントだけを確認する。AC を、テストランナーのみで実行可能なテスト（DOM/ブラウザ環境、フィクスチャ/コンテナ、モックサーバ、外部サービスを必要としない）で実行できる場合は、そちらを優先してエスカレーションを避ける。
+
+**対象コンポーネント**（例）: このタスクが追加・変更するテストが参照する、テストランナー、フィクスチャ/コンテナ、モックサーバ、共有 setup ファイル。
+**確認方法**: プロジェクトのファイル/コマンドを点検し、このタスクが必要とするテストの実行可能性を確認する。
+**利用可能**: typescript-testing スキルに従い RED-GREEN-REFACTOR を実行する。
+**利用不可**: このタスクが選択したテストパスに必要なコンポーネントが欠落しており、かつ AC に対するテストランナーのみの代替が成り立たない場合、`status: "escalation_needed"`、`reason: "Test environment not ready"`、`escalation_type: "test_environment_not_ready"` でエスカレーション（エスカレーションレスポンス表参照）。
+
 #### 実装前確認（パターン5準拠）
 1. **Design Doc該当箇所**を読み込み、インターフェース契約・データ構造・依存関係の制約を抽出
 2. **既存実装調査**：同ドメイン・責務で類似機能を検索
@@ -183,11 +193,14 @@ task_file パスはオーケストレータが渡す入力。プロンプトで
 
 パターンや依存をコードから採用する際、coding-standardsの「参照の代表性」を採用時点で適用する:
 
-□ **リポジトリ全体での確認**: パターンまたは依存バージョンがリポジトリ全体で代表的であることをGrepで確認。異なるディレクトリの3ファイル以上で同じパターンが使われている場合に採用可能。参照元以外で0-2件の場合は、正規の実装かレガシーかを調査してから採用
+□ **リポジトリ全体での確認**: 対象パターンをリポジトリ全体で Grep し、参照元以外で使用されているファイル数で分岐する:
+  - 異なるディレクトリの3ファイル以上で使用 → 採用
+  - 1-2ファイルで使用 → それらが正規の実装かレガシーかを調査。正規と判断できれば採用。判定不能なら `escalation_type: "dependency_version_uncertain"` でエスカレーション
+  - 0ファイル → ローカル規約として扱う。明示的な正当化（周囲のコードとの整合、破壊的変更の回避、関係箇所と協調するアップデート待ち等）を Investigation Notes に記載した上でのみ採用
 □ **依存バージョン確認**（外部依存を採用する場合）:
   - 同じ依存のリポジトリ全体での使用分布を確認
-  - 代替が存在する中で既存バージョンに従う場合、その理由を明記
-  - リポジトリ全体の確認では適切なバージョンが判断できない場合、`reason: "dependency_version_uncertain"` でエスカレーション
+  - 複数の共存バージョンの中で1つに従う場合、その理由を明記
+  - リポジトリ全体の確認で選択が曖昧なまま残る場合は `escalation_type: "dependency_version_uncertain"` でエスカレーション
 □ **複数バージョン共存時の解決**: 複数バージョンやパターンが共存している場合、多数派（最多ファイル数）を特定してから選択。少数派を選ぶ場合は理由を明記
 
 #### 実装フロー（TDD準拠）
@@ -241,6 +254,15 @@ task_file パスはオーケストレータが渡す入力。プロンプトで
 
 **requiresTestReview**: タスクが統合テストまたはE2Eテストを追加・更新した場合は`true`に設定。単体テストのみのタスクやテストなしのタスクでは`false`に設定。
 
+**runnableCheck.result** と **runnableCheck.substance**: 両フィールドを以下の仕様で設定する。
+
+- `result`: テストランナーの実行結果をそのまま反映する — `passed`、`failed`、`skipped` のいずれか。非テスト系の検証（build、typecheck、CLI 実行、成果物チェック）はコマンドがエラーなく完了したら `passed`。
+- `substance`: タスクファイルに記載された AC のエビデンスとしてテスト実行が引用されている場合のみ適用:
+  - `substantive`: 実行されたアサーションのうち少なくとも1つが、AC の観測可能な振る舞いを検証している。意図的な不在を検証するアサーション（例: 空の結果、null 戻り値）は AC が不在を期待する場合に該当する
+  - `non_substantive`: AC に対する実体的なアサーションが存在しない実行 — 例: テストランナーが0件マッチと報告、実行されるべきパスでのテストスキップ、TODO のみの本体、振る舞いに関係なく常に成功するアサーション（例: `expect(true).toBe(true)`、`expect(arr.length).toBeGreaterThanOrEqual(0)`）
+- `substanceIssue`: `substance` が `non_substantive` の場合、具体的な原因と位置を記載する（例: `"always-true assertion at order.test.ts:42"`、`"runner matched 0 tests for pattern *.feature.test.ts"`）。`substantive` のとき、またはテストエビデンスが引用されない場合は `null`。
+- 非テスト系の検証（lint、format、build、typecheck）は `substance: null`。
+
 ### 1. タスク完了時のレスポンス
 タスク完了時は以下のJSON形式で報告（**品質チェックやコミットは実行せず**、品質チェック工程に委譲）：
 
@@ -263,6 +285,8 @@ task_file パスはオーケストレータが渡す入力。プロンプトで
     "executed": true,
     "command": "実行したテストコマンド",
     "result": "passed / failed / skipped",
+    "substance": "substantive | non_substantive | null (非テスト系の検証)",
+    "substanceIssue": "substantive または非テスト系の場合は null。non_substantive の場合は原因と位置を記載",
     "reason": "テスト実行理由・確認内容"
   },
   "readyForQualityCheck": true,
@@ -296,6 +320,7 @@ task_file パスはオーケストレータが渡す入力。プロンプトで
 | `dependency_version_uncertain` | "Dependency version uncertain" | `dependency: {name, versionsFound[], filesChecked[], ambiguityReason}` | "多数派バージョンXを使用" / "理由付きでバージョンYを使用" / "最新安定版を調査" |
 | `binding_decision_violation` | "Binding decision violation" | `phase: 'pre_implementation' \| 'exit_gate'`; `plannedApproach`; `failures[{source, axis, decision, complianceCheck, evaluation: 'N' \| 'Unknown', rationale}]` | "バインディング決定を満たすよう実装計画を調整" / "ADRを更新（その後、作業計画書のADR BindingsとこのタスクのBinding Decisionsを更新）" / "Unknown評価を解消する追加コンテキストを提供" |
 | `out_of_scope_file` | "Out of scope file" | `details: {file_path, allowed_list[], modification_reason}` | "Target Files に追加してリトライ" / "別タスクに分割" / "アプローチを再検討" |
+| `test_environment_not_ready` | "Test environment not ready" | `missingComponent: 'test runner' \| 'fixtures' \| 'mock server' \| 'setup file' \| 'other'`; `description`（欠落コンポーネントがテストをブロックする理由） | "欠落コンポーネントをインストールまたは設定してタスクを再実行" / "環境が整ってからタスクを再割り当て" |
 | `task_file_not_found` / `task_already_completed` / `target_files_missing` | "Task selection precondition failed" | `details: {task_file_path, failure_reason: 'file does not exist' \| 'file unreadable' \| 'all checkboxes already [x]' \| 'Target Files section missing or empty'}` | "正しい task_file パスを提供" / "作業計画を再分解" / "完了済みとしてスキップ" |
 
 最小例（out_of_scope_file）:
@@ -324,6 +349,7 @@ task_file パスはオーケストレータが渡す入力。プロンプトで
 ☐ Fix Mode: `requiredFixes` / `incompleteImplementations` の全項目が `changeSummary` に対応または個別エスカレーション済み
 ☐ 実装が Step 2 で記録した調査メモと整合している（調査対象が存在した場合）
 ☐ Binding Decisions の全 Compliance Check が最終実装に対して `Y` と評価され、その根拠が Investigation Notes に記録されている（タスクファイルに Binding Decisions セクションがある場合）。実装前チェックが通過していても、実装が計画したアプローチから逸脱している可能性があるため、ここで再評価する
+☐ テストエビデンスを引用している場合（タスクがテストを実行した場合）、`runnableCheck.substance` と `runnableCheck.substanceIssue` がフィールド仕様に従って設定されている
 ☐ 最終レスポンスが `status: "completed"` または `status: "escalation_needed"` の単一 JSON で、構造化レスポンス仕様のスキーマに一致する
 
 **強制**: いずれかが未チェックの場合、構造化レスポンス仕様で定義される JSON 形式で `status: "escalation_needed"` を返却。未チェック項目が Binding Decisions の Compliance Check の場合は、`escalation_type: "binding_decision_violation"`（`phase: "exit_gate"`）を使う。

package/.claude/skills-en/subagents-orchestration-guide/SKILL.md

@@ -156,8 +156,8 @@ Subagents respond in JSON format. Key fields for orchestrator decisions:
 | codebase-analyzer | analysisScope.categoriesDetected, dataModel.detected, qualityAssurance (mechanisms[], domainConstraints[]), focusAreas[], existingElements count, limitations | Pass focusAreas to technical-designer as context |
 | ui-analyzer | externalResources (status, per-axis fetch_status), componentStructure[], propsPatterns[], cssLayout[], stateDisplay[], focusAreas[], candidateWriteSet[], limitations | Pass the ui-analyzer JSON to ui-spec-designer and technical-designer-frontend; each consumes the fields named in its own input declaration |
 | code-verifier | status (consistent/mostly_consistent/needs_review/inconsistent), consistencyScore, discrepancies[], reverseCoverage (dataOperationsInCode, testBoundariesSectionPresent). Pre-implementation: verifies Design Doc claims against existing codebase. Post-implementation: verifies implementation consistency against Design Doc (pass `code_paths` scoped to changed files) | Flag discrepancies for document-reviewer |
-| task-executor | Input: `task_file` (required in orchestrated flows); optional Fix Mode signals `requiredFixes` or `incompleteImplementations` — when either is non-empty, skip `task_already_completed` and extend allowed list with each item's `file_path` / `location` (parse `location` as `file[:line]`). Output: status (escalation_needed/completed), filesModified[], testsAdded, requiresTestReview, escalation_type ∈ {task_file_not_found, task_already_completed, target_files_missing, design_compliance_violation, similar_function_found, similar_component_found, investigation_target_not_found, out_of_scope_file, dependency_version_uncertain, binding_decision_violation}. | On escalation_needed: handle by escalation_type |
-| quality-fixer | Input: `task_file` (path to current task file — always pass this in orchestrated flows), `filesModified` (extract from the upstream implementation step's response — passes the task's write set as the primary scope for stub-detection; falls back to `git diff HEAD` when omitted). Status: approved/stub_detected/blocked. `stub_detected` → route back to the implementation step with `incompleteImplementations[]` details for completion, then re-run quality-fixer. `blocked` → see quality-fixer blocked handling below | On stub_detected: re-invoke the implementation step. On blocked: see handling below |
+| task-executor | Input: `task_file` (required in orchestrated flows); optional Fix Mode signals `requiredFixes` or `incompleteImplementations` — when either is non-empty, skip `task_already_completed` and extend allowed list with each item's `file_path` / `location` (parse `location` as `file[:line]`); each `incompleteImplementations[]` entry may carry `type: "missing_logic" \| "hollow_test"` and the executor branches its fix action by `type`. Output: status (escalation_needed/completed), filesModified[], testsAdded, requiresTestReview, runnableCheck{level, executed, command, result, substance, substanceIssue, reason}, escalation_type ∈ {task_file_not_found, task_already_completed, target_files_missing, design_compliance_violation, similar_function_found, similar_component_found, investigation_target_not_found, out_of_scope_file, dependency_version_uncertain, binding_decision_violation, test_environment_not_ready}. | On escalation_needed: handle by escalation_type |
+| quality-fixer | Input: `task_file` (path to current task file — always pass this in orchestrated flows), `filesModified` (extract from the upstream implementation step's response — passes the task's write set as the primary scope for stub-detection; falls back to `git diff HEAD` when omitted), `runnableCheck` (extract from the upstream implementation step's response — passes the test execution evidence including `substance` and `substanceIssue` so the substance check has the runtime signal; omit when the upstream did not run tests). Status: approved/stub_detected/blocked. `stub_detected` → `incompleteImplementations[]` items carry `type: "missing_logic" \| "hollow_test"`; route back to the implementation step (which branches its fix action on `type`), then re-run quality-fixer. `blocked` → see quality-fixer blocked handling below | On stub_detected: re-invoke the implementation step. On blocked: see handling below |
 | document-reviewer | approvalReady (true/false) | Proceed to next step on true; request fixes on false |
 | design-sync | sync_status (NO_CONFLICTS/CONFLICTS_FOUND) | On CONFLICTS_FOUND: present conflicts to user before proceeding |
 | integration-test-reviewer | status (approved/needs_revision/blocked), requiredFixes | On needs_revision: re-invoke the routed executor in Fix Mode with the same task_file and requiredFixes[] |

package/.claude/skills-ja/subagents-orchestration-guide/SKILL.md

@@ -154,8 +154,8 @@ description: サブエージェントのタスク分担と連携を調整。規
 | codebase-analyzer | analysisScope.categoriesDetected, dataModel.detected, qualityAssurance (mechanisms[], domainConstraints[]), focusAreas[], existingElements count, limitations | focusAreasをtechnical-designerにコンテキストとして渡す |
 | ui-analyzer | externalResources (status, per-axis fetch_status), componentStructure[], propsPatterns[], cssLayout[], stateDisplay[], focusAreas[], candidateWriteSet[], limitations | ui-analyzerのJSONをui-spec-designerとtechnical-designer-frontendに渡す。各エージェントは自身の入力宣言に記載されたフィールドを使う |
 | code-verifier | status (consistent/mostly_consistent/needs_review/inconsistent), consistencyScore, discrepancies[], reverseCoverage (dataOperationsInCode, testBoundariesSectionPresent). 実装前: Design Docの主張を既存コードに対して検証。実装後: 実装のDesign Doc整合性を検証（`code_paths`で変更ファイルにスコープ） | discrepanciesをdocument-reviewerに連携 |
-| task-executor | 入力: `task_file`（オーケストレーションフローでは必須）; 任意の Fix Mode シグナル `requiredFixes` または `incompleteImplementations` — いずれかが非空の場合、`task_already_completed` チェックをスキップし、各項目の `file_path` / `location`（`location` は `file[:line]` として解釈）で許可リストを拡張する。出力: status (escalation_needed/completed), filesModified[], testsAdded, requiresTestReview, escalation_type ∈ {task_file_not_found, task_already_completed, target_files_missing, design_compliance_violation, similar_function_found, similar_component_found, investigation_target_not_found, out_of_scope_file, dependency_version_uncertain, binding_decision_violation} | escalation_needed時: escalation_type別に対応 |
-| quality-fixer | 入力: `task_file`（現在のタスクファイルパス — オーケストレーションフローでは常に渡す）、`filesModified`（上流の実装ステップのレスポンスから抽出 — 当該タスクの書き込み集合を未完成実装検出の主要スコープとして渡す。省略時は `git diff HEAD` にフォールバック）。Status: approved/stub_detected/blocked。`stub_detected` → 上流の実装ステップに `incompleteImplementations[]` の詳細を添えて差し戻し、本実装完了後にquality-fixerを再実行。`blocked` → 下記quality-fixer blockedハンドリング参照 | stub_detected: 実装ステップを再実行。blocked: 下記参照 |
+| task-executor | 入力: `task_file`（オーケストレーションフローでは必須）; 任意の Fix Mode シグナル `requiredFixes` または `incompleteImplementations` — いずれかが非空の場合、`task_already_completed` チェックをスキップし、各項目の `file_path` / `location`（`location` は `file[:line]` として解釈）で許可リストを拡張する。`incompleteImplementations[]` の各エントリは `type: "missing_logic" \| "hollow_test"` を持ち得て、executor は `type` で修正アクションを分岐する。出力: status (escalation_needed/completed), filesModified[], testsAdded, requiresTestReview, runnableCheck{level, executed, command, result, substance, substanceIssue, reason}, escalation_type ∈ {task_file_not_found, task_already_completed, target_files_missing, design_compliance_violation, similar_function_found, similar_component_found, investigation_target_not_found, out_of_scope_file, dependency_version_uncertain, binding_decision_violation, test_environment_not_ready} | escalation_needed時: escalation_type別に対応 |
+| quality-fixer | 入力: `task_file`（現在のタスクファイルパス — オーケストレーションフローでは常に渡す）、`filesModified`（上流の実装ステップのレスポンスから抽出 — 当該タスクの書き込み集合を未完成実装検出の主要スコープとして渡す。省略時は `git diff HEAD` にフォールバック）、`runnableCheck`（上流の実装ステップのレスポンスから抽出 — `substance` と `substanceIssue` を含むテスト実行のエビデンスを渡し、Substance チェックが実行時のシグナルを受け取れるようにする。上流がテストを実行していない場合は省略可）。Status: approved/stub_detected/blocked。`stub_detected` → `incompleteImplementations[]` の各エントリは `type: "missing_logic" \| "hollow_test"` を持ち、`type` で executor 側の修正アクションを分岐させた上で上流の実装ステップに差し戻し、本実装完了後にquality-fixerを再実行。`blocked` → 下記quality-fixer blockedハンドリング参照 | stub_detected: 実装ステップを再実行。blocked: 下記参照 |
 | document-reviewer | approvalReady (true/false) | trueで次ステップへ。falseで修正を依頼 |
 | design-sync | sync_status (NO_CONFLICTS/CONFLICTS_FOUND) | CONFLICTS_FOUND時: 矛盾をユーザーに提示してから進む |
 | integration-test-reviewer | status (approved/needs_revision/blocked), requiredFixes | needs_revision時: 同じ task_file と requiredFixes[] を渡してルーティング先の executor を Fix Mode で再実行 |

package/CHANGELOG.md

@@ -5,6 +5,20 @@ 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.23.1] - 2026-05-28
+
+### Added
+
+- **Acceptance evidence discipline** (agents, skills) — Substance check rejects cited test evidence that is hollow (skipped, TODO-only, always-true, or 0-match). `task-executor` reports `runnableCheck.substance` / `substanceIssue`; `quality-fixer` gates on it and routes unrecoverable hollow tests via `stub_detected` with new `incompleteImplementations[].type` (`missing_logic` / `hollow_test`). `code-reviewer` §3-3 and `integration-test-reviewer` add matching inspection criteria
+- **`test_environment_not_ready` escalation** (agents, skills) — `task-executor` / `-frontend` escalate with a typed reason when the required test toolchain is unavailable. Registered in `subagents-orchestration-guide`
+- **Frontend executor symmetry** (agents) — `task-executor-frontend` gains Reference Representativeness (IF-THEN by repository-wide file count) and `dependency_version_uncertain` escalation, matching the backend executor
+
+### Changed
+
+- **Reference Representativeness rule** (agents, skills) — Rewritten as explicit IF-THEN (3+ adopt / 1-2 investigate canonical-vs-legacy / 0 justify) so a canonical pattern with only 1-2 nearby files can still be adopted instead of being forced to escalate
+- **Frontend quality-fixer guidance** (agents) — Replace obsolete patterns (manual `cleanup()`, snapshot-first thinking) with current RTL practice (auto-cleanup, behavior assertions over snapshots, mock at the existing network boundary)
+- **Prompt tightening** (agents, skills) — Compressed Similar Function / Component Duplication Check; removed redundant Special Considerations (`code-reviewer`) and Important Principles (`quality-fixer`); added a Policy References hub to Fix Execution Policy; split `quality-fixer` `blocked` example into Variant A (specification conflict) and Variant B (missing prerequisites); `subagents-orchestration-guide` task-executor Output and quality-fixer Input contracts updated to carry `runnableCheck` through
+
 ## [1.23.0] - 2026-05-22
 
 ### Added

package/package.json

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