create-ai-project 1.20.2 → 1.20.4

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]
@@ -306,6 +305,17 @@ What is verified first, and how, to confirm the approach is correct before scali
 - **Success criteria**: [Observable outcome — e.g., "CSV download produces identical output to legacy", "API returns 200 with expected schema"]
 - **Failure response**: [What to do if early verification fails — e.g., "reassess approach before proceeding", "escalate to user"]
 
+### Output Comparison (When Replacing or Modifying Existing Behavior)
+
+How will behavioral equivalence be verified between existing and new implementation?
+
+- **Comparison input**: [Identical input used for both implementations — e.g., "same DB snapshot", "same API request payload"]
+- **Expected output fields**: [Specific fields/columns to compare — e.g., "all output columns", "response body fields: id, status, amount"]
+- **Diff method**: [How to compare — e.g., "file-level diff", "JSON field-by-field comparison", "row count + spot check"]
+- **Transformation pipeline coverage**: [Each step from codebase analysis `dataTransformationPipelines` and what the comparison covers]
+
+Mark as N/A with brief rationale when the design introduces entirely new behavior with no existing equivalent.
+
 ## Alternative Solutions
 
 ### Alternative 1

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]

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

@@ -20,18 +20,9 @@ This document provides practical behavioral guidelines for me (Claude) to effici
 - **Analysis/Design**: Delegate to the appropriate specialist subagent
 - **First action**: Pass user requirements to requirement-analyzer before any other step
 
-**First Action Rule**: To accurately analyze user requirements, pass them directly to requirement-analyzer and determine the workflow based on its analysis results.
+### First Action Rule
 
-## Decision Flow When Receiving Tasks
-
-```mermaid
-graph TD
-    Start[Receive New Task] --> RA[Analyze requirements with requirement-analyzer]
-    RA --> Scale[Scale assessment]
-    Scale --> Flow[Execute flow based on scale]
-```
-
-**During flow execution, determine next subagent according to scale determination table**
+When receiving a new task, pass user requirements directly to requirement-analyzer. Determine the workflow based on its scale assessment result.
 
 ### Requirement Change Detection During Flow
 
@@ -59,7 +50,7 @@ graph TD
 10. **technical-designer**: ADR/Design Doc creation (latest technology research, Property annotation assignment)
 11. **work-planner**: Work plan creation from Design Doc and test skeletons
 12. **document-reviewer**: Single document quality, completeness, and rule compliance check
-13. **code-verifier**: Verify Design Doc claims against existing codebase (used pre-review in design flow)
+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
 
@@ -141,7 +132,7 @@ 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, focusAreas[], existingElements count, limitations | Pass focusAreas to technical-designer as context |
-| code-verifier | consistencyScore, discrepancies[], reverseCoverage (dataOperationsInCode, testBoundariesSectionPresent) | Flag discrepancies for document-reviewer |
+| 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 | status (escalation_needed/completed), escalation_type, testsAdded, requiresTestReview | On escalation_needed: handle by escalation_type (design_compliance_violation, similar_function_found, similar_component_found, investigation_target_not_found, out_of_scope_file) |
 | quality-fixer | status (approved/blocked), reason, blockingIssues[], missingPrerequisites[] | On blocked: see quality-fixer blocked handling below |
 | document-reviewer | approvalReady (true/false) | Proceed to next step on true; request fixes on false |
@@ -182,9 +173,9 @@ According to scale determination:
 ### Medium Scale (3-5 Files) - 9 Steps (backend) / 11 Steps (frontend/fullstack)
 
 1. requirement-analyzer → Requirement analysis **[Stop]**
-2. codebase-analyzer → Codebase analysis (pass requirement-analyzer output)
-3. **(frontend/fullstack only)** Ask user for prototype code → ui-spec-designer → UI Spec creation
-4. **(frontend/fullstack only)** document-reviewer → UI Spec review **[Stop: UI Spec Approval]**
+2. **(frontend/fullstack only)** Ask user for prototype code → ui-spec-designer → UI Spec creation (UI Spec informs component structure for technical design)
+3. **(frontend/fullstack only)** document-reviewer → UI Spec review **[Stop: UI Spec Approval]**
+4. codebase-analyzer → Codebase analysis (pass requirement-analyzer output)
 5. technical-designer → Design Doc creation (pass codebase-analyzer output as additional context; cross-layer: per layer, see Cross-Layer Orchestration)
 6. code-verifier → Verify Design Doc against existing code (doc_type: design-doc)
 7. document-reviewer → Design Doc review (pass code-verifier results as code_verification; cross-layer: per Design Doc)
