create-ai-project 1.20.6 → 1.20.7

package/.claude/agents-en/codebase-analyzer.md

@@ -81,6 +81,11 @@ For each element discovered in Steps 2-3:
 3. **Configuration dependencies**: Identify referenced config values, environment variables, feature flags
 4. **Hardcoded assumptions**: Note magic numbers, string literals with domain meaning, implicit dependencies
 5. **Existing test coverage**: Glob for test files matching each affected file. Record which elements have test coverage
+6. **Quality assurance mechanisms**: Identify how quality is enforced in the affected area
+   - Grep for linter configuration files, CI workflow definitions, and static analysis configs that cover the affected files
+   - Check if affected files are subject to domain-specific tools (e.g., schema validators, API spec validators, configuration file linters) by examining CI pipelines and pre-commit hooks
+   - Identify domain-specific constraints (naming conventions, length limits, format requirements) from configuration files, CI checks, or documented standards
+   - Record each mechanism with: tool/check name, what it enforces, configuration location, which affected files it covers
 
 ### Step 5: Return JSON Result
 
@@ -160,6 +165,24 @@ Return the JSON result as the final response. See Output Format for the schema.
       "impact": "What breaks if this constraint is violated"
     }
   ],
+  "qualityAssurance": {
+    "mechanisms": [
+      {
+        "tool": "Tool or check name",
+        "enforces": "What quality aspect it enforces",
+        "configLocation": "path/to/config:lineNumber",
+        "coveredFiles": ["affected files covered by this mechanism"],
+        "type": "linter|static_analysis|schema_validator|domain_specific|ci_check"
+      }
+    ],
+    "domainConstraints": [
+      {
+        "constraint": "Description of domain-specific constraint",
+        "source": "path/to/config-or-ci:lineNumber",
+        "affectedFiles": ["files subject to this constraint"]
+      }
+    ]
+  },
   "focusAreas": [
     {
       "area": "Brief area name",
@@ -186,6 +209,8 @@ Return the JSON result as the final response. See Output Format for the schema.
 - [ ] Searched for data access, external integration, and validation patterns using Grep
 - [ ] When data access detected: traced to schema definitions and extracted field-level details
 - [ ] Extracted constraints with file:line evidence
+- [ ] Identified quality assurance mechanisms (linters, CI checks, domain-specific validators) covering affected files
+- [ ] Recorded domain-specific constraints (naming, length, format) from configuration or CI
 - [ ] Generated focus areas with risk descriptions
 - [ ] Checked test coverage for discovered elements
 - [ ] Final response is the JSON output
@@ -199,4 +224,6 @@ Return the JSON result as the final response. See Output Format for the schema.
 - [ ] `dataModel.detected` accurately reflects whether data operations were found
 - [ ] `dataTransformationPipelines` populated for every entry point that transforms data (empty array only when no transformations exist)
 - [ ] Each pipeline step's `externalLookups` lists all master table / config / constant references that modify output values
+- [ ] `qualityAssurance.mechanisms` populated from CI pipelines, config files, and pre-commit hooks (empty array only when no mechanisms found)
+- [ ] `qualityAssurance.domainConstraints` populated from configuration and CI when domain-specific constraints exist
 - [ ] Limitations section documents any files that could not be read or patterns that could not be traced

package/.claude/agents-en/quality-fixer-frontend.md

@@ -20,11 +20,14 @@ Executes quality checks and provides a state where all checks complete with zero
    - Return approved status only after all quality checks pass
 
 2. **Completely Self-contained Fix Execution**
-   - Analyze error messages and identify root causes
-   - Execute both auto-fixes and manual fixes
+   - Analyze error root causes and execute both auto-fixes and manual fixes autonomously
    - Execute necessary fixes yourself and report completed state
    - Continue fixing until errors are resolved
 
+## Input Parameters
+
+- **task_file** (optional): Path to the task file being verified. When provided, read the "Quality Assurance Mechanisms" section and use listed mechanisms as supplementary hints for quality check discovery. This is a hint — primary detection remains code, manifest, and configuration-based.
+
 ## Initial Required Tasks
 
 **Task Registration**: Register work steps with TaskCreate. Always include: first "Confirm skill constraints", final "Verify skill fidelity". Update with TaskUpdate upon completion of each step.
@@ -56,6 +59,8 @@ Review the diff of changed files to detect stub or incomplete implementations. T
 **If no incomplete implementation is found**: Proceed to Step 2.
 
 ### Step 2: Detect Quality Check Commands
+
+**Primary detection** (always executed):
 ```bash
 # Auto-detect from project manifest files
 # Identify project structure and extract quality commands:
@@ -63,6 +68,12 @@ Review the diff of changed files to detect stub or incomplete implementations. T
 # - Build configuration → extract build/check commands
 ```
 
+**Supplementary detection** (when task_file provided):
+- Read the task file's "Quality Assurance Mechanisms" section
+- For each `executable_check`: verify the tool is available and the configuration exists, then add to the quality check command list
+- For each `passive_constraint`: do NOT add to the command list — instead, after all quality phases complete, verify the changed code does not violate the constraint (e.g., check naming conventions via Grep, verify length limits in changed files)
+- If a mechanism cannot be found or executed, note it in the output and continue to the next mechanism
+
 ### Step 3: Execute Quality Checks
 Follow frontend-technical-spec skill "Quality Check Requirements" section:
 - Basic checks (lint, format, build)
@@ -163,6 +174,21 @@ Returned immediately when Step 1 finds incomplete implementations in the diff. Q
 
 **Important**: JSON response is received by main AI (caller) and conveyed to user in an understandable format.
 
+### taskFileMechanisms Schema (included in all response types)
+```json
+"taskFileMechanisms": {
+  "provided": true,
+  "executed": ["mechanism names that were found and executed"],
+  "skipped": [
+    {
+      "mechanism": "mechanism name",
+      "reason": "tool not found | config not found | not executable"
+    }
+  ]
+}
+```
+When `task_file` was not provided, set `"provided": false` and omit `executed`/`skipped`.
+
 ### Internal Structured Response (for Main AI)
 
 **When quality check succeeds**:
@@ -212,6 +238,7 @@ Returned immediately when Step 1 finds incomplete implementations in the diff. Q
       "filesCount": 2
     }
   ],
+  "taskFileMechanisms": "see taskFileMechanisms Schema above",
   "metrics": {
     "totalErrors": 0,
     "totalWarnings": 0,
@@ -261,6 +288,7 @@ Returned immediately when Step 1 finds incomplete implementations in the diff. Q
     "Fix attempt 2: Tried aligning implementation to test",
     "Fix attempt 3: Tried inferring specification from Design Doc"
   ],
+  "taskFileMechanisms": "see taskFileMechanisms Schema above",
   "needsUserDecision": "Please confirm the correct button disabled behavior"
 }
 ```
@@ -281,6 +309,7 @@ Returned immediately when Step 1 finds incomplete implementations in the diff. Q
       "resolutionSteps": ["Create seed script for E2E test player", "Add subscription record to seed"]
     }
   ],
+  "taskFileMechanisms": "see taskFileMechanisms Schema above",
   "testsSkipped": 3,
   "testsPassedWithoutPrerequisites": 47
 }

package/.claude/agents-en/quality-fixer.md

@@ -25,6 +25,10 @@ Executes quality checks and provides a state where all Phases complete with zero
    - Execute necessary fixes yourself and report completed state
    - Continue fixing until errors are resolved
 
+## Input Parameters
+
+- **task_file** (optional): Path to the task file being verified. When provided, read the "Quality Assurance Mechanisms" section and use listed mechanisms as supplementary hints for quality check discovery. This is a hint — primary detection remains code, manifest, and configuration-based.
+
 ## Initial Required Tasks
 
 **Task Registration**: Register work steps with TaskCreate. Always include: first "Confirm skill constraints", final "Verify skill fidelity". Update with TaskUpdate upon completion of each step.
@@ -56,6 +60,8 @@ Review the diff of changed files to detect stub or incomplete implementations. T
 **If no incomplete implementation is found**: Proceed to Step 2.
 
 ### Step 2: Detect Quality Check Commands
+
+**Primary detection** (always executed):
 ```bash
 # Auto-detect from project manifest files
 # Identify project structure and extract quality commands:
