create-ai-project 1.20.2 → 1.20.3

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

@@ -6,13 +6,16 @@ description: 設計ドキュメントからフロントエンド作業計画書
 
 ## オーケストレーター定義
 
-**Role**: オーケストレーター
+**コアアイデンティティ**: 「私はオーケストレーターである。」（subagents-orchestration-guideスキル参照）
 
-**実行方法**:
-- テストスケルトン生成 → acceptance-test-generatorが実行
-- 作業計画書作成 → work-plannerが実行
+**実行プロトコル**:
+1. **全ての作業をサブエージェントに委譲** — サブエージェントを呼び出し、データを橋渡しし、結果を報告する
+2. **subagents-orchestration-guideスキルの計画フローに従う**:
+   - 以下に定義されたステップを実行
+   - **完了前に停止し、計画内容の承認を取得する**
+3. **スコープ**: 下記スコープ境界を参照
 
-オーケストレーターはサブエージェントを呼び出し、構造化JSONを渡します。
+**重要**: work-plannerの前に必ずacceptance-test-generatorを実行すること — テストスケルトンはsubagents-orchestration-guideの中規模/大規模フローで必須の入力。
 
 ## スコープ境界
 
@@ -24,29 +27,33 @@ description: 設計ドキュメントからフロントエンド作業計画書
 
 **責務境界**: このコマンドは作業計画書承認で責務完了。
 
-以下のプロセスでフロントエンド作業計画書を作成:
+以下の計画プロセスに従う:
 
 ## 実行プロセス
 
