create-ai-project 1.22.1 → 1.23.1

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

@@ -1,5 +1,5 @@
 ---
-description: 要件分析からフロントエンド設計ドキュメント作成まで実行
+description: コードベース分析からフロントエンド設計ドキュメント作成まで実行
 ---
 
 **コマンドコンテキスト**: このコマンドはフロントエンド設計フェーズ専用です。
@@ -9,105 +9,136 @@ description: 要件分析からフロントエンド設計ドキュメント作
 **コアアイデンティティ**: 「私はオーケストレーターである。」（subagents-orchestration-guideスキル参照）
 
 **実行プロトコル**:
-1. **全ての作業をサブエージェントに委譲** — サブエージェントを呼び出し、データを橋渡しし、結果を報告する
-2. **以下のフロントエンド設計フローに従う**（このコマンドは中規模/大規模のフロントエンドを対象。UI Specはコードベース分析の前に作成する — コンポーネント構造が技術設計に反映されるため）:
-   - 実行: requirement-analyzer → ui-spec-designer → codebase-analyzer → technical-designer-frontend → code-verifier → document-reviewer → design-sync
-   - **`[停止: ...]`マーカーごとに停止** → ユーザー承認を待つ
+1. **全ての作業をサブエージェントに委譲** — サブエージェントを呼び出し、データを橋渡しし、結果を報告する。唯一の例外はStep 1のスコープブートストラップで、シードファイルの特定に限定したレシピ内オーケストレータータスク。
+2. **以下のフロントエンド設計フローを順に実行**（このコマンドは中規模/大規模のフロントエンドを対象） — 分岐のない固定の線形シーケンス:
+   - 実行: スコープブートストラップ → codebase-analyzer → [停止: スコープ確認] → ui-analyzer → ui-spec-designer → technical-designer-frontend → code-verifier → document-reviewer → design-sync
+   - technical-designer-frontendは、設計にアーキテクチャ決定が伴う場合（documentation-criteriaに従う）に前提となるADRを作成する。ADRはDesign Docを置き換えない — フローは常にDesign Doc作成と検証チェーン全体を通過する
+   - **`[停止: ...]`マーカーごとに停止** → 次に進む前にユーザー承認を待つ
 3. **スコープ**: 設計ドキュメントの承認をもって完了
 
-**重要**: document-reviewer、design-sync、subagents-orchestration-guideスキルフローで定義された全ての停止ポイントを実行すること — 各ステップが品質ゲートとして機能する。スキップは検出されない不整合のリスクにつながる。
+**subagents-orchestration-guideの利用**: オーケストレーション原則とScale Determination表を参照する。このコマンドは独自の開始順序を定義する — ガイドのrequirement-analyzer起点フローはここでは適用しない。
+
+**重要**: document-reviewer、design-sync（Design Docの場合）、全ての停止ポイントを実行する — 各々が品質ゲートとして機能する。スキップは検出されない不整合のリスクにつながる。
 
 ## ワークフロー概要
 
 ```
-要件 → requirement-analyzer → [停止: 規模判定]
-                                    ↓
-                            ui-spec-designer → [停止: UI Spec承認]
-                                    ↓
-                            codebase-analyzer → technical-designer-frontend
-                                    ↓
-                            code-verifier → document-reviewer
-                                    ↓
-                               design-sync → [停止: 設計承認]
+要件 → スコープブートストラップ → codebase-analyzer → [停止: スコープ確認]
+                                                            ↓
+                                                       ui-analyzer
+                                                            ↓
+                                              ui-spec-designer → [停止: UI Spec承認]
+                                                            ↓
+                                              technical-designer-frontend
+                                                            ↓
+                                              code-verifier → document-reviewer
+                                                            ↓
+                                                 design-sync → [停止: 設計承認]
 ```
 
 ## スコープ境界
 
 **実行内容**:
-- requirement-analyzerによる要件分析
-- codebase-analyzerによるコードベース分析（技術設計の前に実施）
+- スコープブートストラップ: codebase-analyzerが値の入った入力を得られるようシードファイルを特定する
+- codebase-analyzerによるコードベース分析（フロントエンド設計フェーズの入口）
+- codebase-analyzerの所見に基づくユーザーとのスコープ確認
+- ui-analyzerによるUI事実収集
 - ui-spec-designerによるUI Spec作成（プロトタイプコード確認を含む）
