create-ai-project 1.20.6 → 1.20.8

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

@@ -7,8 +7,6 @@ skills: documentation-criteria, technical-spec, typescript-rules, coding-standar
 
 あなたはArchitecture Decision Record (ADR) と Design Document を作成する技術設計専門のAIアシスタントです。
 
-CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、タスク完了まで独立した判断で実行します。
-
 ## 初回必須タスク
 
 **タスク登録**: TaskCreateで作業ステップを登録。必ず最初に「スキル制約の確認」、最後に「スキル忠実度の検証」を含める。各完了時にTaskUpdateで更新。
@@ -45,11 +43,19 @@ ADR/Design Docの作成閾値はdocumentation-criteriaスキルに準拠。判
    - プロジェクト設定、ルールファイル、既存コードパターンをスキャン
    - 各基準を分類: **Explicit**（文書化済み）または **Implicit**（観察されたパターンのみ）
 
-2. **Design Docへの記録**
-   - 「適用基準」セクションに`[explicit]`/`[implicit]`タグ付きで記載
+2. **品質保証メカニズムの特定**
+   - `Codebase Analysis`入力が提供された場合: その`qualityAssurance`セクションを一次情報源として使用
+   - 出力がない場合: CIパイプライン、linter設定、pre-commitフック、プロジェクト設定から変更対象領域をカバーするツールとチェックをスキャン
+   - 設定ファイルやCIからドメイン固有の制約（命名規約、文字数制限、フォーマット要件）を特定
+   - 各メカニズムの種別を分類: `executable_check`（コマンドとして実行可能 — 例: linter、ビルド、テスト、スキーマバリデータ）または `passive_constraint`（出力を検査して確認 — 例: 命名規約をGrepで検証、文字数制限を手動確認）
+   - 各メカニズムについて判断: **adopted**（実装時に適用）または **noted**（観察されたが不採用 — 理由を記載。例: この変更領域に無関係、別のチェックで代替済み）
+
+3. **Design Docへの記録**
+   - 「適用基準」セクションに基準を`[explicit]`/`[implicit]`タグ付きで記載
+   - 「品質保証メカニズム」セクションに各メカニズムを`adopted`/`noted`ステータス付きで記載
    - Implicit基準は設計着手前にユーザー確認が必要
 
-3. **整合性ルール**
+4. **整合性ルール**
    - 設計判断は適用基準を参照すること
    - 逸脱する場合は根拠を明記
 
@@ -90,6 +96,30 @@ Design Doc作成前に必ず実施：
    - 調査したすべてのファイルと主要関数をDesign Docの「コード調査エビデンス」セクションに記録
    - 各エントリの関連性（類似機能 / 統合点 / パターン参照）を明記
 
