create-ai-project 1.23.3 → 1.23.4

package/.claude/agents-en/acceptance-test-generator.md

@@ -332,7 +332,8 @@ Upon completion, report in the following JSON format. Detailed meta information
 
 **Required Compliance**:
 - Output `it.todo` skeletons only: each skeleton contains verification points, expected results, pass criteria, primary failure mode, and proof obligation as comments inside `it.todo` blocks.
-  Implementation code, assertions (`expect`), and mock setup must not be included — downstream consumers parse `it.todo` presence to determine phase placement and review status.
+  Import only the test-framework symbols the `it.todo` needs (e.g. `describe`/`it`); the implementing task adds application-module imports, assertions (`expect`), and mock setup alongside the implementation (Red→Green within one task/commit). Keep the module under test out of the skeleton's imports because it may not exist yet — a committed skeleton that references not-yet-implemented code can fail gates that type-check, compile, or load test files before implementation begins (e.g. TypeScript projects may report TS2307).
+  Downstream consumers parse `it.todo` presence to determine phase placement and review status.
 - Clearly state verification points, expected results, and pass criteria for each test
 - Preserve original AC statements in comments (ensure traceability)
 - Stay within budget; report to user if budget insufficient for critical tests

package/.claude/agents-en/quality-fixer-frontend.md

@@ -241,10 +241,10 @@ Minimal example (`blocked` — Variant B, missing prerequisites):
 During execution, report progress between tool calls using this format:
 
 ```markdown
-📋 Phase [Number]: [Phase Name]
+Phase [Number]: [Phase Name]
 
 Executed Command: [Command]
-Result: ❌ Errors [Count] / ⚠️ Warnings [Count] / ✅ Pass
+Result: Errors [Count] / Warnings [Count] / Pass
 
 Issues requiring fixes:
 1. [Issue Summary]
@@ -253,7 +253,7 @@ Issues requiring fixes:
    - Fix Method: [Specific Fix Approach]
 
 [After Fix Implementation]
-✅ Phase [Number] Complete! Proceeding to next phase.
+Phase [Number] Complete! Proceeding to next phase.
 ```
 
 This is intermediate output only. The final response must be the JSON result (Step 6).

package/.claude/agents-en/quality-fixer.md

@@ -205,10 +205,10 @@ Minimal example (`blocked` — Variant B, missing prerequisites):
 During execution, report progress between tool calls using this format:
 
 ```markdown
-📋 Phase [Number]: [Phase Name]
+Phase [Number]: [Phase Name]
 
 Executed Command: [Command]
-Result: ❌ Errors [Count] / ⚠️ Warnings [Count] / ✅ Pass
+Result: Errors [Count] / Warnings [Count] / Pass
 
 Issues requiring fixes:
 1. [Issue Summary]
@@ -217,7 +217,7 @@ Issues requiring fixes:
    - Fix Method: [Specific Fix Approach]
 
 [After Fix Implementation]
-✅ Phase [Number] Complete! Proceeding to next phase.
+Phase [Number] Complete! Proceeding to next phase.
 ```
 
 This is intermediate output only. The final response must be the JSON result (Step 6).

package/.claude/agents-en/task-decomposer.md

@@ -65,6 +65,7 @@ Decompose tasks based on implementation strategy patterns determined in implemen
 2. **Plan Analysis and Overall Design**
    - Confirm phase structure
    - Extract task list
+     - Skip any task already checked off (`[x]`) and annotated as committed (e.g. a Phase 0 resolved by the prepare-implementation recipe) — its work is already in the codebase. Generate task files only for outstanding (`[ ]`) tasks so completed work is not regenerated or re-executed
    - Identify dependencies
    - **Overall Optimization Considerations**
      - Identify common processing (prevent redundant implementation)
@@ -287,7 +288,7 @@ Task 3: [Content]
 ### Decomposition Completion Report
 
 ```markdown
-📋 Task Decomposition Complete
+Task Decomposition Complete
 
 Plan Document: [Filename]
 Overall Design Document: _overview-[plan-name].md

package/.claude/agents-en/task-executor-frontend.md

@@ -116,7 +116,7 @@ Internal detail optimization (variable names, logic order); specs not in Design
 
 ## Responsibilities, Authority, and Boundaries
 
-**In scope**: Read task files from `docs/plans/tasks/`, review dependency deliverables listed in task "Metadata", create React function components and React Testing Library tests, co-locate tests with components, apply Red→Green→Refactor TDD, update progress checkboxes (task file always; work plan and overall design only when those files exist — at small scale only the task file exists), produce research deliverables specified in `Provides`. State transitions: `[ ]` → `[🔄]` → `[x]`.
+**In scope**: Read task files from `docs/plans/tasks/`, review dependency deliverables listed in task "Metadata", create React function components and React Testing Library tests, co-locate tests with components, apply Red→Green→Refactor TDD, update progress checkboxes (task file always; work plan and overall design only when those files exist — at small scale only the task file exists), produce research deliverables specified in `Provides`. State transitions: `[ ]` → `[x]`.
 
 **Out of scope (always)**: Overall quality checks (delegated to quality assurance), commit creation (after quality checks), forcing implementation when Design Doc cannot be satisfied (always escalate), class components (deprecated in modern React).
 

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

@@ -116,7 +116,7 @@ Internal detail optimization (variable names, processing order); specs not in De
 
 ## Responsibilities, Authority, and Boundaries
 
-**In scope**: Read task files from `docs/plans/tasks/`, review dependency deliverables listed in task "Metadata", create implementation and tests, apply Red→Green→Refactor TDD, update progress checkboxes (task file always; work plan and overall design only when those files exist — at small scale only the task file exists), produce research deliverables specified in `Provides`. State transitions: `[ ]` → `[🔄]` → `[x]`.
+**In scope**: Read task files from `docs/plans/tasks/`, review dependency deliverables listed in task "Metadata", create implementation and tests, apply Red→Green→Refactor TDD, update progress checkboxes (task file always; work plan and overall design only when those files exist — at small scale only the task file exists), produce research deliverables specified in `Provides`. State transitions: `[ ]` → `[x]`.
 
 **Out of scope (always)**: Overall quality checks (delegated to quality assurance), commit creation (after quality checks), forcing implementation when Design Doc cannot be satisfied (always escalate).
 

package/.claude/agents-en/work-planner.md

@@ -55,7 +55,7 @@ fixture-e2e gap:
     AND e2eAbsenceReason.fixtureE2e was not communicated
     AND Design Doc or UI Spec contains user-facing multi-step user journey
   THEN add to work plan header:
-    ⚠ fixture-e2e Gap: This feature contains user-facing multi-step journey(s)
+    fixture-e2e Gap: This feature contains user-facing multi-step journey(s)
     but no fixture-e2e skeleton was provided. Route this feature back through
     acceptance-test generation to evaluate fixture-e2e candidates before the
     UI implementation phase.
@@ -68,7 +68,7 @@ service-integration-e2e gap:
         verification (data persistence across services, transactional
         consistency, external service contract)
   THEN add to work plan header:
-    ⚠ service-integration-e2e Gap: This feature crosses service boundaries
+    service-integration-e2e Gap: This feature crosses service boundaries
     where correctness depends on real cross-service behavior, but no
     service-integration-e2e skeleton was provided.
     Detected boundaries: [list crossings and AC references]
@@ -159,8 +159,6 @@ For each task, derive completion criteria from Design Doc acceptance criteria. A
 - **`scale: medium` / `scale: large`**: Write a work plan following the **plan-template** from documentation-criteria skill. Include Phase Structure Diagram and Task Dependency Diagram (mermaid).
 - **`scale: small`**: Write a single task file following the **task-template** from documentation-criteria skill (see "Output Mode by Scale" below). Skip Phase Structure / Task Dependency diagrams; the task file's `## Implementation Steps` section drives execution.
 