@@ -301,7 +292,7 @@ Construct the prompt from the agent's Input Parameters section and the deliverab
    #### codebase-analyzer → technical-designer
 
    **Pass to codebase-analyzer**: requirement-analyzer JSON output, PRD path (if exists), original user requirements
-   **Pass to technical-designer**: codebase-analyzer JSON output as additional context in the Design Doc creation prompt. The designer uses `focusAreas` and `dataModel` to inform the Existing Codebase Analysis section.
+   **Pass to technical-designer**: codebase-analyzer JSON output as additional context in the Design Doc creation prompt. The designer uses `focusAreas`, `dataModel`, and `dataTransformationPipelines` to inform the Existing Codebase Analysis and Verification Strategy sections.
 
    #### code-verifier → document-reviewer (Design Doc review)
 
@@ -327,9 +318,7 @@ Construct the prompt from the agent's Input Parameters section and the deliverab
    - E2E test file: [path] (execute only in final phase)
 
    **On error**: Escalate to user if files are not generated
-3. **Quality Assurance and Commit Execution**: After confirming `status: "approved"`, immediately execute git commit
-4. **Autonomous Execution Mode Management**: Start/stop autonomous execution after approval, escalation decisions
-5. **ADR Status Management**: Update ADR status after user decision (Accepted/Rejected)
+3. **ADR Status Management**: Update ADR status after user decision (Accepted/Rejected)
 
 ## Important Constraints
 
@@ -339,22 +328,16 @@ Construct the prompt from the agent's Input Parameters section and the deliverab
 - **Flow confirmation**: After getting approval, ALWAYS check next step with work planning flow (large/medium/small scale)
 - **Consistency verification**: When subagent outputs conflict, apply Decision precedence (see Delegation Boundary section)
 
-## Required Dialogue Points with Humans
-
-### Basic Principles
-- **Stopping is mandatory**: Always wait for human response at the following timings
-- **Use AskUserQuestion**: Present confirmations and questions at all Stop points
-- **Confirmation -> Agreement cycle**: After document generation, proceed to next step after agreement or fix instructions in update mode
-- **Specific questions**: Make decisions easy with options (A/B/C) or comparison tables
-- **Dialogue over efficiency**: Get confirmation at early stages to prevent rework
-
-### Main Stop Points
-- **After requirement-analyzer completion**: Confirm requirement analysis results and questions
-- **After PRD creation -> document-reviewer execution**: Confirm requirement understanding and consistency (confirm with question list)
-- **After UI Spec creation -> document-reviewer execution** (frontend/fullstack): Confirm UI specification completeness and consistency
-- **After ADR creation -> document-reviewer execution**: Confirm technical direction and consistency (present multiple options with comparison table)
-  - On user approval: Main AI (me) updates Status to Accepted
-  - On user rejection: Main AI (me) updates Status to Rejected
-- **After Design Doc creation -> document-reviewer execution**: Confirm design content and consistency
-- **After work plan creation**: Batch approval for entire implementation phase (confirm with plan summary)
+### Progress Tracking
+
+Register overall phases using TaskCreate. Update each phase with TaskUpdate as it completes.
+
+### Post-Implementation Verification Pass/Fail Criteria
+
+| Verifier | Pass | Fail | Blocked |
+|----------|------|------|---------|
+| code-verifier | `status` is `consistent` or `mostly_consistent` | `status` is `needs_review` or `inconsistent` | — |
+| security-reviewer | `status` is `approved` or `approved_with_notes` | `status` is `needs_revision` | `status` is `blocked` → Escalate to user |
+
+**Re-run rule**: After fix cycle, re-run only verifiers that returned **fail**. Verifiers that passed on the previous run are not re-run. Maximum 2 fix cycles — if still failing after 2 cycles, escalate to user with remaining findings.
 

package/.claude/skills-en/task-analyzer/references/skills-index.yaml

@@ -168,7 +168,6 @@ skills:
       - "Agent Coordination Patterns"
     sections:
       - "Core Principle: I Am an Orchestrator"
-      - "Decision Flow When Receiving Tasks"
       - "Subagents I Can Utilize"
       - "My Orchestration Principles"
       - "Constraints Between Subagents"