@@ -63,6 +69,12 @@ Review the diff of changed files to detect stub or incomplete implementations. T
 # - Build configuration → extract build/check commands
 ```
 
+**Supplementary detection** (when task_file provided):
+- Read the task file's "Quality Assurance Mechanisms" section
+- For each `executable_check`: verify the tool is available and the configuration exists, then add to the quality check command list
+- For each `passive_constraint`: do NOT add to the command list — instead, after all quality phases complete, verify the changed code does not violate the constraint (e.g., check naming conventions via Grep, verify length limits in changed files)
+- If a mechanism cannot be found or executed, note it in the output and continue to the next mechanism
+
 ### Step 3: Execute Quality Checks
 Follow technical-spec skill "Quality Check Requirements" section:
 - Basic checks (lint, format, build)
@@ -127,6 +139,21 @@ Returned immediately when Step 1 finds incomplete implementations in the diff. Q
 
 **Important**: JSON response is passed to subsequent processing and formatted for user presentation.
 
+### taskFileMechanisms Schema (included in all response types)
+```json
+"taskFileMechanisms": {
+  "provided": true,
+  "executed": ["mechanism names that were found and executed"],
+  "skipped": [
+    {
+      "mechanism": "mechanism name",
+      "reason": "tool not found | config not found | not executable"
+    }
+  ]
+}
+```
+When `task_file` was not provided, set `"provided": false` and omit `executed`/`skipped`.
+
 ### Internal Structured Response
 
 **When quality check succeeds**:
@@ -173,6 +200,7 @@ Returned immediately when Step 1 finds incomplete implementations in the diff. Q
       "filesCount": 2
     }
   ],
+  "taskFileMechanisms": "see taskFileMechanisms Schema above",
   "metrics": {
     "totalErrors": 0,
     "totalWarnings": 0,
@@ -222,6 +250,7 @@ Returned immediately when Step 1 finds incomplete implementations in the diff. Q
     "Fix attempt 2: Tried aligning implementation to test",
     "Fix attempt 3: Tried inferring specification from related documentation"
   ],
+  "taskFileMechanisms": "see taskFileMechanisms Schema above",
   "needsUserDecision": "Please confirm the correct error code"
 }
 ```
@@ -242,6 +271,7 @@ Returned immediately when Step 1 finds incomplete implementations in the diff. Q
       "resolutionSteps": ["Create seed script for E2E test player", "Add subscription record to seed"]
     }
   ],
+  "taskFileMechanisms": "see taskFileMechanisms Schema above",
   "testsSkipped": 3,
   "testsPassedWithoutPrerequisites": 47
 }

package/.claude/agents-en/task-decomposer.md

@@ -96,6 +96,7 @@ Decompose tasks based on implementation strategy patterns determined in implemen
    - Target files
    - **Investigation Targets** (what the executor must read and understand before implementing)
    - Concrete implementation steps
+   - **Quality Assurance Mechanisms** (derived from work plan header — see Quality Assurance Mechanism Propagation below)
    - **Operation Verification Methods** (derived from Verification Strategy in work plan)
    - Completion criteria
 
@@ -137,6 +138,15 @@ When the work plan includes a Verification Strategy, derive each task's Operatio
    - **Verification level**: Select L1/L2/L3 per implementation-approach skill
 3. **Investigation Targets**: Include resources needed for verification (e.g., existing implementation for comparison, schema definitions, seed data paths)
 
+## Quality Assurance Mechanism Propagation
+
+When the work plan header includes a Quality Assurance Mechanisms table, propagate mechanisms to each task as follows:
+
+1. **Match by file coverage**: For each mechanism in the work plan, check if any of its covered file paths overlap with the task's target files (exact match or directory prefix match)
+2. **Include matching mechanisms**: List all mechanisms whose coverage overlaps with the task's target files in the task's "Quality Assurance Mechanisms" section
+3. **Include all if coverage is unspecified**: If a mechanism has no specific file coverage (applies project-wide), include it in every task
+4. **Omit when no match**: If no mechanisms match a task's target files, omit the "Quality Assurance Mechanisms" section from that task
+
 ## Task File Template
 
 See task template in documentation-criteria skill for details.
@@ -273,6 +283,7 @@ Please execute decomposed tasks according to the order.
 - [ ] Overall design document creation
 - [ ] Implementation efficiency and rework prevention (pre-identification of common processing, clarification of impact scope)
 - [ ] Investigation Targets specified for every task (specific file paths, not vague categories)
+- [ ] Quality Assurance Mechanisms from work plan header propagated to relevant tasks
 
 ## Task Design Principles
 

package/.claude/agents-en/task-executor.md

@@ -135,6 +135,17 @@ Select and execute files with pattern `docs/plans/tasks/*-task-*.md` that have u
 2. **Investigate existing implementations**: Search for similar functions in same domain/responsibility
 3. **Execute determination**: Determine continue/escalation per "Mandatory Judgment Criteria" above
 
+#### Reference Representativeness (Applied During Implementation)
+
+A per-adoption check applied each time a pattern or dependency is referenced. Apply coding-standards "Reference Representativeness" at the point of adoption:
+
+□ **Repository-wide verification**: Grep the pattern across the repository; adopt only when ≥3 files across different directories use the same pattern. When Grep returns 0-2 files outside the reference, investigate whether they are canonical or legacy before adopting
+□ **Dependency version verification** (when adopting external dependencies):
+  - Verify repository-wide usage distribution for the same dependency
+  - If following an existing version when alternatives exist, state the reason
+  - If repository-wide verification is insufficient to determine the appropriate version, escalate with `reason: "dependency_version_uncertain"`
+□ **Coexistence resolution**: If multiple versions or patterns coexist, identify the majority (highest file count) and adopt it; state the reason when choosing a minority pattern
+
 #### Implementation Flow (TDD Compliant)
 **Completion Confirmation**: If all checkboxes are `[x]`, report "already completed" and end
 
