create-ai-project 1.23.3 → 1.23.5

package/.claude/skills-en/integration-e2e-testing/SKILL.md

@@ -45,6 +45,8 @@ The two E2E lanes are budgeted independently — having a fixture-e2e for a jour
 
 ### Required Comment Format
 
+The committed skeleton imports only the test framework (for `describe`/`it`/`it.todo`); the module under test is imported by the implementing task, never by the skeleton — a skeleton that references a not-yet-created module can fail gates that type-check, compile, or load test files before implementation begins.
+
 Each test MUST include the following annotations.
 
 ```typescript

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

@@ -216,14 +216,9 @@ According to scale determination:
 
 Note: At Small scale the implementation step still runs through task-executor with the standard 4-step cycle (`task-executor → escalation judgment → quality-fixer → commit`). Direct orchestrator edits are not used.
 
-### Implementation Readiness Marker
+### Optional Preflight
 
-For Medium / Large scale, after Batch approval the work plan carries an `Implementation Readiness:` header (work-planner emits `pending`; promotion to `ready` or `escalated` is an external orchestration concern). The marker takes one of three values:
-- `pending` — initial state set by work-planner
-- `ready` — readiness verification has completed with no remaining gaps; safe to start the task execution cycle
-- `escalated` — readiness verification has completed but residual gaps require user judgment before execution
-
-External orchestration owns both the producer that promotes the marker beyond `pending` and the consumer that reads it before invoking task-executor. This guide does not invoke any orchestrator above the agent layer; agents read/write the marker only when explicitly asked.
+For Medium / Large scale, after Batch approval implementation proceeds directly. Verifying the plan is implementable end-to-end (verification-strategy references, fixtures, UI rendering surface, E2E/local lane environment) is an optional preflight the user runs at their discretion via the prepare-implementation recipe, which exits no-op when readiness criteria already pass. This guide does not invoke any orchestrator above the agent layer.
 
 ## Cross-Layer Orchestration
 

package/.claude/skills-en/technical-spec/SKILL.md

@@ -92,6 +92,7 @@ Quality checks are mandatory upon implementation completion:
 - **Cache issues**: Run the `test:coverage:fresh` script
 - **Dependency errors**: Clean reinstall dependencies
 
-### Coverage Requirements
-- **MANDATORY**: Unit test coverage MUST be 70% or higher
-- **Metrics**: Statements, Branches, Functions, Lines
+### Coverage
+- Treat coverage as a diagnostic signal for finding untested areas, not a target (a target gets gamed into trivial tests — Goodhart's Law). Concentrate tests on critical paths and business logic whose regression would matter
+- Any enforced numeric threshold is the project's CI/coverage config, not a goal in itself
+- **Metrics** (what coverage reports break down): Statements, Branches, Functions, Lines

package/.claude/skills-en/typescript-testing/SKILL.md

@@ -14,14 +14,14 @@ description: Applies Vitest test design and quality standards. Provides coverage
 ## Basic Testing Policy
 
 ### Quality Requirements
-- **Coverage**: Unit test coverage must be 70% or higher
+- **Coverage**: treat coverage as a diagnostic signal for finding untested areas, not a target (a target gets gamed into trivial tests — Goodhart's Law). Concentrate tests on critical paths, business logic, and behavior whose regression would matter. Any numeric threshold is the project's CI config
 - **Independence**: Each test can run independently without depending on other tests
 - **Reproducibility**: Tests are environment-independent and always return the same results
 - **Readability**: Test code maintains the same quality as production code
 
-### Coverage Requirements
-**Mandatory**: Unit test coverage must be 70% or higher
-**Metrics**: Statements, Branches, Functions, Lines
+### Coverage
+- Prioritize meaningful assertions over the coverage number; raise coverage where a gap leaves a real regression unguarded, not to hit a percentage
+- **Metrics** (what coverage reports break down): Statements, Branches, Functions, Lines
 
 ### Test Types and Scope
 1. **Unit Tests**

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

@@ -5,8 +5,6 @@
 想定影響範囲: Xファイル
 関連Issue/PR: #XXX（該当する場合）
 レビュースコープ: [Design Docとタスク対象から導出した変更予定ファイルの範囲。既存作業に対する改訂計画の場合はベースブランチ + diff範囲]
-<!-- 下記の行はmedium / large規模のみ — small規模はこのplan-templateではなくtask-templateを使用する。値の行は末尾コメントを付けず、下流のパーサがbare statusの抽出（pending | ready | escalated）を行えるように保つこと。 -->
-Implementation Readiness: pending
 
 ## 関連ドキュメント
 - 設計書:
@@ -214,7 +212,7 @@ Design Docの実装アプローチに基づいてフェーズ構成をひとつ
 - [ ] セキュリティレビュー: Design Docのセキュリティ考慮事項が実装されていることを確認
 - [ ] 品質チェック（型、lint、format）
 - [ ] 全テスト実行（テストスケルトン提供時は統合/E2Eテスト含む）
-- [ ] カバレッジ70%以上
+- [ ] クリティカルパスのギャップシグナルとしてカバレッジを確認（強制しきい値はプロジェクトの CI 設定に従う）
 - [ ] ドキュメント更新
 
 ### 品質保証

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

@@ -17,6 +17,13 @@ Metadata:
 実装開始前に読むべきファイル（ファイルパス、任意でサーチヒント付き）:
 - [例: src/orders/checkout (processOrder関数) — タスクの性質に基づきタスク分解時に決定]
 
+## Change Category
+（タスクがバグ修正・リグレッション・状態変更・境界変更の場合のみ本フィールドを記載する — タスク分解時に設定。それ以外は省略する。）
+
+`Change Category: <bug-fix, regression, state-change, boundary-change のうち該当するものをカンマ区切りで>`
+
+記載がある場合、実装は同一の経路・契約・永続状態・外部境界を共有するケースを、同一クラスの欠陥について走査する（Implementation Steps の Red Phase 参照）。
+
 ## Binding Decisions
 （作業計画書のADR Bindings表がこのタスクをカバーする場合に本セクションを記載する。それ以外は省略する。）
 
@@ -32,6 +39,7 @@ Metadata:
 ## Implementation Steps (TDD: Red-Green-Refactor)
 ### 1. Red Phase
 - [ ] 全ての Investigation Targets を読み、主要な所見を記録
+- [ ] （Change Category が設定されている場合）同一の経路/契約/状態/境界を共有する隣接ケースを同一クラスの欠陥について走査し、スコープ内で見つかったものを失敗するテストに取り込む
 - [ ] Dependencies の成果物を確認（ある場合）
 - [ ] 契約定義を確認・作成
 - [ ] 失敗するテストを書く

package/.claude/skills-ja/frontend-technical-spec/SKILL.md

@@ -133,14 +133,10 @@ package.jsonの`packageManager`フィールドに応じた実行コマンドを
 - `test:coverage:fresh` - カバレッジ測定
 - `check:all` - 全体統合チェック
 
-### カバレッジ要件
-- **必須**: 単体テストのカバレッジは60%以上
-- **コンポーネント別目標**:
-  - Atoms: 70%以上
-  - Molecules: 65%以上
-  - Organisms: 60%以上
-  - Custom Hooks: 65%以上
-  - Utils: 70%以上
+### カバレッジ
+- カバレッジは目標ではなく未テスト領域を見つける診断シグナルとして扱う（目標化すると自明なテストに歪む — グッドハートの法則）
+- 基盤的で再利用度の高いユニット（共有コンポーネント、カスタムフック、utils）にテストの重点を置く — リグレッション時の影響範囲が最も広い。合成度の高い面（organisms、ページ）は統合/E2Eのカバレッジに委ねる
+- 強制する数値しきい値はプロジェクトの CI / カバレッジ設定であり、それ自体が目的ではない
 
 ### 非機能要件
 - **ブラウザ互換性**: Chrome/Firefox/Safari/Edge（最新2バージョン）

package/.claude/skills-ja/frontend-typescript-rules/SKILL.md

@@ -34,6 +34,7 @@ const user = raw // User に絞り込み済み
 - **Custom hook** をロジック再利用と依存注入の単位とする（テスト容易性のため、協調オブジェクトは hook 経由で注入する）。
 - **関数引数:** 位置引数は 0〜2 個。3 個以上は単一の options オブジェクトで受ける。
 - **状態の形:** 状態は明示的に型付けする。複数フィールドかつ離散的な遷移を持つ状態は、複数の `useState` ではなく discriminated union の action 型を用いた `useReducer` にする。
+- **Server/Client 境界**（RSC フレームワークのみ — 例: Next.js App Router）: データ取得とレンダリングは既定でサーバーコンポーネントに置き、インタラクティブ性は必要最小のスコープで `"use client"` 境界の内側に隔離する。ブラウザ専用 API（`window`、`localStorage`、イベントハンドラ）はクライアントコンポーネント内に留める — サーバーコンポーネントで呼ぶとレンダリングが壊れる。クライアントのみの SPA（例: Vite）では N/A — サーバーコンポーネントランタイムが無いプロジェクトではスキップする。
 
 ## エラーハンドリング
 - すべてのエラーを表に出す: ログして処理するか伝播する — 握り潰さない。
@@ -41,6 +42,7 @@ const user = raw // User に絞り込み済み
 - 想定内の失敗は `Result` 型で値として表現する。`throw` は想定外/回復不能なケースに限る。
 - 目的別のエラークラスは `code` を持つ基底 `AppError` を継承する（例: ValidationError, ApiError, NotFoundError）。
 - **層の責務:** API 層は transport エラーをドメインエラーへ変換する。hook は `AppError` を上位へ伝播する。Error Boundary はレンダリング時のエラーを捕捉しフォールバック UI を表示する。
+- **Effect の競合/クリーンアップ:** `useEffect` 内のデータ取得は、順序が入れ替わった応答とアンマウント後の状態更新に対してガードする — `AbortController` か mounted フラグで stale な結果を中断・無視するか、キャンセルと重複排除を行うサーバー状態ライブラリ（React Query/SWR）を使う。`try-catch` だけではこれをカバーできない。
 - 機微情報（password, token, apiKey, creditCard）をログに出さない。
 
 ```typescript
