create-ai-project 1.23.2 → 1.23.4

package/.claude/agents-ja/technical-designer.md

@@ -29,31 +29,7 @@ ADR/Design Docの作成閾値はdocumentation-criteriaスキルに準拠。判
 
 ### ゲート順序 [BLOCKING]
 
-以下のサブセクションは並列の必須事項ではなく、4段階の直列ゲートを構成する。各ゲートを完了してから次のゲートに進むこと。各ゲート内では列挙されたサブセクションすべてが必須（各サブセクションの条件に従う）。
-
-**Gate 0 — Inputs and Standards**（上流依存なし）:
-- Agreement Checklist
-- Standards Identification
-
-**Gate 1 — Existing State Analysis**（Gate 0 に依存）:
-- Existing Code Investigation
-- Fact Disposition（Codebase Analysis 入力が提供される場合）
-- Data Representation Decision（新規または変更されるデータ構造を導入する場合）
-- Minimal Surface Alternatives（永続状態、公開コントラクト要素または境界を越えるフィールド、振る舞いモード/フラグ、再利用可能な抽象を導入する場合）
-
-**Gate 2 — Design Decisions**（Gate 1 に依存）:
-- Implementation Approach Decision
-- Common ADR Process
-- Data Contracts
-- State Transitions（該当する場合）
-
-**Gate 3 — Impact Documentation**（Gate 2 に依存）:
-- Integration Points
-- Change Impact Map
-- Field Propagation Map（フィールドがコンポーネント境界を越える場合）
-- Interface Change Impact Analysis
-
-各サブセクションには見出しに `[Gate N — ...]` の注記を付す。サブセクションはゲート順（Gate 0 → 1 → 2 → 3）で記載されており、文書順に実行すること。
+以下のサブセクションは並列の必須事項ではなく、4段階の直列ゲートを構成する: **Gate 0** Inputs & Standards → **Gate 1** Existing-State Analysis → **Gate 2** Design Decisions → **Gate 3** Impact Documentation。各ゲートを完了してから次のゲートに進むこと。各サブセクションには見出しに `[Gate N — ...]` の注記（適用条件を含む）が付き、ゲート順に記載されている。文書順に実行すること。
 
 ### 合意事項チェックリスト [Gate 0 — Required]
 Design Doc作成の最初に必ず実施：
@@ -370,6 +346,14 @@ Design Doc作成時に必ず含める:
 
 ## 受け入れ基準作成ガイドライン
 
+### 価値起点のドラフトと境界拡張
+
+各ACは価値起点でドラフトし、下記のルールを適用する前に要件境界へ展開する:
+
+1. **価値起点**: まずユーザー/オペレーター/保守者にとっての価値を挙げ、次にそれを実現する観測可能な振る舞い、最後にそれを支える技術的境界を特定する。
+2. **境界への展開**（候補抽出 — 採否は下記ルールが決定）: ある振る舞いはメインパスでは成立しつつ、別の次元で退行しうる。振る舞いを変えるACごとに、約束した振る舞いが成立すべき箇所すべてでACを検討する — 単一/最新/全件のコレクション、同一サーフェス上の隣接フィールド、後続のライフサイクル状態やリトライ、stale/欠損/空の値、リフレッシュ失敗やフォールバック不在、権限/バリデーション/ポリシーの境界、入力スコープと選択/順序/識別キー、副作用、公開・可視性の境界（状態が別プロセス・コンポーネント・ユーザー・後続ステップから観測可能になる箇所）。
+3. **同一粒度での比較**: ACが既存または参照先の振る舞いに関わる場合、参照元（source）の振る舞いと対象（target）の振る舞いを同じ詳細度で記述し、各境界が保持されているか意図的に変更されたかをレビュアーが確認できるようにする。
+
 ### 測定可能なACの書き方
 
 **原則**: AC = 独立した環境で検証可能かつユーザーが観測可能な振る舞い。正常系・異常系・エッジケースをカバー。非機能要件（パフォーマンス、信頼性、スケーラビリティ）は別の「非機能要件」セクションで定義する。

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/frontend-technical-spec/SKILL.md

@@ -17,10 +17,10 @@ TypeScript-based React application implementation. Architecture patterns should
 - Properly implement default value settings and mandatory checks
 
 ```typescript
-// Build tool environment variables (public values only)
+// Build tool environment variables (public values only; client-exposed vars need the VITE_ prefix)
 const config = {
-  apiUrl: import.meta.env.API_URL || 'http://localhost:3000',
-  appName: import.meta.env.APP_NAME || 'My App'
+  apiUrl: import.meta.env.VITE_API_URL || 'http://localhost:3000',
+  appName: import.meta.env.VITE_APP_NAME || 'My App'
 }
 
 // Does not work in frontend
@@ -37,7 +37,7 @@ const apiUrl = process.env.API_URL
 **Correct Approach for Secrets**:
 ```typescript
 // Security risk: API key exposed in browser
-const apiKey = import.meta.env.API_KEY
+const apiKey = import.meta.env.VITE_API_KEY
 const response = await fetch(`https://api.example.com/data?key=${apiKey}`)
 
 // Correct: Backend manages secrets, frontend accesses via proxy