@@ -292,6 +303,30 @@ When an Investigation Target file does not exist or the path is stale, escalate
 }
 ```
 
+#### 2-4. Dependency Version Uncertain Escalation
+When repository-wide verification is insufficient to determine the appropriate dependency version, escalate in following JSON format:
+
+```json
+{
+  "status": "escalation_needed",
+  "reason": "Dependency version uncertain",
+  "taskName": "[Task name being executed]",
+  "escalation_type": "dependency_version_uncertain",
+  "dependency": {
+    "name": "[dependency name]",
+    "versionsFound": ["list of versions found in repository"],
+    "filesChecked": ["file paths where dependency was found"],
+    "ambiguityReason": "[why repository state alone is insufficient — e.g., multiple versions coexist with no clear majority, no existing usage found]"
+  },
+  "user_decision_required": true,
+  "suggested_options": [
+    "Use version X (majority in repository)",
+    "Use version Y (specific reason)",
+    "Research latest stable version and advise"
+  ]
+}
+```
+
 ## Completion Gate [BLOCKING]
 
 ☐ All task checkboxes completed with evidence

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

@@ -45,11 +45,19 @@ Must be performed before any investigation:
    - 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
+2. **Identify Quality Assurance Mechanisms**
+   - When codebase-analyzer output is available: use its `qualityAssurance` section as the primary source
+   - When not available: scan CI pipelines, linter configs, pre-commit hooks, and project configuration for tools and checks that cover the change area
+   - Identify domain-specific constraints (naming conventions, length limits, format requirements) from configuration or CI
+   - Classify each mechanism: `executable_check` (tool can be invoked as a command — e.g., linter, build, test, schema validator) or `passive_constraint` (rule verified by inspecting output — e.g., naming convention checked via Grep, length limit checked manually)
+   - For each mechanism, decide: **adopted** (will be enforced during implementation) or **noted** (observed but not adopted — state reason, e.g., not relevant to this change area, superseded by another check)
+
+3. **Record in Design Doc**
+   - List standards in "Applicable Standards" section with `[explicit]`/`[implicit]` tags
+   - List quality assurance mechanisms in "Quality Assurance Mechanisms" section with `adopted`/`noted` status
    - Implicit standards require user confirmation before design proceeds
 
-3. **Alignment Rule**
+4. **Alignment Rule**
    - Design decisions must reference applicable standards
    - Deviations require documented rationale
 
@@ -292,6 +300,7 @@ Implementation sample creation checklist:
 
 **All modes**:
 - [ ] **Standards identification gate completed** (required)
+- [ ] **Quality assurance mechanisms identified with adopted/noted status** (required)
 - [ ] **Code inspection evidence recorded** (required)
 - [ ] **Integration points enumerated with contracts** (required)
 - [ ] **Data contracts clarified** (required)

package/.claude/agents-en/work-planner.md

@@ -27,6 +27,7 @@ Read the Design Doc(s), UI Spec, PRD, and ADR (if provided). Extract:
 - Technical dependencies and implementation order
 - Integration points and their contracts
 - **Verification Strategy**: Correctness Proof Method (correctness definition, verification method, verification timing) and Early Verification Point (first verification target, success criteria, failure response)
+- **Quality Assurance Mechanisms**: From Design Doc "Quality Assurance Mechanisms" section, extract all items with `adopted` status — these are the quality gates that must be enforced during implementation
 
 ### 2. Process Test Design Information (when provided)
 Read test skeleton files and extract meta information (see Test Design Information Processing section).
@@ -38,6 +39,7 @@ Choose Strategy A (TDD) if test skeletons are provided, Strategy B (implementati
 
 **Common rules (all approaches)**:
 - **Include Verification Strategy summary in work plan header** for downstream task reference
+- **Include adopted Quality Assurance Mechanisms in work plan header** for downstream task reference — list each adopted mechanism with tool name, what it enforces, configuration path, and covered files (literal file paths or directory prefixes from Design Doc, or "project-wide" if not scoped to specific files)
 - Include verification tasks in the phase corresponding to Verification Strategy's verification timing
 - When test skeletons are provided, place integration test implementation in corresponding phases and E2E test execution in the final phase
 - When test skeletons are not provided, include test implementation tasks based on Design Doc acceptance criteria
@@ -259,6 +261,7 @@ When creating work plans, **Phase Structure Diagrams** and **Task Dependency Dia
   - [ ] No `gap` entries without justification
   - [ ] All justified `gap` entries flagged for user confirmation before plan approval
 - [ ] Verification Strategy extracted from Design Doc and included in plan header
+- [ ] Adopted Quality Assurance Mechanisms extracted from Design Doc and included in plan header
 - [ ] Phase structure matches implementation approach (vertical → value unit phases, horizontal → layer phases)
 - [ ] Early verification point placed in Phase 1 (when Verification Strategy specifies one)
 - [ ] All requirements converted to tasks

package/.claude/agents-ja/codebase-analyzer.md

@@ -81,6 +81,11 @@ skills: coding-standards, project-context, technical-spec
 3. **設定依存**: 参照されている設定値、環境変数、フィーチャーフラグを特定
 4. **ハードコードされた前提**: マジックナンバー、ドメイン意味を持つ文字列リテラル、暗黙の依存関係を記録
 5. **既存テストカバレッジ**: 影響ファイルに対応するテストファイルをGlob。テストカバレッジのある要素を記録
+6. **品質保証メカニズム**: 影響領域で品質がどのように担保されているかを特定
+   - 影響ファイルをカバーするlinter設定ファイル、CIワークフロー定義、静的解析設定をGrepで検索
+   - 影響ファイルがドメイン固有ツール（スキーマバリデータ、API spec validator、設定ファイルリンター等）の対象かどうかをCIパイプラインやpre-commitフックを調べて確認
+   - 設定ファイル、CIチェック、ドキュメント化された基準からドメイン固有の制約（命名規約、文字数制限、フォーマット要件）を特定
+   - 各メカニズムについて記録: ツール/チェック名、検証内容、設定ファイルの場所、カバーする影響ファイル
 
 ### ステップ5: JSON結果の返却
 
@@ -160,6 +165,24 @@ skills: coding-standards, project-context, technical-spec
       "impact": "この制約に違反した場合の影響"
     }
   ],
+  "qualityAssurance": {
+    "mechanisms": [
+      {
+        "tool": "ツールまたはチェック名",
+        "enforces": "検証する品質項目",
+        "configLocation": "path/to/config:行番号",
+        "coveredFiles": ["このメカニズムでカバーされる影響ファイル"],
+        "type": "linter|static_analysis|schema_validator|domain_specific|ci_check"
+      }
+    ],
+    "domainConstraints": [
+      {
+        "constraint": "ドメイン固有の制約の説明",
+        "source": "path/to/config-or-ci:行番号",
+        "affectedFiles": ["この制約の対象ファイル"]
+      }
+    ]
+  },
   "focusAreas": [
     {
       "area": "領域名",
@@ -186,6 +209,8 @@ skills: coding-standards, project-context, technical-spec
 - [ ] Grepでデータアクセス、外部統合、バリデーションパターンを検索した
 - [ ] データアクセス検出時: スキーマ定義をトレースしフィールドレベルの詳細を抽出した
 - [ ] file:lineエビデンス付きで制約を抽出した
+- [ ] 影響ファイルをカバーする品質保証メカニズム（linter、CIチェック、ドメイン固有バリデータ）を特定した
+- [ ] 設定ファイルやCIからドメイン固有の制約（命名規約、文字数制限、フォーマット）を記録した
 - [ ] リスク記述付きの注目領域を生成した
 - [ ] 発見した要素のテストカバレッジを確認した
 - [ ] 最終レスポンスがJSON出力
@@ -199,4 +224,6 @@ skills: coding-standards, project-context, technical-spec
 - [ ] `dataModel.detected`がデータ操作の検出有無を正確に反映
 - [ ] `dataTransformationPipelines`がデータを変換するすべてのエントリポイントについて記録されている（変換が存在しない場合のみ空配列）
 - [ ] 各パイプラインステップの`externalLookups`が出力値を変更するすべてのマスタテーブル/設定値/定数参照を列挙
+- [ ] `qualityAssurance.mechanisms`がCIパイプライン、設定ファイル、pre-commitフックから記録されている（メカニズムが見つからない場合のみ空配列）
+- [ ] `qualityAssurance.domainConstraints`がドメイン固有の制約を設定やCIから記録している（該当する場合）
 - [ ] limitationsセクションが読み込めなかったファイルやトレースできなかったパターンを記録

package/.claude/agents-ja/quality-fixer-frontend.md

@@ -25,6 +25,10 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
    - 修正が必要なものは自分で実行し、完成した状態で報告
    - エラーが解消するまで修正を継続
 
+## 入力パラメータ
+
+- **task_file**（任意）: 検証対象のタスクファイルへのパス。指定された場合、「品質保証メカニズム」セクションを読み込み、品質チェック検出の補助ヒントとして使用する。これはあくまでヒントであり、コード・マニフェスト・設定ベースの一次検出が優先。
+
 ## 初回必須タスク
 
 **タスク登録**: TaskCreateで作業ステップを登録。必ず最初に「スキル制約の確認」、最後に「スキル忠実度の検証」を含める。各完了時にTaskUpdateで更新。
@@ -56,6 +60,8 @@ package.jsonの`packageManager`フィールドに応じた実行コマンドを
 **未完成実装が見つからなかった場合**: ステップ2へ進む。
 
 ### ステップ2: 品質チェックコマンドの検出
+
+**一次検出**（常に実行）:
 ```bash
 # プロジェクトのマニフェストファイルから自動検出
 # プロジェクト構造を特定し品質コマンドを抽出:
@@ -63,6 +69,12 @@ package.jsonの`packageManager`フィールドに応じた実行コマンドを
 # - ビルド設定 → build/checkコマンドを抽出
 ```
 
+**補助検出**（task_file指定時）:
+- タスクファイルの「品質保証メカニズム」セクションを読み込む
+- `executable_check`: ツールが利用可能で設定ファイルが存在することを確認し、品質チェックコマンドリストに追加
+- `passive_constraint`: コマンドリストには追加しない — 全品質フェーズ完了後、変更コードが制約に違反していないことを確認する（例: 命名規約をGrepで検証、文字数制限を変更ファイルで確認）
+- 見つからない・実行できないメカニズムは出力に記録し、次のメカニズムに進む
+
 ### ステップ3: 品質チェックの実行
 frontend-technical-specスキルの「品質チェック要件」セクションに従う:
 - 基本チェック（lint, format, build）
@@ -164,6 +176,21 @@ blockedにする前に、以下の順序で仕様を確認：
 
 **重要**: JSONレスポンスはメインAI（呼び出し元）が受け取り、ユーザーが理解できる形式に加工して伝えます。
 
+### taskFileMechanismsスキーマ（全レスポンス型に含める）
+```json
+"taskFileMechanisms": {
+  "provided": true,
+  "executed": ["検出・実行されたメカニズム名"],
+  "skipped": [
+    {
+      "mechanism": "メカニズム名",
+      "reason": "tool not found | config not found | not executable"
+    }
+  ]
+}
+```
+`task_file`が指定されなかった場合は`"provided": false`とし、`executed`/`skipped`は省略。
+
 ### 内部構造化レスポンス（メインAI向け）
 
 **品質チェック成功時**:
@@ -213,6 +240,7 @@ blockedにする前に、以下の順序で仕様を確認：
       "filesCount": 2
     }
   ],
+  "taskFileMechanisms": "上記taskFileMechanismsスキーマ参照",
   "metrics": {
     "totalErrors": 0,
     "totalWarnings": 0,
@@ -261,6 +289,7 @@ blockedにする前に、以下の順序で仕様を確認：
     "修正試行2: 実装をテストに合わせる試み",
     "修正試行3: Design Docから仕様を推測する試み"
   ],
+  "taskFileMechanisms": "上記taskFileMechanismsスキーマ参照",
   "needsUserDecision": "ボタン無効化の正しい動作を確認してください"
 }
 ```
@@ -281,6 +310,7 @@ blockedにする前に、以下の順序で仕様を確認：
       "resolutionSteps": ["E2Eテストプレイヤー用seed scriptの作成", "サブスクリプションレコードをseedに追加"]
     }
   ],
+  "taskFileMechanisms": "上記taskFileMechanismsスキーマ参照",
   "testsSkipped": 3,
   "testsPassedWithoutPrerequisites": 47
 }

package/.claude/agents-ja/quality-fixer.md

@@ -25,6 +25,10 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
    - 修正が必要なものは自分で実行し、完成した状態で報告
    - エラーが解消するまで修正を継続
 
+## 入力パラメータ
+
+- **task_file**（任意）: 検証対象のタスクファイルへのパス。指定された場合、「品質保証メカニズム」セクションを読み込み、品質チェック検出の補助ヒントとして使用する。これはあくまでヒントであり、コード・マニフェスト・設定ベースの一次検出が優先。
+
 ## 初回必須タスク
 
 **タスク登録**: TaskCreateで作業ステップを登録。必ず最初に「スキル制約の確認」、最後に「スキル忠実度の検証」を含める。各完了時にTaskUpdateで更新。
@@ -56,6 +60,8 @@ package.jsonの`packageManager`フィールドに応じた実行コマンドを
 **未完成実装が見つからなかった場合**: ステップ2へ進む。
 
 ### ステップ2: 品質チェックコマンドの検出
+
+**一次検出**（常に実行）:
 ```bash
 # プロジェクトのマニフェストファイルから自動検出
 # プロジェクト構造を特定し品質コマンドを抽出:
@@ -63,6 +69,12 @@ package.jsonの`packageManager`フィールドに応じた実行コマンドを
 # - ビルド設定 → build/checkコマンドを抽出
 ```
 
+**補助検出**（task_file指定時）:
+- タスクファイルの「品質保証メカニズム」セクションを読み込む
+- `executable_check`: ツールが利用可能で設定ファイルが存在することを確認し、品質チェックコマンドリストに追加
+- `passive_constraint`: コマンドリストには追加しない — 全品質フェーズ完了後、変更コードが制約に違反していないことを確認する（例: 命名規約をGrepで検証、文字数制限を変更ファイルで確認）
+- 見つからない・実行できないメカニズムは出力に記録し、次のメカニズムに進む
+
 ### ステップ3: 品質チェックの実行
 technical-specスキルの「品質チェック要件」セクションに従う:
 - 基本チェック（lint, format, build）
@@ -128,6 +140,21 @@ blockedにする前に、以下の順序で仕様を確認：
 
 **重要**: JSONレスポンスは次の処理に渡され、最終的にユーザー向けの形式に加工されます。
 
+### taskFileMechanismsスキーマ（全レスポンス型に含める）
+```json
+"taskFileMechanisms": {
+  "provided": true,
+  "executed": ["検出・実行されたメカニズム名"],
+  "skipped": [
+    {
+      "mechanism": "メカニズム名",
+      "reason": "tool not found | config not found | not executable"
+    }
+  ]
+}
+```
+`task_file`が指定されなかった場合は`"provided": false`とし、`executed`/`skipped`は省略。
+
 ### 内部構造化レスポンス
 
 **品質チェック成功時**:
@@ -174,6 +201,7 @@ blockedにする前に、以下の順序で仕様を確認：
       "filesCount": 2
     }
   ],
+  "taskFileMechanisms": "上記taskFileMechanismsスキーマ参照",
   "metrics": {
     "totalErrors": 0,
     "totalWarnings": 0,
@@ -222,6 +250,7 @@ blockedにする前に、以下の順序で仕様を確認：
     "修正2: 実装をテストに合わせる試み",
     "修正3: 関連ドキュメントから仕様を推測"
   ],
+  "taskFileMechanisms": "上記taskFileMechanismsスキーマ参照",
   "needsUserDecision": "正しいエラーコードを確認してください"
 }
 ```
@@ -242,6 +271,7 @@ blockedにする前に、以下の順序で仕様を確認：
       "resolutionSteps": ["E2Eテストプレイヤー用seed scriptの作成", "サブスクリプションレコードをseedに追加"]
     }
   ],
+  "taskFileMechanisms": "上記taskFileMechanismsスキーマ参照",
   "testsSkipped": 3,
   "testsPassedWithoutPrerequisites": 47
 }

package/.claude/agents-ja/task-decomposer.md

@@ -96,6 +96,7 @@ implementation-approachスキルで決定された実装戦略パターンに基
    - 対象ファイル
    - **調査対象**（executorが実装前に読んで理解すべきもの）
    - 具体的な実装手順
+   - **品質保証メカニズム**（作業計画書ヘッダーから導出 — 下記「品質保証メカニズムの伝播」参照）
    - **動作検証方法**（作業計画書の検証戦略から導出）
    - 完了条件
 
@@ -137,6 +138,15 @@ implementation-approachスキルで決定された実装戦略パターンに基
    - **検証レベル**: implementation-approachスキルに従いL1/L2/L3を選択
 3. **調査対象**: 検証に必要なリソースを含める（例: 比較対象の既存実装、スキーマ定義、seed dataのパス）
 
+## 品質保証メカニズムの伝播
+
+作業計画書ヘッダーに品質保証メカニズムテーブルが含まれる場合、以下のルールで各タスクに伝播する:
+
+1. **ファイルカバレッジによるマッチング**: 作業計画書の各メカニズムについて、カバー範囲のファイルパスがタスクの対象ファイルと重複するか確認（完全一致またはディレクトリプレフィックス一致）
+2. **該当メカニズムを記載**: カバー範囲がタスクの対象ファイルと重複するメカニズムをすべてタスクの「品質保証メカニズム」セクションに記載
+3. **カバー範囲未指定の場合は全タスクに記載**: メカニズムのカバー範囲が指定されていない場合（project-wide）、すべてのタスクに含める
+4. **該当なしの場合は省略**: タスクの対象ファイルに該当するメカニズムがなければ「品質保証メカニズム」セクションを省略
+
 ## タスクファイルテンプレート
 
 詳細はdocumentation-criteriaスキルのタスクテンプレートを参照。
@@ -273,6 +283,7 @@ implementation-approachスキルで決定された実装戦略パターンに基
 - [ ] 全体設計書の作成
 - [ ] 実装効率と手戻り防止（共通処理の事前識別、影響範囲の明確化）
 - [ ] 全タスクに調査対象が指定されている（具体的なファイルパス、曖昧なカテゴリではない）
+- [ ] 作業計画書ヘッダーの品質保証メカニズムを該当タスクに伝播済み
 
 ## タスク設計の原則
 

package/.claude/agents-ja/task-executor.md

@@ -132,6 +132,17 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 2. **既存実装調査**：同ドメイン・責務で類似機能を検索
 3. **判定実行**：上記「必須判断基準」に従い継続・エスカレーション判定
 
+#### 参照の代表性チェック（実装中に随時適用）
+
+パターンや依存をコードから採用する際、coding-standardsの「参照の代表性」を採用時点で適用する:
+
+□ **リポジトリ全体での確認**: パターンまたは依存バージョンがリポジトリ全体で代表的であることをGrepで確認。異なるディレクトリの3ファイル以上で同じパターンが使われている場合に採用可能。参照元以外で0-2件の場合は、正規の実装かレガシーかを調査してから採用
+□ **依存バージョン確認**（外部依存を採用する場合）:
+  - 同じ依存のリポジトリ全体での使用分布を確認
+  - 代替が存在する中で既存バージョンに従う場合、その理由を明記
+  - リポジトリ全体の確認では適切なバージョンが判断できない場合、`reason: "dependency_version_uncertain"` でエスカレーション
+□ **複数バージョン共存時の解決**: 複数バージョンやパターンが共存している場合、多数派（最多ファイル数）を特定してから選択。少数派を選ぶ場合は理由を明記
+
 #### 実装フロー（TDD準拠）
 **完了確認**: 全チェックボックスが`[x]`の場合は「既に完了」と報告して終了
 
@@ -289,6 +300,30 @@ Design Doc通りに実装できない場合は以下のJSON形式でエスカレ
 }
 ```
 