@@ -179,7 +178,6 @@ skills:
       - "Autonomous Execution Mode"
       - "My Main Roles as Orchestrator"
       - "Important Constraints"
-      - "Required Dialogue Points with Humans"
 
   skill-optimization:
     skill: "skill-optimization"

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

@@ -49,12 +49,14 @@ Sources: OWASP Top 10:2025, DryRun Agentic Coding Security Report (2026-03)
 - 認証ミドルウェアなしで定義されたエンドポイントやルートハンドラ
 - 認可検証なしのリソースアクセス操作（読み取り、更新、削除）
 - 昇格された権限なしでアクセス可能な管理操作や破壊的操作
-- 最近の研究でこのパターンがAI生成コードで高い発生率を示す — 高優先度のレビュー対象として扱う
+- AI生成コードでは認証ミドルウェアと認可チェックの欠落が頻発する — 全ルートハンドラとリソースアクセス操作をレビュー時に明示的に検証対象とする
+- 検出方法: 認証ミドルウェアを持たないルート/エンドポイントハンドラ定義を検索し、呼び出しチェーン内で認可チェックなしのリソース操作（読み取り、更新、削除）を検索
 
 ### 例外条件の不適切な処理（OWASP A10:2025）
 - レスポンスに内部システム詳細（スタックトレース、データベースエラー、ファイルパス）を露出するエラーハンドラ
-- フェイルオープン（エラー時にアクセスを許可または検証をスキップ）するエラーハンドラ
+- 例外発生時にアクセスを許可、認証をスキップ、または認可をバイパスするエラーハンドラ（フェイルオープン動作）
 - セキュリティ上重要な操作（認証、認可、暗号操作）でのエラーハンドリング欠如
+- 検出方法: レスポンスにスタックトレース、データベースエラーメッセージ、ファイルパスを返すcatch/エラーハンドラブロックを検索。セキュリティ状態を再検証せずにnext()を呼び出すまたは成功を返すcatchブロックを検索
 
 ### ソフトウェアサプライチェーンパターン（OWASP A03:2025）
 - バージョン固定なしでインポートされた依存関係

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

@@ -50,18 +50,14 @@ description: PRD、ADR、Design Doc、作業計画書の作成を支援。技術
 
 **含むもの**:
 - ビジネス要件とユーザー価値
-- 成功指標とKPI（測定可能な形式）
+- 成功指標とKPI（各指標に数値目標、測定方法、期間を明記）
 - ユーザーストーリーとユースケース
 - MoSCoW法による優先順位（Must/Should/Could/Won't）
 - MVPとFutureフェーズの分離
 - ユーザージャーニー図（必須）
 - スコープ境界図（必須）
 
-**含まないもの**:
-- 技術実装詳細（→Design Doc）
-- 技術選定理由（→ADR）
-- **実装フェーズ**（→作業計画書）
-- **タスク分解**（→作業計画書）
+**スコープ**: ビジネス要件、ユーザー価値、成功指標、ユーザーストーリー、優先順位のみ。技術実装詳細はDesign Doc、技術選定理由はADR、フェーズとタスク分解は作業計画書に記載。
 
 ### ADR（Architecture Decision Record）
 
@@ -74,11 +70,7 @@ description: PRD、ADR、Design Doc、作業計画書の作成を支援。技術
 - アーキテクチャへの影響
 - 実装への原則的な指針（例:「依存性注入を使用」）
 
-**含まないもの**:
-- 実装スケジュール、期間（→作業計画書）
-- 実装手順の詳細（→Design Doc）
-- 具体的なコード例（→Design Doc）
-- 担当者の割り当て（→作業計画書）
+**スコープ**: 決定事項、根拠、選択肢比較、アーキテクチャへの影響、原則的な指針のみ。実装手順とコード例はDesign Doc、スケジュールと担当割り当ては作業計画書に記載。
 
 ### UI Spec
 
@@ -94,11 +86,7 @@ description: PRD、ADR、Design Doc、作業計画書の作成を支援。技術
 - ビジュアル受入条件(AC)（ゴールデンステート、レイアウト制約）
 - アクセシビリティ要件（キーボード、スクリーンリーダー、コントラスト）
 
