create-ai-project 1.20.6 → 1.20.8

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 (理由)`
+
 ### 解決すべき課題
 
 [この機能が解決しようとする具体的な問題や課題]
@@ -104,6 +110,20 @@ unknowns:
 ### コード調査エビデンス
 - [パス:関数] — [関連性: 類似機能 / 統合点 / パターン参照]
 
+### Fact Disposition Table
+
+コードベース分析の`focusAreas`の各エントリに対して1行ずつ記載する。この表は**構造的な既存事実**と設計を結び付ける主たるテーブル（Verification StrategyのOutput Comparisonは**ランタイムの振る舞い**を別途拘束する）。既存の振る舞いに言及する他セクションはこの表の行を`fact_id`値で参照する。
+
+| Fact ID | Focus Area | Disposition | Rationale | Evidence | Related Files |
+|---------|------------|-------------|-----------|----------|---------------|
+| [focusAreasのfact_id] | [focusAreasのarea] | preserve / transform / remove / out-of-scope | [preserve: 確認のみの文言、例「既存の振る舞いを変更なしで維持」 — 振る舞い変更を主張するRationaleはレビューでpreserve mismatchとして検出される、transform: 新しい観測可能な結果を記述、例「分岐Xは410でなく404を返す」 — 全体として無変更を主張するRationaleはtransform mismatchとして検出される、remove: 理由を記述、ポリシー由来ならPRD/UI Specセクションを引用 — 本番コードパスでの保持を主張するRationaleはremove mismatchとして検出される（テスト/移行スクリプトでの保持を明示した場合は妥当）、out-of-scope: スコープ定義セクションを引用、既存の振る舞いがそのまま残るならpreserveを優先] | [focusAreasのevidence値をそのまま引き継ぎ] | [focusAreas.relatedFilesのパス一覧をそのまま引き継ぎ、カンマ区切り、例: `src/auth/createUser.ts, src/api/routes/users.ts`] |
+
+### Cross-Layer Assumptions（レイヤー横断フロー時のみ）
+
+本Design Docが前レイヤーのDesign Docの未検証主張に依存する場合（Prior-Layer Verification参照）、各主張に正当化と下流検証先を記載する:
+
+- [主張]: [正当化]; 検証先: [ステップまたは成果物]
+
 ## 設計
 
 ### 変更影響マップ
@@ -299,7 +319,7 @@ unknowns:
 
 ## 検証戦略
 
-設計時に「正しさとは何か」「どう証明するか」を定義する。L1/L2/L3（implementation-approachスキル）はタスク実行時の完了検証の粒度を定義する。
+設計時に「正しさとは何か」「どう証明するか」を定義する。L1/L2/L3（検証粒度の階層）はタスク実行時の完了検証の粒度を定義する。
 
 ### 正しさの証明方法
 

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つ必要。タスクがない場合は明示的なギャップ理由が必要。
@@ -60,7 +69,7 @@ Design Docの各技術要件をカバーするタスクへのマッピング。
 
 Design Docの実装アプローチに基づいてフェーズ構成をひとつ選択する。
 詳細はdocumentation-criteriaスキルのフェーズ分割基準を参照。
-全品質チェックはcoding-standardsスキルの品質チェックワークフローに従う。
+全品質チェックはプロジェクト標準の品質チェックワークフローに従う。
 **未使用のOptionは最終計画書から削除すること。** ハイブリッドの場合はOption Cを使用する。
 
 ### Option A: 垂直スライスのフェーズ構成

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/skill-optimization/SKILL.md

@@ -136,7 +136,7 @@ description: スキルファイルの品質を8つのコンテンツパターン
 | # | 原則 | 合格基準 | 不合格例 |
 |---|------|----------|----------|
 | 1 | コンテキスト効率 | 全文がLLMの判断に寄与する。冗長な記述なし | 「これは〜に役立つ重要なスキルで...」 |
-| 2 | 重複排除 | スキル内・スキル間で同じ抽象レベルにおける概念の重複説明なし。異なる構造的役割（例: 分類体系と実行詳細）での言及は、新たな制約や判断基準を伴う場合に限り重複に該当しない | coding-standardsとtypescript-rulesに同じエラーハンドリング規則 |
+| 2 | 重複排除 | スキル内・スキル間で同じ抽象レベルにおける概念の重複説明なし。異なる構造的役割（例: 分類体系と実行詳細）での言及は、新たな制約や判断基準を伴う場合に限り重複に該当しない | 関連する複数スキルで同じエラーハンドリング規則が同じ抽象レベルで繰り返される |
 | 3 | 関連内容の集約 | 関連する基準を1セクションに集約（読み込み回数最小化） | エラーハンドリング規則が4セクションに散在 |
 | 4 | 測定可能性 | 全基準がif-then形式または具体的閾値 | 「きれいなコードを書く」の定義なし |
 | 5 | 肯定形 | 指示は「何をするか」を記述（BP-001適用済み） | 「一切使わないこと」→「Xのみ使用する」 |

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

@@ -40,7 +40,7 @@ description: サブエージェントのタスク分担と連携を調整。規
 2. **task-decomposer**: 作業計画書の適切なタスク分解
 3. **task-executor**: 個別タスクの実行と構造化レスポンス
 4. **integration-test-reviewer**: 統合テスト/E2Eテストのスケルトン準拠レビュー
-5. **security-reviewer**: 全タスク完了後のDesign Docおよびcoding-standardsに対するセキュリティ準拠レビュー
+5. **security-reviewer**: 全タスク完了後のDesign Docおよびプロジェクトのコーディング規約に対するセキュリティ準拠レビュー
 
 ### ドキュメント作成エージェント
 6. **requirement-analyzer**: 要件分析と作業規模判定（WebSearch対応、最新技術情報の調査）
@@ -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に戻す |
@@ -195,17 +195,19 @@ requirement-analyzerが複数レイヤー（backend + frontend）にまたがる
 | ステップ | エージェント | 目的 |
 |---------|-----------|------|
 | 8 | codebase-analyzer ×2 | レイヤー別コードベース分析（要件分析結果をレイヤーでフィルタして入力） |
-| 9a | technical-designer | バックエンドDesign Doc（バックエンドcodebase-analyzerコンテキスト付き） |
-| 9b | technical-designer-frontend | フロントエンドDesign Doc（フロントエンドcodebase-analyzerコンテキスト + バックエンドIntegration Points付き） |
-| 10 | code-verifier ×2 | 各Design Docを既存コードに対して検証 |
-| 11 | document-reviewer ×2 | 各Design Docをレビュー（code-verifier結果をcode_verificationとして入力） |
-| 12 | design-sync | レイヤー間整合性検証 **[停止]** |
+| 9 | technical-designer | バックエンドDesign Doc（バックエンドcodebase-analyzerコンテキスト付き） |
+| 10 | code-verifier | バックエンドDesign Docを既存コードに対して検証（結果JSONはステップ12に`prior_layer_verification`として渡す） |
+| 11 | document-reviewer | バックエンドDesign Docをレビュー（ステップ10の結果を`code_verification`、バックエンドcodebase-analyzer JSONを`codebase_analysis`として入力）**[criticalで停止]** — ここで構造的欠陥が出た場合はステップ12に進めない |
+| 12 | technical-designer-frontend | フロントエンドDesign Doc（フロントエンドcodebase-analyzerコンテキスト + レビュー済みバックエンドDesign Doc + ステップ10の`prior_layer_verification` + UI Spec付き） |
+| 13 | code-verifier | フロントエンドDesign Docを既存コードに対して検証 |
+| 14 | document-reviewer | フロントエンドDesign Docをレビュー（ステップ13の結果を`code_verification`、フロントエンドcodebase-analyzer JSONを`codebase_analysis`として入力）**[criticalで停止]** — ここで構造的欠陥が出た場合はステップ15に進めない |
+| 15 | design-sync | レイヤー間整合性検証 **[停止]** |
 
-×2のステップはレイヤー毎に1回ずつ呼び出す。各呼び出しは独立しており、オーケストレーターが並列Agent呼び出しをサポートする場合は並列実行可能。
+`codebase-analyzer ×2` の呼び出しは並列実行可能。バックエンド経路（ステップ9〜11）はステップ12の前に直列で完了させる。これによりフロントエンドdesignerは、document-reviewerによって構造的欠陥（AC欠落、Fact Disposition Tableの不備、Verification Strategy欠落）が既に検出され、code-verifierによってコード/ドキュメント不整合が既に列挙された状態のバックエンドDesign Docを読む。フロントエンドdesignerは `prior_layer_verification.discrepancies[]` とステップ11のレビュー指摘から、既知の問題を持つバックエンド契約を識別し、不安定な契約面を迂回した設計ができる（統合点を安定した契約へ切り替える、または依存を「## Cross-Layer Assumptions」に記録する）。
 
 **Design Doc作成時のレイヤーコンテキスト指定**:
 - **バックエンド**: 「PRD [パス] からバックエンドDesign Docを作成。コードベース分析: [バックエンドレイヤー用codebase-analyzerのJSON]。対象: APIコントラクト、データ層、ビジネスロジック、サービスアーキテクチャ。」
-- **フロントエンド**: 「PRD [パス] からフロントエンドDesign Docを作成。コードベース分析: [フロントエンドレイヤー用codebase-analyzerのJSON]。バックエンドDesign Doc [パス] のAPIコントラクトとIntegration Pointsを参照。対象: コンポーネント階層、状態管理、UI操作、データ取得。」
+- **フロントエンド**: 「PRD [パス] からフロントエンドDesign Docを作成。コードベース分析: [フロントエンドレイヤー用codebase-analyzerのJSON]。レビュー済みバックエンドDesign Doc [パス] — このドキュメントからAPIコントラクトとIntegration Pointsを抽出し、フロントエンドのIntegration Point Mapに反映する。バックエンドレビュー指摘: [ステップ11 document-reviewerのcritical/important項目があればそれ]。prior_layer_verification: [バックエンドDesign Docに対するcode-verifierのJSON]。`prior_layer_verification.discrepancies[]`とレビュー指摘から不安定なバックエンド契約を識別する。検証済みと見なせる主張は検証結果JSONに明示されているものに限定する。未検証のまま依存せざるを得ない契約は、「## Cross-Layer Assumptions」セクションに正当化と検証先を記載する。UI Spec [パス] のコンポーネント構造を参照。対象: コンポーネント階層、状態管理、UI操作、データ取得。」
 
 **design-sync**: フロントエンドDesign Docをソースとして使用。`docs/design/`内の他のDesign Docを自動検出して比較。
 
@@ -288,12 +290,18 @@ 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作成プロンプトの追加コンテキストとして渡す。必須の使い道:
+   - `focusAreas` → Fact Disposition Tableの正典となるdisposition targetリスト（各focusAreaを1行に展開し、`fact_id`と`evidence`をそのまま引き継ぐ）
+   - `dataModel`、`dataTransformationPipelines`、`qualityAssurance` → 「既存コードベース分析」「検証戦略」「品質保証メカニズム」の各セクションに反映
 
    #### code-verifier → document-reviewer（Design Docレビュー）
 
-   **code-verifierへの入力**: Design Docパス（doc_type: design-doc）。`code_paths`は意図的に未指定 — verifierがドキュメントからコードスコープを独自に発見する。
-   **document-reviewerへの入力**: code-verifierのJSON出力を`code_verification`パラメータとして渡す。
+   **code-verifierへの入力**: Design Docパス（doc_type: design-doc）。`code_paths`は指定を省略する — verifierがドキュメントからコードスコープを独自に発見する。
+   **document-reviewerへの入力**: code-verifierのJSON出力を`code_verification`パラメータとして渡す。**加えて**、designerに渡したものと同じcodebase-analyzerのJSONを`codebase_analysis`として渡す。reviewerは`codebase_analysis.focusAreas`を使ってFact Disposition Tableのカバレッジを検証する。
+
+   #### code-verifier + document-reviewer → 次レイヤーのtechnical-designer（レイヤー横断フロー時のみ）
+
+   **次レイヤーのtechnical-designerへの入力**: レビュー済みの前レイヤーDesign Docパスに加えて`prior_layer_verification`（前レイヤーcode-verifierのJSON）を渡す。シーケンスは「レイヤー横断オーケストレーション」セクションを参照。`prior_layer_verification.discrepancies[]`と前レイヤーのレビュー指摘を用いて不安定な契約を識別する。検証済みと見なせる主張は検証結果JSONに明示されているものに限定する。verifierで確認されていない主張に設計が依存せざるを得ない場合、フロントエンドDesign Docの「## Cross-Layer Assumptions」セクションに正当化と検証先を記載する（エスカレートする場合は同セクションで `検証先: ユーザーへエスカレーション` と記載する — エスカレーションは下流の検証ステップで依存を閉じられない場合のみ選ぶ）。
 
    #### technical-designer → work-planner
 

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,45 @@ 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.8] - 2026-04-17
+
+### Added
+
+- **codebase-analyzer: Fact Disposition targets in focusAreas** (agents) — Step 4 enumerates existing facts within change scope. Schema expanded with `fact_id` (format: `<primary-file-path>:<symbol>`), `evidence` (single-form reference string), `factsToAddress` (designer checklist), and `relatedFiles` fields. Cross-layer canonical anchor rule: shared types/schemas/APIs referenced from multiple layers anchor `fact_id` to the canonical source file so per-layer analysis runs produce matching identifiers for the same concept. Priority ordering (branching outcomes > external contracts > domain invariants) with cardinality target 5-15 and explicit overflow handling
+- **technical-designer: Fact Disposition Table section** (agents) — Required when Codebase Analysis input is provided. Six-column table (Fact ID / Focus Area / Disposition / Rationale / Evidence / Related Files) with one row per `focusArea`. Dispositions: `preserve` / `transform` / `remove` / `out-of-scope` with specific selection criteria and rationale content guidance per value. Applied to both technical-designer and technical-designer-frontend
+- **document-reviewer: Fact Disposition coverage and semantic alignment checks** (agents) — New `codebase_analysis` input parameter. Gate 0 verifies Fact Disposition Table section presence. Gate 1 verifies row-level coverage of every `focusArea`, verbatim carry-through of `fact_id` / `evidence` / `relatedFiles`, and rationale-disposition semantic alignment using whole-phrase judgment with valid/invalid example patterns per disposition
+- **design-sync: Disposition conflict detection** (agents) — New extraction target for Fact Disposition Table rows as `(fact_id, disposition)` pairs. Critical conflict type detects same `fact_id` across documents carrying different `disposition` values. Detection scope explicitly documented: same-layer cross-DD conflicts and cross-layer conflicts sharing a common anchor file
+- **code-reviewer: Step 4-1 disposition implementation verification** (agents) — Post-implementation verification per disposition row. `remove` rows: cited symbol absent from production code path. `transform` rows: observable behavior matches rationale. `preserve` rows: observable behavior unchanged from pre-change state. `out-of-scope` rows: cited files not modified in the implementation diff. Mismatches produce `dd_violation` findings with specific rationale
+- **Cross-Layer Orchestration: serial backend-first flow with symmetric review gates** (skills) — Sequence updated to Backend design → verify → review → Frontend design → verify → review → design-sync. Both document-reviewer invocations carry `[Stop on critical issues]` to block structural defect propagation to the next layer. Backend verification output passed to the frontend designer as `prior_layer_verification`
+- **technical-designer-frontend: formal cross-layer inputs** (agents) — Required Information section adds Reviewed Prior-Layer Design Doc, Prior-Layer Review Findings, and Prior-Layer Verification as optional cross-layer-only inputs with explicit usage guidance
+- **Cross-Layer Assumptions mechanism** (agents, skills) — Designers record prior-layer claims the design must depend on when those claims remain unverified. Format: `- [claim]: [justification]; verify at [target]`. document-reviewer validates presence (when prior-layer dependencies exist) and verification-target presence per entry. design-template section added
+- **Design Doc template: Fact Disposition Table** (skills) — Six-column template added between Code Inspection Evidence and Design sections. L1/L2/L3 inline definition ("verification granularity tiers") added for self-documenting terminology
+
+### Changed
+
+- **Rationale-disposition alignment: semantic judgment over substring matching** (agents) — document-reviewer evaluates rationale as whole phrases against disposition semantics with valid/invalid example patterns per disposition. Eliminates false-positive risk where valid preserve phrasing (e.g., "no change", "unchanged") would have triggered on substring matches. Writer-side guidance in technical-designer and design-template updated symmetrically across all four dispositions
+- **Agent-to-agent and skill-to-skill decoupling** (agents, skills) — Direct agent name references replaced with artifact names, passive voice, or parameter names across 52 agent files. Dead skill pointers (references to skills not loaded in the reading context) removed or neutralized across skill files. In-context references that aid precision are preserved (e.g., `task-analyzer` routing table)
+- **Scope clarifiers for delegated work** (agents) — Cross-document consistency checks in technical-designer update mode explicitly marked "out of scope for this agent" to remove ambiguity about delegation
+
+### Removed
+
+- **Redundant CLAUDE.md context statement from all subagents** (agents) — Removed "Operates in an independent context without CLAUDE.md principles, executing autonomously until task completion." from 25 EN + 25 JA agent files. Subagents invoked via the Agent tool receive only their own system prompt, environment details, and frontmatter-declared skills — the parent's CLAUDE.md / project memory does not load. The removed statement restated the platform default and added no guidance. `rule-advisor` retains the description-level `(CLAUDE.md required process)` note since it references the caller's obligation, not its own context.
+
+## [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.8",
   "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": [