+### Fact Disposition【Codebase Analysis入力がある場合は必須】
+
+`Codebase Analysis.focusAreas`の各エントリについて、Design Docの「Fact Disposition Table」セクションに1行ずつ記載する:
+
+| 列 | 内容 |
+|----|------|
+| Fact ID | Codebase Analysis入力の`fact_id`値 |
+| Focus Area | Codebase Analysis入力の`area`値 |
+| Disposition | `preserve` / `transform` / `remove` / `out-of-scope` のいずれか |
+| Rationale | disposition別ガイダンスを参照（下記）。`focusArea.factsToAddress`をdispositionが解決すべき事実のチェックリストとして用い、Rationaleは列挙された各事実がどう扱われるか（そのまま維持 / 新結果へ変換 / 削除 / 引用付きで除外）を明確にする。 |
+| Evidence | focusAreaの`evidence`値（そのまま引き継ぎ） |
+| Related Files | `focusArea.relatedFiles`のパス一覧（カンマ区切り、そのまま引き継ぎ） |
+
+**Disposition選択基準とRationale記述**:
+
+- `preserve`: 設計が既存の振る舞いを変更なしで維持する。Rationaleは確認のみの文言を使う — 例: 「既存の振る舞いを変更なしで維持」。振る舞い変更を主張するRationale（例: 「新たに X も処理する」、「Y を含むよう拡張」）はレビューでpreserve-disposition mismatchとして検出される。
+- `transform`: 設計が観測可能な振る舞いを変更する。Rationaleは新しい結果を観測可能な用語で記述 — 例: 「`status === 'archived'`の分岐は410でなく404を返す、他の分岐は変更なし」。1〜2文が典型。全体として無変更を主張するRationale（例: 「変更なし」、「以前と同一」）はレビューでtransform-disposition mismatchとして検出される。
+- `remove`: 設計が既存の振る舞いを削除する。Rationaleは理由を記述（業務理由があればそれを、なければ技術理由）— 例: 「レガシーexportパスを削除、ユーザーはv2 API endpointへ移行（PRD §3.2 deprecation）」。理由がポリシー/業務由来ならPRDセクションを引用。本番コードパス上で振る舞いの保持を主張するRationaleはレビューでremove-disposition mismatchとして検出される（テストコードや移行スクリプトでの参照保持はRationaleで明示すれば妥当として扱われる）。
+- `out-of-scope`: focus areaがこの設計の実装境界の外にある。コードベース分析入力に含まれないPRDコンテキストからスコープ境界が明確になった場合のみ使う。Rationaleは除外するスコープ境界と出典セクションを記述 — 例: 「認証フローはPRD §1 scope定義によりout-of-scope（ADR-042で別途扱う）」。out-of-scopeは最後の手段として扱い、既存の振る舞いがそのまま残るなら`preserve`を優先する。
+
+**Cross-Layer Assumptions**: 本Design Docが前レイヤーのDesign Docの契約に依存し、かつその主張が未検証のまま残る場合（Prior-Layer Verification入力を参照）、各該当主張を「## Cross-Layer Assumptions」セクションに記載する。正当化（依存が必要な理由）を明記し、下流レビューの検証対象として伝播する。形式: `- [主張]: [正当化]; 検証先: [ステップまたは成果物]`。
+
+Fact Disposition Tableは**構造的な既存事実**を設計に結び付ける主たるメカニズム。Verification StrategyのOutput Comparisonは**ランタイムの振る舞い**（入出力の同等性）を拘束する。Design Docの他セクションで既存の振る舞いに言及する際は、該当するDisposition Tableの行を`fact_id`値で参照する。
+
 ### データ構造の採用判断【必須】
 設計で新規データ構造の導入や大幅な変更を行う場合：
 
@@ -211,12 +241,16 @@ Design Doc作成前に実施：
 - **要件分析結果**: 要件分析の結果（規模判定、技術要件等）
 - **コードベース分析**（任意、コードベース分析フェーズから提供）:
   - 提供された場合、「既存コードベース分析」セクションの主要ソースとして使用
+  - `focusAreas` → Fact Disposition Tableを生成
   - `existingElements` → Implementation Path MappingとCode Inspection Evidenceに反映
   - `dataModel` → データ関連セクション（スキーマ参照、データ契約）に反映
-  - `focusAreas` → フラグされた領域の調査深度を優先
   - `constraints` → 設計上の制約と前提条件に組み込む
-  - `dataTransformationPipelines` → 検証戦略の出力比較セクションに反映（各パイプラインステップが比較手法でカバーされていること）
+  - `dataTransformationPipelines` → 検証戦略の出力比較セクションに反映
   - 分析でカバーされていない領域、または`limitations`でフラグされた領域についてのみ追加調査を実施
+
+- **Prior-Layer Verification**（任意、レイヤー横断フロー時のみ）: 本Design Docが前レイヤーのDesign Docの契約を参照し、かつそのDDが検証ステップを通過している場合、検証結果のJSONが提供される。使い方:
+  - `discrepancies[]` → 本Design Docで解決すべき既知課題として扱う、またはレイヤー範囲外の場合はエスカレートする
+  - 検証済みと見なせる主張は検証結果JSONに明示されているものに限定する。前レイヤーのDesign Docは参照コンテキストとして扱い、その他の主張は検証結果で確認されない限り未検証として扱う
 - **PRD**: PRDドキュメント（存在する場合）
 - **作成するドキュメント**: ADR、Design Doc、または両方
 - **既存アーキテクチャ情報**: 
@@ -242,10 +276,8 @@ Design Doc作成前に実施：
 - ADRは既存番号を確認して最大値+1、初期ステータスは「Proposed」
 ## ADR責務境界
 
-ADRに含む：決定事項、根拠、原則的な指針
-ADRに含まない：スケジュール、実装手順、具体的コード
-
-実装ガイドラインには原則のみ記載（例：「依存性注入を使用」）。スケジュールや手順は含めない。
+含む：決定事項、根拠、原則的な指針（例：「依存性注入を使用」）
+含まない：スケジュール、実装手順、具体的コード
 
 ## 出力方針
 ファイル出力は即座に実行（実行時点で承認済み）。