+#### 2-4. 依存バージョン不確定エスカレーション
+リポジトリ全体の確認では適切な依存バージョンが判断できない場合、以下のJSON形式でエスカレーション:
+
+```json
+{
+  "status": "escalation_needed",
+  "reason": "Dependency version uncertain",
+  "taskName": "[実行中のタスク名]",
+  "escalation_type": "dependency_version_uncertain",
+  "dependency": {
+    "name": "[依存名]",
+    "versionsFound": ["リポジトリで検出されたバージョンのリスト"],
+    "filesChecked": ["依存が検出されたファイルパス"],
+    "ambiguityReason": "[リポジトリの状態だけでは判断できない理由 — 例: 複数バージョンが共存し明確な多数派がない、既存の使用が見つからない]"
+  },
+  "user_decision_required": true,
+  "suggested_options": [
+    "バージョンXを使用（リポジトリの多数派）",
+    "バージョンYを使用（特定の理由）",
+    "最新安定バージョンを調査して提案"
+  ]
+}
+```
+
 ## 完了ゲート [BLOCKING]
 
 ☐ 全タスクチェックボックスがエビデンス付きで完了

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

@@ -45,11 +45,19 @@ ADR/Design Docの作成閾値はdocumentation-criteriaスキルに準拠。判
    - プロジェクト設定、ルールファイル、既存コードパターンをスキャン
    - 各基準を分類: **Explicit**（文書化済み）または **Implicit**（観察されたパターンのみ）
 
-2. **Design Docへの記録**
-   - 「適用基準」セクションに`[explicit]`/`[implicit]`タグ付きで記載
+2. **品質保証メカニズムの特定**
+   - codebase-analyzerの出力がある場合: その`qualityAssurance`セクションを一次情報源として使用
+   - 出力がない場合: CIパイプライン、linter設定、pre-commitフック、プロジェクト設定から変更対象領域をカバーするツールとチェックをスキャン
+   - 設定ファイルやCIからドメイン固有の制約（命名規約、文字数制限、フォーマット要件）を特定
+   - 各メカニズムの種別を分類: `executable_check`（コマンドとして実行可能 — 例: linter、ビルド、テスト、スキーマバリデータ）または `passive_constraint`（出力を検査して確認 — 例: 命名規約をGrepで検証、文字数制限を手動確認）
+   - 各メカニズムについて判断: **adopted**（実装時に適用）または **noted**（観察されたが不採用 — 理由を記載。例: この変更領域に無関係、別のチェックで代替済み）
+
+3. **Design Docへの記録**
+   - 「適用基準」セクションに基準を`[explicit]`/`[implicit]`タグ付きで記載
+   - 「品質保証メカニズム」セクションに各メカニズムを`adopted`/`noted`ステータス付きで記載
    - Implicit基準は設計着手前にユーザー確認が必要
 
-3. **整合性ルール**
+4. **整合性ルール**
    - 設計判断は適用基準を参照すること
    - 逸脱する場合は根拠を明記
 
@@ -291,6 +299,7 @@ ADRに含まない：スケジュール、実装手順、具体的コード
 
 **全モード共通**:
 - [ ] **基準特定ゲート完了**（必須）
+- [ ] **品質保証メカニズムをadopted/notedステータス付きで特定**（必須）
 - [ ] **コード調査エビデンス記録済み**（必須）
 - [ ] **統合ポイントをコントラクト付きで列挙**（必須）
 - [ ] **データ契約の明確化**（必須）

package/.claude/agents-ja/work-planner.md

@@ -27,6 +27,7 @@ Design Doc、UI Spec、PRD、ADR（提供されている場合）を読み込み
 - 技術的依存関係と実装順序
 - 統合ポイントとそのコントラクト
 - **検証戦略**: 正しさの証明方法（正しさの定義、検証手法、検証タイミング）と早期検証ポイント（最初の検証対象、成功基準、失敗時の対応）
+- **品質保証メカニズム**: Design Docの「品質保証メカニズム」セクションから`adopted`ステータスの全項目を抽出 — 実装時に適用すべき品質ゲート
 
 ### 2. テスト設計情報の処理（提供時）
 テストスケルトンファイルを読み込み、メタ情報を抽出（テスト設計情報の処理セクションを参照）。
@@ -38,6 +39,7 @@ Design Doc、UI Spec、PRD、ADR（提供されている場合）を読み込み
 
 **全アプローチ共通**:
 - **検証戦略の要約を作業計画書ヘッダーに記載**（後続タスクへの参照用）
+- **採用した品質保証メカニズムを作業計画書ヘッダーに記載**（後続タスクへの参照用） — 各メカニズムについてツール名、検証内容、設定パス、カバー範囲（Design Docのファイルパスまたはディレクトリプレフィックス、スコープが限定されない場合は "project-wide"）を記載
 - 検証戦略の検証タイミングに対応するフェーズに検証タスクを配置
 - テストスケルトンが提供されている場合、統合テスト実装を対応するフェーズに配置し、E2Eテスト実行を最終フェーズに配置
 - テストスケルトンが提供されていない場合、Design Docの受入条件に基づくテスト実装タスクを含める
@@ -258,6 +260,7 @@ Design Docの技術的依存関係と実装アプローチに基づいてフェ
   - [ ] 理由なしの`gap`がないこと
   - [ ] 理由ありの`gap`は計画承認前にユーザー確認を実施
 - [ ] Design Docから検証戦略を抽出し計画書ヘッダーに記載
+- [ ] Design Docから採用済み品質保証メカニズムを抽出し計画書ヘッダーに記載
 - [ ] フェーズ構成が実装アプローチと整合（垂直 → 価値単位フェーズ、水平 → レイヤーフェーズ）
 - [ ] 早期検証ポイントをPhase 1に配置（検証戦略で指定されている場合）
 - [ ] 全要件のタスク化

package/.claude/commands-en/build.md

@@ -84,7 +84,7 @@ For EACH task, YOU MUST:
      - `needs_revision` → Return to step 2 with `requiredFixes`
      - `approved` → Proceed to step 4
    - `readyForQualityCheck: true` → Proceed to step 4
-4. **INVOKE quality-fixer**: Execute all quality checks and fixes (cross-layer: see Layer-Aware Agent Routing)
+4. **INVOKE quality-fixer**: Execute all quality checks and fixes (cross-layer: see Layer-Aware Agent Routing). **Always pass** the current task file path as `task_file`
 5. **CHECK quality-fixer response**:
    - `stub_detected` → Return to step 2 with `incompleteImplementations[]` details
    - `blocked` → STOP and escalate to user

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

@@ -84,7 +84,7 @@ For EACH task, YOU MUST:
      - `needs_revision` → Return to step 2 with `requiredFixes`
      - `approved` → Proceed to step 4
    - `readyForQualityCheck: true` → Proceed to step 4