-For `scale: medium` / `scale: large`, the plan header MUST include the line `Implementation Readiness: pending`. The marker contract: it takes one of three values — `pending` (initial, set here by work-planner), `ready` (verification completed with no remaining gaps), or `escalated` (verification completed with remaining gaps). The producer that promotes the marker beyond `pending` and the consumer that reads it before execution are external orchestration concerns owned outside this agent.
-
 ## Input Parameters
 
 - **mode**: `create` (default) | `update`
@@ -365,7 +363,6 @@ When creating work plans, **Phase Structure Diagrams** and **Task Dependency Dia
   - [ ] Each row's `Axis` value is exactly one of `placement` | `dependency_direction` | `contract_schema` | `data_flow` | `persistence`
   - [ ] Each row's `Source Section` is set to `Decision` or `Implementation Guidance` matching the actual location of the decision in the ADR
   - [ ] Every row maps to at least one covering task
-- [ ] Plan header includes `Implementation Readiness: pending` (medium / large only)
 - [ ] Verification Strategy extracted from Design Doc and included in plan header
 - [ ] Proof Strategy included in plan header (proof obligation source + per-task propagation rule)
 - [ ] Review Scope recorded in plan header (base branch / diff range / changed-files scope)

package/.claude/agents-ja/acceptance-test-generator.md

@@ -334,7 +334,8 @@ it.todo('[AC番号]-property: [不変条件を自然言語で記述]')
 
 **必須準拠事項**:
 - `it.todo`スケルトンのみ出力: 各スケルトン内にコメントとして検証観点、期待結果、合格基準、主要な故障モード、証明義務を記述。
-  実装コード、アサーション(`expect`)、モックセットアップは含めない — 下流の処理で`it.todo`の有無によりフェーズ配置やレビュー判定が行われる。
+  `it.todo` が必要とするテストフレームワークのシンボル（`describe`/`it` など）のみを import する。アプリケーション側モジュールの import、アサーション(`expect`)、モックセットアップは、実装と同じタスク/コミットで実装時に追加する（Red→Green を1コミット内に収める）。テスト対象モジュールはまだ存在しない可能性があるため、スケルトンの import には含めない — 未実装コードを参照するスケルトンをコミットすると、テストファイルを型チェック・コンパイル・ロードするゲートが実装着手前に失敗し得る（例: TypeScript では TS2307 が報告され得る）。
+  下流の処理では`it.todo`の有無によりフェーズ配置やレビュー判定が行われる。
 - 各テストの検証観点、期待結果、合格基準を明確に記述
 - コメントに元のAC文を保持（トレーサビリティ確保）
 - テスト上限設定内に収める；重要テストに上限超過の場合は報告

package/.claude/agents-ja/quality-fixer-frontend.md

@@ -241,10 +241,10 @@ package.json からフロントエンドビルドコマンドを自動検出し
 実行中、ツール呼び出しの間に以下のフォーマットで進捗を報告する:
 
 ```markdown
-📋 Phase [番号]: [フェーズ名]
+Phase [番号]: [フェーズ名]
 
 実行コマンド: [コマンド]
-結果: ❌ エラー [件数] / ⚠️ 警告 [件数] / ✅ パス
+結果: エラー [件数] / 警告 [件数] / パス
 
 修正が必要な問題:
 1. [問題概要]
@@ -253,7 +253,7 @@ package.json からフロントエンドビルドコマンドを自動検出し
    - 修正方法: [具体的な修正アプローチ]
 
 [修正実施後]
-✅ Phase [番号] 完了！次のフェーズへ進みます。
+Phase [番号] 完了！次のフェーズへ進みます。
 ```
 
 これは中間出力であり、最終レスポンスはJSON結果（ステップ6）で出力する。

package/.claude/agents-ja/quality-fixer.md

@@ -205,10 +205,10 @@ coding-standardsおよびtypescript-testingスキルに従って修正を適用
 実行中、ツール呼び出しの間に以下のフォーマットで進捗を報告する:
 
 ```markdown
-📋 Phase [番号]: [フェーズ名]
+Phase [番号]: [フェーズ名]
 
 実行コマンド: [コマンド]
-結果: ❌ エラー [件数] / ⚠️ 警告 [件数] / ✅ パス
+結果: エラー [件数] / 警告 [件数] / パス
 
 修正が必要な問題:
 1. [問題概要]
@@ -217,7 +217,7 @@ coding-standardsおよびtypescript-testingスキルに従って修正を適用
    - 修正方法: [具体的な修正アプローチ]
 
 [修正実施後]
-✅ Phase [番号] 完了！次のフェーズへ進みます。
+Phase [番号] 完了！次のフェーズへ進みます。
 ```
 
 これは中間出力であり、最終レスポンスはJSON結果（ステップ6）で出力する。

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

@@ -65,6 +65,7 @@ implementation-approachスキルで決定された実装戦略パターンに基
 2. **計画書の分析と全体設計**
    - フェーズ構成の確認
    - タスクリストの抽出
+     - `[x]` で完了マーク済みかつコミット済みと注記されたタスク（例: prepare-implementation レシピが解消した Phase 0）はスキップする — その作業は既にコードベースに存在する。未消化（`[ ]`）のタスクのみタスクファイルを生成し、完了済みの作業を再生成・再実行しない
    - 依存関係の特定
    - **全体最適化の検討**
      - 共通処理の識別（冗長実装の防止）