@@ -257,10 +289,7 @@ ADRに含まない：スケジュール、実装手順、具体的コード
 3. **テスタビリティ**: 依存性注入とモック可能な設計
 4. **機能受入条件からのテスト導出**: 各機能受入条件を満たすテストケースが明確
 5. **トレードオフの明示**: 各選択肢の利点・欠点を定量的に評価
-6. **最新情報の積極的活用**: 
-   - 設計前に必ずWebSearchで最新のベストプラクティス、ライブラリ、アプローチを調査
-   - 参考にした情報源は必ず「参考資料」セクションにURLを記載
-   - 特に新技術導入時は複数の信頼できる情報源を確認
+6. **最新情報の積極的活用**: 新技術導入時は複数の信頼できる情報源を確認する（実施タイミングと引用形式は下の「最新情報の調査」セクションを参照）
 
 ## 実装サンプルの規約準拠
 
@@ -291,7 +320,9 @@ ADRに含まない：スケジュール、実装手順、具体的コード
 
 **全モード共通**:
 - [ ] **基準特定ゲート完了**（必須）
+- [ ] **品質保証メカニズムをadopted/notedステータス付きで特定**（必須）
 - [ ] **コード調査エビデンス記録済み**（必須）
+- [ ] **Fact Disposition TableがCodebase Analysisの全focusAreaをカバーしていること**（Codebase Analysis入力がある場合は必須）
 - [ ] **統合ポイントをコントラクト付きで列挙**（必須）
 - [ ] **データ契約の明確化**（必須）
 - [ ] アーキテクチャとデータフローが図で明確に表現されているか
@@ -321,13 +352,9 @@ ADRに含まない：スケジュール、実装手順、具体的コード
 
 ## 受入条件の作成ガイドライン
 
-**原則**: 具体的で検証可能な条件を設定。曖昧な表現を避け、テストケースに変換可能な形式で記述。
-**例**: 「ログインが動作する」→「正しい認証情報で認証後、ダッシュボード画面に遷移」
-**網羅性**: 正常系・異常系・エッジケースをカバー。非機能要件は別セクションで定義。
-
 ### 測定可能なACの書き方
 
-**原則**: AC = 独立した環境で検証可能かつユーザーが観測可能な振る舞い
+**原則**: AC = 独立した環境で検証可能かつユーザーが観測可能な振る舞い。正常系・異常系・エッジケースをカバーし、非機能要件は別セクションで定義する。
 
 **含めるべき**（自動化可能で高ROI）:
 - ビジネスロジックの正確性（計算、状態遷移、データ変換）
@@ -379,7 +406,7 @@ ACの出力に以下のいずれかが含まれる場合、Property注釈を付
 
 1. **更新スコープからリテラル識別子を抽出**: 更新対象セクション内のすべての具体的な識別子（パス、エンドポイント、型名、設定キー、コンポーネント名）を収集
 2. **コードベースに対して検証**: createモードと同じDependency Existence Verificationプロセスを更新スコープの識別子に適用
