create-ai-project 1.22.0 → 1.23.0

package/CHANGELOG.md

@@ -5,6 +5,34 @@ 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.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
+
+- **Minimal Surface Alternatives design gate** (agents, skills) — Gate-1 sub-gate for `technical-designer` and `technical-designer-frontend` requiring each new maintenance-surface-bearing element (persistent state; public-contract elements or cross-boundary fields/props; behavioral modes/flags/variants; reusable abstractions or component splits) to be evaluated against subtractive alternatives via a 5-step procedure: Fix Requirements (referencing the Design Doc, PRD, or UI Spec by AC ID, AC heading, EARS clause, or constraint ID) → Diverge with at least one subtractive alternative → Compare in a context-adaptive table → Converge on the smallest surface using a 5-column resolution priority → Record Rejected Alternatives. Context-specific in-scope sets distinguish backend (fields crossing module/service boundaries, concept/mode/flag) from frontend (ownership boundary crossings — public API props of exported reusable components, Context values, state lifted across ownership boundaries — plus props/modes/variants that change observable behavior). `document-reviewer` enforces section existence at Gate 0 and per-element quality at Gate 1 (AC reference present, subtractive alternative present, rationale anchored to a current requirement smaller alternatives fail to cover, rejected log present). `code-reviewer` escalates when implementation introduces in-scope elements absent from the Design Doc's section. `technical-designer` Reverse-Engineer Mode skips the gate (documenting existing elements, not introducing new ones)
+- **Minimum Surface for Required Coverage principle** (skills) — New `coding-standards` Basic Principle, distinct from YAGNI: YAGNI is a time-axis check (refuse work for future-only needs); this principle constrains surface area at a fixed coverage point. Adoption is justified by naming a current requirement or constraint that smaller alternatives fail to cover; value-based arguments (reusable, future-ready, convenient for implementation) serve as tiebreakers only
+- **Design Doc template: Minimal Surface Alternatives and Future Extensibility sections** (skills) — `design-template.md` gains a per-element 5-step output template (fixed requirements, alternatives table with column-name adaptation guidance for backend/frontend contexts, resolution priority for selecting "smallest", selection rationale, rejected alternatives log) and a Future Extensibility section recording capabilities excluded from the current design surface (Deferred possibilities tied to a current requirement, Intentional limitations, Extension points limited to existing interfaces with named current consumers). The two sections are distinguished by record granularity — Step 5 records element-level rejections, Future Extensibility records capability-level exclusions
+- **CLAUDE.md Scope Discipline rule** (project rules) — New section in `CLAUDE.md` defining how to keep edits within the user's specified scope
+
+### Changed
+
+- **`documentation-criteria` Design Doc Includes list** (skills) — Adds "Minimal Surface Alternatives" as required Design Doc content when introducing maintenance-surface elements, keeping the required-content list in sync with `document-reviewer` enforcement
+
 ## [1.22.0] - 2026-05-10
 
 ### Added

package/CLAUDE.en.md

@@ -29,7 +29,7 @@ Core rules for maximizing AI execution accuracy. All instructions must follow th
 **Trigger**: When starting work that involves Edit/Write/MultiEdit tools
 
 - [ ] Execute rule-advisor subagent (using Task tool)
-- [ ] Update tasks with TaskCreate/TaskUpdate
+- [ ] Create/update tasks with TaskCreate/TaskUpdate
   - Record taskEssence as completion criteria
   - Reflect firstActionGuidance as first action
   - Record warningPatterns as checkpoints during execution
@@ -70,6 +70,15 @@ Pause work and report status when these conditions occur:
 4. Present action plan to user
 5. Execute fix after approval
 
+## Scope Discipline
+
+**Apply instructions to the user's specified scope. Ask before expanding it.**
+
+- Treat explicit quantities and targets ("one", "this file", "only X") as boundaries
+- Copy/move/mirror requests preserve content verbatim; edit content only when requested
+- Port/translation requests preserve intent and behavior; adapt only what the destination context requires
+- Ask before changing related files, symmetric locations, adjacent behavior, or adding "helpful" extras
+
 ## User Confirmation Required
 
 Obtain user confirmation before implementation in these situations:

package/CLAUDE.ja.md

@@ -6,7 +6,7 @@ AI実行精度最大化のための中核ルール。全ての指示はこのフ
 
 **すべてのEdit/Write/MultiEditツール使用前にユーザー承認が必須**
 
-- 編集作業の前にAskUserQuestionで変更計画を提示し、明示的な承認を得ること
+- 編集ツール使用前にAskUserQuestionで変更計画を提示し、明示的な承認を得ること
 - 調査・読み込み・分析は承認不要
 
 ## 品質基準：技術的な妥協をしない