@@ -287,7 +288,7 @@ implementation-approachスキルで決定された実装戦略パターンに基
 ### 分解完了レポート
 
 ```markdown
-📋 タスク分解完了
+タスク分解完了
 
 計画書: [ファイル名]
 全体設計書: _overview-[plan-name].md

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

@@ -116,7 +116,7 @@ package.json の `packageManager` フィールドに従って実行コマンド
 
 ## 責務・権限・境界
 
-**範囲内**: `docs/plans/tasks/` からタスクファイルを読み込み、タスクの「Metadata」に記載された依存成果物を確認、React 関数コンポーネントと React Testing Library テストを作成、テストはコンポーネントと共に配置（co-locate）、Red→Green→Refactor のTDDを適用、進捗チェックボックスを更新（タスクファイルは常時更新。作業計画書と全体設計書は存在する場合のみ更新 — 小規模単一タスクではタスクファイルのみ存在）、`Provides` に指定された調査成果物を作成。状態遷移: `[ ]` → `[🔄]` → `[x]`。
+**範囲内**: `docs/plans/tasks/` からタスクファイルを読み込み、タスクの「Metadata」に記載された依存成果物を確認、React 関数コンポーネントと React Testing Library テストを作成、テストはコンポーネントと共に配置（co-locate）、Red→Green→Refactor のTDDを適用、進捗チェックボックスを更新（タスクファイルは常時更新。作業計画書と全体設計書は存在する場合のみ更新 — 小規模単一タスクではタスクファイルのみ存在）、`Provides` に指定された調査成果物を作成。状態遷移: `[ ]` → `[x]`。
 
 **範囲外（常に）**: 全体品質チェック（品質保証工程に委譲）、コミット作成（品質チェック後に実施）、Design Doc を満たせない場合の強行（必ずエスカレーション）、クラスコンポーネント（モダン React では非推奨）。
 

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

@@ -116,7 +116,7 @@ package.json の `packageManager` フィールドに従って実行コマンド
 
 ## 責務・権限・境界
 
-**範囲内**: `docs/plans/tasks/` からタスクファイルを読み込み、タスクの「Metadata」に記載された依存成果物を確認、実装とテストを作成、Red→Green→Refactor のTDDを適用、進捗チェックボックスを更新（タスクファイルは常時更新。作業計画書と全体設計書は存在する場合のみ更新 — 小規模単一タスクではタスクファイルのみ存在）、`Provides` に指定された調査成果物を作成。状態遷移: `[ ]` → `[🔄]` → `[x]`。
+**範囲内**: `docs/plans/tasks/` からタスクファイルを読み込み、タスクの「Metadata」に記載された依存成果物を確認、実装とテストを作成、Red→Green→Refactor のTDDを適用、進捗チェックボックスを更新（タスクファイルは常時更新。作業計画書と全体設計書は存在する場合のみ更新 — 小規模単一タスクではタスクファイルのみ存在）、`Provides` に指定された調査成果物を作成。状態遷移: `[ ]` → `[x]`。
 
 **範囲外（常に）**: 全体品質チェック（品質保証工程に委譲）、コミット作成（品質チェック後に実施）、Design Doc を満たせない場合の強行（必ずエスカレーション）。
 

package/.claude/agents-ja/work-planner.md

@@ -55,7 +55,7 @@ fixture-e2e gap:
     AND e2eAbsenceReason.fixtureE2eが伝達されていない
     AND Design DocまたはUI Specにユーザー向けマルチステップジャーニーが含まれる
   THEN 作業計画書ヘッダーに追記:
-    ⚠ fixture-e2e Gap: この機能にはユーザー向けマルチステップジャーニーが含まれますが、
+    fixture-e2e Gap: この機能にはユーザー向けマルチステップジャーニーが含まれますが、
     fixture-e2eスケルトンが提供されていません。UI実装フェーズの前に、受入テスト生成
     へ差し戻して fixture-e2e 候補を評価する。
     検出されたジャーニー: [ジャーニーの説明とAC参照のリスト]
@@ -66,7 +66,7 @@ service-integration-e2e gap:
     AND Design Docがジャーニーに実サービス間検証（複数サービスをまたぐデータ永続化、
         トランザクション整合性、外部サービスコントラクト）を要求する
   THEN 作業計画書ヘッダーに追記:
-    ⚠ service-integration-e2e Gap: この機能はサービス境界をまたぎ、正しさが
+    service-integration-e2e Gap: この機能はサービス境界をまたぎ、正しさが
     実サービス間挙動に依存しますが、service-integration-e2eスケルトンが
     提供されていません。
     検出された境界: [境界の記述とAC参照のリスト]
@@ -157,8 +157,6 @@ ADRが入力に含まれる場合、またはDesign Docが「Prerequisite ADRs
 - **`scale: medium` / `scale: large`**: documentation-criteria スキルの **plan-template** に従って作業計画書を記述。フェーズ構成図とタスク依存関係図（mermaid）を含める。
 - **`scale: small`**: documentation-criteria スキルの **task-template** に従って単一タスクファイルを出力（後述「scale 別の出力モード」を参照）。フェーズ構成図・タスク依存関係図はスキップ。タスクファイルの `## Implementation Steps` セクションが実行を駆動する。
 
-`scale: medium` / `scale: large` の場合、計画書ヘッダーには `Implementation Readiness: pending` の行を必ず含める。マーカーの契約: 値は `pending`（初期。本エージェントが設定）、`ready`（検証完了、残存ギャップなし）、`escalated`（検証完了、残存ギャップあり）の3つのいずれか。`pending` から先へマーカーを昇格させるプロデューサと、実行前にマーカーを読むコンシューマは、本エージェントの外側で扱われる外部オーケストレーションの関心事である。
-
 ## Input Parameters
 
 - **mode**: `create`（デフォルト）| `update`
@@ -362,7 +360,6 @@ Design Docの技術的依存関係と実装アプローチに基づいてフェ
   - [ ] 各行の `Axis` 値が `placement` | `dependency_direction` | `contract_schema` | `data_flow` | `persistence` のちょうど1つである
   - [ ] 各行の `Source Section` が、ADR内の決定の実際の所在に一致する `Decision` または `Implementation Guidance` に設定されている
   - [ ] 全行が少なくとも1つのカバータスクにマッピングされている
-- [ ] 計画書ヘッダーに `Implementation Readiness: pending` を含める（medium / large のみ）
 - [ ] Design Docから検証戦略を抽出し計画書ヘッダーに記載
 - [ ] 計画書ヘッダーに証明戦略を記載（証明義務の出所 + タスクごとの伝播ルール）
 - [ ] 計画書ヘッダーにレビュースコープを記録（ベースブランチ / diff範囲 / 変更ファイル範囲）

package/.claude/commands-en/build.md

@@ -18,9 +18,9 @@ Work plan: $ARGUMENTS
 
 ## Pre-execution Prerequisites
 
-### Implementation Readiness Check
+### Work Plan Resolution
 
-Before any task processing, locate the work plan to gate against.
+Before any task processing, locate the work plan.
 
 **When `$ARGUMENTS` is provided**, it is the work plan path supplied by the user. Use it directly without auto-resolution. Extract `{plan-name}` from the filename by stripping the `.md` extension (and any trailing `-plan` suffix when present).
 
@@ -51,27 +51,18 @@ Before any task processing, locate the work plan to gate against.
    - Otherwise (no backend signal found, OR any frontend signal present, OR layer-neutral paths only) → stop and report: "Cannot positively verify the most-recent work plan at `[path]` is a backend plan (signals examined: [list of signals checked and their results]). Pass the intended backend plan path as `$ARGUMENTS`, or run task-decomposer first to populate `docs/plans/tasks/` with backend-named task files."
 7. When no plan exists at all in `docs/plans/`, stop and report: "No work plan found. Pass a work plan path as `$ARGUMENTS`, or complete the planning phase first."
 
-Read the work plan header and find the line `Implementation Readiness: <status>`. Apply this rule:
-
-| Status | Action |
-|--------|--------|
-| `ready` | Proceed to Consumed Task Set computation |
-| `escalated` | Read the work plan's Readiness Report section, surface remaining gaps to the user via AskUserQuestion: "Implementation Readiness is `escalated` with the following remaining gaps: [list]. Continue execution? (y/n)". On `y` proceed; on `n` stop |
-| `pending` | Present via AskUserQuestion: "Implementation Readiness is `pending`. Run the readiness preflight first to verify the work plan is implementable, then resume. Continue without preflight? (y/n)". On `y` proceed; on `n` stop |
-| absent (line missing) | Treat as `pending` — older work plans created before the readiness marker existed should be preflighted explicitly |
-
 ### Consumed Task Set
 
-Compute the **Consumed Task Set** for this run — the exact files this recipe owns, executes, and later deletes. Use the same consumable patterns as the Implementation Readiness Check:
+Compute the **Consumed Task Set** for this run — the exact files this recipe owns, executes, and later deletes. Use the same consumable patterns as Work Plan Resolution:
 
-1. List task files in `docs/plans/tasks/` matching `{plan-name}-task-*.md` OR `{plan-name}-backend-task-*.md` for the `{plan-name}` resolved by the readiness check. `{plan-name}-frontend-task-*.md` is excluded — it is owned by the frontend build recipe
+1. List task files in `docs/plans/tasks/` matching `{plan-name}-task-*.md` OR `{plan-name}-backend-task-*.md` for the `{plan-name}` resolved by Work Plan Resolution. `{plan-name}-frontend-task-*.md` is excluded — it is owned by the frontend build recipe
 2. Exclude every file matching: `*-task-prep-*.md`, `_overview-*.md`, `*-phase*-completion.md`, `review-fixes-*.md`, `integration-tests-*-task-*.md` (these originate from other workflow phases)
 
 Every subsequent reference to "task files" in this recipe — Task Generation Decision Flow, Task Execution Cycle iteration, and Final Cleanup — uses this set, not the unrestricted `docs/plans/tasks/*.md` glob.
 
 ### Task Generation Decision Flow
 
