create-ai-project 1.14.12 → 1.14.14

package/.claude/agents-en/document-reviewer.md

@@ -62,6 +62,8 @@ Operates in an independent context without CLAUDE.md principles, executing auton
 ### Step 1: Parameter Analysis
 - Confirm mode is `composite` or unspecified
 - Specialized verification based on doc_type
+- For DesignDoc: Verify "Applicable Standards" section exists with explicit/implicit classification
+  - Missing or incomplete → `critical` issue; implicit standards without confirmation → `important` issue
 
 ### Step 2: Target Document Collection
 - Load document specified by target
@@ -69,16 +71,29 @@ Operates in an independent context without CLAUDE.md principles, executing auton
 - For Design Docs, also check common ADRs (`ADR-COMMON-*`)
 
 ### Step 3: Perspective-based Review Implementation
-#### Comprehensive Review Mode
+
+#### Gate 0: Structural Existence (must pass before Gate 1)
+Verify required elements exist per documentation-criteria skill template. Gate 0 failure on any item → `needs_revision`.
+
+For DesignDoc, additionally verify:
+- [ ] Code inspection evidence recorded (files and functions listed)
+- [ ] Applicable standards listed with explicit/implicit classification
+- [ ] Field propagation map present (when fields cross boundaries)
+
+#### Gate 1: Quality Assessment (only after Gate 0 passes)
+
+**Comprehensive Review Mode**:
 - Consistency check: Detect contradictions between documents
-- Completeness check: Confirm presence of required elements
+- Completeness check: Confirm depth and coverage of required elements
 - Rule compliance check: Compatibility with project rules
 - Feasibility check: Technical and resource perspectives
 - Assessment consistency check: Verify alignment between scale assessment and document requirements
+- Rationale verification: Design decision rationales must reference identified standards or existing patterns; unverifiable rationale → `important` issue
 - Technical information verification: When sources exist, verify with WebSearch for latest information and validate claim validity
 - Failure scenario review: Identify failure scenarios across normal usage, high load, and external failures; specify which design element becomes the bottleneck
+- Code inspection evidence review: Verify inspected files are relevant to design scope; flag if key related files are missing
 
-#### Perspective-specific Mode
+**Perspective-specific Mode**:
 - Implement review based on specified mode and focus
 
 ### Step 4: Prior Context Resolution Check
@@ -131,6 +146,10 @@ Complete all items before proceeding to output.
     "rule_compliance": 90,
     "clarity": 75
   },