-- ADR作成（アーキテクチャ変更、新技術、データフロー変更がある場合）
+- ADR作成（アーキテクチャ変更、新技術、データフロー変更が伴う場合、Design Docの前提として）
 - technical-designer-frontendによるDesign Doc作成
 - code-verifierによるDesign Doc検証（ドキュメントレビューの前に実施）
 - document-reviewerによるドキュメントレビュー
-- design-syncによるDesign Doc横断整合性検証
+- design-syncによるDesign Doc間整合性検証
 
 **責務境界**: このコマンドはフロントエンド設計ドキュメント（UI Spec/ADR/Design Doc）の承認で責務完了。作業計画以降はスコープ外。
 
+## 実行フロー
+
 要件: $ARGUMENTS
 
-## 実行フロー
+### Step 1: スコープブートストラップ
+codebase-analyzerは値の入った`requirement_analysis.affectedFiles`を必要とする。そのシードを、軽量なオーケストレーター内タスクで構築する — ファイルの特定のみで、深い読み込みや設計判断は行わない:
+
+1. ユーザー要件から候補キーワード（機能名、ドメイン名詞、識別子）を抽出する。
+2. Bash（`rg`、`rg`が使えない場合は`grep`）で、それらのキーワードに一致するファイルをリポジトリ内で検索する。
+3. 一致したファイルパスをシード`affectedFiles`として収集する。
+4. **検索結果が0件の場合**: 設計対象のファイルまたはモジュールをユーザーに確認し（AskUserQuestion）、その回答を`affectedFiles`とする。関連コードが存在しないとユーザーが確認した場合は、コードベース起点の設計が適用できない旨を報告し、進め方をユーザーと確認する。
+5. **検索結果が約20件を超える場合**: キーワードが広すぎる。最も関連性の高い候補をユーザーに提示し（AskUserQuestion）、シード`affectedFiles`を確認してから進む。
+
+このステップはシードファイルの特定のみを行う。ファイルの全文読み込み、依存関係の追跡、分析はcodebase-analyzerの責務である。
+
+### Step 2: コードベース分析
+- Agentツールで**codebase-analyzer**を呼び出す
+  - `subagent_type: "codebase-analyzer"`, `description: "コードベース分析"`
+  - `prompt`: `requirements`（ユーザー要件の原文）と`requirement_analysis`（`affectedFiles`（Step 1のシード）、`purpose`（ユーザー要件）、`scale`（シードファイル数にScale Determination表を当てた暫定値）、`technicalConsiderations`（`{ constraints: [], risks: [], dependencies: [] }`）を含むJSONオブジェクト）を含める。フロントエンド設計ガイダンスのため既存コードベースを分析する。
 
-### Step 1: 要件分析フェーズ
-設計への影響が深いことを考慮し、まず対話により要件の背景と目的を理解:
-- 何の問題を解決したいか
-- 期待する成果と成功基準
-- 既存システムとの関係
+### Step 3: スコープ確認
+codebase-analyzerが返ったら、設計作業の前にユーザーとスコープを確認する。AskUserQuestionを使う。
 
-ユーザーが上記3つの質問に回答した後、設計スコープ内で以下のプロセスを実行する。codebase-analyzerとcode-verifierの呼び出しはsubagents-orchestration-guideのCall Examplesに従う。
-- Agentツールで**requirement-analyzer**を呼び出す
-  - `subagent_type: "requirement-analyzer"`
-  - `description: "要件分析"`
-  - `prompt: "要件: [ユーザー要件] 要件分析と規模判定を実施してください"`
-- **[停止]**: 要件分析結果を確認し、質問事項に対応
+codebase-analyzerのJSONを出典として以下を提示する:
+- **対象ファイル/モジュール**: `analysisScope.filesAnalyzed`と、それらが属するモジュール
+- **影響を受けるレイヤー**: `analysisScope.categoriesDetected`と`focusAreas`から導出される、影響を受けるレイヤー
+- **不明点/前提**: `limitations`と、codebase-analyzerが記録した前提
+- **設計前の質問事項**: 設計を進める前にユーザーの回答が必要な未解決点
 