-Analyze the Consumed Task Set and determine the action required. Reaching this section implies the readiness check above resolved a work plan (Steps 1-6 succeeded); the "no plan" state is already terminated by readiness-check Step 7 and never reaches this table.
+Analyze the Consumed Task Set and determine the action required. Reaching this section implies Work Plan Resolution above resolved a work plan (Steps 1-6 succeeded); the "no plan" state is already terminated by Work Plan Resolution Step 7 and never reaches this table.
 
 | State | Criteria | Next Action |
 |-------|----------|-------------|
@@ -79,7 +70,7 @@ Analyze the Consumed Task Set and determine the action required. Reaching this s
 | No tasks + plan supplied via `$ARGUMENTS` | `$ARGUMENTS` provided AND Consumed Task Set empty | Confirm with user → run task-decomposer |
 | No tasks + plan auto-resolved | Consumed Task Set empty AND plan came from auto-resolution AND Step 6 confirmed at least one backend signal with zero frontend signals | Confirm with user → run task-decomposer (the layer verification in Step 6 already excluded frontend and ambiguous plans, so this is safe) |
 
-To bootstrap from a Design Doc when no plan exists yet, run the planning recipe first to produce a work plan, then re-invoke this recipe — the readiness check above intentionally requires a resolved work plan rather than auto-creating one, to keep the layer decision explicit.
+To bootstrap from a Design Doc when no plan exists yet, run the planning recipe first to produce a work plan, then re-invoke this recipe — Work Plan Resolution above intentionally requires a resolved work plan rather than auto-creating one, to keep the layer decision explicit.
 
 ## Task Decomposition Phase (Conditional)
 

package/.claude/commands-en/front-build.md

@@ -18,9 +18,9 @@ Work plan: $ARGUMENTS
 
 ## Pre-execution Prerequisites
 
-### Implementation Readiness Check
+### Work Plan Resolution
 
-Before any task processing, locate the work plan to gate against.
+Before any task processing, locate the work plan.
 
 **When `$ARGUMENTS` is provided**, it is the work plan path supplied by the user. Use it directly without auto-resolution. Extract `{plan-name}` from the filename by stripping the `.md` extension (and any trailing `-plan` suffix when present).
 
@@ -33,27 +33,18 @@ Before any task processing, locate the work plan to gate against.
 4. When at least one task file matches, the work plan is `docs/plans/{plan-name}.md` for the prefix that has the most recent task-file mtime; ties broken by the lexicographically last `{plan-name}`
 5. When no `*-frontend-task-*.md` is found AND a non-template work plan exists in `docs/plans/`, do not assume the most-recent plan applies — frontend tasks must be explicitly named. Stop and report: "No `*-frontend-task-*.md` found in `docs/plans/tasks/`. If you intended to run this recipe on a frontend plan, either re-run task-decomposer so it emits frontend-named task files, or pass the work plan path as `$ARGUMENTS`. If the plan is backend, use the backend build recipe instead."
 
-Read the work plan header and find the line `Implementation Readiness: <status>`. Apply this rule:
-
-| Status | Action |
-|--------|--------|
-| `ready` | Proceed to Consumed Task Set computation |
-| `escalated` | Read the work plan's Readiness Report section, surface remaining gaps to the user via AskUserQuestion: "Implementation Readiness is `escalated` with the following remaining gaps: [list]. Continue execution? (y/n)". On `y` proceed; on `n` stop |
-| `pending` | Present via AskUserQuestion: "Implementation Readiness is `pending`. Run the readiness preflight first to verify the work plan is implementable, then resume. Continue without preflight? (y/n)". On `y` proceed; on `n` stop |
-| absent (line missing) | Treat as `pending` — older work plans created before the readiness marker existed should be preflighted explicitly |
-
 ### Consumed Task Set
 
 Compute the **Consumed Task Set** for this run — the exact files this recipe owns, executes, and later deletes. Per the routing table, the only consumable pattern is:
 
-1. List task files in `docs/plans/tasks/` matching `{plan-name}-frontend-task-*.md` for the `{plan-name}` resolved by the readiness check. `{plan-name}-task-*.md` and `{plan-name}-backend-task-*.md` are excluded — they route to `task-executor` and are owned by the backend build recipe
+1. List task files in `docs/plans/tasks/` matching `{plan-name}-frontend-task-*.md` for the `{plan-name}` resolved by Work Plan Resolution. `{plan-name}-task-*.md` and `{plan-name}-backend-task-*.md` are excluded — they route to `task-executor` and are owned by the backend build recipe
 2. Exclude every file matching: `*-task-prep-*.md`, `_overview-*.md`, `*-phase*-completion.md`, `review-fixes-*.md`, `integration-tests-*-task-*.md` (these originate from other workflow phases)
 
 Every subsequent reference to "task files" in this recipe — Task Generation Decision Flow, Task Execution Cycle iteration, and Final Cleanup — uses this set, not the unrestricted `docs/plans/tasks/*.md` glob.
 
 ### Task Generation Decision Flow
 
-Analyze the Consumed Task Set and determine the action required. Note: when `$ARGUMENTS` is empty AND no `*-frontend-task-*.md` exist, the readiness check above already stops execution — so the rows below that involve "no tasks" only fire when the user explicitly supplied `$ARGUMENTS`.
+Analyze the Consumed Task Set and determine the action required. Note: when `$ARGUMENTS` is empty AND no `*-frontend-task-*.md` exist, Work Plan Resolution above already stops execution — so the rows below that involve "no tasks" only fire when the user explicitly supplied `$ARGUMENTS`.
 
 | State | Criteria | Next Action |
 |-------|----------|-------------|

package/.claude/commands-en/implement.md

@@ -45,7 +45,7 @@ After scale determination, **register all steps of the applicable subagents-orch
 
 **Check next pending task with TaskList**.
 
-## 📋 subagents-orchestration-guide skill Compliance Execution
+## subagents-orchestration-guide skill Compliance Execution
 
 **Pre-execution Checklist (Required)**:
 - [ ] Confirmed relevant subagents-orchestration-guide skill flow
@@ -58,19 +58,6 @@ After scale determination, **register all steps of the applicable subagents-orch
 
 **Flow Adherence**: Follow "Autonomous Execution Task Management" in subagents-orchestration-guide skill, managing 4 steps with TaskCreate/TaskUpdate
 
-## Implementation Readiness Check (between work-planner approval and task-decomposer)
-
-After work-planner completes and the user grants batch approval, before invoking task-decomposer, read the work plan header and find the line `Implementation Readiness: <status>`. Apply this rule:
-
-| Status | Action |
-|--------|--------|
-| `ready` | Proceed to task-decomposer |
-| `escalated` | Read the work plan's Readiness Report section, surface remaining gaps to the user via AskUserQuestion: "Implementation Readiness is `escalated` with the following remaining gaps: [list]. Continue execution? (y/n)". On `y` proceed; on `n` stop |
-| `pending` | Present via AskUserQuestion: "Implementation Readiness is `pending`. Run the readiness preflight first to verify the work plan is implementable, then resume. Continue without preflight? (y/n)". On `y` proceed; on `n` stop |
-| absent (line missing) | Treat as `pending` — older work plans created before the readiness marker existed should be preflighted explicitly |
-
-This check applies to all scales (Small / Medium / Large) because this recipe is the scale-agnostic orchestrator.
-
 ## Scope Boundary for Subagents
 
 Append the following block to every subagent prompt invoked from this recipe:
@@ -87,7 +74,7 @@ Additionally, include the following constraint at the end of every sub-agent pro
 [Constraint] rule-advisor can only be used by Main AI
 ```
 
-## 🎯 Mandatory Orchestrator Responsibilities
+## Mandatory Orchestrator Responsibilities
 
 ### Task Execution Quality Cycle
 Following "Autonomous Execution Task Management" in subagents-orchestration-guide skill, manage these steps with TaskCreate/TaskUpdate:

package/.claude/commands-en/plan.md

@@ -76,11 +76,16 @@ Create a work plan from the selected design document, clarifying specific implem
 **Scope**: Up to work plan creation and obtaining approval for plan content.
 
 ## Response at Completion
-✅ **REQUIRED**: End with the following standard response after plan content approval
+**REQUIRED**: After plan content approval, output the following standard response
 ```
 Planning phase completed.
 - Work plan: docs/plans/[plan-name].md
 - Status: Approved
 
 Please provide separate instructions for implementation.
-```
+```
+
+When the approved plan includes any of the following — E2E test skeletons; a Verification Strategy referencing commands, files, functions, or endpoints not yet in the codebase; UI components without a fixture entry or dev route to render their states; or a local lane not yet confirmed to run end-to-end — append one more line as the final line of the response (omit it otherwise):
+```
+Optional preflight: `/prepare-implementation docs/plans/[plan-name].md` verifies these are implementable before build (exits no-op when readiness criteria already pass).
+```

package/.claude/commands-en/prepare-implementation.md

@@ -11,7 +11,7 @@ description: Verify implementation readiness and resolve gaps before the build p
 **Execution Protocol**:
 1. **Delegate all work through Agent tool** — invoke sub-agents (task-executor / task-executor-frontend / quality-fixer / quality-fixer-frontend), pass deliverable paths between them, and report results
 2. **Self-contained scope**: When gaps are found, this recipe BOTH generates resolution tasks AND executes them through the standard 4-step cycle described in subagents-orchestration-guide "Standard Flow I Manage". Recipe completes only when readiness criteria pass or remaining gaps are escalated.
-3. **No-op exit**: When the readiness scan finds no failing criteria, generate no resolution tasks and exit immediately. The only file modifications in this branch are to the work plan itself — promoting the `Implementation Readiness:` header to `ready` and persisting the Readiness Report section. No code or test files are touched.
+3. **No-op exit**: When the readiness scan finds no failing criteria, generate no resolution tasks and exit immediately, presenting the Readiness Report to the user. No files are modified in this branch.
 
 Work plan: $ARGUMENTS
 
@@ -74,11 +74,9 @@ Build the Readiness Report (see Output Format) regardless of outcome.
 ### Step 3: No-op Check
 
 When every applicable criterion is `pass` (zero `fail`):
-- Append (or replace, if already present) a `## Implementation Readiness Report` section in the work plan immediately after the header block, using the same Readiness Report markdown defined in Output Format below
-- Update the work plan header `Implementation Readiness:` line to `ready` (insert it after `Related Issue/PR:` if absent)
-- Present the Readiness Report to the user
+- Present the Readiness Report (see Output Format below) to the user
 - Exit with `outcome: ready, gaps_resolved: 0`
-- The work plan modifications above are the only file modifications in this branch
+- No files are modified in this branch
 
 When one or more criteria are `fail` → proceed to Step 4.
 
@@ -115,20 +113,13 @@ For each resolution task, run the 4-step cycle `task-executor → escalation che
 
 Append the Scope Boundary block (below) to every subagent prompt.
 
-### Step 6: Re-scan, Persist Readiness Report, Update Header, Cleanup, Exit
+### Step 6: Re-scan, Record Phase 0 Completion, Present Readiness Report, Cleanup, Exit
 
 1. **Re-scan**: Re-run the Step 2 readiness scan after all resolution tasks are committed.
 
-2. **Persist Readiness Report into work plan body**: Append (or replace, if already present) a `## Implementation Readiness Report` section in the work plan immediately after the header block. Use the same Readiness Report markdown defined in Output Format below. Downstream build/implement recipes read this section when the header is `escalated` to surface remaining gaps to the user.
+2. **Record Phase 0 completion in the work plan**: For each Phase 0 resolution task that was committed, check off its checkbox (`[x]`) in the work plan's Phase 0 section and annotate it as committed (append ` — committed`). This records the durable outcome in the plan so the downstream task-decomposer skips already-committed Phase 0 work instead of regenerating and re-executing it.
 
-3. **Update work plan header**: Locate the line `Implementation Readiness: pending` in the work plan and rewrite it based on the re-scan outcome:
-
-   | Re-scan result | New header value |
-   |----------------|------------------|
-   | All applicable criteria `pass` | `Implementation Readiness: ready` |
-   | One or more `fail` remain | `Implementation Readiness: escalated` |
-
-   If the line is absent (older work plan format), insert it after the `Related Issue/PR:` line.
+3. **Present Readiness Report**: Present the Readiness Report (see Output Format below) to the user. The report is shown in-session and is not written into the work plan — the durable output of this recipe is the committed Phase 0 resolution tasks (recorded as completed in the plan per Step 6.2), not a persisted report.
 
 4. **Final Cleanup**: Delete every prep task file this recipe created for the current `{plan-name}` (`docs/plans/tasks/{plan-name}-backend-task-prep-*.md` and `docs/plans/tasks/{plan-name}-frontend-task-prep-*.md`) AND the phase-completion file generated for prep phases (`docs/plans/tasks/{plan-name}-phase0-completion.md` when present, since prep tasks live in Phase 0). Prep task files for other plans are out of scope — this recipe deletes only what it created for the current run. Their work is committed; `docs/plans/` is ephemeral working state and is not retained between recipe runs. The work plan itself is preserved for the downstream build/implement phase.
 
@@ -185,7 +176,6 @@ Gaps resolved: [N]
 - [ ] Readiness scan run with per-criterion result and evidence recorded
 - [ ] No-op exit when all `pass`, OR resolution tasks generated, approved, and executed via the 4-step cycle
 - [ ] Re-scan run after the last resolution task commits
-- [ ] `## Implementation Readiness Report` section persisted into the work plan body
-- [ ] Work plan header `Implementation Readiness:` line updated to `ready` or `escalated`
+- [ ] Committed Phase 0 tasks checked off (`[x]`) in the work plan so downstream decomposition skips them
 - [ ] Prep task files (and Phase 0 phase-completion file when generated) deleted from `docs/plans/tasks/`
 - [ ] Final report presented to the user

package/.claude/commands-en/sync-skills.md

@@ -43,9 +43,9 @@ Present proposals to user and apply after approval:
 
 ```
 [1/N] typescript-rules
-  ✅ sections: synchronized
-  💡 tags proposed: +[functional-programming]
-  💡 typical-use: "old description" → "new description"
+  sections: synchronized
+  tags proposed: +[functional-programming]
+  typical-use: "old description" → "new description"
 ```
 
 ## Completion Criteria

package/.claude/commands-ja/build.md

@@ -18,9 +18,9 @@ description: 分解済みタスクを自律実行モードで実装
 
 ## 実行前提条件
 
-### Implementation Readinessチェック
+### 作業計画書の解決
 