@@ -29,7 +29,7 @@ AI実行精度最大化のための中核ルール。全ての指示はこのフ
 **トリガー**: Edit/Write/MultiEditツールを使う作業の開始時
 
 - [ ] rule-advisorサブエージェントを実行（Taskツール使用）
-- [ ] TaskCreate/TaskUpdateでタスクを更新
+- [ ] TaskCreate/TaskUpdateでタスクを作成・更新
   - taskEssenceを完了判断基準として記録
   - firstActionGuidanceを初動アクションとして反映
   - warningPatternsを実行中の確認項目として記録
@@ -43,7 +43,7 @@ AI実行精度最大化のための中核ルール。全ての指示はこのフ
 ### Step 3: 実装実行
 
 - [ ] 承認されたアプローチに従いEdit/Write/MultiEditを実行
-- [ ] 3ファイル編集ごとにTaskUpdateで更新（進捗と方向性を確認）
+- [ ] ファイル編集3回ごとにTaskUpdateで更新（進捗と方向性を確認）
 
 ### Step 4: 品質検証
 
@@ -70,6 +70,15 @@ AI実行精度最大化のための中核ルール。全ての指示はこのフ
 4. 対処計画をユーザーに提示
 5. 承認後に修正を実行
 
+## スコープ規律
+
+**指示はユーザーが指定したスコープ内で実行する。拡張する前に確認を取る。**
+
+- 明示された数量と対象（"one"、"this file"、"only X" 等）は境界として扱う
+- コピー/移動/ミラー依頼は内容をそのまま維持し、変更は依頼があったときのみ行う
+- 移植/翻訳依頼は意図と振る舞いを保持し、適応は移植先・翻訳先の文脈で必要な範囲に限る
+- 関連ファイル、対応箇所、隣接する振る舞いの変更、「ついで」の追加は、変更前に確認する
+
 ## ユーザー確認必須
 
 以下の状況では実装前にユーザー確認を取得：

package/CLAUDE.md

@@ -6,7 +6,7 @@ AI実行精度最大化のための中核ルール。全ての指示はこのフ
 
 **すべてのEdit/Write/MultiEditツール使用前にユーザー承認が必須**
 
-- 編集作業の前にAskUserQuestionで変更計画を提示し、明示的な承認を得ること
+- 編集ツール使用前にAskUserQuestionで変更計画を提示し、明示的な承認を得ること
 - 調査・読み込み・分析は承認不要
 
 ## 品質基準：技術的な妥協をしない
@@ -29,7 +29,7 @@ AI実行精度最大化のための中核ルール。全ての指示はこのフ
 **トリガー**: Edit/Write/MultiEditツールを使う作業の開始時
 
 - [ ] rule-advisorサブエージェントを実行（Taskツール使用）
-- [ ] TaskCreate/TaskUpdateでタスクを更新
+- [ ] TaskCreate/TaskUpdateでタスクを作成・更新
   - taskEssenceを完了判断基準として記録
   - firstActionGuidanceを初動アクションとして反映
   - warningPatternsを実行中の確認項目として記録
@@ -43,7 +43,7 @@ AI実行精度最大化のための中核ルール。全ての指示はこのフ
 ### Step 3: 実装実行
 
 - [ ] 承認されたアプローチに従いEdit/Write/MultiEditを実行
-- [ ] 3ファイル編集ごとにTaskUpdateで更新（進捗と方向性を確認）
+- [ ] ファイル編集3回ごとにTaskUpdateで更新（進捗と方向性を確認）
 
 ### Step 4: 品質検証
 
@@ -70,6 +70,15 @@ AI実行精度最大化のための中核ルール。全ての指示はこのフ
 4. 対処計画をユーザーに提示
 5. 承認後に修正を実行
 
+## スコープ規律
+
+**指示はユーザーが指定したスコープ内で実行する。拡張する前に確認を取る。**
+
+- 明示された数量と対象（"one"、"this file"、"only X" 等）は境界として扱う
+- コピー/移動/ミラー依頼は内容をそのまま維持し、変更は依頼があったときのみ行う
+- 移植/翻訳依頼は意図と振る舞いを保持し、適応は移植先・翻訳先の文脈で必要な範囲に限る
+- 関連ファイル、対応箇所、隣接する振る舞いの変更、「ついで」の追加は、変更前に確認する
+
 ## ユーザー確認必須
 
 以下の状況では実装前にユーザー確認を取得：

package/package.json

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