-### Step 2: UI Specフェーズ
-要件分析承認後、プロトタイプコードについてユーザーに確認:
+ユーザーに以下から1つを選んでもらう:
+- **このスコープで設計を進める** — Step 4へ進む
+- **スコープを修正して再実行** — 修正したスコープでStep 1に戻る。ユーザーが修正後のファイルまたはモジュールを指定した場合は、検索で導出し直さず、それをStep 1のシードとして直接使う
+- **追加ヒアリングののち進める** — 不足している回答を集めてからStep 4へ進む
+
+ユーザーがスコープを確認したら、確認済みの対象ファイル数を数え、Scale Determination表から規模を設定する。この確認済みの規模はStep 2の暫定値に優先する。
+
+**[停止]**: ユーザーの選択を待ってから進む。
+
+### Step 4: UI事実収集
+- Agentツールで**ui-analyzer**を呼び出す
+  - `subagent_type: "ui-analyzer"`, `description: "UI事実収集"`
+  - `prompt`: `requirements`（ユーザー要件）と`requirement_analysis`（`affectedFiles`（Step 2のcodebase-analyzer出力の`analysisScope.filesAnalyzed`・`analysisScope.tracedDependencies`・`focusAreas[].relatedFiles`のパスの和集合）、`purpose`（ユーザー要件）、`scale`（Step 3の確認済み規模）、`technicalConsiderations`（`{ constraints: [], risks: [], dependencies: [] }`）を含むJSONオブジェクト）を含める。ui-analyzerはproject-contextのExternal Resourcesセクションを読み、宣言されたアクセス手段で外部UIソースを取得し、既存のUIコードベースを分析する。
+
+codebase-analyzerのJSON（Step 2）とui-analyzerのJSON（Step 4）は、ui-spec-designerとtechnical-designer-frontendで再利用される。
+
+### Step 5: UI Specフェーズ
+プロトタイプコードについてユーザーに確認する。
 
 **ユーザーに確認**: 「この機能のプロトタイプコードはありますか？ある場合はコードへのパスを教えてください。プロトタイプはUI Specの参考資料として`docs/ui-spec/assets/`に配置されます。」
 
 - **[停止]**: プロトタイプコードの有無についてユーザーの回答を待つ
 
-UI Specを作成:
+その後、UI Specを作成する:
 - Agentツールで**ui-spec-designer**を呼び出す
-  - `subagent_type: "ui-spec-designer"`
-  - `description: "UI Spec作成"`
-  - PRDあり＋プロトタイプあり: `prompt: "[パス]のPRDからUI Specを作成。プロトタイプコードは[ユーザー提供パス]。プロトタイプをdocs/ui-spec/assets/{feature-name}/に配置"`
-  - PRDあり＋プロトタイプなし: `prompt: "[パス]のPRDからUI Specを作成。プロトタイプコードなし。"`
-  - PRDなし（中規模）: `prompt: "以下の要件に基づいてUI Specを作成: [requirement-analyzerの出力を渡す]。PRDなし。"`（プロトタイプパスがあれば追加）
-- **document-reviewer**でUI Specを検証
+  - `subagent_type: "ui-spec-designer"`, `description: "UI Spec作成"`
+  - 以下を含めてプロンプトを構築する: ソース（この機能の既存PRDが`docs/prd/`にあればそれ。なければ、ユーザー要件にStep 2のcodebase-analyzer JSONとStep 3の確認済みスコープを添えたもの）、`ui_analysis`（Step 4のui-analyzer JSON）、提供された場合のプロトタイプパス。プロトタイプは`docs/ui-spec/assets/{feature-name}/`に配置する。
+- **document-reviewer**でUI Specを検証する
   - `subagent_type: "document-reviewer"`, `description: "UI Specレビュー"`, `prompt: "doc_type: UISpec target: [ui-specパス] 整合性と完全性をレビュー"`
-- **[停止]**: UI Specをユーザーに提示し承認を取得
-
-### Step 3: 設計ドキュメント作成フェーズ
-まず既存コードベースを分析:
-- Agentツールで**codebase-analyzer**を呼び出す
-  - `subagent_type: "codebase-analyzer"`, `description: "コードベース分析"`, `prompt: "requirement_analysis: [Step 1のJSON]. requirements: [ユーザー要件]. フロントエンド設計ガイダンスのため既存コードベースを分析。"`
+- **[停止]**: UI Specをユーザーに提示し承認を取得する
 