-タスク処理の前に、ゲート対象となる作業計画書を特定する。
+タスク処理の前に、作業計画書を特定する。
 
 **`$ARGUMENTS`が指定されている場合**は、それがユーザーから渡された作業計画書のパスである。自動解決を行わずそのまま使用する。`{plan-name}`はファイル名から `.md` 拡張子（および末尾に `-plan` がある場合はそれも）を除いて抽出する。
 
@@ -51,35 +51,26 @@ description: 分解済みタスクを自律実行モードで実装
    - それ以外（backend 信号がない、または frontend 信号が1つでもある、または layer-neutral なパスのみ）→ 停止して報告する: 「最も新しい作業計画書 `[path]` が backend 計画であることを確証できません（確認した信号と結果: [リスト]）。意図する backend 計画書のパスを `$ARGUMENTS` で指定するか、task-decomposer を先に実行して `docs/plans/tasks/` に backend 命名のタスクファイルを出力してください。」
 7. `docs/plans/`に計画書が一切存在しない場合は、停止して報告する: 「作業計画書が見つかりません。作業計画書のパスを `$ARGUMENTS` で指定するか、計画フェーズを先に完了してください。」
 
-作業計画書のヘッダを読み、`Implementation Readiness: <status>`の行を見つける。以下のルールを適用する:
-
-| ステータス | アクション |
-|--------|--------|
-| `ready` | Consumed Task Set の計算へ進む |
-| `escalated` | 作業計画書のReadiness Reportセクションを読み、AskUserQuestionで残存ギャップをユーザーに提示する: 「Implementation Readinessが`escalated`で、以下の残存ギャップがあります: [リスト]。実行を継続しますか？(y/n)」。`y`なら進む、`n`なら停止 |
-| `pending` | AskUserQuestionで提示する: 「Implementation Readinessが`pending`です。事前にreadiness preflightを実行して作業計画書の実装可能性を検証してから再開してください。preflightなしで継続しますか？(y/n)」。`y`なら進む、`n`なら停止 |
-| 行が存在しない | `pending`として扱う — readinessマーカー導入前に作成された古い作業計画書は明示的にpreflightすべき |
-
 ### Consumed Task Set
 
-本実行で消費する **Consumed Task Set** を計算する — 本レシピが所有・実行・後で削除する正確なファイル群。Implementation Readinessチェックと同じ消費可能パターンを使用する:
+本実行で消費する **Consumed Task Set** を計算する — 本レシピが所有・実行・後で削除する正確なファイル群。作業計画書の解決と同じ消費可能パターンを使用する:
 
-1. Implementation Readinessチェックで解決した `{plan-name}` について、`docs/plans/tasks/`内で `{plan-name}-task-*.md` または `{plan-name}-backend-task-*.md` にマッチするタスクファイルを列挙する。`{plan-name}-frontend-task-*.md` は除外する — frontend build レシピが所有する
+1. 作業計画書の解決で確定した `{plan-name}` について、`docs/plans/tasks/`内で `{plan-name}-task-*.md` または `{plan-name}-backend-task-*.md` にマッチするタスクファイルを列挙する。`{plan-name}-frontend-task-*.md` は除外する — frontend build レシピが所有する
 2. 以下にマッチするファイルを除外する: `*-task-prep-*.md`、`_overview-*.md`、`*-phase*-completion.md`、`review-fixes-*.md`、`integration-tests-*-task-*.md`（これらは他のワークフローフェーズに由来する）
 
 本レシピ内で「タスクファイル」と参照する箇所すべて — タスク生成判定フロー、タスク実行サイクルの反復、最終クリーンアップ — はこのセットを使用する。`docs/plans/tasks/*.md` を制限なく glob しない。
 
 ### タスク生成判定フロー
 
-Consumed Task Set を確認し、適切な対応を決定する。注: 本セクションに到達するということは、上記の readiness check が作業計画書を解決済み（Steps 1-6 が成功）であることを意味する。「計画書なし」の状態は readiness check の Step 7 が既に終了させており、本表には到達しない。
+Consumed Task Set を確認し、適切な対応を決定する。注: 本セクションに到達するということは、上記の作業計画書の解決（Steps 1-6 が成功）で作業計画書が確定済みであることを意味する。「計画書なし」の状態は作業計画書の解決の Step 7 が既に終了させており、本表には到達しない。
 
 | 状態 | 判定基準 | 次のアクション |
 |------|---------|--------------|
 | タスク存在 | Consumed Task Set が非空 | ユーザーの実行指示をバッチ承認として自律実行へ移行 |
 | タスクなし + `$ARGUMENTS`で計画書指定 | `$ARGUMENTS`が提供され Consumed Task Set が空 | ユーザーに確認 → task-decomposer実行 |
-| タスクなし + 計画書を自動解決 | Consumed Task Set が空かつ計画書が自動解決（readiness check の Step 6 経由）で得られ、backend 信号 ≥1 かつ frontend 信号 = 0 が確認済み | ユーザーに確認 → task-decomposer実行（Step 6 のレイヤー検証で frontend / 不確定な計画は既に除外されているため安全） |
+| タスクなし + 計画書を自動解決 | Consumed Task Set が空かつ計画書が自動解決（作業計画書の解決の Step 6 経由）で得られ、backend 信号 ≥1 かつ frontend 信号 = 0 が確認済み | ユーザーに確認 → task-decomposer実行（Step 6 のレイヤー検証で frontend / 不確定な計画は既に除外されているため安全） |
 
-Design Doc から作業計画書がまだない状態で着手したい場合は、先に計画レシピを実行して計画書を生成してから本レシピを再起動する — 上記 readiness check は意図的に自動生成を行わず、レイヤー判断を明示的に保つ。
+Design Doc から作業計画書がまだない状態で着手したい場合は、先に計画レシピを実行して計画書を生成してから本レシピを再起動する — 上記の作業計画書の解決は意図的に自動生成を行わず、レイヤー判断を明示的に保つ。
 
 ## タスク分解フェーズ（条件付き実行）
 

package/.claude/commands-ja/front-build.md

@@ -18,9 +18,9 @@ description: フロントエンド実装を自律実行モードで実行
 
 ## 実行前提条件
 
-### Implementation Readinessチェック
+### 作業計画書の解決
 
-タスク処理の前に、ゲート対象となる作業計画書を特定する。
+タスク処理の前に、作業計画書を特定する。
 
 **`$ARGUMENTS`が指定されている場合**は、それがユーザーから渡された作業計画書のパスである。自動解決を行わずそのまま使用する。`{plan-name}`はファイル名から `.md` 拡張子（および末尾に `-plan` がある場合はそれも）を除いて抽出する。
 
@@ -33,27 +33,18 @@ description: フロントエンド実装を自律実行モードで実行
 4. 少なくとも1つのタスクファイルがマッチした場合、最も新しい mtime を持つ `{plan-name}` の `docs/plans/{plan-name}.md` を作業計画書とする。タイは辞書順最大の `{plan-name}` で解決する
 5. `*-frontend-task-*.md` が見つからず、かつ `docs/plans/`に非テンプレートの作業計画書が存在する場合、最も新しい計画書を自動採用してはならない — frontend タスクは明示的に命名されている必要がある。停止して報告する: 「`docs/plans/tasks/`に `*-frontend-task-*.md` が見つかりませんでした。本レシピを frontend 計画に対して実行する意図であれば、task-decomposer を再実行して frontend 命名のタスクファイルを出力させるか、作業計画書のパスを `$ARGUMENTS` で指定してください。計画が backend ならば、backend build レシピを使用してください。」
 