-4. **INVOKE quality-fixer-frontend**: Execute all quality checks and fixes
+4. **INVOKE quality-fixer-frontend**: Execute all quality checks and fixes. **Always pass** the current task file path as `task_file`
 5. **CHECK quality-fixer-frontend response**:
    - `stub_detected` → Return to step 2 with `incompleteImplementations[]` details
    - `blocked` → STOP and escalate to user

package/.claude/commands-en/implement.md

@@ -76,7 +76,7 @@ Following "Autonomous Execution Task Management" in subagents-orchestration-guid
      - `needs_revision` → Return to step 1 with `requiredFixes`
      - `approved` → Proceed to step 3
    - Otherwise → Proceed to step 3
-3. **INVOKE quality-fixer**: Execute all quality checks and fixes (cross-layer: see Layer-Aware Agent Routing)
+3. **INVOKE quality-fixer**: Execute all quality checks and fixes (cross-layer: see Layer-Aware Agent Routing). **Always pass** the current task file path as `task_file`
    - `stub_detected` → Return to step 1 with `incompleteImplementations[]` details
    - `blocked` → Escalate to user
    - `approved` → Proceed to step 4

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

@@ -84,7 +84,7 @@ Agentツールでtask-decomposerを呼び出す:
      - `needs_revision` → `requiredFixes`を添えてステップ2に戻る
      - `approved` → ステップ4へ
    - `readyForQualityCheck: true` → ステップ4へ
-4. **quality-fixer実行**: 全品質チェックと修正を実行（レイヤー横断時: レイヤー別エージェントルーティング参照）
+4. **quality-fixer実行**: 全品質チェックと修正を実行（レイヤー横断時: レイヤー別エージェントルーティング参照）。**必ず**現在のタスクファイルパスを`task_file`として渡す
 5. **quality-fixerレスポンスチェック**:
    - `stub_detected` → `incompleteImplementations[]`の詳細を添えてステップ2に戻す
    - `blocked` → 停止してユーザーにエスカレーション

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

@@ -84,7 +84,7 @@ Agentツールでtask-decomposerを呼び出す:
      - `needs_revision` → `requiredFixes`を添えてステップ2に戻る
      - `approved` → ステップ4へ
    - `readyForQualityCheck: true` → ステップ4へ
-4. **quality-fixer-frontend実行**: 全品質チェックと修正を実行（レイヤー横断時: レイヤー別エージェントルーティング参照）
+4. **quality-fixer-frontend実行**: 全品質チェックと修正を実行（レイヤー横断時: レイヤー別エージェントルーティング参照）。**必ず**現在のタスクファイルパスを`task_file`として渡す
 5. **quality-fixer-frontendレスポンスチェック**:
    - `stub_detected` → `incompleteImplementations[]`の詳細を添えてステップ2に戻す
    - `blocked` → 停止してユーザーにエスカレーション

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

@@ -76,7 +76,7 @@ subagents-orchestration-guideスキルの「自律実行中のタスク管理」
      - `needs_revision` → `requiredFixes`を添えてステップ1に戻る
      - `approved` → ステップ3へ
    - それ以外 → ステップ3へ
-3. **quality-fixer実行**: 全品質チェックと修正を実行（レイヤー横断時: レイヤー別エージェントルーティング参照）
+3. **quality-fixer実行**: 全品質チェックと修正を実行（レイヤー横断時: レイヤー別エージェントルーティング参照）。**必ず**現在のタスクファイルパスを`task_file`として渡す
    - `stub_detected` → `incompleteImplementations[]`の詳細を添えてステップ1に戻す
    - `blocked` → ユーザーにエスカレーション
    - `approved` → ステップ4へ

package/.claude/skills-en/coding-standards/SKILL.md

@@ -68,6 +68,22 @@ How to handle duplicate code based on Martin Fowler's "Refactoring":
 - Significant readability decrease from commonalization
 - Simple helpers in test code
 
+## Reference Representativeness
+
+**Failure mode**: Adopting patterns or dependency versions from the nearest 2-3 files without verifying repository-wide usage leads to outdated patterns, version mismatches, and architecture inconsistency.
+
+### Verifying References Before Adoption
+When adopting patterns, APIs, or dependencies from existing code:
+- **IF** referencing only 2-3 nearby files → **THEN** Grep the pattern across the repository; adopt only when ≥3 files across different directories use the same pattern
+- **IF** Grep returns 1-2 files outside the reference → **THEN** investigate whether those files are the canonical implementation or legacy outliers before adopting
+- **IF** Grep returns 0 files outside the reference → **THEN** treat the pattern as local convention; adopt only with explicit justification (e.g., consistency with surrounding code, avoiding breaking changes)
+- **IF** multiple approaches coexist in the repository → **THEN** identify the majority pattern (highest file count) and adopt it; state the reason when choosing a minority pattern
+- **IF** adopting an external dependency (library, plugin, SDK) → **THEN** verify repository-wide usage distribution for the same dependency; if the appropriate version cannot be determined from repository state alone, escalate
+- **IF** following an existing pattern → **THEN** state the reason for following it when an alternative exists (e.g., consistency with surrounding code, avoiding breaking changes, pending coordinated update)
+
+### Principle
+Nearby code is a starting point for investigation. Verify repository-wide usage (≥3 files across different directories) before adopting a pattern as representative.
+
 ## Common Failure Patterns and Avoidance Methods
 
 ### Pattern 1: Error Fix Chain
@@ -93,14 +109,15 @@ How to handle duplicate code based on Martin Fowler's "Refactoring":
 - For low certainty cases, create minimal verification code first
 
 ### Pattern 5: Insufficient Existing Code Investigation
-**Symptom**: Duplicate implementations, architecture inconsistency, integration failures
-**Cause**: Insufficient understanding of existing code before implementation
+**Symptom**: Duplicate implementations, architecture inconsistency, integration failures, adopting outdated patterns
+**Cause**: Insufficient understanding of existing code before implementation; referencing only nearby files without verifying representativeness
 **Avoidance Methods**:
 - Before implementation, always search for similar functionality (using domain, responsibility, configuration patterns as keywords)
 - Similar functionality found -> Use that implementation (do not create new implementation)
 - Similar functionality is technical debt -> Create ADR improvement proposal before implementation
 - No similar functionality exists -> Implement new functionality following existing design philosophy
 - Record all decisions and rationale in "Existing Codebase Analysis" section of Design Doc
+- **Reference representativeness check**: See "Reference Representativeness" section above for IF-THEN thresholds
 
 ## Debugging Techniques
 

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

@@ -52,6 +52,12 @@ unknowns:
 - [Standard/convention] `[explicit]` — Source: [config / rule file / doc path]
 - [Observed pattern] `[implicit]` — Evidence: [file paths] — Confirmed: [Yes/No]
 
+#### Quality Assurance Mechanisms
+How quality is enforced in the change area. Each item is either adopted (will be enforced during implementation) or noted (observed but not adopted, with reason).
+
+- [ ] [Tool/check name] — Enforces: [what] — Config: [path] — Covers: [literal file paths or directory prefixes, or "project-wide"] — Type: `executable_check` — Status: `adopted` / `noted (reason)`
+- [ ] [Domain-specific constraint] — Enforces: [what] — Source: [path] — Covers: [literal file paths or directory prefixes, or "project-wide"] — Type: `passive_constraint` — Status: `adopted` / `noted (reason)`
+
 ### Problem to Solve
 
 [Specific problems or challenges this feature aims to address]

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

@@ -24,6 +24,15 @@ Related Issue/PR: #XXX (if any)
 - **Success criteria**: [extracted from Design Doc]
 - **Failure response**: [extracted from Design Doc]
 
+## Quality Assurance Mechanisms (from Design Doc)
+
+Adopted quality gates for the change area. Each task in this plan must satisfy these mechanisms.
+
+| Mechanism | Enforces | Config/Source | Covered Files | Type |
+|-----------|----------|---------------|---------------|------|
+| [Tool/check name] | [What quality aspect it enforces] | [path/to/config] | [literal file paths or directory prefixes, or "project-wide"] | executable_check |
+| [Domain constraint] | [What it enforces] | [path/to/source] | [literal file paths or directory prefixes, or "project-wide"] | passive_constraint |
+
 ## Design-to-Plan Traceability
 
 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.

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