-### 1. 設計ドキュメント選択
-! ls -la docs/design/*.md | head -10
-- 設計ドキュメントの存在を確認、なければユーザーに通知
-- 複数ある場合は選択肢を提示（$ARGUMENTSで指定可能）
+### Step 1: 設計ドキュメント選択
+   ! ls -la docs/design/*.md | head -10
+   - 設計ドキュメントの存在を確認、なければユーザーに通知
+   - 複数ある場合は選択肢を提示（$ARGUMENTSで指定可能）
 
-### 2. テストスケルトン生成
-Agentツールで**acceptance-test-generator**を呼び出す:
+### Step 2: テストスケルトン生成
+Agentツールでacceptance-test-generatorを呼び出す:
 - `subagent_type`: "acceptance-test-generator"
 - `description`: "テストスケルトン生成"
 - UI Specあり: `prompt: "[パス]のDesign Docからテストスケルトンを生成。UI Specは[ui-specパス]。"`
 - UI Specなし: `prompt: "[パス]のDesign Docからテストスケルトンを生成。"`
 
-### 3. 作業計画書作成
-Agentツールで**work-planner**を呼び出す:
+統合テストファイルパスとE2Eテストファイルパスを、subagents-orchestration-guideの「acceptance-test-generator → work-planner」セクションに従いwork-plannerに渡す。
+
+### Step 3: 作業計画書作成
+Agentツールでwork-plannerを呼び出す:
 - `subagent_type`: "work-planner"
 - `description`: "作業計画書作成"
 - `prompt`: "[パス]のDesign Docから作業計画を作成。統合テストファイル: [ステップ2の統合テストパス]。E2Eテストファイル: [ステップ2のE2Eテストパス]。統合テストは各フェーズ実装と同時に作成、E2Eテストは最終フェーズでのみ実行。"
 
-ユーザーと対話して計画を完成させ、計画内容の承認を得る。具体的な実装ステップとリスクを明確化。
+- subagents-orchestration-guideのPrompt Construction Ruleに従い追加パラメータを構成
+- 作業計画書をユーザーに提示しレビューを受ける。変更要望があればwork-plannerを修正パラメータで再実行
+- スコープが不明確なステップや外部依存があるステップを強調し、ユーザーに確認を求める
 
 **スコープ**: 作業計画書作成と計画内容の承認取得まで。
 

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

@@ -4,24 +4,25 @@ description: Design Doc準拠検証とセキュリティ検証、必要に応じ
 
 **コマンドコンテキスト**: React/TypeScriptフロントエンド向け実装後品質保証コマンド
 
-## 実行方法
+## オーケストレーター定義
 
-- 準拠検証 -> code-reviewerが実行
-- セキュリティ検証 -> security-reviewerが実行
-- ルール分析 -> rule-advisorが実行
-- 修正実装 -> task-executor-frontendが実行
-- 品質チェック -> quality-fixer-frontendが実行
-- 再検証 -> code-reviewer / security-reviewerが実行
+**コアアイデンティティ**: 「私はオーケストレーターである。」（subagents-orchestration-guideスキル参照）
 
-オーケストレーターがサブエージェントを呼び出し、構造化JSONを受け渡す。
+**初回アクション**: 実行前にTaskCreateでStep 1-11を登録する。
 
-Design Doc（省略時は直近のもの）: $ARGUMENTS
+## 実行方法
+
+- 準拠検証 → code-reviewerが実行
+- セキュリティ検証 → security-reviewerが実行
+- 修正実装 → task-executor-frontendが実行
+- 品質チェック → quality-fixer-frontendが実行
+- 再検証 → code-reviewer / security-reviewerが実行
 
-**Think deeply** 準拠検証の本質を理解し、以下のステップで実行:
+Design Doc（省略時は直近のもの）: $ARGUMENTS
 
 ## 実行フロー
 
-### 1. 前提条件チェック
+### Step 1: 前提条件チェック
 ```bash
 # Design Docを特定
 ls docs/design/*.md | grep -v template | tail -1
@@ -30,15 +31,15 @@ ls docs/design/*.md | grep -v template | tail -1
 git diff --name-only main...HEAD
 ```
 
-### 2. code-reviewer実行
+### Step 2: code-reviewer実行
 Agent toolでcode-reviewerを呼び出す:
 - `subagent_type`: "code-reviewer"
 - `description`: "コード準拠レビュー"
-- `prompt`: "Design Doc: [path]. Implementation files: [git diff file list]. Review mode: full. Design Doc準拠を検証し、complianceRate、verdict、acceptanceCriteria、qualityIssuesを含む構造化JSONレポートを返却。"
+- `prompt`: "Design Doc: [path]. Implementation files: [git diff file list]. Review mode: full. Design Doc準拠を検証し、構造化JSONレポートを返却。"
 
 **出力を保存**: `$STEP_2_OUTPUT`
 
-### 3. security-reviewer実行
+### Step 3: security-reviewer実行
 Agent toolでsecurity-reviewerを呼び出す:
 - `subagent_type`: "security-reviewer"
 - `description`: "セキュリティレビュー"
@@ -46,7 +47,7 @@ Agent toolでsecurity-reviewerを呼び出す:
 
 **出力を保存**: `$STEP_3_OUTPUT`
 
-### 4. 判定と対応
+### Step 4: 判定と対応
 
 **security-reviewerが`blocked`を返した場合**: 即座に停止。blockedの検出結果を報告しユーザーにエスカレーション。修正ステップには進まない。
 
@@ -63,10 +64,15 @@ Agent toolでsecurity-reviewerを呼び出す:
 ```
 Code Compliance: [code-reviewerのcomplianceRate]
   Verdict: [code-reviewerのverdict]
+  Identifier Match Rate: [code-reviewerのidentifierMatchRate]
   Acceptance Criteria:
-  - [fulfilled] [item]
+  - [fulfilled] [item] (confidence: [high/medium/low])
   - [partially_fulfilled] [item]: [gap] — [suggestion]
   - [unfulfilled] [item]: [gap] — [suggestion]
+  Identifier Mismatches:
+  - [identifier]: DD=[designDocValue] Code=[codeValue] at [location]
+  Quality Findings:
+  - [category] [location]: [description] — [rationale]
 
 Security Review: [security-reviewerのstatus]
   Findings by category:
@@ -79,46 +85,44 @@ Security Review: [security-reviewerのstatus]
 修正を実行しますか？ (y/n):
 ```
 
-両方合格でユーザーが`n`を選択: 修正ステップをスキップし、最終レポートへ。
+両方合格でユーザーが`n`を選択: Steps 5-10をスキップし、Step 11へ。
 
-ユーザーが`y`を選択した場合:
+### Step 5: タスクテンプレートの読み込み
 
-## 修正実行前のメタ認知
+documentation-criteriaスキルを読み込み、Step 6用のタスクファイルテンプレート（references/task-template.md）を取得。
 
-### 5. rule-advisor実行
-Agent toolでrule-advisorを呼び出す:
-- `subagent_type`: "rule-advisor"
-- `description`: "修正アプローチの分析"
-- `prompt`: "Task: レビュー検出結果の修正。Code issues: $STEP_2_OUTPUT. Security findings: $STEP_3_OUTPUT. 修正の本質を分析し適切なルールを選択。"
+### Step 6: タスクファイル作成
 
-### 6. タスクファイル作成
-TaskCreateで作業ステップを登録。必ず含める: 最初に「スキル制約の確認」、最後に「スキル忠実度の検証」。タスクテンプレートに従ってタスクファイル作成（documentation-criteriaスキル参照） → `docs/plans/tasks/review-fixes-YYYYMMDD.md`。コード準拠の問題とセキュリティのrequiredFixesの両方を含める。
+`docs/plans/tasks/review-fixes-YYYYMMDD.md` にタスクファイルを作成。
+コード準拠の問題とセキュリティのrequiredFixesの両方を含める。
 
-### 7. 修正実行
+### Step 7: 修正実行
 Agent toolでtask-executor-frontendを呼び出す:
 - `subagent_type`: "task-executor-frontend"
 - `description`: "レビュー修正の実行"
 - `prompt`: "Task file: docs/plans/tasks/review-fixes-YYYYMMDD.md. 段階的修正を適用（5ファイルで停止）。"
 
-### 8. 品質チェック
+### Step 8: 品質チェック
 Agent toolでquality-fixer-frontendを呼び出す:
 - `subagent_type`: "quality-fixer-frontend"
 - `description`: "品質ゲートチェック"
 - `prompt`: "修正ファイルの品質ゲート通過を確認。"
 
-### 9. code-reviewer再検証
+### Step 9: code-reviewer再検証
+
 Agent toolでcode-reviewerを呼び出す:
 - `subagent_type`: "code-reviewer"
 - `description`: "準拠の再検証"
-- `prompt`: "修正後のDesign Doc準拠を再検証。前回の問題: $STEP_2_OUTPUT。Design Doc: [path]. Implementation files: [file list]。"
+- `prompt`: "修正後のDesign Doc準拠を再検証。Design Doc: [path]. Implementation files: [file list]. 前回の準拠問題: $STEP_2_OUTPUT。各問題が解決されたことを確認。"
 
-### 10. security-reviewer再検証（セキュリティ修正が実行された場合のみ）
-Agent toolでsecurity-reviewerを呼び出す:
+### Step 10: security-reviewer再検証
+
+Agent toolでsecurity-reviewerを呼び出す（セキュリティ修正が実行された場合のみ）:
 - `subagent_type`: "security-reviewer"
 - `description`: "セキュリティの再検証"
 - `prompt`: "修正後のセキュリティを再検証。前回の検出結果: $STEP_3_OUTPUT。Design Doc: [path]. Implementation files: [file list]。"
 
-### 最終レポート
+### Step 11: 最終レポート
 ```
 Code Compliance:
   初回: [X]%

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

@@ -33,7 +33,7 @@ git diff --name-only main...HEAD
 Agent toolでcode-reviewerを呼び出す:
 - `subagent_type`: "code-reviewer"
 - `description`: "コード準拠レビュー"
-- `prompt`: "Design Doc: [path]. Implementation files: [git diff file list]. Review mode: full. Design Doc準拠を検証し、complianceRate、verdict、acceptanceCriteria、qualityIssuesを含む構造化JSONレポートを返却。"
+- `prompt`: "Design Doc: [path]. Implementation files: [git diff file list]. Review mode: full. Design Doc準拠を検証し、構造化JSONレポートを返却。"
 
 **出力を保存**: `$STEP_2_OUTPUT`
 
@@ -62,10 +62,15 @@ Agent toolでsecurity-reviewerを呼び出す:
 ```
 Code Compliance: [code-reviewerのcomplianceRate]
   Verdict: [code-reviewerのverdict]
+  Identifier Match Rate: [code-reviewerのidentifierMatchRate]
   Acceptance Criteria:
-  - [fulfilled] [item]
+  - [fulfilled] [item] (confidence: [high/medium/low])
   - [partially_fulfilled] [item]: [gap] — [suggestion]
   - [unfulfilled] [item]: [gap] — [suggestion]
+  Identifier Mismatches:
+  - [identifier]: DD=[designDocValue] Code=[codeValue] at [location]
+  Quality Findings:
+  - [category] [location]: [description] — [rationale]
 
 Security Review: [security-reviewerのstatus]
   Findings by category:
@@ -80,9 +85,9 @@ Security Review: [security-reviewerのstatus]
 
 両方合格でユーザーが`n`を選択: Steps 5-10をスキップし、Step 11へ。
 
-### 5. Skill実行
+### 5. タスクテンプレートの読み込み
 
-Skill: documentation-criteria を実行（タスクファイルテンプレート用）
+documentation-criteriaスキルを読み込み、Step 6用のタスクファイルテンプレート（references/task-template.md）を取得。
 
 ### 6. タスクファイル作成
 
@@ -108,7 +113,7 @@ Agent toolでquality-fixerを呼び出す:
 Agent toolでcode-reviewerを呼び出す:
 - `subagent_type`: "code-reviewer"
 - `description`: "準拠の再検証"
-- `prompt`: "修正後のDesign Doc準拠を再検証。前回の準拠問題: $STEP_2_OUTPUT。各問題が解決されたことを確認。"
+- `prompt`: "修正後のDesign Doc準拠を再検証。Design Doc: [path]. Implementation files: [file list]. 前回の準拠問題: $STEP_2_OUTPUT。各問題が解決されたことを確認。"
 
 ### 10. security-reviewer再検証
 

package/.claude/skills-en/coding-standards/references/security-checks.md

@@ -49,12 +49,14 @@ Sources: OWASP Top 10:2025, DryRun Agentic Coding Security Report (2026-03)
 - Endpoints or route handlers defined without authentication middleware
 - Resource access operations (read, update, delete) without authorization verification
 - Administrative or destructive operations accessible without elevated permissions
-- Recent research indicates this pattern appears at elevated rates in AI-generated code — treat as high-priority review target
+- AI-generated code frequently omits authentication middleware and authorization checks — flag every route handler and resource access operation for explicit verification during review
+- Detection approach: search for route/endpoint handler definitions that lack authentication middleware, and resource operations (read, update, delete) without authorization checks in the call chain
 
 ### Mishandling of Exceptional Conditions (OWASP A10:2025)
 - Error handlers that expose internal system details (stack traces, database errors, file paths) in responses
-- Error handlers that fail open (grant access or skip validation on error)
+- Error handlers that grant access, skip authentication, or bypass authorization when an exception occurs (fail-open behavior)
 - Missing error handling on security-critical operations (authentication, authorization, cryptographic operations)
+- Detection approach: search for catch/error handler blocks that return stack traces, database error messages, or file paths in responses; search for catch blocks that call next() or return success without re-validating security state
 
 ### Software Supply Chain Patterns (OWASP A03:2025)
 - Dependencies imported without version pinning

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

@@ -50,18 +50,14 @@ description: Guides PRD, ADR, Design Doc, and Work Plan creation. Use when creat
 
 **Includes**:
 - Business requirements and user value
-- Success metrics and KPIs (measurable format)
+- Success metrics and KPIs (each metric specifies a numeric target, measurement method, and timeframe)
 - User stories and use cases
 - MoSCoW prioritization (Must/Should/Could/Won't)
 - MVP and Future phase separation
 - User journey diagram (required)
 - Scope boundary diagram (required)
 
-**Excludes**:
-- Technical implementation details (->Design Doc)
-- Technical selection rationale (->ADR)
-- **Implementation phases** (->Work Plan)
-- **Task breakdown** (->Work Plan)
+**Scope**: Business requirements, user value, success metrics, user stories, and prioritization only. Implementation details belong in Design Doc, technical selection rationale in ADR, phases and task breakdown in Work Plan.
 
 ### ADR (Architecture Decision Record)
 
@@ -74,11 +70,7 @@ description: Guides PRD, ADR, Design Doc, and Work Plan creation. Use when creat
 - Architecture impact
 - Principled implementation guidelines (e.g., "Use dependency injection")
 
-**Excludes**:
-- Implementation schedule, duration (->Work Plan)
-- Detailed implementation procedures (->Design Doc)
-- Specific code examples (->Design Doc)
-- Resource assignments (->Work Plan)
+**Scope**: Decision, rationale, option comparison, architecture impact, and principled guidelines only. Implementation procedures and code examples belong in Design Doc, schedule and resource assignments in Work Plan.
 
 ### UI Specification
 
@@ -94,11 +86,7 @@ description: Guides PRD, ADR, Design Doc, and Work Plan creation. Use when creat
 - Visual acceptance criteria (golden states, layout constraints)
 - Accessibility requirements (keyboard, screen reader, contrast)
 
-**Excludes**:
-- Technical implementation details (-> Design Doc)
-- API contracts and data layer design (-> Design Doc)
-- Test implementation (-> acceptance-test-generator skeletons)
-- Implementation schedule (-> Work Plan)
+**Scope**: Screen structure, transitions, component decomposition, interaction design, and visual acceptance criteria only. Technical implementation and API contracts belong in Design Doc, test implementation in acceptance-test-generator skeletons, schedule in Work Plan.
 
 **Required Structural Elements**:
 - At least one component with state x display matrix and interaction table
@@ -123,7 +111,7 @@ description: Guides PRD, ADR, Design Doc, and Work Plan creation. Use when creat
 - **Technical dependencies and implementation constraints** (required implementation order)
 - Interface and type definitions
 - Data flow and component design
-- **Acceptance criteria (EARS format: When/While/If-then/none)**
+- **Acceptance criteria (EARS format — see design-template.md; each criterion specifies a verifiable condition with pass/fail threshold)**
 - Change impact map (clearly specify direct impact/indirect impact/no ripple effect)
 - Complete enumeration of integration points
 - Data contract clarification
@@ -137,10 +125,7 @@ description: Guides PRD, ADR, Design Doc, and Work Plan creation. Use when creat
   - Correctness proof method (what "correct" means for this change, how it's verified, when)
   - Early verification point (first target to prove the approach works, success criteria, failure response)
 
-**Excludes**:
-- Why that technology was chosen (->Reference ADR)
-- When to implement, duration (->Work Plan)
-- Who will implement (->Work Plan)
+**Scope**: Technical implementation methods, interfaces, data flow, acceptance criteria, and verification strategy only. Technology selection rationale belongs in ADR, schedule and assignments in Work Plan.
 
 ### Work Plan
 
@@ -154,28 +139,23 @@ description: Guides PRD, ADR, Design Doc, and Work Plan creation. Use when creat
 - **Final Quality Assurance Phase (required)**
 - Progress records (checkbox format)
 
-**Excludes**:
-- Technical rationale (->ADR)
-- Design details (->Design Doc)
+**Scope**: Task breakdown, dependencies, schedule, verification strategy summary, and progress tracking only. Technical rationale belongs in ADR, design details in Design Doc.
 
 **Phase Division Criteria** (adapt to implementation approach from Design Doc):
 
 **When Vertical Slice selected**:
 - Each phase = one value unit (feature, component, or migration target)
 - Each phase includes its own implementation + verification per Verification Strategy
-- Final Phase: Quality Assurance (cross-cutting verification, all tests passing)
 
 **When Horizontal Slice selected**:
 1. **Phase 1: Foundation Implementation** - Type definitions, interfaces, test preparation
 2. **Phase 2: Core Feature Implementation** - Business logic, unit tests
 3. **Phase 3: Integration Implementation** - External connections, presentation layer
-4. **Final Phase: Quality Assurance (Required)** - Acceptance criteria achievement, all tests passing, quality checks
 
 **When Hybrid selected**:
 - Combine vertical and horizontal as defined in Design Doc implementation approach
-- Final Phase: Quality Assurance (Required)
 
-**All approaches**: Final phase is always Quality Assurance. Each phase's verification method follows Verification Strategy from Design Doc.
+**All approaches**: Final phase is always Quality Assurance (acceptance criteria achievement, all tests passing, quality checks). Each phase's verification method follows Verification Strategy from Design Doc.
 
 **Three Elements of Task Completion Definition**:
 1. **Implementation Complete**: Code is functional

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

@@ -2,7 +2,7 @@
 
 ## Status
 
-[Proposed | Accepted | Deprecated | Superseded]
+[Proposed | Accepted | Deprecated | Superseded | Rejected]
 
 ## Context
 
@@ -54,6 +54,10 @@
 
 - [List changes that are neither good nor bad]
 
+## Architecture Impact
+
+[Describe how this decision affects existing architecture: (1) components that change, (2) new dependencies introduced, (3) architectural constraints added or removed]
+
 ## Implementation Guidance
 
 [Principled direction only. Implementation procedures go to Design Doc]

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

@@ -222,11 +222,16 @@ Invariants:
 
 ### Error Handling
 
-[Types of errors and how to handle them]
+| Error Category | Example | Detection | Recovery Strategy | User Impact |
+|---------------|---------|-----------|-------------------|-------------|
+| [Validation / External / Infrastructure / Business logic] | [Specific error] | [How detected] | [Retry / Fallback / Propagate / Log-and-continue] | [User-facing message or silent handling] |
 
 ### Logging and Monitoring
 
-[What to record in logs and how to monitor]
+- **Log events**: [Key events to log: state transitions, external calls, error occurrences, performance thresholds]
+- **Log levels**: [Which events at DEBUG/INFO/WARN/ERROR]
+- **Sensitive data**: [Fields to mask or exclude — coordinate with Security Considerations]
+- **Monitoring**: [Metrics to track, alert thresholds, dashboard requirements]
 
 ## Implementation Plan
 
@@ -246,12 +251,6 @@ Invariants:
    - Technical Reason: [Technical necessity to implement after A]
    - Prerequisites: [Required pre-implementations]
 
-### Integration Points
-
-**Integration Point 1: [Name]**
-- Components: [Component A] -> [Component B]
-- Contract: [Interface/API contract between components]
-
 ### Migration Strategy
 
 [Technical migration approach, ensuring backward compatibility]

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

@@ -47,7 +47,8 @@ Related Issue/PR: #XXX (if any)
 
 Select ONE phase structure based on implementation approach from Design Doc.
 See documentation-criteria skill for detailed Phase Division Criteria.
-**Delete the unused Option entirely from the final plan.** For hybrid approach, use Option A as the base and add horizontal foundation phases where needed.
+All quality checks follow Quality Check Workflow from coding-standards skill.
+**Delete the unused Option entirely from the final plan.** For hybrid approach, use Option C.
 
 ### Option A: Vertical Slice Phase Structure
 
@@ -60,7 +61,7 @@ Use when implementation approach is Vertical Slice. Each phase = one value unit
 ##### Tasks
 - [ ] Task 1: Implementation
 - [ ] Task 2: Verification per Verification Strategy
-- [ ] Quality check: Implement staged quality checks (refer to technical-spec skill)
+- [ ] Quality check (staged)
 
 ##### Phase Completion Criteria
 - [ ] Early verification point passed
@@ -89,7 +90,7 @@ Use when implementation approach is Horizontal Slice. Phases follow Foundation
 ##### Tasks
 - [ ] Task 1: Specific work content
 - [ ] Task 2: Specific work content
-- [ ] Quality check: Implement staged quality checks (refer to technical-spec skill)
+- [ ] Quality check (staged)
 - [ ] Unit tests: All related tests pass
 
 ##### Phase Completion Criteria
@@ -102,7 +103,7 @@ Use when implementation approach is Horizontal Slice. Phases follow Foundation
 ##### Tasks
 - [ ] Task 1: Specific work content
 - [ ] Task 2: Specific work content
-- [ ] Quality check
+- [ ] Quality check (staged)
 - [ ] Integration tests: Verify overall feature functionality
 
 ##### Phase Completion Criteria
@@ -115,13 +116,17 @@ Use when implementation approach is Horizontal Slice. Phases follow Foundation
 ##### Tasks
 - [ ] Task 1: Specific work content
 - [ ] Task 2: Specific work content
-- [ ] Quality check
+- [ ] Quality check (staged)
 - [ ] Integration tests: Verify component coordination
 
 ##### Phase Completion Criteria
 - [ ] [Functional completion criteria]
 - [ ] [Quality completion criteria]
 
+### Option C: Hybrid Phase Structure
+
+Use when implementation approach is Hybrid. Combine vertical and horizontal phases as defined in Design Doc implementation approach. Structure phases per Design Doc specification, ensuring each phase has Tasks, Verification, and Phase Completion Criteria sections matching the format above.
+
 ### Final Phase: Quality Assurance (Required) (Estimated commits: 1)
 
 This phase is required for ALL implementation approaches.
@@ -137,7 +142,7 @@ This phase is required for ALL implementation approaches.
 - [ ] Document updates
 
 ### Quality Assurance
-- [ ] Implement staged quality checks (details: refer to technical-spec skill)
+- [ ] Quality check (staged)
 
 ## Risks and Countermeasures
 | Risk | Countermeasure |

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

@@ -25,23 +25,45 @@ So that [expected value/benefit]
 2. [Specific usage scenario 2]
 3. [Specific usage scenario 3]
 
+### User Journey Diagram
+```mermaid
+journey
+    title [Feature Name] User Journey
+    section [Phase 1]
+      [Step]: [satisfaction score]: [actor]
+```
+[Map the end-to-end user experience from trigger event to goal completion]
+
+### Scope Boundary Diagram
+```mermaid
+C4Context
+    Boundary(scope, "In Scope") {
+        [Components in scope]
+    }
+    Boundary(out, "Out of Scope") {
+        [Components out of scope]
+    }
+```
+[Clarify what is and is not included in this feature]
+
 ## Functional Requirements
 
-### Must Have (MVP)
+### Must Have (P1 - MVP)
 - [ ] Requirement 1: [Detailed description]
   - AC: [Acceptance criteria - Given/When/Then format or measurable standard]
 - [ ] Requirement 2: [Detailed description]
   - AC: [Acceptance criteria]
-- [ ] Requirement 3: [Detailed description]
+
+### Should Have (P2)
+- [ ] Requirement 1: [Detailed description]
   - AC: [Acceptance criteria]
 
-### Nice to Have
+### Could Have (P3)
 - [ ] Requirement 1: [Detailed description]
-- [ ] Requirement 2: [Detailed description]
 
-### Out of Scope
-- Item 1: [Description and reason]
-- Item 2: [Description and reason]
+### Won't Have (this release)
+- Item 1: [Description and reason for exclusion]
+- Item 2: [Description and reason for exclusion]
 
 ## Non-Functional Requirements
 
@@ -69,9 +91,9 @@ So that [expected value/benefit]
 ## Success Criteria
 
 ### Quantitative Metrics
-1. [Measurable success metric 1]
-2. [Measurable success metric 2]
-3. [Measurable success metric 3]
+1. [Metric name]: [numeric target] measured by [method] within [timeframe]
+2. [Metric name]: [numeric target] measured by [method] within [timeframe]
+3. [Metric name]: [numeric target] measured by [method] within [timeframe]
 
 ### Qualitative Metrics
 1. [User experience metric 1]

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

@@ -38,7 +38,7 @@ Files to read before starting implementation (file path, with optional search hi
 - **Verification method**: [What to verify and how — e.g., "compare new implementation output against existing implementation at src/legacy/order_calc", "run endpoint against test database and verify response matches contract"]
 - **Success criteria**: [Observable outcome that proves correctness — e.g., "output matches existing implementation for all input combinations", "API returns 200 with expected schema"]
 - **Failure response**: [What to do if verification fails — e.g., "reassess approach before proceeding", "escalate to user"]
-- **Verification level**: [L1/L2/L3, per implementation-approach skill]
+- **Verification level**: [L1: Functional operation as end-user feature / L2: New tests added and passing / L3: Code builds without errors]
 
 ## Completion Criteria
 - [ ] All added tests pass
@@ -47,4 +47,4 @@ Files to read before starting implementation (file path, with optional search hi
 
 ## Notes
 - Impact scope: [Areas where changes may propagate]
-- Constraints: [Areas not to be modified]
+- Scope boundary: [Files to preserve unchanged — path and reason]