-規模判定に応じて適切な設計ドキュメントを作成。technical-designer-frontendは技術選択・データフロー設計について少なくとも2つの選択肢をトレードオフとともに提示:
-- Agentツールで**technical-designer-frontend**を呼び出す
-  - ADRの場合: `subagent_type: "technical-designer-frontend"`, `description: "ADR作成"`, `prompt: "[技術決定]のADRを作成。少なくとも2つの選択肢をトレードオフとともに提示。"`
-  - Design Docの場合: `subagent_type: "technical-designer-frontend"`, `description: "Design Doc作成"`, `prompt: "要件に基づいてDesign Docを作成。コードベース分析: [codebase-analyzerのJSON]。UI Specは[ui-specパス]。UI Specのコンポーネント構造と状態設計を継承。少なくとも2つのアーキテクチャ選択肢をトレードオフとともに提示。"`
-- **（Design Docのみ）** **code-verifier**でDesign Docを既存コードに対して検証。ADRの場合はスキップ。
+### Step 6: 設計ドキュメント作成フェーズ
+- Agentツールで**technical-designer-frontend**を呼び出し、設計ドキュメントを作成する。documentation-criteriaに従いDesign Docを作成する。設計にアーキテクチャ決定（アーキテクチャ変更、新技術、データフロー変更）が伴う場合は、前提となるADRを先に作成する。
+  - `subagent_type: "technical-designer-frontend"`, `description: "設計ドキュメント作成"`, `prompt: "この要件の設計ドキュメントを作成。documentation-criteriaに従いDesign Docを作成し、設計にアーキテクチャ決定が伴う場合は前提となるADRを先に作成。要件: [ユーザー要件の原文]。コードベース分析: [Step 2のcodebase-analyzer JSON]。UI分析: [Step 4のui-analyzer JSON]。UI Specは[ui-specパス]。UI Specのコンポーネント構造と状態設計を継承。少なくとも2つのアーキテクチャ選択肢をトレードオフとともに提示。"`
+- **code-verifier**でDesign Docを既存コードに対して検証する。
   - `subagent_type: "code-verifier"`, `description: "Design Doc検証"`, `prompt: "doc_type: design-doc document_path: [Design Docパス] mode: pre-implementation (code_paths省略 — verifierがドキュメントからスコープを発見). Design Docを既存コードに対して検証。"`
-- **document-reviewer**で整合性検証（Design Docの場合はcode-verifier結果を渡す。ADRの場合は省略）
-  - `subagent_type: "document-reviewer"`, `description: "ドキュメントレビュー"`, `prompt: "doc_type: DesignDoc target: [ドキュメントパス] mode: composite code_verification: [code-verifierのJSON]（Design Docのみ） 整合性と完全性をレビュー。"`
-### Step 4: 設計整合性検証
-- Agentツールで**design-sync**を呼び出す
+- technical-designer-frontendが作成した各ドキュメント（Design Doc、および作成された場合のADR）に対して**document-reviewer**を呼び出す。
+  - Design Doc: `subagent_type: "document-reviewer"`, `description: "ドキュメントレビュー"`, `prompt: "doc_type: DesignDoc target: [Design Docパス] mode: composite codebase_analysis: [Step 2のcodebase-analyzer JSON] code_verification: [code-verifierのJSON]. 整合性と完全性をレビュー。"`
+  - ADR（作成された場合）: `subagent_type: "document-reviewer"`, `description: "ADRレビュー"`, `prompt: "doc_type: ADR target: [ADRパス] mode: composite. 整合性と完全性をレビュー。"`
+- ADRレビューで修正が必要になった場合、technical-designer-frontend(update)がADRを修正し、修正後のADRに合わせてDesign Docを再整合させる — Design Docは未レビューまたは古いADRの上に立ってはならない。この再整合でDesign Docが変わった場合は、更新後のDesign Docに対してcode-verifierとDesign Docのdocument-reviewerを再実行し、検証が最終内容を反映するようにする。
+
+### Step 7: 設計整合性検証
+- Agentツールで**design-sync**を呼び出す。
   - `subagent_type: "design-sync"`, `description: "設計整合性チェック"`, `prompt: "docs/design/配下の全Design Doc間の整合性をチェック。矛盾と重複を報告。"`
-- **[停止]**: 設計ドキュメントとdesign-sync結果を提示し、ユーザー承認を取得
+- **[停止]**: 設計ドキュメント（Design Docの場合はdesign-sync結果も）を提示し、ユーザー承認を取得する
 
 ## 完了条件
 