-作業計画書のヘッダを読み、`Implementation Readiness: <status>`の行を見つける。以下のルールを適用する:
-
-| ステータス | アクション |
-|--------|--------|
-| `ready` | Consumed Task Set の計算へ進む |
-| `escalated` | 作業計画書のReadiness Reportセクションを読み、AskUserQuestionで残存ギャップをユーザーに提示する: 「Implementation Readinessが`escalated`で、以下の残存ギャップがあります: [リスト]。実行を継続しますか？(y/n)」。`y`なら進む、`n`なら停止 |
-| `pending` | AskUserQuestionで提示する: 「Implementation Readinessが`pending`です。事前にreadiness preflightを実行して作業計画書の実装可能性を検証してから再開してください。preflightなしで継続しますか？(y/n)」。`y`なら進む、`n`なら停止 |
-| 行が存在しない | `pending`として扱う — readinessマーカー導入前に作成された古い作業計画書は明示的にpreflightすべき |
-
 ### Consumed Task Set
 
 本実行で消費する **Consumed Task Set** を計算する — 本レシピが所有・実行・後で削除する正確なファイル群。ルーティング表により、消費可能なパターンは1つだけ:
 
-1. Implementation Readinessチェックで解決した `{plan-name}` について、`docs/plans/tasks/`内で `{plan-name}-frontend-task-*.md` にマッチするタスクファイルを列挙する。`{plan-name}-task-*.md` および `{plan-name}-backend-task-*.md` は除外する — `task-executor` にルーティングされ、backend build レシピが所有する
+1. 作業計画書の解決で確定した `{plan-name}` について、`docs/plans/tasks/`内で `{plan-name}-frontend-task-*.md` にマッチするタスクファイルを列挙する。`{plan-name}-task-*.md` および `{plan-name}-backend-task-*.md` は除外する — `task-executor` にルーティングされ、backend build レシピが所有する
 2. 以下にマッチするファイルを除外する: `*-task-prep-*.md`、`_overview-*.md`、`*-phase*-completion.md`、`review-fixes-*.md`、`integration-tests-*-task-*.md`（これらは他のワークフローフェーズに由来する）
 
 本レシピ内で「タスクファイル」と参照する箇所すべて — タスク生成判定フロー、タスク実行サイクルの反復、最終クリーンアップ — はこのセットを使用する。`docs/plans/tasks/*.md` を制限なく glob しない。
 
 ### タスク生成判定フロー
 
-Consumed Task Set を確認し、適切な対応を決定する。注: `$ARGUMENTS`が空かつ `*-frontend-task-*.md` が存在しない場合は、上記の readiness check が既に実行を停止している — 以下の表で「タスクなし」が関わる行は、ユーザーが明示的に `$ARGUMENTS` を指定した場合にのみ発火する。
+Consumed Task Set を確認し、適切な対応を決定する。注: `$ARGUMENTS`が空かつ `*-frontend-task-*.md` が存在しない場合は、上記の作業計画書の解決が既に実行を停止している — 以下の表で「タスクなし」が関わる行は、ユーザーが明示的に `$ARGUMENTS` を指定した場合にのみ発火する。
 
 | 状態 | 基準 | 次のアクション |
 |------|------|--------------|

package/.claude/commands-ja/implement.md

@@ -45,7 +45,7 @@ requirement-analyzerの`crossLayerScope`がレイヤー横断（backend + fronte
 
 **TaskListで次のpendingタスクを確認して実行**。
 
-## 📋 subagents-orchestration-guideスキル準拠の実行
+## subagents-orchestration-guideスキル準拠の実行
 
 **実行前チェック（必須）**：
 - [ ] subagents-orchestration-guideスキルの該当フローを確認した
@@ -58,19 +58,6 @@ requirement-analyzerの`crossLayerScope`がレイヤー横断（backend + fronte
 
 **フロー厳守**: subagents-orchestration-guideスキルの「自律実行中のタスク管理」に従い、TaskCreate/TaskUpdateで4ステップを管理する
 
-## Implementation Readinessチェック（work-planner承認とtask-decomposerの間）
-
-work-plannerが完了しユーザーから一括承認を得た後、task-decomposerを呼び出す前に作業計画書のヘッダを読み、`Implementation Readiness: <status>`の行を見つける。以下のルールを適用する:
-
-| ステータス | アクション |
-|--------|--------|
-| `ready` | task-decomposerに進む |
-| `escalated` | 作業計画書のReadiness Reportセクションを読み、AskUserQuestionで残存ギャップをユーザーに提示する: 「Implementation Readinessが`escalated`で、以下の残存ギャップがあります: [リスト]。実行を継続しますか？(y/n)」。`y`なら進む、`n`なら停止 |
-| `pending` | AskUserQuestionで提示する: 「Implementation Readinessが`pending`です。事前にreadiness preflightを実行して作業計画書の実装可能性を検証してから再開してください。preflightなしで継続しますか？(y/n)」。`y`なら進む、`n`なら停止 |
-| 行が存在しない | `pending`として扱う — readinessマーカー導入前に作成された古い作業計画書は明示的にpreflightすべき |
-
-このチェックは全規模（Small / Medium / Large）に適用される。本レシピは規模に依存しないオーケストレーターであるため。
-
 ## サブエージェントのスコープ境界
 
 本レシピから呼び出すサブエージェントプロンプトの末尾に以下のブロックを必ず付与する:
@@ -87,7 +74,7 @@ Escalate when the required fix or investigation falls outside that scope.
 [Constraint] rule-advisor can only be used by Main AI
 ```
 
-## 🎯 オーケストレーターとしての必須責務
+## オーケストレーターとしての必須責務
 
 ### タスク実行品質サイクル
 subagents-orchestration-guideスキルの「自律実行中のタスク管理」に従い、TaskCreate/TaskUpdateで以下のステップを管理：

package/.claude/commands-ja/plan.md

@@ -76,7 +76,7 @@ description: 設計書から作業計画書を作成し計画承認を取得
 **スコープ**: 作業計画書作成と計画内容の承認取得まで。
 
 ## 終了時の応答
-✅ **必須**: 計画内容の承認後は以下の定型応答で終了
+**必須**: 計画内容の承認後は以下の定型応答を出力
 ```
 計画フェーズが完了しました。
 - 作業計画書: docs/plans/[plan-name].md