+  "gate0": {
+    "status": "pass|fail",
+    "missing_elements": []
+  },
   "verdict": {
     "decision": "approved_with_conditions",
     "conditions": [
@@ -219,10 +238,15 @@ Include in output when `prior_context_count > 0`:
 - [ ] Verification of sources for technical claims and consistency with latest information
 - [ ] Failure scenario coverage
 - [ ] Complexity justification: If complexity_level is medium/high, complexity_rationale must specify (1) requirements/ACs necessitating the complexity, (2) constraints/risks it addresses
+- [ ] Gate 0 structural existence checks pass before quality review
+- [ ] Design decision rationales verified against identified standards/patterns
+- [ ] Code inspection evidence covers files relevant to design scope
+- [ ] Field propagation map present when fields cross component boundaries
 
 ## Review Criteria (for Comprehensive Mode)
 
 ### Approved
+- Gate 0: All structural existence checks pass
 - Consistency score > 90
 - Completeness score > 85
 - No rule violations (severity: high is zero)
@@ -230,6 +254,7 @@ Include in output when `prior_context_count > 0`:
 - Prior context items (if any): All critical/major resolved
 
 ### Approved with Conditions
+- Gate 0: All structural existence checks pass
 - Consistency score > 80
 - Completeness score > 75
 - Only minor rule violations (severity: medium or below)
@@ -237,6 +262,7 @@ Include in output when `prior_context_count > 0`:
 - Prior context items (if any): At most 1 major unresolved
 
 ### Needs Revision
+- Gate 0: Any structural existence check fails OR
 - Consistency score < 80 OR
 - Completeness score < 75 OR
 - Serious rule violations (severity: high)

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

@@ -51,6 +51,21 @@ Details of documentation creation criteria follow documentation-criteria skill.
 
 ## Mandatory Process Before Design Doc Creation
 
+### Standards Identification Gate【Required】
+Must be performed before any investigation:
+
+1. **Identify Project Standards**
+   - Scan project configuration, rule files, and existing code patterns
+   - Classify each: **Explicit** (documented) or **Implicit** (observed pattern only)
+
+2. **Record in Design Doc**
+   - List in "Applicable Standards" section with `[explicit]`/`[implicit]` tags
+   - Implicit standards require user confirmation before design proceeds
+
+3. **Alignment Rule**
+   - Design decisions must reference applicable standards
+   - Deviations require documented rationale
+
 ### Existing Code Investigation【Required】
 Must be performed before Design Doc creation:
 
@@ -76,6 +91,23 @@ Must be performed before Design Doc creation:
    - Clearly document similar functionality search results (found implementations or "none")
    - Record adopted decision (use existing/improvement proposal/new implementation) and rationale
 
+5. **Code Inspection Evidence**
+   - Record all inspected files and key functions in "Code Inspection Evidence" section of Design Doc
+   - Each entry must state relevance (similar functionality / integration point / pattern reference)
+
+### Data Representation Decision【Required】
+When the design introduces or significantly modifies data structures:
+
+1. **Reuse-vs-New Assessment**
+   - Search for existing structures with overlapping purpose
+   - Evaluate: semantic fit, responsibility fit, lifecycle fit, boundary/interop cost
+
+2. **Decision Rule**
+   - All criteria satisfied → Reuse existing
+   - 1-2 criteria fail → Evaluate extension with adapter
+   - 3+ criteria fail → New structure justified
+   - Record decision and rationale in Design Doc
+
 ### Integration Point Analysis【Important】
 Clarify integration points with existing systems when adding new features or modifying existing ones:
 
@@ -142,6 +174,12 @@ No Ripple Effect:
   - Other services, DB structure
 ```
 
+### Field Propagation Map【Required】
+When new or changed fields cross component boundaries:
+
+Document each field's status (preserved / transformed / dropped) at each boundary with rationale.
+Skip if no fields cross component boundaries.
+
 ### Interface Change Impact Analysis【Required】
 
 **Change Matrix:**
@@ -305,6 +343,10 @@ Implementation sample creation checklist:
 - [ ] Implementation approach selection rationale (vertical/horizontal/hybrid)
 - [ ] Latest best practices researched and references cited
 - [ ] **Complexity assessment**: complexity_level set; if medium/high, complexity_rationale specifies (1) requirements/ACs, (2) constraints/risks
+- [ ] **Standards identification gate completed** (required)
+- [ ] **Code inspection evidence recorded** (required)
+- [ ] **Data representation decision documented** (when new structures introduced)
+- [ ] **Field propagation map included** (when fields cross boundaries)
 
 
 ## Acceptance Criteria Creation Guidelines

package/.claude/agents-ja/document-reviewer.md

@@ -62,6 +62,8 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 ### ステップ1: パラメータ解析
 - modeが`composite`または未指定を確認
 - doc_typeに基づく特化した検証
+- DesignDocの場合:「適用基準」セクションの存在をexplicit/implicit分類付きで確認
+  - 欠落・不完全 → `critical`、implicit基準の未確認 → `important`
 
 ### ステップ2: 対象ドキュメントの収集
 - targetで指定されたドキュメントを読み込み
@@ -69,16 +71,29 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 - Design Docの場合は共通ADR（`ADR-COMMON-*`）も確認
 
 ### ステップ3: 観点別レビューの実施
-#### 総合レビューモード
+
+#### Gate 0: 必須要素の存在チェック（Gate 1の前に必ず実施）
+documentation-criteriaスキルのテンプレートに基づき必須要素の存在を確認。いずれかの項目で不合格 → `needs_revision`。
+
+DesignDocの場合、追加で以下を確認:
+- [ ] コード調査エビデンスの記録（ファイルと関数の一覧）
+- [ ] 適用基準のexplicit/implicit分類付き一覧
+- [ ] フィールド伝播マップの存在（フィールドが境界を越える場合）
+
+#### Gate 1: 品質評価（Gate 0通過後のみ実施）
+
+**総合レビューモード**:
 - 整合性チェック：ドキュメント間の矛盾を検出
-- 完成度チェック：必須要素の有無を確認
+- 完成度チェック：必須要素の深度と網羅性を確認
 - ルール準拠チェック：プロジェクトルールとの適合性
 - 実現可能性チェック：技術的・リソース的観点
 - 判定整合性チェック：規模判定とドキュメント要件の整合性を検証
+- 根拠検証：設計判断の根拠は特定された基準または既存パターンを参照すること。検証不能な根拠 → `important`
 - 技術情報検証：出典がある場合はWebSearchで最新情報を確認、主張の妥当性を検証
 - 失敗シナリオ検証：正常系・高負荷・外部障害の失敗シナリオを特定し、どの設計要素がボトルネックになるか指摘
+- コード調査エビデンス検証：調査ファイルが設計スコープに関連するか確認、主要な関連ファイルの漏れを指摘
 
-#### 観点特化モード
+**観点特化モード**:
 - 指定されたmodeとfocusに基づいてレビューを実施
 
 ### ステップ4: prior context解決チェック
@@ -131,6 +146,10 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
     "rule_compliance": 90,
     "clarity": 75
   },
+  "gate0": {
+    "status": "pass|fail",
+    "missing_elements": []
+  },
   "verdict": {
     "decision": "approved_with_conditions",
     "conditions": [
@@ -219,10 +238,15 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 - [ ] 技術的主張の出典確認と最新情報との整合性
 - [ ] 失敗シナリオの網羅性
 - [ ] 複雑性の正当化: complexity_levelがmedium/highの場合、complexity_rationaleは(1)その複雑性を必要とする要件/AC、(2)対処する制約/リスクを明記すること
+- [ ] Gate 0の存在チェックが品質レビュー前に通過していること
+- [ ] 設計判断の根拠が特定された基準/パターンに照合されていること
+- [ ] コード調査エビデンスが設計スコープに関連するファイルを網羅していること
+- [ ] フィールドが境界を越える場合にフィールド伝播マップが存在すること
 
 ## レビュー基準（総合モード用）
 
 ### 承認（Approved）
+- Gate 0: すべての存在チェック通過
 - 整合性スコア > 90
 - 完成度スコア > 85
 - ルール違反なし（重大度: high がゼロ）
@@ -230,6 +254,7 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 - prior context項目（ある場合）: critical/majorすべて解決済み
 
 ### 条件付き承認（Approved with Conditions）
+- Gate 0: すべての存在チェック通過
 - 整合性スコア > 80
 - 完成度スコア > 75
 - 軽微なルール違反のみ（重大度: medium 以下）
@@ -237,6 +262,7 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 - prior context項目（ある場合）: major未解決は最大1件
 
 ### 要修正（Needs Revision）
+- Gate 0: いずれかの存在チェック不合格、または
 - 整合性スコア < 80 または
 - 完成度スコア < 75 または
 - 重大なルール違反あり（重大度: high）

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

@@ -51,6 +51,21 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 
 ## Design Doc作成前の必須プロセス
 
+### 基準特定ゲート【必須】
+調査開始前に必ず実施：
+
+1. **プロジェクト基準の特定**
+   - プロジェクト設定、ルールファイル、既存コードパターンをスキャン
+   - 各基準を分類: **Explicit**（文書化済み）または **Implicit**（観察されたパターンのみ）
+
+2. **Design Docへの記録**
+   - 「適用基準」セクションに`[explicit]`/`[implicit]`タグ付きで記載
+   - Implicit基準は設計着手前にユーザー確認が必要
+
+3. **整合性ルール**
+   - 設計判断は適用基準を参照すること
+   - 逸脱する場合は根拠を明記
+
 ### 既存コード調査【必須】
 Design Doc作成前に必ず実施：
 
@@ -76,6 +91,23 @@ Design Doc作成前に必ず実施：
    - 類似機能の検索結果（発見した実装、または「なし」）を明記
    - 採用した判断（既存使用/改善提案/新規実装）とその根拠を記録
 
+5. **コード調査エビデンス**
+   - 調査したすべてのファイルと主要関数をDesign Docの「コード調査エビデンス」セクションに記録
+   - 各エントリの関連性（類似機能 / 統合点 / パターン参照）を明記
+
+### データ構造の採用判断【必須】
+設計で新規データ構造の導入や大幅な変更を行う場合：
+
+1. **再利用vs新規の評価**
+   - 目的が重複する既存構造を検索
+   - 評価: 意味的適合、責務適合、ライフサイクル適合、境界/相互運用コスト
+
+2. **判断ルール**
+   - 全基準適合 → 既存を再利用
+   - 1-2基準不適合 → アダプターによる拡張を検討
+   - 3基準以上不適合 → 新規構造を正当化
+   - 判断と根拠をDesign Docに記録
+
 ### 統合ポイント分析【重要】
 新機能や既存機能の変更時に、既存システムとの統合ポイントを明確化：
 
@@ -138,10 +170,16 @@ Design Doc作成時に必ず含める:
 間接影響:
   - セッション管理（トークン形式変更）
   - ログ出力（新フィールド追加）
-波及なし: 
+波及なし:
   - 他のサービス、DB構造
 ```
 
+### フィールド伝播マップ【必須】
+フィールドがコンポーネント境界を越える場合：
+
+各境界でのフィールドのステータス（preserved / transformed / dropped）を根拠付きで記録。
+フィールドが境界を越えない場合はスキップ。
+
 ### インターフェース変更影響分析【必須】
 
 **変更マトリクス:**
@@ -304,6 +342,10 @@ ADRに含まない：スケジュール、実装手順、具体的コード
 - [ ] 実装アプローチ（垂直/水平/ハイブリッド）の選択根拠
 - [ ] 最新のベストプラクティスの調査と参考資料の記載
 - [ ] **複雑性評価**: complexity_levelを設定。medium/highの場合、complexity_rationaleに(1)要件/AC、(2)制約/リスクを明記
+- [ ] **基準特定ゲート完了**（必須）
+- [ ] **コード調査エビデンス記録済み**（必須）
+- [ ] **データ構造の採用判断の文書化**（新規構造導入時）
+- [ ] **フィールド伝播マップの記載**（フィールドが境界を越える場合）
 
 
 ## 受入条件の作成ガイドライン

package/.claude/commands-en/add-integration-tests.md

@@ -1,5 +1,4 @@
 ---
-name: add-integration-tests
 description: Add integration/E2E tests to existing backend codebase using Design Doc
 ---
 

package/.claude/commands-en/front-reverse-design.md

@@ -1,5 +1,4 @@
 ---
-name: front-reverse-design
 description: Generate frontend Design Docs from existing codebase using existing PRD
 ---
 

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

@@ -1,5 +1,4 @@
 ---
-name: front-review
 description: Design Doc compliance validation with optional auto-fixes
 ---
 

package/.claude/commands-en/reverse-engineer.md

@@ -1,5 +1,4 @@
 ---
-name: reverse-engineer
 description: Generate PRD and Design Docs from existing codebase through discovery, generation, verification, and review workflow
 ---
 

package/.claude/commands-en/update-doc.md

@@ -0,0 +1,178 @@
+---
+description: Update existing design documents (Design Doc / PRD / ADR) with review
+---
+
+**Command Context**: This command is dedicated to updating existing design documents.
+
+## Orchestrator Definition
+
+**Core Identity**: "I am not a worker. I am an orchestrator." (see subagents-orchestration-guide skill)
+
+**First Action**: Register Steps 1-6 to TodoWrite before any execution.
+
+**Execution Protocol**:
+1. **Delegate all work** to sub-agents (NEVER edit documents yourself)
+2. **Execute update flow**:
+   - Identify target → Clarify changes → Update document → Review → Consistency check
+   - **Stop at every `[Stop: ...]` marker** → Wait for user approval before proceeding
+3. **Scope**: Complete when updated document receives approval
+
+**CRITICAL**: NEVER skip document-reviewer or stopping points.
+
+## Workflow Overview
+
+```
+Target document → [Stop: Confirm changes]
+                        ↓
+              technical-designer / prd-creator (update mode)
+                        ↓
+              document-reviewer → [Stop: Review approval]
+                        ↓ (Design Doc only)
+              design-sync → [Stop: Final approval]
+```
+
+## Scope Boundaries
+
+**Included in this command**:
+- Existing document identification and selection
+- Change content clarification with user
+- Document update with appropriate agent (update mode)
+- Document review with document-reviewer
+- Consistency verification with design-sync (Design Doc only)
+
+**NOT included**:
+- New requirement analysis (use /design for new documents)
+- Work planning or implementation (use /plan or /task after this command)
+
+**Responsibility Boundary**: This command completes with updated document approval.
+
+Target document: $ARGUMENTS
+
+## Execution Flow
+
+### Step 1: Target Document Identification
+
+```bash
+# Check existing documents
+ls docs/design/*.md docs/prd/*.md docs/adr/*.md 2>/dev/null | grep -v template
+```
+
+**Decision flow**:
+
+| Situation | Action |
+|-----------|--------|
+| $ARGUMENTS specifies a path | Use specified document |
+| $ARGUMENTS describes a topic | Search documents matching the topic |
+| Multiple candidates found | Present options with AskUserQuestion |
+| No documents found | Report and end (suggest /design instead) |
+
+### Step 2: Document Type Determination
+
+Determine type from document path:
+
+| Path Pattern | Type | Update Agent | Notes |
+|-------------|------|--------------|-------|
+| `docs/design/*.md` | Design Doc | technical-designer | - |
+| `docs/prd/*.md` | PRD | prd-creator | - |
+| `docs/adr/*.md` | ADR | technical-designer | Minor changes: update existing file; Major changes: create new ADR file |
+
+**ADR Update Guidance**:
+- **Minor changes** (clarification, typo fix, small scope adjustment): Update the existing ADR file
+- **Major changes** (decision reversal, significant scope change): Create a new ADR that supersedes the original
+
+### Step 3: Change Content Clarification [Stop]
+
+Use AskUserQuestion to clarify what changes are needed:
+- What sections need updating
+- Reason for the change (bug fix findings, spec change, review feedback, etc.)
+- Expected outcome after the update
+
+Confirm understanding of changes with user before proceeding.
+
+### Step 4: Document Update
+
+Invoke the update agent determined in Step 2:
+```
+subagent_type: [Update Agent from Step 2]
+description: "Update [Type from Step 2]"
+prompt: |
+  Operation Mode: update
+  Existing Document: [path from Step 1]
+
+  ## Changes Required
+  [Changes clarified in Step 3]
+
+  Update the document to reflect the specified changes.
+  Add change history entry.
+```
+
+### Step 5: Document Review [Stop]
+
+Invoke document-reviewer:
+```
+subagent_type: document-reviewer
+description: "Review updated document"
+prompt: |
+  Review the following updated document.
+
+  doc_type: [Design Doc / PRD / ADR]
+  target: [path from Step 1]
+  mode: standard
+
+  Focus on:
+  - Consistency of updated sections with rest of document
+  - No contradictions introduced by changes
+  - Completeness of change history
+```
+
+**On review result**:
+- Approved → Proceed to Step 6
+- Needs revision → Return to Step 4 with reviewer feedback (max 2 iterations)
+- **After 2 rejections** → Flag for human review, present accumulated feedback to user and end
+
+Present review result to user for approval.
+
+### Step 6: Consistency Verification (Design Doc only) [Stop]
+
+**Skip condition**: Document type is PRD or ADR → Proceed to completion.
+
+For Design Doc, invoke design-sync:
+```
+subagent_type: design-sync
+description: "Verify consistency"
+prompt: |
+  Verify consistency of the updated Design Doc with other design documents.
+
+  Updated document: [path from Step 1]
+```
+
+**On consistency result**:
+- No conflicts → Present result to user for final approval
+- Conflicts detected → Present conflicts to user with AskUserQuestion:
+  - A: Return to Step 4 to resolve conflicts in this document
+  - B: End command and address conflicts separately
+
+## Error Handling
+
+| Error | Action |
+|-------|--------|
+| Target document not found | Report and end (suggest /design instead) |
+| Sub-agent update fails | Log failure, present error to user, retry once |
+| Review rejects after 2 revisions | Stop loop, flag for human intervention |
+| design-sync detects conflicts | Present to user for resolution decision |
+
+## Completion Criteria
+
+- [ ] Identified target document
+- [ ] Clarified change content with user
+- [ ] Updated document with appropriate agent (update mode)
+- [ ] Executed document-reviewer and addressed feedback
+- [ ] Executed design-sync for consistency verification (Design Doc only)
+- [ ] Obtained user approval for updated document
+
+## Output Example
+Document update completed.
+- Updated document: docs/design/[document-name].md
+- Approval status: User approved
+
+**Important**: This command ends with document approval. Does not propose transition to next phase.

package/.claude/commands-ja/add-integration-tests.md

@@ -1,5 +1,4 @@
 ---
-name: add-integration-tests
 description: Design Docを使用して既存バックエンドコードベースに統合/E2Eテストを追加
 ---
 

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

@@ -1,5 +1,4 @@
 ---
-name: front-reverse-design
 description: 既存PRDを使用して既存コードベースからフロントエンドDesign Docを生成
 ---
 

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

@@ -1,5 +1,4 @@
 ---
-name: front-review
 description: Design Doc準拠検証と必要に応じた自動修正
 ---
 

package/.claude/commands-ja/reverse-engineer.md

@@ -1,5 +1,4 @@
 ---
-name: reverse-engineer
 description: 既存コードベースからPRDとDesign Docを生成するリバースエンジニアリングワークフロー
 ---
 

package/.claude/commands-ja/update-doc.md

@@ -0,0 +1,178 @@
+---
+description: 既存設計ドキュメント（Design Doc / PRD / ADR）をレビュー付きで更新
+---
+
+**コマンドコンテキスト**: このコマンドは既存設計ドキュメントの更新専用です。
+
+## オーケストレーター定義
+
+**コアアイデンティティ**: 「私は作業者ではない。オーケストレーターである。」（subagents-orchestration-guideスキル参照）
+
+**初期アクション**: 実行前にステップ1-6をTodoWriteに登録する。
+
+**実行プロトコル**:
+1. **全作業をサブエージェントに委譲**（自分でドキュメントを編集しない）
+2. **更新フローを実行**:
+   - 対象特定 → 変更内容確認 → ドキュメント更新 → レビュー → 整合性チェック
+   - **`[停止: ...]`マーカーで必ず停止** → 次に進む前にユーザー承認を待つ
+3. **スコープ**: 更新されたドキュメントが承認されたら完了
+
+**重要**: document-reviewerと停止ポイントは必ず実行する。
+
+## ワークフロー概要
+
+```
+対象ドキュメント → [停止: 変更内容確認]
+                        ↓
+              technical-designer / prd-creator（updateモード）
+                        ↓
+              document-reviewer → [停止: レビュー承認]
+                        ↓（Design Docのみ）
+              design-sync → [停止: 最終承認]
+```
+
+## スコープ境界
+
+**実行内容**:
+- 既存ドキュメントの特定と選択
+- ユーザーとの変更内容確認
+- 適切なエージェントによるドキュメント更新（updateモード）
+- document-reviewerによるドキュメントレビュー
+- design-syncによる整合性検証（Design Docのみ）
+
+**実行しない**:
+- 新規要件分析（新規ドキュメントには/designを使用）
+- 作業計画や実装（本コマンド後に/planまたは/taskを使用）
+
+**責務境界**: このコマンドは更新されたドキュメントの承認で責務完了。
+
+対象ドキュメント: $ARGUMENTS
+
+## 実行フロー
+
+### ステップ1: 対象ドキュメントの特定
+
+```bash
+# 既存ドキュメントを確認
+ls docs/design/*.md docs/prd/*.md docs/adr/*.md 2>/dev/null | grep -v template
+```
+
+**判断フロー**:
+
+| 状況 | アクション |
+|------|-----------|
+| $ARGUMENTSがパスを指定 | 指定ドキュメントを使用 |
+| $ARGUMENTSがトピックを記述 | トピックに合致するドキュメントを検索 |
+| 複数の候補が見つかった | AskUserQuestionで選択肢を提示 |
+| ドキュメントが見つからない | 報告して終了（代わりに/designを推奨） |
+
+### ステップ2: ドキュメントタイプの判定
+
+ドキュメントパスからタイプを判定:
+
+| パスパターン | タイプ | 更新エージェント | 備考 |
+|-------------|--------|-----------------|------|
+| `docs/design/*.md` | Design Doc | technical-designer | - |
+| `docs/prd/*.md` | PRD | prd-creator | - |
+| `docs/adr/*.md` | ADR | technical-designer | 軽微な変更: 既存ファイルを更新、大きな変更: 元を置き換える新ADRを作成 |
+
+**ADR更新ガイダンス**:
+- **軽微な変更**（明確化、誤字修正、小規模なスコープ調整）: 既存ADRファイルを更新
+- **大きな変更**（決定の変更、大規模なスコープ変更）: 元のADRを置き換える新しいADRを作成
+
+### ステップ3: 変更内容の確認 [停止]
+
+AskUserQuestionで必要な変更を確認:
+- どのセクションの更新が必要か
+- 変更の理由（バグ修正の発見、仕様変更、レビューフィードバック等）
+- 更新後の期待される結果
+
+変更内容の理解をユーザーと確認してから進む。
+
+### ステップ4: ドキュメント更新
+
+ステップ2で決定した更新エージェントを呼び出す:
+```
+subagent_type: [ステップ2の更新エージェント]
+description: "[ステップ2のタイプ]を更新"
+prompt: |
+  動作モード: update
+  既存ドキュメント: [ステップ1のパス]
+
+  ## 必要な変更
+  [ステップ3で確認した変更内容]
+
+  指定された変更を反映するようドキュメントを更新する。
+  変更履歴エントリを追加する。
+```
+
+### ステップ5: ドキュメントレビュー [停止]
+
+document-reviewerを呼び出す:
+```
+subagent_type: document-reviewer
+description: "更新されたドキュメントをレビュー"
+prompt: |
+  以下の更新されたドキュメントをレビューする。
+
+  doc_type: [Design Doc / PRD / ADR]
+  target: [ステップ1のパス]
+  mode: standard
+
+  注力ポイント:
+  - 更新セクションとドキュメント全体の整合性
+  - 変更による矛盾が発生していないこと
+  - 変更履歴の完全性
+```
+
+**レビュー結果に基づく対応**:
+- 承認 → ステップ6へ進む
+- 要修正 → レビュアーフィードバックを持ってステップ4に戻る（最大2回）
+- **2回のリジェクト後** → 人間レビュー用にフラグ、蓄積されたフィードバックをユーザーに提示して終了
+
+レビュー結果をユーザーに提示して承認を得る。
+
+### ステップ6: 整合性検証（Design Docのみ） [停止]
+
+**スキップ条件**: ドキュメントタイプがPRDまたはADR → 完了へ進む。
+
+Design Docの場合、design-syncを呼び出す:
+```
+subagent_type: design-sync
+description: "整合性を検証"
+prompt: |
+  更新されたDesign Docと他の設計ドキュメントとの整合性を検証する。
+
+  更新されたドキュメント: [ステップ1のパス]
+```
+
+**整合性結果に基づく対応**:
+- 矛盾なし → 結果をユーザーに提示して最終承認を得る
+- 矛盾を検出 → AskUserQuestionで矛盾をユーザーに提示:
+  - A: このドキュメントの矛盾を解決するためステップ4に戻る
+  - B: コマンドを終了し、矛盾は別途対応する
+
+## エラーハンドリング
+
+| エラー | アクション |
+|--------|-----------|
+| 対象ドキュメントが見つからない | 報告して終了（代わりに/designを推奨） |
+| サブエージェントの更新が失敗 | 失敗をログ、エラーをユーザーに提示、1回リトライ |
+| 2回の修正後もレビューがリジェクト | ループを停止、人間介入用にフラグ |
+| design-syncが矛盾を検出 | 解決判断のためユーザーに提示 |
+
+## 完了条件
+
+- [ ] 対象ドキュメントを特定した
+- [ ] ユーザーと変更内容を確認した
+- [ ] 適切なエージェントでドキュメントを更新した（updateモード）
+- [ ] document-reviewerを実行しフィードバックに対応した
+- [ ] design-syncで整合性検証を実行した（Design Docのみ）
+- [ ] 更新されたドキュメントのユーザー承認を取得した
+
+## 出力例
+ドキュメント更新が完了しました。
+- 更新されたドキュメント: docs/design/[ドキュメント名].md
+- 承認ステータス: ユーザー承認済み
+
+**重要**: 本コマンドはドキュメント承認で終了。次フェーズへの移行提案は行わない。

package/.claude/skills-en/documentation-criteria/SKILL.md

@@ -97,6 +97,10 @@ description: Guides PRD, ADR, Design Doc, and Work Plan creation with templates
 - Complete enumeration of integration points
 - Data contract clarification
 - **Agreement checklist** (agreements with stakeholders)
+- **Code inspection evidence** (inspected files/functions during investigation)
+- **Field propagation map** (when fields cross component boundaries)
+- **Data representation decision** (when introducing new structures)
+- **Applicable standards** (explicit/implicit classification)
 - **Prerequisite ADRs** (including common ADRs)
 
 **Excludes**:
@@ -133,6 +137,7 @@ description: Guides PRD, ADR, Design Doc, and Work Plan creation with templates
 ## Creation Process
 
 1. **Problem Analysis**: Change scale assessment, ADR condition check
+   - Identify explicit and implicit project standards before investigation
 2. **ADR Option Consideration** (ADR only): Compare 3+ options, specify trade-offs
 3. **Creation**: Use templates, include measurable conditions
 4. **Approval**: "Accepted" after review enables implementation

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

@@ -44,6 +44,10 @@ unknowns:
 - [ ] Backward compatibility: [Required/Not required]
 - [ ] Performance measurement: [Required/Not required]
 
+#### Applicable Standards
+- [Standard/convention] `[explicit]` — Source: [config / rule file / doc path]
+- [Observed pattern] `[implicit]` — Evidence: [file paths] — Confirmed: [Yes/No]
+
 ### Problem to Solve
 
 [Specific problems or challenges this feature aims to address]
@@ -93,6 +97,9 @@ Each AC is written in EARS format. Keywords determine test type.
 - **Integration Target**: [What to connect with]
 - **Invocation Method**: [How it will be invoked]
 
+### Code Inspection Evidence
+- [path:function] — [relevance: similar functionality / integration point / pattern reference]
+
 ## Design
 
 ### Change Impact Map
@@ -140,6 +147,14 @@ No Ripple Effect:
 - **Interface**: [APIs and type definitions provided]
 - **Dependencies**: [Relationships with other components]
 
+### Data Representation Decision (When Introducing New Structures)
+Evaluate existing structures: semantic fit, responsibility fit, lifecycle fit, boundary/interop cost.
+- All fit → reuse existing
+- 1-2 fail → extend with adapter
+- 3+ fail → new structure justified
+
+**Decision**: [reuse / extend / new] — [rationale]
+
 ### Type Definitions
 
 ```typescript
@@ -165,6 +180,9 @@ Invariants:
   - [Conditions that remain unchanged before and after processing]
 ```
 
+### Field Propagation Map (When Fields Cross Boundaries)
+- [field]: [ComponentA → B] — preserved / transformed / dropped — [reason]
+
 ### State Transitions and Invariants
 
 [If the feature involves state management, describe state transitions and invariants here]

package/.claude/skills-ja/documentation-criteria/SKILL.md

@@ -97,6 +97,10 @@ description: PRD、ADR、Design Doc、作業計画書の作成を支援。テン
 - 統合点の完全な列挙
 - データ契約の明確化
 - **合意事項チェックリスト**（関係者との合意内容）
+- **コード調査エビデンス**（調査時に確認したファイル/関数）
+- **フィールド伝播マップ**（フィールドがコンポーネント境界を越える場合）
+- **データ構造の採用判断**（新規構造導入時）
+- **適用基準**（explicit/implicit分類）
 - **前提となるADR**（共通ADR含む）
 
 **必須構造要素**:
@@ -144,6 +148,7 @@ description: PRD、ADR、Design Doc、作業計画書の作成を支援。テン
 ## 作成プロセス
 
 1. **問題分析**: 変更規模判定、ADR条件確認
+   - 調査開始前にプロジェクトのexplicit/implicit基準を特定
 2. **ADR選択肢検討**（ADR時のみ）: 3案以上比較、トレードオフ明記
 3. **作成**: テンプレート使用、測定可能な条件記載
 4. **承認**: レビュー後「Accepted」で実装可

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

@@ -44,6 +44,10 @@ unknowns:
 - [ ] 後方互換性: [必要/不要]
 - [ ] パフォーマンス計測: [必要/不要]
 
+#### 適用基準
+- [基準/規約] `[explicit]` — 出典: [設定ファイル / ルールファイル / ドキュメントパス]
+- [観察されたパターン] `[implicit]` — 根拠: [ファイルパス] — 確認: [済/未]
+
 ### 解決すべき課題
 
 [この機能が解決しようとする具体的な問題や課題]
@@ -93,6 +97,9 @@ unknowns:
 - **統合先**: [何と連携するか]
 - **呼び出し方式**: [どのように呼び出されるか]
 
+### コード調査エビデンス
+- [パス:関数] — [関連性: 類似機能 / 統合点 / パターン参照]
+
 ## 設計
 
 ### 変更影響マップ
@@ -140,6 +147,14 @@ unknowns:
 - **インターフェース**: [提供するAPIや型定義]
 - **依存関係**: [他のコンポーネントとの関係]
 
+### データ構造の採用判断（新規構造導入時）
+既存構造を評価: 意味的適合、責務適合、ライフサイクル適合、境界/相互運用コスト。
+- 全適合 → 既存を再利用
+- 1-2不適合 → アダプターで拡張
+- 3以上不適合 → 新規構造を正当化
+
+**判断**: [再利用 / 拡張 / 新規] — [根拠]
+
 ### 型定義
 
 ```typescript
@@ -165,6 +180,9 @@ unknowns:
   - [処理前後で変わらない条件]
 ```
 
+### フィールド伝播マップ（フィールドが境界を越える場合）
+- [フィールド名]: [コンポーネントA → B] — preserved / transformed / dropped — [理由]
+
 ### 状態遷移と不変条件
 
 [機能が状態管理を含む場合、状態遷移と不変条件をここに記述]

package/README.ja.md

@@ -132,6 +132,7 @@ Claude Codeで利用できる主要なコマンド：
 | `/reverse-engineer` | コードからPRD/Design Docを生成 | 既存システムのドキュメント化（Backend） |
 | `/front-reverse-design` | フロントエンドDesign Docを生成 | 既存フロントエンドコードのドキュメント化 |
 | `/add-integration-tests` | 統合/E2Eテストの追加 | Design Doc存在時のテスト追加 |
+| `/update-doc` | 既存設計ドキュメントの更新 | 仕様変更、レビューフィードバック対応 |
 
 [コマンドの詳細はこちら →](docs/guides/ja/use-cases.md)
 

package/README.md

@@ -138,6 +138,7 @@ Essential commands for Claude Code:
 | `/reverse-engineer` | Generate PRD/Design Docs from code | Legacy system documentation (Backend) |
 | `/front-reverse-design` | Generate frontend Design Docs | Existing frontend code documentation |
 | `/add-integration-tests` | Add integration/E2E tests | When Design Doc exists but tests missing |
+| `/update-doc` | Update existing design documents | Spec changes, review feedback |
 
 [Full command reference →](docs/guides/en/use-cases.md)
 
@@ -162,7 +163,7 @@ Generate PRD and Design Docs from existing code:
 ```mermaid
 graph TB
     subgraph Phase1[Phase 1: PRD Generation]
-        CMD[/reverse-engineer] --> SD1[scope-discoverer]
+        CMD["/reverse-engineer"] --> SD1[scope-discoverer]
         SD1 --> PRD[prd-creator]
         PRD --> CV1[code-verifier]
         CV1 --> DR1[document-reviewer]

package/package.json

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