@@ -63,8 +65,8 @@ class ErrorBoundary extends React.Component<{ children: React.ReactNode; fallbac
 ```
 
 ## プロジェクト規約
-- **環境変数:** ビルドツールの環境変数システム経由で読む（ブラウザに `process.env` は存在しない）。秘密情報はすべてサーバーサイドに置く — フロントエンドのコードはクライアントに配信される。
-- **バンドルとパフォーマンス:** `build` スクリプトで監視し 500KB 未満に保つ。高コストなコンポーネントは `React.memo` でメモ化する。`React.lazy` + `Suspense` でコード分割する。再レンダリングを最小化する状態構造にする。
+- **環境変数:** クライアント側の環境変数はバンドラが公開するアクセサ経由で読む — 公開プレフィックスを持つ変数だけがブラウザに届き、プレフィックスの無い変数はブラウザでは `undefined` になる。プロジェクトのバンドラに合わせる: Vite は `import.meta.env.VITE_*`、Next.js の公開変数は `process.env.NEXT_PUBLIC_*`、CRA は `process.env.REACT_APP_*`。秘密情報はすべてサーバーサイドに置く — フロントエンドのコードはクライアントに配信される。
+- **バンドルとパフォーマンス:** バンドルサイズは `build` スクリプトでプロジェクトの予算に対して監視する。`React.lazy` + `Suspense` でコード分割する。再レンダリングを最小化する状態構造にする。メモ化: React Compiler が有効なときはそれに任せる。手動の `React.memo`/`useMemo`/`useCallback` は、プロファイラまたは参照同一性で正当化される逃げ道としてのみ用いる（実測されたボトルネック、またはサードパーティ API や effect 依存に対する安定した参照同一性）。
 - **命名:** コンポーネント/型は `PascalCase`、変数/関数は `camelCase`、hook は `use` 接頭辞、定数は `SCREAMING_SNAKE_CASE`。
 - **インポート:** `src/` からの絶対パス。順序: React → 外部ライブラリ → 内部（絶対）→ 内部（相対）→ 型のみ → スタイル/アセット。
 - **フォーマット:** Biome に従う（セミコロンやスタイルはプロジェクト設定に従う）。

package/.claude/skills-ja/frontend-typescript-testing/SKILL.md

@@ -24,21 +24,15 @@ description: React Testing Library、MSW、Playwright E2Eでテストを設計
 ## テストの基本方針
 
 ### 品質要件
-- **カバレッジ**: 単体テストのカバレッジは60%以上を必須（フロントエンド標準 2025）
+- **カバレッジ**: クリティカルパスと高再利用コンポーネントに対する意味のあるアサーションを優先する。カバレッジは目標ではなくギャップ検出のシグナルとして扱う（目標化すると自明なテストに歪む — グッドハートの法則）。数値しきい値はプロジェクトの CI 設定に委ねる
 - **独立性**: 各テストは他のテストに依存せず実行可能
 - **再現性**: テストは環境に依存せず、常に同じ結果を返す
 - **可読性**: テストコードも製品コードと同様の品質を維持
 
-### カバレッジ要件
-**必須**: 単体テストのカバレッジは60%以上
-**コンポーネント別目標**:
-- Atoms（Button、Text等）: 70%以上
-- Molecules（FormField等）: 65%以上
-- Organisms（Header、Footer等）: 60%以上
-- Custom Hooks: 65%以上
-- Utils: 70%以上
+### テストの重点配分
+基盤的で再利用度の高いユニット（共有コンポーネント、カスタムフック、utils）を最も厚くテストする — 多くの機能から再利用されるものほど、リグレッション時の影響範囲が広い。合成度の高い面（organisms、ページ）は統合/E2Eのカバレッジに委ねる。数値しきい値はプロジェクトの CI 設定に委ねる。
 
-**指標**: Statements（文）、Branches（分岐）、Functions（関数）、Lines（行）
+**指標**（カバレッジレポートの内訳）: Statements（文）、Branches（分岐）、Functions（関数）、Lines（行）
 
 ### テストの種類と範囲
 1. **単体テスト（React Testing Library）**
@@ -74,7 +68,7 @@ src/
 
 **理由**:
 - React Testing Libraryのベストプラクティス
-- ADR-0002 Co-location原則
+- Co-location原則: テストはそれがカバーする実装と同じ場所に置く
 - 実装と一緒にテストを見つけやすく、保守しやすい
 
 ### 命名規則

package/.claude/skills-ja/integration-e2e-testing/SKILL.md

@@ -45,6 +45,8 @@ description: 統合テストとE2Eテストを設計。モック境界と振る
 
 ### 必須コメント形式
 
+コミットするスケルトンは、テストフレームワーク（`describe`/`it`/`it.todo` 用）のみを import する。テスト対象モジュールは実装タスクが import するものであり、スケルトンでは import しない — まだ作成されていないモジュールを参照するスケルトンは、テストファイルを型チェック・コンパイル・ロードするゲートが実装着手前に失敗し得る。
+
 各テストに以下のアノテーションを含めること。
 
 ```typescript

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

@@ -211,14 +211,9 @@ quality-fixerが `status: "blocked"` を返した場合、`reason`で判別：
 
 注: 小規模スケールでも実装ステップは task-executor を介して標準の4ステップサイクル（`task-executor → エスカレーション判定 → quality-fixer → commit`）で実行する。オーケストレーターによる直接編集は行わない。
 
-### Implementation Readinessマーカー
+### 任意の事前検証（Optional Preflight）
 
-Medium / Large規模では、一括承認後、作業計画書のヘッダに `Implementation Readiness:` 行が含まれる（work-plannerが`pending`を出力する。`ready` または `escalated` への昇格は外部オーケストレーションの関心事である）。マーカーは以下3値のいずれかを取る:
-- `pending` — work-plannerが設定する初期状態
-- `ready` — readiness検証が完了し残存ギャップなし。タスク実行サイクルを安全に開始できる
-- `escalated` — readiness検証は完了したが残存ギャップが存在し、実行前にユーザー判断が必要
-
-`pending`から先へマーカーを昇格させるプロデューサと、task-executor呼び出し前にマーカーを読むコンシューマは、いずれも外部オーケストレーションが所有する。本ガイドはエージェント層の上位にあるオーケストレーターを呼び出さない。エージェントは明示的に依頼された場合にのみマーカーを読み書きする。
+Medium / Large規模では、一括承認後、実装はそのまま進行する。計画がエンドツーエンドで実装可能か（検証戦略の参照、fixture、UI 描画面、E2E/ローカルレーン環境）の検証は、ユーザーが任意に prepare-implementation レシピで実行する事前検証であり、readiness 基準が既に満たされていれば no-op で終了する。本ガイドはエージェント層の上位にあるオーケストレーターを呼び出さない。
 
 ## レイヤー横断オーケストレーション
 

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

@@ -51,7 +51,7 @@ skills:
   typescript-testing:
     skill: "typescript-testing"
     tags: [quality, testing, coverage, vitest, backend, implementation]
-    typical-use: "バックエンドテスト作成、Vitest設定、70%カバレッジ要件、テスト品質基準"
+    typical-use: "バックエンドテスト作成、Vitest設定、カバレッジ方針、テスト品質基準"
     size: small
     key-references:
       - "Vitest公式ドキュメント"
@@ -200,12 +200,12 @@ skills:
   frontend-typescript-testing:
     skill: "frontend-typescript-testing"
     tags: [frontend, react, quality, testing, coverage, vitest, react-testing-library, msw, component-testing, implementation, playwright, e2e]
-    typical-use: "Reactコンポーネントのテスト作成、React Testing Library、MSW、60%カバレッジ要件、Co-location、Playwright E2Eテスト"
+    typical-use: "Reactコンポーネントのテスト作成、React Testing Library、MSW、カバレッジ方針、Co-location、Playwright E2Eテスト"
     size: small
     key-references:
       - "React Testing Library - Kent C. Dodds"
       - "MSW (Mock Service Worker) - API Mocking"
-      - "ADR-0002 Co-location原則"
+      - "Co-location原則"
       - "references/e2e.md - Playwright E2Eパターン"
     sections:
       - "参照"

package/.claude/skills-ja/technical-spec/SKILL.md

@@ -92,6 +92,7 @@ package.jsonの`packageManager`フィールドに応じた実行コマンドを
 - **キャッシュ問題**: `test:coverage:fresh` スクリプトを実行
 - **依存関係エラー**: 依存関係のクリーンインストールを実行
 
-### カバレッジ要件
-- **必須**: ユニットテストカバレッジは70%以上
-- **メトリクス**: Statements、Branches、Functions、Lines
+### カバレッジ
+- カバレッジは目標ではなく未テスト領域を見つける診断シグナルとして扱う（目標化すると自明なテストに歪む — グッドハートの法則）。クリティカルパスとビジネスロジックなど、リグレッションが問題になる箇所にテストを集中させる
+- 強制する数値しきい値はプロジェクトの CI / カバレッジ設定であり、それ自体が目的ではない
+- **メトリクス**（カバレッジレポートの内訳）: Statements、Branches、Functions、Lines

package/.claude/skills-ja/typescript-testing/SKILL.md

@@ -14,14 +14,14 @@ description: Vitestテスト設計と品質基準を適用。カバレッジ要
 ## テストの基本方針
 
 ### 品質要件
-- **カバレッジ**: 単体テストのカバレッジは70%以上を必須
+- **カバレッジ**: カバレッジは目標ではなく未テスト領域を見つける診断シグナルとして扱う（目標化すると自明なテストに歪む — グッドハートの法則）。クリティカルパス・ビジネスロジック・リグレッションが問題になる振る舞いにテストを集中させる。数値しきい値はプロジェクトの CI 設定に委ねる
 - **独立性**: 各テストは他のテストに依存せず実行可能
 - **再現性**: テストは環境に依存せず、常に同じ結果を返す
 - **可読性**: テストコードも製品コードと同様の品質を維持
 
-### カバレッジ要件
-**必須**: 単体テストのカバレッジは70%以上
-**指標**: Statements（文）、Branches（分岐）、Functions（関数）、Lines（行）
+### カバレッジ
+- カバレッジ数値よりも意味のあるアサーションを優先する。パーセンテージ達成のためではなく、ギャップが実際のリグレッションを無防備にしている箇所でカバレッジを上げる
+- **指標**（カバレッジレポートの内訳）: Statements（文）、Branches（分岐）、Functions（関数）、Lines（行）
 
 ### テストの種類と範囲
 1. **単体テスト（Unit Tests）**

package/CHANGELOG.md

@@ -5,6 +5,22 @@ 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.5] - 2026-06-14
+
+### Changed
+
+- **Adjacent-case sweep** (agents, skills) — bug-fix / regression / state-change / boundary-change tasks carry a `Change Category` that drives a scoped sweep of sibling cases sharing the change's path, contract, state, or boundary: `task-decomposer` extends Investigation Targets, `task-executor` / `-frontend` fold in-scope residuals into tests and escalate confirmed out-of-scope siblings, `code-reviewer` adds an `adjacent_residual` finding (with optional `taskFiles` input and a self-classification fallback), and `verifier` / `solver` trace adjacent cases. Applied across en/ja.
+- **Frontend rules modernization** (skills) — `frontend-typescript-rules` adopts bundler-agnostic env access (Vite / Next.js / CRA prefixes), React Compiler-aware memoization, a `useEffect` race/cleanup guard, RSC Server/Client boundary guidance, and a project-defined bundle budget in place of a fixed size.
+- **Coverage reframed as a signal** (agents, skills) — coverage is a diagnostic signal rather than a target (Goodhart's Law), with any threshold deferred to the project's CI config; removed an invented standard label and a dangling ADR reference across the testing/spec skills.
+
+## [1.23.4] - 2026-06-09
+
+### Changed
+
+- **Implementation Readiness gate → optional preflight** (agents, commands, skills) — The work plan no longer carries an `Implementation Readiness` marker and the build / front-build / implement recipes no longer halt on it. Verifying a plan is implementable end-to-end is now an optional, user-invoked preflight via `prepare-implementation`, which presents its Readiness Report in-session (instead of persisting it into the plan or promoting a header marker) and records committed Phase 0 tasks as done so `task-decomposer` does not regenerate them. `plan` surfaces the preflight as a conditional suggestion; `subagents-orchestration-guide` describes it as optional. Applied across en/ja.
+- **Test skeletons stay green under static gates** (agents, skills) — `acceptance-test-generator` and `integration-e2e-testing` bound skeleton generation so a committed skeleton imports only the test framework (no module under test, assertions, or mocks); the implementing task adds executable code alongside the implementation, keeping a freshly committed skeleton green under typecheck / compile / test-load gates.
+- **Removed decorative emojis** (agents, commands) — Stripped pictographic emojis from prompt files and simplified `task-executor` progress states to `[ ] → [x]`. Functional symbols (`[ ]` / `[x]` checkboxes, `→` flow arrows, check / cross marks) are retained.
+
 ## [1.23.3] - 2026-06-06
 
 ### Added

package/package.json

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