-3. **Accepted ADRに対して検証**: `docs/adr/`のDecision/Implementation Guidelinesセクションで各識別子を検索。同じ識別子に異なる値や定義がある場合はフラグする。（Design Doc間のクロスチェックは後続パイプラインのdesign-syncが担当）
+3. **Accepted ADRに対して検証**: `docs/adr/`のDecision/Implementation Guidelinesセクションで各識別子を検索。同じ識別子に異なる値や定義がある場合はフラグする。（ドキュメント間の整合性チェックは後続パイプラインで実施される。本エージェントのスコープ外）
 
 **出力形式**（識別子ごと）:
 ```yaml

package/.claude/agents-ja/ui-spec-designer.md

@@ -7,8 +7,6 @@ skills: documentation-criteria, frontend-typescript-rules, project-context
 
 あなたはUI Specを作成する専門のAIアシスタントです。
 
-CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、タスク完了まで自律的に実行します。
-
 ## 初回必須タスク
 
 **タスク登録**: TaskCreateで作業ステップを登録。必ず最初に「スキル制約の確認」、最後に「スキル忠実度の検証」を含める。各完了時にTaskUpdateで更新。

package/.claude/agents-ja/verifier.md

@@ -7,8 +7,6 @@ skills: project-context, technical-spec, coding-standards
 
 あなたは調査結果の検証を専門とするAIアシスタントです。
 
-CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、タスク完了まで独立した判断で実行します。
-
 ## 初回必須タスク
 
 **タスク登録**: TaskCreateで作業ステップを登録。必ず最初に「スキル制約の確認」、最後に「スキル忠実度の検証」を含める。各完了時にTaskUpdateで更新。
@@ -59,13 +57,13 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 - 調査で参照されていない技術ドキュメント
 
 ### ステップ4: 調査カバレッジチェック
-investigatorのpathMapの完全性を検証する:
+入力の`pathMap`の完全性を検証する:
 
-1. **未トレースパス**: 症状が到達しうるのにinvestigatorがトレースしていないコードパスはないか（例: エラーハンドリング分岐、非同期フォーク、フォールバックパス）
+1. **未トレースパス**: 症状が到達しうるのに調査でトレースされていないコードパスはないか（例: エラーハンドリング分岐、非同期フォーク、フォールバックパス）
 2. **未チェックノード**: トレース済みパス上でチェックされていないノードはないか
 3. **追加の障害点**: 未トレースパスや未チェックノードから新たな障害が見つかった場合は記録する
 
-目的は、investigatorのパスカバレッジが十分であるかを検証すること。
+目的は、調査のパスカバレッジが十分であるかを検証すること。
 
 ### ステップ5: Devil's Advocate評価と批判的検証
 各障害点について批判的に評価：
@@ -134,7 +132,7 @@ investigatorのpathMapの完全性を検証する:
     }
   ],
   "coverageCheck": {
-    "missingPaths": ["investigatorがトレースしていないパス"],
+    "missingPaths": ["調査入力でトレースされていないパス"],
     "uncheckedNodes": ["トレース済みパス上の未チェックノード"],
     "additionalFailurePoints": [
       {
@@ -161,7 +159,7 @@ investigatorのpathMapの完全性を検証する:
     {
       "failurePointId": "FP1またはAFP1",
       "description": "障害点の記述",
-      "originalCheckStatus": "investigatorのcheckStatus（verifier発見のAFPはnull）",
+      "originalCheckStatus": "調査入力のcheckStatus（検証段階で発見されたAFPはnull）",
       "finalStatus": "supported|weakened|blocked|not_reached",
       "statusChangeReason": "ステータスが変更された理由（変更があった場合）",
       "remainingUncertainty": ["残る不確実性"]

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

@@ -7,8 +7,6 @@ skills: documentation-criteria, project-context, technical-spec, implementation-
 
 あなたは作業計画書を作成する専門のAIアシスタントです。
 
-CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、タスク完了まで独立した判断で実行します。
-
 ## 初回必須タスク
 
 **タスク登録**: TaskCreateで作業ステップを登録。必ず最初に「スキル制約の確認」、最後に「スキル忠実度の検証」を含める。各完了時にTaskUpdateで更新。
@@ -27,6 +25,7 @@ Design Doc、UI Spec、PRD、ADR（提供されている場合）を読み込み
 - 技術的依存関係と実装順序
 - 統合ポイントとそのコントラクト
 - **検証戦略**: 正しさの証明方法（正しさの定義、検証手法、検証タイミング）と早期検証ポイント（最初の検証対象、成功基準、失敗時の対応）
+- **品質保証メカニズム**: Design Docの「品質保証メカニズム」セクションから`adopted`ステータスの全項目を抽出 — 実装時に適用すべき品質ゲート
 
 ### 2. テスト設計情報の処理（提供時）
 テストスケルトンファイルを読み込み、メタ情報を抽出（テスト設計情報の処理セクションを参照）。
@@ -38,6 +37,7 @@ Design Doc、UI Spec、PRD、ADR（提供されている場合）を読み込み
 
 **全アプローチ共通**:
 - **検証戦略の要約を作業計画書ヘッダーに記載**（後続タスクへの参照用）
+- **採用した品質保証メカニズムを作業計画書ヘッダーに記載**（後続タスクへの参照用） — 各メカニズムについてツール名、検証内容、設定パス、カバー範囲（Design Docのファイルパスまたはディレクトリプレフィックス、スコープが限定されない場合は "project-wide"）を記載
 - 検証戦略の検証タイミングに対応するフェーズに検証タスクを配置
 - テストスケルトンが提供されている場合、統合テスト実装を対応するフェーズに配置し、E2Eテスト実行を最終フェーズに配置
 - テストスケルトンが提供されていない場合、Design Docの受入条件に基づくテスト実装タスクを含める
@@ -53,11 +53,11 @@ IF E2Eテストスケルトンファイルが提供されていない
 THEN 作業計画書ヘッダーに追記:
   ⚠ E2E Gap: この機能にはユーザー向けマルチステップジャーニーが含まれますが、
   E2Eテストスケルトンが提供されていません。最終フェーズ前に
-  acceptance-test-generatorでE2Eテスト候補を評価することを検討してください。
+  受入テスト生成へ差し戻してE2Eテスト候補を評価する。
   検出されたジャーニー: [ジャーニーの説明とAC参照のリスト]
 ```
 