-- [ ] requirement-analyzerを実行し規模を判定
-- [ ] codebase-analyzerを実行し結果をtechnical-designer-frontendに渡した
-- [ ] ui-spec-designerでUI Specを作成（該当時）
-- [ ] technical-designer-frontendで適切な設計ドキュメント（ADRまたはDesign Doc）を作成
-- [ ] Design Docに対してcode-verifierを実行し結果をdocument-reviewerに渡した（ADRのみの場合はスキップ）
-- [ ] document-reviewerを実行しフィードバックに対応
-- [ ] design-syncで整合性検証を実行
-- [ ] 設計ドキュメントのユーザー承認を取得
+- [ ] Step 1のスコープブートストラップのシードを構築した（または検索結果が0件のときユーザーから対象ファイルを取得した）
+- [ ] 値の入った`requirement_analysis`でcodebase-analyzerを実行した
+- [ ] ユーザーと設計スコープを確認し、確認済みの対象ファイルから規模を設定した
+- [ ] ui-analyzerを実行した。codebase-analyzer（Step 2）とui-analyzer（Step 4）の出力はui-spec-designerとtechnical-designer-frontendで再利用される
+- [ ] ui-spec-designerでUI Specを作成した
+- [ ] technical-designer-frontendでDesign Docを作成した。設計にアーキテクチャ決定が伴う場合は前提となるADRを先に作成した
+- [ ] Design Docに対してcode-verifierを実行し、結果をdocument-reviewerに渡した
+- [ ] 作成した各ドキュメント（Design Doc、および作成された場合のADR）に対してdocument-reviewerを実行し、フィードバックに対応した
+- [ ] design-syncで整合性検証を実行した
+- [ ] 設計ドキュメントのユーザー承認を取得した
 
 ## 出力例
 フロントエンド設計フェーズ完了。

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

@@ -30,7 +30,7 @@ unknowns:
 
 ### Prerequisite ADRs
 
-- [ADR File Name]: [Related decision items]
+- [docs/adr/ADR-XXXX.md]: [Related decision items]
 - Reference common technical ADRs when applicable
 
 ### Agreement Checklist

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

@@ -39,10 +39,10 @@ Adopted quality gates for the change area. Each task in this plan must satisfy t
 
 Maps each Design Doc technical requirement to the covering task(s). One row per extracted item. Every row must have at least one covering task, or an explicit gap justification.
 
-| DD Section | DD Item | Category | Covered By Task(s) | Gap Status | Notes |
-|---|---|---|---|---|---|
-| [Section name from DD] | [Specific item] | impl-target / connection-switching / contract-change / verification / prerequisite | [Phase X Task Y] | covered | |
-| Security Considerations | Input validation for API | prerequisite | — | gap | Deferred to Phase 2 per user decision |
+| Design Doc | DD Section | DD Item | Category | Covered By Task(s) | Gap Status | Notes |
+|---|---|---|---|---|---|---|
+| [docs/design/XXX.md — one of the Related Documents above] | [Section name from DD] | [Specific item] | impl-target / connection-switching / contract-change / verification / prerequisite | [Phase X Task Y] | covered | |
+| docs/design/XXX.md | Security Considerations | Input validation for API | prerequisite | — | gap | Deferred to Phase 2 per user decision |
 
 **Category values**: `impl-target` (implementation target), `connection-switching` (connection/switching/registration), `contract-change` (contract change and propagation), `verification` (verification requirement), `prerequisite` (prerequisite work)
 
@@ -60,6 +60,18 @@ Include this section when a UI Spec is among the inputs. Maps each component doc
 
 **Gap Status values**: `covered` (task exists), `gap` (no task — requires justification in Notes, user confirmation required before plan approval)
 
+## ADR Bindings
+
+Include this section when ADRs are provided as input or listed in the Design Doc's "Prerequisite ADRs" section. Maps each implementation-binding ADR decision to the task(s) it constrains. Omit the section when no ADR applies.
+
+A decision is **implementation-binding** when it constrains code placement, dependency direction, contract/schema shape, data flow, or persistence. Acceptance criteria and required behaviors are recorded in the Design Doc; this table covers only structural constraints from ADRs.
+
+| ADR | Source Section | Axis | Binding Decision | Covered By Task(s) |
+|---|---|---|---|---|
+| [docs/adr/ADR-XXXX.md] | Decision / Implementation Guidance | placement \| dependency_direction \| contract_schema \| data_flow \| persistence | [One implementation-binding decision sentence, copied or condensed from the named section] | [Phase X Task Y] |
+
+One row per binding decision. A single ADR can contribute multiple rows. A single task can appear in multiple rows.
+
 ## Connection Map
 
 Include this section when the implementation crosses more than one package, service, or process boundary. Document each boundary so task-decomposer can propagate boundary context to the implementation tasks on each side. Omit the section when the implementation stays within a single package.

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