-**含まないもの**:
-- 技術実装詳細（→ Design Doc）
-- APIコントラクトとデータレイヤー設計（→ Design Doc）
-- テスト実装（→ acceptance-test-generatorのスケルトン）
-- 実装スケジュール（→ 作業計画書）
+**スコープ**: 画面構造、遷移、コンポーネント分解、インタラクション設計、ビジュアル受入条件のみ。技術実装とAPIコントラクトはDesign Doc、テスト実装はacceptance-test-generatorスケルトン、スケジュールは作業計画書に記載。
 
 **必須構造要素**:
 - 状態×表示マトリクスとインタラクション表を含むコンポーネントが1つ以上
@@ -123,7 +111,7 @@ description: PRD、ADR、Design Doc、作業計画書の作成を支援。技術
 - **技術的依存関係と実装制約**（実装の必要順序）
 - インターフェース定義と型定義
 - データフローとコンポーネント設計
-- **受入条件（EARS形式: When/While/If-then/無印）**
+- **受入条件（EARS形式 — design-template.md参照。各条件に検証可能な条件と合否閾値を明記）**
 - 変更影響マップ（直接影響/間接影響/波及なしを明記）
 - 統合点の完全な列挙
 - データ契約の明確化
@@ -152,10 +140,7 @@ description: PRD、ADR、Design Doc、作業計画書の作成を支援。技術
   互換性確保: [方法]
 ```
 
-**含まないもの**:
-- なぜその技術を選んだか（→ADR参照）
-- いつ実装するか、期間（→作業計画書）
-- 誰が実装するか（→作業計画書）
+**スコープ**: 技術実装方法、インターフェース、データフロー、受入条件、検証戦略のみ。技術選定理由はADR、スケジュールと担当は作業計画書に記載。
 
 ### 作業計画書
 
@@ -170,29 +155,23 @@ description: PRD、ADR、Design Doc、作業計画書の作成を支援。技術
 - **最終フェーズに品質保証を含む**（必須）
 - 進捗記録（チェックボックス形式）
 
-**含まないもの**:
-- 技術的な根拠（→ADR）
-- 設計の詳細（→Design Doc）
-- 技術的依存関係の決定（→Design Doc）
+**スコープ**: タスク分解、依存関係、スケジュール、検証戦略の要約、進捗追跡のみ。技術的な根拠はADR、設計詳細はDesign Docに記載。
 
 **フェーズ分割基準**（Design Docの実装アプローチに応じて適用）:
 
 **垂直スライス選択時**:
 - 各フェーズ = 1つの価値単位（機能、コンポーネント、移行対象）
 - 各フェーズに検証戦略に基づく実装＋検証を含む
-- 最終フェーズ: 品質保証（横断的検証、全テストパス）
 
 **水平スライス選択時**:
 1. **Phase 1: 基盤実装** - 型定義、インターフェース、テスト準備
 2. **Phase 2: コア機能実装** - ビジネスロジック、ユニットテスト
 3. **Phase 3: 統合実装** - 外部接続、プレゼンテーション層
-4. **最終Phase: 品質保証（必須）** - 受入条件達成、全テストパス、品質チェック
 
 **ハイブリッド選択時**:
 - Design Docの実装アプローチに基づき垂直と水平を組み合わせる
-- 最終フェーズ: 品質保証（必須）
 
-**全アプローチ共通**: 最終フェーズは常に品質保証。各フェーズの検証手法はDesign Docの検証戦略に従う。
+**全アプローチ共通**: 最終フェーズは常に品質保証（受入条件達成、全テストパス、品質チェック）。各フェーズの検証手法はDesign Docの検証戦略に従う。
 
 **タスク完了定義の3要素**:
 1. **実装完了**: コードが動作する

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

@@ -2,7 +2,7 @@
 
 ## ステータス
 
-[Proposed | Accepted | Deprecated | Superseded]
+[Proposed | Accepted | Deprecated | Superseded | Rejected]
 
 ## 経緯
 
@@ -54,6 +54,10 @@
 
 - [良くも悪くもない変化をリストアップ]
 
+## アーキテクチャへの影響
+
+[この決定が既存アーキテクチャにどう影響するか: (1) 変更されるコンポーネント、(2) 新たに導入される依存関係、(3) 追加または撤廃されるアーキテクチャ制約]
+
 ## 実装指針
 
 [原則的な方向性のみ。実装手順はDesign Docへ]

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

@@ -222,11 +222,16 @@ unknowns:
 
 ### エラーハンドリング
 
-[エラーの種類とその処理方法]
+| エラーカテゴリ | 例 | 検出方法 | 復旧戦略 | ユーザーへの影響 |
+|-------------|-----|---------|---------|---------------|
+| [検証 / 外部 / インフラ / ビジネスロジック] | [具体的なエラー] | [検出方法] | [リトライ / フォールバック / 伝播 / ログ後続行] | [ユーザー向けメッセージまたはサイレント処理] |
 
 ### ロギングとモニタリング
 
-[ログに記録する内容とモニタリング方法]
+- **ログイベント**: [記録すべきイベント: 状態遷移、外部呼び出し、エラー発生、パフォーマンス閾値]
+- **ログレベル**: [DEBUG/INFO/WARN/ERRORの振り分け]
+- **機密データ**: [マスクまたは除外するフィールド — セキュリティ考慮事項と連携]
+- **モニタリング**: [追跡する指標、アラート閾値、ダッシュボード要件]
 
 ## 実装計画
 
@@ -306,6 +311,17 @@ unknowns:
 - **成功基準**: [観察可能な成果 — 例: 「CSVダウンロードが既存と同一の出力を生成」「APIが期待スキーマで200を返す」]
 - **失敗時の対応**: [早期検証が失敗した場合の対処 — 例: 「続行前にアプローチを再評価」「ユーザーにエスカレーション」]
 
+### 出力比較（既存の振る舞いを置換または変更する場合）
+
+既存実装と新実装の振る舞いの同等性をどう検証するか?
+
+- **比較入力**: [両実装に対して使用する同一入力 — 例: 「同一DBスナップショット」「同一APIリクエストペイロード」]
+- **期待される出力フィールド**: [比較対象の具体的なフィールド/カラム — 例: 「全出力カラム」「レスポンスボディのフィールド: id, status, amount」]
+- **差分比較方法**: [比較手法 — 例: 「ファイルレベルのdiff」「JSONフィールド単位の比較」「行数 + スポットチェック」]
+- **変換パイプラインカバレッジ**: [コードベース分析の`dataTransformationPipelines`の各ステップと、比較がカバーする範囲]
+
+既存の同等物がなく完全に新規の振る舞いを導入する場合は、簡潔な理由とともにN/Aと記載。
+
 ## 代替案
 
 ### 代替案1

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

@@ -47,7 +47,8 @@
 
 Design Docの実装アプローチに基づいてフェーズ構成をひとつ選択する。
 詳細はdocumentation-criteriaスキルのフェーズ分割基準を参照。
-**未使用のOptionは最終計画書から削除すること。** ハイブリッドの場合はOption Aをベースに、必要に応じて水平基盤フェーズを追加する。
+全品質チェックはcoding-standardsスキルの品質チェックワークフローに従う。
+**未使用のOptionは最終計画書から削除すること。** ハイブリッドの場合はOption Cを使用する。
 
 ### Option A: 垂直スライスのフェーズ構成
 
@@ -60,7 +61,7 @@ Design Docの実装アプローチに基づいてフェーズ構成をひとつ
 ##### タスク
 - [ ] タスク1: 実装
 - [ ] タスク2: 検証戦略に基づく検証
-- [ ] 品質チェック: 段階的品質チェック実施（technical-specスキル参照）
+- [ ] 品質チェック（段階的）
 
 ##### フェーズ完了条件
 - [ ] 早期検証ポイント通過
@@ -89,7 +90,7 @@ Design Docの実装アプローチに基づいてフェーズ構成をひとつ
 ##### タスク
 - [ ] タスク1: 具体的な作業内容
 - [ ] タスク2: 具体的な作業内容
-- [ ] 品質チェック: 段階的品質チェック実施（technical-specスキル参照）
+- [ ] 品質チェック（段階的）
 - [ ] 単体テスト: 関連する全テストがパス
 
 ##### フェーズ完了条件
@@ -102,7 +103,7 @@ Design Docの実装アプローチに基づいてフェーズ構成をひとつ
 ##### タスク
 - [ ] タスク1: 具体的な作業内容
 - [ ] タスク2: 具体的な作業内容
-- [ ] 品質チェック
+- [ ] 品質チェック（段階的）
 - [ ] 統合テスト: 機能全体の動作確認
 
 ##### フェーズ完了条件
@@ -115,13 +116,17 @@ Design Docの実装アプローチに基づいてフェーズ構成をひとつ
 ##### タスク
 - [ ] タスク1: 具体的な作業内容
 - [ ] タスク2: 具体的な作業内容
-- [ ] 品質チェック
+- [ ] 品質チェック（段階的）
 - [ ] 統合テスト: コンポーネント連携の検証
 
 ##### フェーズ完了条件
 - [ ] [機能完了条件]
 - [ ] [品質完了条件]
 
+### Option C: ハイブリッドのフェーズ構成
+
+実装アプローチがハイブリッドの場合に使用。Design Docの実装アプローチに基づき垂直と水平を組み合わせる。各フェーズにタスク、検証、フェーズ完了条件のセクションを上記フォーマットに合わせて記載。
+
 ### 最終Phase: 品質保証（必須）（想定コミット数: 1）
 
 このフェーズは全実装アプローチで必須。
@@ -137,7 +142,7 @@ Design Docの実装アプローチに基づいてフェーズ構成をひとつ
 - [ ] ドキュメント更新
 
 ### 品質保証
-- [ ] 段階的品質チェック実施（詳細: technical-specスキル参照）
+- [ ] 品質チェック（段階的）
 
 ## リスクと対策
 | リスク | 対策 |

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

@@ -25,23 +25,45 @@
 2. [具体的な利用シナリオ2]
 3. [具体的な利用シナリオ3]
 
+### ユーザージャーニー図
+```mermaid
+journey
+    title [機能名] ユーザージャーニー
+    section [フェーズ1]
+      [ステップ]: [満足度スコア]: [アクター]
+```
+[トリガーイベントから目標達成までのエンドツーエンドのユーザー体験をマッピング]
+
+### スコープ境界図
+```mermaid
+C4Context
+    Boundary(scope, "スコープ内") {
+        [スコープ内のコンポーネント]
+    }
+    Boundary(out, "スコープ外") {
+        [スコープ外のコンポーネント]
+    }
+```
+[この機能に含まれるものと含まれないものを明確化]
+
 ## 機能要件
 
-### Must Have（MVP）
+### Must Have (P1 - MVP)
 - [ ] 要件1: [詳細説明]
   - AC: [受入条件 - Given/When/Then形式または測定可能な基準]
 - [ ] 要件2: [詳細説明]
   - AC: [受入条件]
-- [ ] 要件3: [詳細説明]
+
+### Should Have (P2)
+- [ ] 要件1: [詳細説明]
   - AC: [受入条件]
 
-### Nice to Have
+### Could Have (P3)
 - [ ] 要件1: [詳細説明]
-- [ ] 要件2: [詳細説明]
 
-### スコープ外
-- 項目1: [説明と理由]
-- 項目2: [説明と理由]
+### Won't Have（今回のリリース対象外）
+- 項目1: [説明と除外理由]
+- 項目2: [説明と除外理由]
 
 ## 非機能要件
 
@@ -69,9 +91,9 @@
 ## 成功基準
 
 ### 定量的指標
-1. [測定可能な成功指標1]
-2. [測定可能な成功指標2]
-3. [測定可能な成功指標3]
+1. [指標名]: [数値目標] を [測定方法] で [期間] 以内に達成
+2. [指標名]: [数値目標] を [測定方法] で [期間] 以内に達成
+3. [指標名]: [数値目標] を [測定方法] で [期間] 以内に達成
 
 ### 定性的指標
 1. [ユーザー体験の指標1]

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

@@ -38,7 +38,7 @@
 - **検証手法**: [何をどう検証するか — 例: 「新実装の出力をsrc/legacy/order_calcの既存実装と比較」「エンドポイントをテストDBに対して実行しレスポンスがコントラクトに一致することを確認」]
 - **成功基準**: [正しさを証明する観察可能な成果 — 例: 「全入力パターンで既存実装と出力が一致」「APIが期待スキーマで200を返す」]
 - **失敗時の対応**: [検証失敗時の対処 — 例: 「続行前にアプローチを再評価」「ユーザーにエスカレーション」]
-- **検証レベル**: [L1/L2/L3、implementation-approachスキル参照]
+- **検証レベル**: [L1: エンドユーザー機能としての動作確認 / L2: 新規テスト追加・パス / L3: ビルドエラーなし]
 
 ## 完了条件
 - [ ] 追加した全テストがパス
@@ -47,4 +47,4 @@
 
 ## 備考
 - 影響範囲: [変更が波及する可能性のある領域]
-- 制約: [変更してはいけない領域]
+- スコープ境界: [変更せず維持するファイル — パスと理由]