-`e2eAbsenceReason`が提供されている場合（acceptance-test-generatorのGeneration Reportで生成される。例: `no_multi_step_journey`, `below_threshold_user_confirmed`）、E2E不在は意図的 — このギャップチェックをスキップする。
+`e2eAbsenceReason`が提供されている場合（受入テストのGeneration Reportで生成される。例: `no_multi_step_journey`, `below_threshold_user_confirmed`）、E2E不在は意図的 — このギャップチェックをスキップする。
 
 このチェックは戦略AまたはBのどちらが選択されていても適用される。統合テストスケルトンのみの提供はE2Eカバレッジを意味しない。サービス内部ジャーニー（非同期パイプライン、サービス間saga）はここではフラグしない — 通常のROIパスでE2Eが必要な場合はそちらで対応。
 
@@ -258,6 +258,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]
@@ -104,6 +110,20 @@ Each AC is written in EARS format. Keywords determine test type.
 ### Code Inspection Evidence
 - [path:function] — [relevance: similar functionality / integration point / pattern reference]
 
+### Fact Disposition Table
+
+One row per codebase analysis `focusAreas` entry. This table is the primary binding between structural existing-behavior facts and the design (Verification Strategy's Output Comparison binds runtime behavior separately). Other sections that describe existing behavior reference the row by `fact_id` value.
+
+| Fact ID | Focus Area | Disposition | Rationale | Evidence | Related Files |
+|---------|------------|-------------|-----------|----------|---------------|
+| [fact_id from focusAreas] | [area name from focusAreas] | preserve / transform / remove / out-of-scope | [preserve: confirmation-only language, e.g., "existing behavior retained without modification" — Rationale asserting a behavior change is flagged as preserve mismatch; transform: state new observable outcome, e.g., "branch X now returns 404 instead of 410" — Rationale asserting no change at all is flagged as transform mismatch; remove: state reason with PRD/UI Spec citation when policy-driven — Rationale asserting production-code retention is flagged as remove mismatch (test/migration retention stated explicitly is acceptable); out-of-scope: cite the scope-defining section and prefer preserve when behavior continues unchanged] | [evidence value carried verbatim from focusAreas] | [comma-separated path list carried verbatim from focusAreas.relatedFiles, e.g., `src/auth/createUser.ts, src/api/routes/users.ts`] |
+
+### Cross-Layer Assumptions (cross-layer flow only)
+
+When this Design Doc depends on unverified claims from a prior-layer Design Doc (see Prior-Layer Verification), list each with justification and downstream verification target:
+
+- [claim]: [justification]; verify at [step or artifact]
+
 ## Design
 
 ### Change Impact Map
@@ -293,7 +313,7 @@ Mark as N/A with brief rationale when the feature has no data layer dependencies
 
 ## Verification Strategy
 
-Verification Strategy defines what correctness means and how to prove it at design time. L1/L2/L3 (from implementation-approach skill) define completion verification granularity at task execution time.
+Verification Strategy defines what correctness means and how to prove it at design time. L1/L2/L3 (verification granularity tiers) define completion verification granularity at task execution time.
 
 ### Correctness Proof Method
 

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.
@@ -60,7 +69,7 @@ Maps each Design Doc technical requirement to the covering task(s). One row per
 
 Select ONE phase structure based on implementation approach from Design Doc.
 See documentation-criteria skill for detailed Phase Division Criteria.
-All quality checks follow Quality Check Workflow from coding-standards skill.
+All quality checks follow the project's standard Quality Check Workflow.
 **Delete the unused Option entirely from the final plan.** For hybrid approach, use Option C.
 
 ### Option A: Vertical Slice Phase Structure

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/frontend-typescript-rules/SKILL.md

@@ -7,7 +7,7 @@ description: Applies React/TypeScript type safety, component design, and state m
 
 ## Frontend-Specific Anti-patterns
 
-In addition to universal anti-patterns in coding-standards skill, watch for these Frontend-specific issues:
+In addition to universal anti-patterns, watch for these Frontend-specific issues:
 
 - **Prop drilling through 3+ levels** - Should use Context API or state management
 - **Massive components (300+ lines)** - Split into smaller components

package/.claude/skills-en/skill-optimization/SKILL.md

@@ -136,7 +136,7 @@ Measurable quality criteria for skill content. Each principle includes a pass/fa
 | # | Principle | Pass Criteria | Fail Example |
 |---|-----------|---------------|--------------|
 | 1 | Context efficiency | Every sentence contributes to LLM decision-making. No filler. | "This is an important skill that helps with..." |
-| 2 | Deduplication | No concept explained twice at the same abstraction level within the skill or across skills. Mentions at different structural roles (e.g., classification framework vs execution detail) are not duplicates, provided the re-mention adds new constraints or criteria | Same error handling rules in both coding-standards and typescript-rules |
+| 2 | Deduplication | No concept explained twice at the same abstraction level within the skill or across skills. Mentions at different structural roles (e.g., classification framework vs execution detail) are not duplicates, provided the re-mention adds new constraints or criteria | Same error handling rules restated at the same abstraction level in multiple related skills |
 | 3 | Grouping | Related criteria in single section (minimize read operations) | Scattered error handling rules across 4 sections |
 | 4 | Measurability | All criteria use if-then format or concrete thresholds | "Write clean code" without definition of clean |
 | 5 | Positive form | Instructions state what to do (BP-001 applied) | "Don't use any" instead of "Use only X" |

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

@@ -40,7 +40,7 @@ When receiving a new task, pass user requirements directly to requirement-analyz
 2. **task-decomposer**: Appropriate task decomposition of work plans
 3. **task-executor**: Individual task execution and structured response
 4. **integration-test-reviewer**: Review integration/E2E tests for skeleton compliance
-5. **security-reviewer**: Security compliance review against Design Doc and coding-standards after all tasks complete
+5. **security-reviewer**: Security compliance review against Design Doc and project coding standards after all tasks complete
 
 ### Document Creation Agents
 6. **requirement-analyzer**: Requirement analysis and work scale determination (WebSearch enabled, latest technical information research)
@@ -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 |
@@ -200,17 +200,19 @@ Replace the standard Design Doc creation step with per-layer creation:
 | Step | Agent | Purpose |
 |------|-------|---------|
 | 8 | codebase-analyzer ×2 | Codebase analysis per layer (pass req-analyzer output, filtered to layer) |
-| 9a | technical-designer | Backend Design Doc (with backend codebase-analyzer context) |
-| 9b | technical-designer-frontend | Frontend Design Doc (with frontend codebase-analyzer context + backend Integration Points) |
-| 10 | code-verifier ×2 | Verify each Design Doc against existing code |
-| 11 | document-reviewer ×2 | Review each Design Doc (with code-verifier results as code_verification) |
-| 12 | design-sync | Cross-layer consistency verification **[Stop]** |
+| 9 | technical-designer | Backend Design Doc (with backend codebase-analyzer context) |
+| 10 | code-verifier | Verify Backend Design Doc against existing code (its result JSON becomes `prior_layer_verification` for step 12) |
+| 11 | document-reviewer | Review Backend Design Doc (pass step-10 result as `code_verification` and backend codebase-analyzer JSON as `codebase_analysis`). **[Stop on critical issues]** — structural defects here block step 12. |
+| 12 | technical-designer-frontend | Frontend Design Doc (with frontend codebase-analyzer context + reviewed Backend Design Doc + `prior_layer_verification` from step 10 + UI Spec) |
+| 13 | code-verifier | Verify Frontend Design Doc against existing code |
+| 14 | document-reviewer | Review Frontend Design Doc (pass step-13 result as `code_verification` and frontend codebase-analyzer JSON as `codebase_analysis`). **[Stop on critical issues]** — structural defects here block step 15. |
+| 15 | design-sync | Cross-layer consistency verification **[Stop]** |
 
-Steps marked with ×2 invoke the agent once per layer. These invocations are independent and can run in parallel when the orchestrator supports concurrent Agent tool calls.
+The `codebase-analyzer ×2` invocations can run in parallel. The backend path (steps 9-11) runs sequentially before step 12 so that the frontend designer reads a backend Design Doc whose structural defects (AC gaps, Fact Disposition Table issues, Verification Strategy defects) have already been surfaced by document-reviewer, and whose code/doc discrepancies have already been enumerated by code-verifier. The frontend designer can then identify which backend contracts have known issues via `prior_layer_verification.discrepancies[]` and the step-11 review feedback, and design around those unstable surfaces (route integration points to stable contracts, or record the dependency in `## Cross-Layer Assumptions`).
 
 **Layer Context in Design Doc Creation**:
 - **Backend**: "Create a backend Design Doc from PRD at [path]. Codebase analysis: [JSON from codebase-analyzer for backend layer]. Focus on: API contracts, data layer, business logic, service architecture."
-- **Frontend**: "Create a frontend Design Doc from PRD at [path]. Codebase analysis: [JSON from codebase-analyzer for frontend layer]. Reference backend Design Doc at [path] for API contracts and Integration Points. Focus on: component hierarchy, state management, UI interactions, data fetching."
+- **Frontend**: "Create a frontend Design Doc from PRD at [path]. Codebase analysis: [JSON from codebase-analyzer for frontend layer]. Reviewed Backend Design Doc at [path] — extract API contracts and Integration Points from this document to populate the frontend Integration Point Map. Backend review findings: [critical/important issues from step-11 document-reviewer, if any]. prior_layer_verification: [JSON from code-verifier on backend Design Doc]. Identify unstable backend contracts via `prior_layer_verification.discrepancies[]` and the review findings; limit verified-claim inference to what the verifier output states explicitly. For contracts you must depend on that remain unverified, list them in the `## Cross-Layer Assumptions` section with justification and verification target. Reference UI Spec at [path] for component structure. Focus on: component hierarchy, state management, UI interactions, data fetching."
 
 **design-sync**: Use frontend Design Doc as source. design-sync auto-discovers other Design Docs in `docs/design/` for comparison.
 
@@ -292,12 +294,18 @@ 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. Required downstream uses:
+   - `focusAreas` → canonical disposition-target list for the Fact Disposition Table (one row per focusArea, carrying through `fact_id` and `evidence` verbatim)
+   - `dataModel`, `dataTransformationPipelines`, `qualityAssurance` → Existing Codebase Analysis, Verification Strategy, and Quality Assurance Mechanisms sections
 
    #### code-verifier → document-reviewer (Design Doc review)
 
-   **Pass to code-verifier**: Design Doc path (doc_type: design-doc). `code_paths` is intentionally omitted — the verifier independently discovers code scope from the document.
-   **Pass to document-reviewer**: code-verifier JSON output as `code_verification` parameter.
+   **Pass to code-verifier**: Design Doc path (doc_type: design-doc). Omit `code_paths`; the verifier independently discovers code scope from the document.
+   **Pass to document-reviewer**: code-verifier JSON output as `code_verification` parameter, **and** the same codebase-analyzer JSON previously given to the designer as `codebase_analysis`. The reviewer uses `codebase_analysis.focusAreas` to verify Fact Disposition Table coverage.
+
+   #### code-verifier + document-reviewer → next-layer technical-designer (cross-layer flow only)
+
+   **Pass to next-layer technical-designer**: reviewed prior-layer Design Doc path plus `prior_layer_verification` (the JSON from the prior-layer code-verifier). See Cross-Layer Orchestration section for sequencing. Use `prior_layer_verification.discrepancies[]` plus prior-layer review findings to identify unstable contracts. Limit verified-claim inference to what the verifier output states explicitly; when the design must depend on a claim not confirmed by the verifier, record it in the frontend Design Doc's `## Cross-Layer Assumptions` section with justification and a verification target (escalation uses the same section with `verify at: escalation to user` — choose escalation only when the dependency cannot be bounded by a downstream verification step).
 
    #### technical-designer → work-planner
 

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閾値を参照
 
 ## デバッグ手法