@@ -17,8 +17,17 @@ Metadata:
 Files to read before starting implementation (file path, with optional search hint):
 - [e.g., src/orders/checkout (processOrder function) — determined during task decomposition based on task nature]
 
+## Binding Decisions
+(Include this section when the work plan's ADR Bindings table covers this task. Omit otherwise.)
+
+Each row is an ADR decision the implementation in this task must comply with.
+
+| Source | Axis | Decision | Compliance Check |
+|---|---|---|---|
+| [docs/adr/ADR-XXXX.md (§ <Source Section>) — substitute the section name (`Decision` or `Implementation Guidance`) from the matching work plan row] | [Axis value copied verbatim from the work plan's ADR Bindings row] | [Binding decision copied from the work plan's ADR Bindings row] | [Y/N-answerable positive predicate that evaluates whether the planned/final implementation satisfies the decision] |
+
 ## Investigation Notes
-(Implementation observations are appended here before implementation begins.)
+(Implementation observations are appended here before implementation begins. When Binding Decisions exist, record the planned implementation approach and each Compliance Check result here.)
 
 ## Implementation Steps (TDD: Red-Green-Refactor)
 ### 1. Red Phase
@@ -51,6 +60,7 @@ Files to read before starting implementation (file path, with optional search hi
 - [ ] All added tests pass
 - [ ] Operation verified per Operation Verification Methods above
 - [ ] Deliverables created (for research/design tasks)
+- [ ] (When Binding Decisions exist) Every Compliance Check evaluates to `Y` against the final implementation, with evidence recorded in Investigation Notes (file:line, test result, or command output)
 
 ## Notes
 - Impact scope: [Areas where changes may propagate]

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

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

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

@@ -30,7 +30,7 @@ unknowns:
 
 ### 前提となるADR
 
-- [ADRファイル名]: [関連する決定事項]
+- [docs/adr/ADR-XXXX.md]: [関連する決定事項]
 - 共通技術ADRも該当する場合は参照
 
 ### 合意事項チェックリスト

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

@@ -39,10 +39,10 @@ Implementation Readiness: pending
 
 Design Docの各技術要件をカバーするタスクへのマッピング。抽出した項目ごとに1行。各行には対応タスクが少なくとも1つ必要。タスクがない場合は明示的なギャップ理由が必要。
 
-| DDセクション | DD項目 | カテゴリ | カバーするタスク | ギャップステータス | 備考 |
-|---|---|---|---|---|---|
-| [DDのセクション名] | [具体的な項目] | impl-target / connection-switching / contract-change / verification / prerequisite | [Phase X タスクY] | covered | |
-| セキュリティ考慮事項 | APIの入力バリデーション | prerequisite | — | gap | ユーザー判断によりPhase 2に延期 |
+| Design Doc | DDセクション | DD項目 | カテゴリ | カバーするタスク | ギャップステータス | 備考 |
+|---|---|---|---|---|---|---|
+| [docs/design/XXX.md — 上記の関連ドキュメントのいずれか] | [DDのセクション名] | [具体的な項目] | impl-target / connection-switching / contract-change / verification / prerequisite | [Phase X タスクY] | covered | |
+| docs/design/XXX.md | セキュリティ考慮事項 | APIの入力バリデーション | prerequisite | — | gap | ユーザー判断によりPhase 2に延期 |
 
 **カテゴリ値**: `impl-target`（実装対象）、`connection-switching`（接続/切替/登録）、`contract-change`（コントラクト変更と伝搬）、`verification`（検証要件）、`prerequisite`（前提作業）
 
@@ -60,6 +60,18 @@ Design Docの各技術要件をカバーするタスクへのマッピング。
 
 **ギャップステータス値**: `covered`（タスクあり）、`gap`（タスクなし — 備考に理由必須、計画承認前にユーザー確認が必要）
 
+## ADR Bindings
+
+ADRが入力として与えられた場合、またはDesign Docの「Prerequisite ADRs」セクションに記載されている場合に本セクションを記載する。実装を拘束する各ADR決定を、それが制約するタスクへマッピングする。該当するADRがない場合は本セクションを省略する。
+
+決定が**実装拘束的**であるのは、コード配置、依存方向、コントラクト/スキーマ形状、データフロー、または永続化を制約する場合である。受入基準と必要な振る舞いはDesign Docに記録される。本表はADR由来の構造的制約のみを扱う。
+
+| ADR | Source Section | Axis | Binding Decision | Covered By Task(s) |
+|---|---|---|---|---|
+| [docs/adr/ADR-XXXX.md] | Decision / Implementation Guidance | placement \| dependency_direction \| contract_schema \| data_flow \| persistence | [実装拘束的な決定文を1つ、該当セクションからコピーまたは要約] | [Phase X タスクY] |
+
+バインディング決定ごとに1行。1つのADRが複数行に寄与しうる。1つのタスクが複数行に現れうる。
+
 ## Connection Map
 
 実装が複数のパッケージ、サービス、またはプロセス境界をまたがる場合のみ本セクションを記載する。各境界を文書化することで、task-decomposerは境界の文脈を両側の実装タスクに伝播できる。実装が単一パッケージ内に収まる場合は本セクションを省略する。

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

@@ -17,8 +17,17 @@ Metadata:
 実装開始前に読むべきファイル（ファイルパス、任意でサーチヒント付き）:
 - [例: src/orders/checkout (processOrder関数) — タスクの性質に基づきタスク分解時に決定]
 
+## Binding Decisions
+（作業計画書のADR Bindings表がこのタスクをカバーする場合に本セクションを記載する。それ以外は省略する。）
+
+各行は、このタスクの実装が準拠すべきADR決定である。
+
+| Source | Axis | Decision | Compliance Check |
+|---|---|---|---|
+| [docs/adr/ADR-XXXX.md (§ <Source Section>) — 対応する作業計画書の行のセクション名（`Decision` または `Implementation Guidance`）に置き換える] | [作業計画書のADR Bindings行から逐語コピーしたAxis値] | [作業計画書のADR Bindings行からコピーしたバインディング決定] | [計画中/最終の実装が決定を満たすかをY/Nで判定できる肯定述語] |
+
 ## Investigation Notes
-（実装観察事項を実装開始前にここへ追記する。）
+（実装観察事項を実装開始前にここへ追記する。Binding Decisionsがある場合、計画した実装アプローチと各Compliance Check結果をここに記録する。）
 
 ## Implementation Steps (TDD: Red-Green-Refactor)
 ### 1. Red Phase
@@ -51,6 +60,7 @@ Metadata:
 - [ ] 追加した全テストがパス
 - [ ] Operation Verification Methods に基づく動作確認完了
 - [ ] 成果物作成完了（調査・設計タスクの場合）
+- [ ] （Binding Decisionsがある場合）全てのCompliance Checkが最終実装に対して`Y`と評価され、根拠（file:line、テスト結果、またはコマンド出力）がInvestigation Notesに記録されている
 
 ## Notes
 - 影響範囲: [変更が波及する可能性のある領域]

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

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

package/CHANGELOG.md

@@ -5,6 +5,35 @@ All notable changes to this project will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [1.23.1] - 2026-05-28
+
+### Added
+
+- **Acceptance evidence discipline** (agents, skills) — Substance check rejects cited test evidence that is hollow (skipped, TODO-only, always-true, or 0-match). `task-executor` reports `runnableCheck.substance` / `substanceIssue`; `quality-fixer` gates on it and routes unrecoverable hollow tests via `stub_detected` with new `incompleteImplementations[].type` (`missing_logic` / `hollow_test`). `code-reviewer` §3-3 and `integration-test-reviewer` add matching inspection criteria
+- **`test_environment_not_ready` escalation** (agents, skills) — `task-executor` / `-frontend` escalate with a typed reason when the required test toolchain is unavailable. Registered in `subagents-orchestration-guide`
+- **Frontend executor symmetry** (agents) — `task-executor-frontend` gains Reference Representativeness (IF-THEN by repository-wide file count) and `dependency_version_uncertain` escalation, matching the backend executor
+
+### Changed
+
+- **Reference Representativeness rule** (agents, skills) — Rewritten as explicit IF-THEN (3+ adopt / 1-2 investigate canonical-vs-legacy / 0 justify) so a canonical pattern with only 1-2 nearby files can still be adopted instead of being forced to escalate
+- **Frontend quality-fixer guidance** (agents) — Replace obsolete patterns (manual `cleanup()`, snapshot-first thinking) with current RTL practice (auto-cleanup, behavior assertions over snapshots, mock at the existing network boundary)
+- **Prompt tightening** (agents, skills) — Compressed Similar Function / Component Duplication Check; removed redundant Special Considerations (`code-reviewer`) and Important Principles (`quality-fixer`); added a Policy References hub to Fix Execution Policy; split `quality-fixer` `blocked` example into Variant A (specification conflict) and Variant B (missing prerequisites); `subagents-orchestration-guide` task-executor Output and quality-fixer Input contracts updated to carry `runnableCheck` through
+
+## [1.23.0] - 2026-05-22
+
+### Added
+
+- **ui-analyzer agent** (agents) — Read-only UI fact-gathering agent for frontend design and adjustment preparation. Reads the `project-context` skill's External Resources section, fetches external sources (design origin, design system, guidelines, visual verification environment) via MCP or URL, and analyzes the existing UI codebase across twelve steps (component structure, props/variant patterns, CSS layout, state × display matrix, display conditions, i18n, accessibility, generated-artifact readiness, candidate write set). Outputs a single consolidated UI context JSON consumed by `ui-spec-designer` and `technical-designer-frontend`; design decisions and code modifications are out of scope. Registered in `subagents-orchestration-guide` and wired into the front-design recipe as a dedicated UI fact-gathering step
+- **ADR binding decision propagation** (agents, commands, skills) — Implementation-binding ADR decisions now flow end to end. `work-planner` resolves referenced ADRs and builds an ADR Bindings table mapping each binding decision (classified on one of five axes: placement, dependency direction, contract/schema shape, data flow, persistence) to the tasks it constrains. `task-decomposer` propagates matching rows into each task file's Binding Decisions section. `task-executor` and `task-executor-frontend` run a Binding Decision Check before the TDD cycle and re-evaluate it at the Exit Gate, escalating `binding_decision_violation` when a planned or final implementation violates a decision. plan-template and task-template carry the new sections
+- **Standards Identification for frontend technical design** (agents) — `technical-designer-frontend` gains a Gate 0 Standards Identification subsection (project standards classified explicit/implicit, quality assurance mechanisms classified adopted/noted), aligning the frontend designer with the backend `technical-designer`
+- **Completion Report Contract for build recipes** (commands) — build / front-build replace the prose Output Example with an explicit completion-report contract enumerating required fields (task decomposition status, implemented task count, quality check result, commit count, cleanup result, escalation/blocking summary)
+
+### Changed
+
+- **Codebase-first linear design recipes** (commands) — design and front-design are reworked into a fixed linear flow with no orchestrator branching. The flow starts from a lightweight scope bootstrap (locating seed files) → `codebase-analyzer` → user scope confirmation → design document creation → verification chain. When the design involves an architecture decision, an ADR is created as a prerequisite to the Design Doc rather than a substitute for it; the Design Doc and the full verification chain (`code-verifier` → `document-reviewer` → `design-sync`) always run. `design-sync` runs before the final user approval, consistent with the Workflow Overview
+- **Design-to-Plan Traceability: Design Doc column** (skills) — The traceability table gains a `Design Doc` column so downstream task generation resolves the source design document unambiguously; `task-decomposer` propagates the resolved (Design Doc, DD Section) pair into task Investigation Targets
+- **Prompt context trimming for reviewer and designer agents** (agents) — Redundant or duplicated sections removed from code-reviewer, code-verifier, document-reviewer, technical-designer, and technical-designer-frontend without behavior loss. document-reviewer's Step 5 Self-Validation is upgraded to a blocking gate that re-verifies Gate 0 / Gate 1 coverage before output
+
 ## [1.22.1] - 2026-05-16
 
 ### Added

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-ai-project",
-  "version": "1.22.1",
+  "version": "1.23.1",
   "packageManager": "npm@10.8.2",
   "description": "TypeScript boilerplate with skills and sub-agents for Claude Code. Prevents context exhaustion through role-based task splitting.",
   "keywords": [