@@ -33,6 +33,10 @@ Files to read before starting implementation (file path, with optional search hi
 - [ ] Improve code (maintain passing tests)
 - [ ] Confirm added tests still pass
 
+## Quality Assurance Mechanisms
+(From work plan header — mechanisms relevant to this task's target files)
+- [Tool/check name] — Enforces: [what] — Config/Source: [path] — Type: `executable_check` | `passive_constraint`
+
 ## Operation Verification Methods
 (Derived from Verification Strategy in work plan)
 - **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"]

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

@@ -131,10 +131,10 @@ Subagents respond in JSON format. Key fields for orchestrator decisions:
 | Agent | Key Fields | Decision Logic |
 |-------|-----------|----------------|
 | 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 |
+| codebase-analyzer | analysisScope.categoriesDetected, dataModel.detected, qualityAssurance (mechanisms[], domainConstraints[]), focusAreas[], existingElements count, limitations | Pass focusAreas to technical-designer as context |
 | 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/stub_detected/blocked). `stub_detected` → route back to task-executor with `incompleteImplementations[]` details for completion, then re-run quality-fixer. `blocked` → see quality-fixer blocked handling below | On stub_detected: re-invoke task-executor. On blocked: see handling below |
+| task-executor | status (escalation_needed/completed), escalation_type (design_compliance_violation/similar_function_found/similar_component_found/investigation_target_not_found/out_of_scope_file/dependency_version_uncertain), testsAdded, requiresTestReview | On escalation_needed: handle by escalation_type |
+| quality-fixer | Input: `task_file` (path to current task file — always pass this in orchestrated flows). Status: approved/stub_detected/blocked. `stub_detected` → route back to task-executor with `incompleteImplementations[]` details for completion, then re-run quality-fixer. `blocked` → see quality-fixer blocked handling below | On stub_detected: re-invoke task-executor. 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: pass requiredFixes back to task-executor |
@@ -292,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`, `dataModel`, and `dataTransformationPipelines` to inform the Existing Codebase Analysis and Verification Strategy sections.
+   **Pass to technical-designer**: codebase-analyzer JSON output as additional context in the Design Doc creation prompt. The designer uses `focusAreas`, `dataModel`, `dataTransformationPipelines`, and `qualityAssurance` to inform the Existing Codebase Analysis, Verification Strategy, and Quality Assurance Mechanisms sections.
 
    #### code-verifier → document-reviewer (Design Doc review)
 

package/.claude/skills-en/technical-spec/SKILL.md

@@ -54,6 +54,16 @@ Use the appropriate run command based on the `packageManager` field in package.j
 - `test:safe` - Safe test execution (with auto cleanup)
 - `cleanup:processes` - Cleanup Vitest processes
 
+### Quality Assurance Mechanism Awareness
+
+Before executing quality checks, identify what quality mechanisms exist for the change area:
+- Primary detection: inspect the change area's file types, project manifest, and configuration to identify applicable quality tools
+  - Check CI pipeline definitions for checks that cover the affected paths
+  - Check for domain-specific linter or validator configurations (e.g., schema validators, API spec validators, configuration file linters)
+  - Check for domain-specific constraints in project configuration (naming rules, length limits, format requirements)
+- Supplementary hint: IF task file specifies Quality Assurance Mechanisms → use them as additional hints for which domain-specific checks to look for
+- Include discovered domain-specific checks alongside standard quality phases below
+
 ### Quality Check Requirements
 
 Quality checks are mandatory upon implementation completion:

package/.claude/skills-ja/coding-standards/SKILL.md

@@ -68,6 +68,22 @@ Martin Fowler「Refactoring」に基づく重複コードの扱い方：
 - 共通化により可読性が著しく低下
 - テストコード内の簡単なヘルパー
 
+## 参照の代表性
+
+**失敗パターン**: 近隣2-3ファイルのパターンや依存バージョンをリポジトリ全体での使用状況を確認せずに採用すると、古いパターン、バージョン不一致、アーキテクチャ不整合が発生する。
+
+### 採用前の確認
+既存コードからパターン、API、依存を採用する場合:
+- **IF** 参照が近隣2-3ファイルのみ → **THEN** Grepでリポジトリ全体を検索し、異なるディレクトリの3ファイル以上で同じパターンが使われている場合に採用可能
+- **IF** Grepで参照元以外に1-2件のみ検出 → **THEN** それが正規の実装かレガシーの残存か調査してから採用を判断
+- **IF** Grepで参照元以外に0件 → **THEN** ローカル規約として扱い、明示的な理由がある場合のみ採用（例: 周辺コードとの整合性、破壊的変更の回避）
+- **IF** リポジトリ内に複数のアプローチが共存 → **THEN** 多数派パターン（最多ファイル数）を特定して採用。少数派を選ぶ場合は理由を明記
+- **IF** 外部依存（ライブラリ、プラグイン、SDK）を採用 → **THEN** 同じ依存のリポジトリ全体での使用分布を確認。リポジトリの状態だけでは適切なバージョンが判断できない場合はエスカレーション
+- **IF** 既存パターンに従う → **THEN** 代替が存在する場合はその理由を明記（例: 周辺コードとの整合性、破壊的変更の回避、統一的なアップデートを予定）
+
+### 原則
+近隣コードは調査の起点。採用の根拠にするにはリポジトリ全体での使用状況（異なるディレクトリの3ファイル以上）を確認すること。
+
 ## よくある失敗パターンと回避方法
 
 ### パターン1: エラー修正の連鎖
@@ -93,14 +109,15 @@ Martin Fowler「Refactoring」に基づく重複コードの扱い方：
 - 確実性lowの場合、最初に最小限の動作確認コードを作成
 
 ### パターン5: 既存コード調査不足
-**症状**: 重複実装、アーキテクチャ不整合、結合時の障害
-**原因**: 実装前の既存コード理解不足
+**症状**: 重複実装、アーキテクチャ不整合、結合時の障害、古いパターンの採用
+**原因**: 実装前の既存コード理解不足、近隣ファイルのみ参照し代表性を確認していない
 **回避方法**:
 - 実装前に類似機能の存在を必ず検索（同じドメイン、責務、設定パターンをキーワードに）
 - 類似機能を発見 → その実装を使用する（新規実装は行わない）
 - 類似機能が技術的負債 → ADRで改善提案を作成してから実装
 - 類似機能が存在しない → 既存の設計思想に沿って新規実装
 - すべての判断と根拠をDesign Docの「既存コードベース分析」セクションに記録
+- **参照の代表性チェック**: 上記「参照の代表性」セクションのIF-THEN閾値を参照
 
 ## デバッグ手法
 

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

@@ -52,6 +52,12 @@ unknowns:
 - [基準/規約] `[explicit]` — 出典: [設定ファイル / ルールファイル / ドキュメントパス]
 - [観察されたパターン] `[implicit]` — 根拠: [ファイルパス] — 確認: [済/未]
 
+#### 品質保証メカニズム
+変更対象領域で品質がどのように担保されているか。各項目は adopted（実装時に適用）または noted（観察されたが不採用、理由付き）のいずれか。
+
+- [ ] [ツール/チェック名] — 検証内容: [何を担保するか] — 設定: [パス] — カバー範囲: [ファイルパスまたはディレクトリプレフィックス、もしくは "project-wide"] — 種別: `executable_check` — ステータス: `adopted` / `noted (理由)`
+- [ ] [ドメイン固有の制約] — 検証内容: [何を担保するか] — 出典: [パス] — カバー範囲: [ファイルパスまたはディレクトリプレフィックス、もしくは "project-wide"] — 種別: `passive_constraint` — ステータス: `adopted` / `noted (理由)`
+
 ### 解決すべき課題
 
 [この機能が解決しようとする具体的な問題や課題]

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

@@ -24,6 +24,15 @@
 - **成功基準**: [Design Docから抽出]
 - **失敗時の対応**: [Design Docから抽出]
 
+## 品質保証メカニズム（Design Docより）
+
+変更対象領域で採用された品質ゲート。本計画の各タスクはこれらのメカニズムを満たす必要がある。
+
+| メカニズム | 検証内容 | 設定/出典 | カバー範囲 | 種別 |
+|-----------|---------|----------|-----------|------|
+| [ツール/チェック名] | [何を担保するか] | [path/to/config] | [ファイルパスまたはディレクトリプレフィックス、もしくは "project-wide"] | executable_check |
+| [ドメイン固有の制約] | [何を担保するか] | [path/to/source] | [ファイルパスまたはディレクトリプレフィックス、もしくは "project-wide"] | passive_constraint |
+
 ## 設計-計画トレーサビリティ
 
 Design Docの各技術要件をカバーするタスクへのマッピング。抽出した項目ごとに1行。各行には対応タスクが少なくとも1つ必要。タスクがない場合は明示的なギャップ理由が必要。

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

@@ -33,6 +33,10 @@
 - [ ] コードを改善（テストはパス状態を維持）
 - [ ] 追加したテストが引き続きパスすることを確認
 
+## 品質保証メカニズム
+（作業計画書ヘッダーより — このタスクの対象ファイルに該当するメカニズム）
+- [ツール/チェック名] — 検証内容: [何を担保するか] — 設定/出典: [パス] — 種別: `executable_check` | `passive_constraint`
+
 ## 動作検証方法
 （作業計画書の検証戦略から導出）
 - **検証手法**: [何をどう検証するか — 例: 「新実装の出力をsrc/legacy/order_calcの既存実装と比較」「エンドポイントをテストDBに対して実行しレスポンスがコントラクトに一致することを確認」]

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

@@ -129,10 +129,10 @@ description: サブエージェントのタスク分担と連携を調整。規
 | Agent | 主要フィールド | 判断ロジック |
 |-------|---------------|-------------|
 | requirement-analyzer | scale, confidence, adrRequired, crossLayerScope, scopeDependencies, questions | scaleでフローを選択。adrRequiredでADRステップ要否を判断 |
-| codebase-analyzer | analysisScope.categoriesDetected, dataModel.detected, focusAreas[], existingElements count, limitations | focusAreasをtechnical-designerにコンテキストとして渡す |
+| codebase-analyzer | analysisScope.categoriesDetected, dataModel.detected, qualityAssurance (mechanisms[], domainConstraints[]), focusAreas[], existingElements count, limitations | focusAreasをtechnical-designerにコンテキストとして渡す |
 | 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 | status (escalation_needed/completed), escalation_type, testsAdded, requiresTestReview | escalation_needed時: escalation_type別に対応（design_compliance_violation, similar_function_found, similar_component_found, investigation_target_not_found, out_of_scope_file） |
-| quality-fixer | status (approved/stub_detected/blocked), reason, blockingIssues[], missingPrerequisites[] | approved: コミット可。stub_detected: スタブ実装を検出、task-executorに差し戻して本実装を完了させる。blocked: 下記quality-fixer blockedハンドリング参照 |
+| task-executor | status (escalation_needed/completed), escalation_type (design_compliance_violation/similar_function_found/similar_component_found/investigation_target_not_found/out_of_scope_file/dependency_version_uncertain), testsAdded, requiresTestReview | escalation_needed時: escalation_type別に対応 |
+| quality-fixer | 入力: `task_file`（現在のタスクファイルパス — オーケストレーションフローでは常に渡す）。Status: approved/stub_detected/blocked。`stub_detected` → task-executorに`incompleteImplementations[]`の詳細を添えて差し戻し、本実装完了後にquality-fixerを再実行。`blocked` → 下記quality-fixer blockedハンドリング参照 | stub_detected: task-executorを再実行。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時: requiredFixesをtask-executorに戻す |
@@ -288,7 +288,7 @@ requirement-analyzerが複数レイヤー（backend + frontend）にまたがる
    #### codebase-analyzer → technical-designer
 
    **codebase-analyzerへの入力**: 要件分析JSON出力、PRDパス（存在する場合）、元のユーザー要件
-   **technical-designerへの入力**: codebase-analyzerのJSON出力をDesign Doc作成プロンプトの追加コンテキストとして渡す。technical-designerは`focusAreas`、`dataModel`、`dataTransformationPipelines`を「既存コードベース分析」セクションおよび「検証戦略」セクションに反映する。
+   **technical-designerへの入力**: codebase-analyzerのJSON出力をDesign Doc作成プロンプトの追加コンテキストとして渡す。technical-designerは`focusAreas`、`dataModel`、`dataTransformationPipelines`、`qualityAssurance`を「既存コードベース分析」「検証戦略」「品質保証メカニズム」の各セクションに反映する。
 
    #### code-verifier → document-reviewer（Design Docレビュー）
 

package/.claude/skills-ja/technical-spec/SKILL.md

@@ -54,6 +54,16 @@ package.jsonの`packageManager`フィールドに応じた実行コマンドを
 - `test:safe` - 安全なテスト実行（自動クリーンアップ付き）
 - `cleanup:processes` - Vitestプロセスのクリーンアップ
 
+### 品質保証メカニズムの認識
+
+品質チェック実行前に、変更対象領域にどのような品質メカニズムが存在するかを特定する:
+- 一次検出: 変更対象のファイル種別、プロジェクトマニフェスト、設定から適用可能な品質ツールを特定
+  - 影響パスをカバーするCIパイプライン定義を確認
+  - ドメイン固有のlinterやバリデータ設定（スキーマバリデータ、API specバリデータ、設定ファイルリンター等）を確認
+  - プロジェクト設定におけるドメイン固有の制約（命名規約、文字数制限、フォーマット要件）を確認
+- 補助ヒント: タスクファイルに品質保証メカニズムが記載されている場合 → どのドメイン固有チェックを探すべきかの追加ヒントとして使用
+- 検出したドメイン固有チェックを以下の標準品質フェーズに併せて実行
+
 ### 品質チェック要件
 
 品質チェックは実装完了時に必須：

package/CHANGELOG.md

@@ -5,6 +5,21 @@ 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.20.7] - 2026-04-12
+
+### Added
+
+- **codebase-analyzer: Quality assurance mechanism discovery** (agents) — New Step 4 item identifies linters, CI checks, schema validators, and domain-specific constraints (naming conventions, length limits, format requirements) covering affected files. New `qualityAssurance` output section with `mechanisms[]` and `domainConstraints[]`
+- **technical-designer: QA mechanism identification in Standards Gate** (agents) — New step evaluates discovered mechanisms as `adopted` (enforced during implementation) or `noted` (observed, not adopted with reason). Recorded in Design Doc "Quality Assurance Mechanisms" section
+- **work-planner: QA mechanism extraction and propagation** (agents) — Extracts adopted mechanisms from Design Doc and includes them in work plan header for downstream task reference
+- **task-decomposer: File-coverage-based mechanism propagation** (agents) — Deterministic rule matches mechanisms to tasks by file path overlap (exact match or directory prefix). Project-wide mechanisms included in every task
+- **quality-fixer: Task file input and mechanism-aware detection** (agents) — New `task_file` optional input parameter. Supplementary detection reads task file QA mechanisms, splits by type: `executable_check` added to command list, `passive_constraint` verified via Grep/file inspection after quality phases. New `taskFileMechanisms` output field. Applied to both quality-fixer and quality-fixer-frontend
+- **task-executor: Reference Representativeness check** (agents) — Per-adoption verification with concrete thresholds (≥3 files across different directories = representative). New `dependency_version_uncertain` escalation type when repository-wide verification is insufficient
+- **coding-standards: Reference Representativeness section** (skills) — IF-THEN criteria for verifying patterns, APIs, and dependencies before adoption. Failure mode documented. Pattern 5 extended with representativeness check reference
+- **technical-spec: Quality Assurance Mechanism Awareness** (skills) — New section before Quality Check Requirements for identifying domain-specific quality mechanisms before executing standard phases
+- **Documentation templates: QA Mechanisms sections** (skills) — Design template, plan template, and task template extended with Quality Assurance Mechanisms sections. Mechanism type (`executable_check` / `passive_constraint`) explicitly distinguished
+- **Orchestration: task_file passing and updated response specs** (commands/skills) — build, front-build, implement commands always pass task file path to quality-fixer. Orchestration guide updated with `qualityAssurance` in codebase-analyzer handoff, `dependency_version_uncertain` escalation type, and `task_file` input documentation
+
 ## [1.20.6] - 2026-04-10
 
 ### Added

package/package.json

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