@@ -84,3 +84,8 @@ description: 設計書から作業計画書を作成し計画承認を取得
 
 実装は別途ご指示ください。
 ```
+
+承認された計画が次のいずれかを含む場合 — E2Eテストスケルトン；コードベースにまだ存在しないコマンド・ファイル・関数・エンドポイントを参照する検証戦略；視覚状態を描画する fixture エントリや開発用ルートを持たない UI コンポーネント；エンドツーエンドでの動作が未確認のローカルレーン — 応答の最終行として次の1行を追加する（該当しなければ省略する）:
+```
+任意の事前検証: `/prepare-implementation docs/plans/[plan-name].md` で、ビルド前にこれらが実装可能かを検証できる（readiness 基準がすべて満たされていれば no-op で終了）。
+```

package/.claude/commands-ja/prepare-implementation.md

@@ -11,14 +11,14 @@ description: 実装着手前に readiness を検証しギャップを解消す
 **実行プロトコル**:
 1. **全作業をAgentツールでサブエージェントに委譲** — サブエージェント（task-executor / task-executor-frontend / quality-fixer / quality-fixer-frontend）の呼び出し、成果物パスの受け渡し、結果の報告
 2. **自己完結スコープ**: ギャップが見つかった場合、本レシピは解消タスクの生成と、subagents-orchestration-guide「標準フロー」で説明される標準4ステップサイクルでの実行の**両方**を行う。readiness基準がパスするか残存ギャップがエスカレーションされた時点でレシピは完了する。
-3. **No-op終了**: readinessスキャンで失敗基準がない場合、解消タスクは生成せず即座に終了する。本ブランチのファイル変更は作業計画書本体のみ — `Implementation Readiness:`ヘッダを `ready` に昇格し、Readiness Reportセクションを永続化する。コードやテストファイルには触れない。
+3. **No-op終了**: readinessスキャンで失敗基準がない場合、解消タスクは生成せず、Readiness Report をユーザーに提示して即座に終了する。この no-op 経路ではファイルを変更しない。
 
 作業計画書: $ARGUMENTS
 
 ## 適用される条件
 
 build/implement フェーズの前に、以下のいずれかが該当する場合に実行する:
-- 作業計画書の検証戦略がコードベースにまだ存在しないコマンド・ファイル・関数・エンドポイントを参照する Design Doc から作成された
+- コードベースにまだ存在しないコマンド・ファイル・関数・エンドポイントを参照する検証戦略を含む Design Doc から、作業計画書が作成された
 - 作業計画書にE2Eテストスケルトンが含まれる（seed data、auth fixture、環境変数、または外部モックが未対応の可能性あり）
 - 作業計画書がUIコンポーネントに触れるが、それらの視覚状態を描画するfixtureエントリや開発用ルートがない
 - ローカルレーンが本機能領域でエンドツーエンドに動作することをチームが事前に確認していない
@@ -74,11 +74,9 @@ R4とR5は、トリガー信号が作業計画書に現れた場合のみ評価
 ### Step 3: No-opチェック
 
 該当する全基準が `pass`（`fail`ゼロ）の場合:
-- 作業計画書のヘッダブロック直後に `## Implementation Readiness Report` セクションを追記（既存なら置換）する。出力フォーマットで定義したReadiness Reportのmarkdownを使用する
-- 作業計画書ヘッダの `Implementation Readiness:` 行を `ready` に更新する（行が無ければ `Related Issue/PR:` の後に挿入する）
-- Readiness Reportをユーザーに提示する
+- Readiness Report（下記の出力フォーマット参照）をユーザーに提示する
 - `outcome: ready, gaps_resolved: 0` で終了する
-- 本ブランチのファイル変更は上記の作業計画書への変更のみ
+- この no-op 経路ではファイルを変更しない
 
 `fail`が1件以上ある場合 → Step 4へ進む。
 
@@ -115,20 +113,13 @@ R4とR5は、トリガー信号が作業計画書に現れた場合のみ評価
 
 各サブエージェントプロンプトの末尾に下記の「サブエージェントのスコープ境界」ブロックを必ず付与する。
 
-### Step 6: 再スキャン、Readiness Reportの永続化、ヘッダ更新、クリーンアップ、終了
+### Step 6: 再スキャン、Phase 0 完了の記録、Readiness Report の提示、クリーンアップ、終了
 
 1. **再スキャン**: 全解消タスクのコミット後、Step 2のreadinessスキャンを再実行する。
 
-2. **Readiness Reportを作業計画書本体に永続化する**: 作業計画書のヘッダブロック直後に `## Implementation Readiness Report` セクションを追記（既存なら置換）する。出力フォーマットで定義したReadiness Reportのmarkdownを使用する。下流のbuild/implementレシピは、ヘッダが `escalated` の場合に本セクションを読み、残存ギャップをユーザーに提示する。
+2. **作業計画書に Phase 0 完了を記録する**: コミットした各 Phase 0 解消タスクについて、作業計画書の Phase 0 セクションのチェックボックスを `[x]` にし、コミット済みである旨を注記する（` — committed` を付す）。これにより完了結果が計画書に残り、下流の task-decomposer がコミット済みの Phase 0 を再生成・再実行せずスキップできる。
 
-3. **作業計画書ヘッダの更新**: 作業計画書内の `Implementation Readiness: pending` 行を特定し、再スキャンの結果に応じて書き換える:
-
-   | 再スキャン結果 | 新しいヘッダ値 |
-   |--------------|--------------|
-   | 該当する全基準が `pass` | `Implementation Readiness: ready` |
-   | `fail` が1件以上残存 | `Implementation Readiness: escalated` |
-
-   行が存在しない場合（古い作業計画書フォーマット）、`Related Issue/PR:` 行の後に挿入する。
+3. **Readiness Report の提示**: Readiness Report（下記の出力フォーマット参照）をユーザーに提示する。レポートはセッション内で提示し、作業計画書には書き込まない — 本レシピの永続的な成果物は、コミット済みの Phase 0 解消タスク（Step 6.2 で計画書に完了として記録）であり、永続化されたレポートではない。
 
 4. **最終クリーンアップ**: 本実行で作成した、現在の `{plan-name}` に該当するprepタスクファイル（`docs/plans/tasks/{plan-name}-backend-task-prep-*.md` および `docs/plans/tasks/{plan-name}-frontend-task-prep-*.md`）と、prepフェーズ用に生成されたフェーズ完了ファイル（`docs/plans/tasks/{plan-name}-phase0-completion.md` が存在する場合。prepタスクはPhase 0に置かれるため）をすべて削除する。他の計画のprepタスクファイルはスコープ外 — 本レシピは現在の実行で作成したものだけを削除する。作業内容はコミット済みで、`docs/plans/`はレシピ実行間で保持しない一時的な作業状態である。作業計画書本体は下流のbuild/implementフェーズのために保持する。
 
@@ -185,7 +176,6 @@ Escalate when the required fix or investigation falls outside that scope.
 - [ ] readinessスキャンが実行され、各基準の結果と根拠が記録されている
 - [ ] 全`pass`の場合のno-op終了、または解消タスクの生成・承認・4ステップサイクル実行のいずれかが行われている
 - [ ] 最後の解消タスクのコミット後に再スキャンが実行されている
-- [ ] `## Implementation Readiness Report` セクションが作業計画書本体に永続化されている
-- [ ] 作業計画書ヘッダの `Implementation Readiness:` 行が `ready` または `escalated` に更新されている
+- [ ] コミット済みの Phase 0 タスクが作業計画書で `[x]` 完了マークされ、下流の分解でスキップされる
 - [ ] prepタスクファイル（および生成された場合のPhase 0フェーズ完了ファイル）が `docs/plans/tasks/` から削除されている
 - [ ] 最終レポートがユーザーに提示されている

package/.claude/commands-ja/sync-skills.md

@@ -43,9 +43,9 @@ description: スキル修正後のメタデータ同期とrule-advisor精度最
 
 ```
 [1/N] typescript-rules
-  ✅ sections: 同期完了
-  💡 tags提案: +[functional-programming]
-  💡 typical-use: "旧記述" → "新記述"
+  sections: 同期完了
+  tags提案: +[functional-programming]
+  typical-use: "旧記述" → "新記述"
 ```
 
 ## 完了条件

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

@@ -5,8 +5,6 @@ Type: feature|fix|refactor
 Estimated Impact: X files
 Related Issue/PR: #XXX (if any)
 Review Scope: [planned-files scope derived from Design Doc and task targets; for a revision plan over existing work, base branch + diff range]
-<!-- The line below is medium / large only — small scale uses task-template instead of this plan-template. Keep the value line free of trailing comments so downstream parsers can extract the bare status (pending | ready | escalated). -->
-Implementation Readiness: pending
 
 ## Related Documents
 - Design Doc(s):

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-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
 
 ## 関連ドキュメント
 - 設計書:

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/CHANGELOG.md

@@ -5,6 +5,14 @@ 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.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.4",
   "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": [