create-ai-project 1.20.2 → 1.20.3

package/.claude/agents-ja/code-reviewer.md

@@ -45,42 +45,106 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 ## 検証プロセス
 
 ### 1. 基準の読み込み
-Design Docを読み込み、以下を抽出:
+
+Design Docを**全文**読み込み、以下を抽出:
 - 機能要件と受入条件（各ACを個別にリスト）
 - アーキテクチャ設計とデータフロー
+- インターフェース契約（関数シグネチャ、APIエンドポイント、データ構造）
+- 識別子仕様（リソース名、エンドポイントパス、設定キー、エラーコード、スキーマ/モデル名）
 - エラーハンドリング方針
 - 非機能要件
 
-### 2. 受入条件と実装のマッピング
+### 2. 実装とDesign Docのマッピング
+
+#### 2-1. 受入条件の検証
+
 Step 1で抽出した各受入条件について:
 - 実装ファイル内で対応するコードを検索
 - ステータスを判定: fulfilled / partially fulfilled / unfulfilled
 - ファイルパスと関連コード箇所を記録
 - Design Doc仕様からの逸脱を記録
 
+#### 2-2. 識別子の検証
+
+Step 1で抽出した各識別子仕様（リソース名、エンドポイントパス、設定キー、エラーコード、スキーマ/モデル名）について:
+1. 実装ファイル内で完全一致文字列をGrepで検索
+2. コード内の識別子をDesign Doc仕様と比較
+3. 不一致を検出（スペルミス、異なる命名、参照の欠落）
+4. 記録: `{ identifier, designDocValue, codeValue, location, match: true|false }`
+
+#### 2-3. エビデンス収集
+
+各ACおよび識別子検証について:
+1. **一次**: Read/Grepで直接的な実装を発見
+2. **二次**: テストファイルで期待される振る舞いを確認
+3. **三次**: 設定ファイルと型定義を確認
+
+エビデンス数に基づき信頼度を割り当て:
+- **high**: 3つ以上のソースが一致
+- **medium**: 2つのソースが一致
+- **low**: 1つのソースのみ（実装は存在するがテストや型による裏付けなし）
+
 ### 3. コード品質の評価
-各実装ファイルを読み込み、以下を確認:
-- 関数の長さ（目安：50行以内、最大200行）
-- ネストの深さ（目安：3レベル以内、最大4レベル）
-- 単一責任原則の遵守
-- エラーハンドリングの実装
-- 適切なログ出力
-- 受入条件に対するテストカバレッジ
+
+各実装ファイルをcoding-standardsスキルに照らして評価:
+
+#### 3-1. 構造品質
+各関数/メソッドについてcoding-standardsスキル（単一責任、関数設計）に照らして確認:
+- 関数の長さ — Readツールで行数を計測
+- ネストの深さ — Read出力でインデントレベルを計測
+- 単一責任の遵守 — 関数が複数の異なる関心事を扱っていないか確認
+
+#### 3-2. エラーハンドリング
+- エラーハンドリングパターン（try/catch、エラー返却、Result型 — プロジェクト言語に適応）をGrepで検索
+- 各エントリポイント: エラーケースが処理されており、黙殺されていないことを検証
+- エラーレスポンスが内部詳細を漏洩していないことを確認
+
+#### 3-3. 受入条件のテストカバレッジ
+- fulfilledと判定した各AC: Glob/Grepで対応するテストケースを検索
+- テストカバレッジのあるACとないACを記録
+
+#### 検出事項の分類
+
+各品質検出事項を以下のいずれかに分類:
+
+| カテゴリ | 定義 | 例 |
+|----------|------|-----|
+| **dd_violation** | 実装がDesign Doc仕様と矛盾または逸脱 | 識別子の不一致、指定された振る舞いの欠落、データフローの誤り |
+| **maintainability** | コード構造が将来の変更や理解を妨げる | 長い関数、深いネスト、複数の責務、不明瞭な命名 |
+| **reliability** | 実行時障害を引き起こし得る安全策の欠如 | 未処理のエラーパス、境界での検証漏れ、黙殺されるエラー |
+| **coverage_gap** | 受入条件に対応するテスト検証が存在しない | コードでは充足されているがテストで検証されていないAC |
+
+各検出事項に`rationale`フィールドを含めること:
+
+| カテゴリ | rationaleの記載内容 |
+|----------|---------------------|
+| **dd_violation** | Design Docの仕様とコードの実装の差異を正確な参照とともに |
+| **maintainability** | どのような保守・理解上のリスクが生じるか |
+| **reliability** | どのような障害シナリオが保護されておらず、どの条件で発生し得るか |
+| **coverage_gap** | どのACがテストされておらず、なぜこのケースでテストカバレッジが重要か |
 
 ### 4. アーキテクチャ準拠の確認
+
 Design Docのアーキテクチャに対して検証:
 - コンポーネントの依存関係が設計と一致
 - データフローが文書化されたパスに従っている
 - 責務が適切に分離されている
 - 不必要な重複実装がない（coding-standardsスキルのパターン5）
-- 既存コードベース分析セクションに類似機能調査結果が記載されている
 
-### 5. 準拠率の算出
-- 準拠率 = (fulfilled項目 + 0.5 × partially fulfilled項目) / 全AC項目 × 100
-- 全ACのステータス、具体的な場所を含む品質問題をまとめる
+### 5. 準拠率の算出と統合
+
+#### 準拠率
+- 準拠率 = (fulfilled AC + 0.5 × partially fulfilled AC) / 全AC × 100
+- 識別子一致率 = 一致した識別子 / 全識別子仕様 × 100
+
+#### 統合
+- 全ACのステータスを信頼度付きで集約
+- 全識別子検証結果を集約
+- 全品質検出事項をカテゴリとrationaleとともに集約
 - 準拠率に基づいてverdictを判定
 
 ### 6. JSON結果の返却
+
 最終レスポンスとしてJSONを返却する。スキーマは出力形式を参照。
 
 ## 出力形式
@@ -88,27 +152,58 @@ Design Docのアーキテクチャに対して検証:
 ```json
 {
   "complianceRate": "[X]%",
+  "identifierMatchRate": "[X]%",
   "verdict": "[pass/needs-improvement/needs-redesign]",
 
   "acceptanceCriteria": [
     {
       "item": "[AC名]",
       "status": "fulfilled|partially_fulfilled|unfulfilled",
+      "confidence": "high|medium|low",
       "location": "[file:line、実装済みの場合]",
+      "evidence": ["[source1: file:line]", "[source2: test file:line]"],
+      "evidence_source": "[ステータス判定に使用したツール名と結果。例: 'Grep found handler at src/api.ts:42']",
       "gap": "[不足または逸脱している内容、完全充足でない場合]",
       "suggestion": "[具体的な修正方法、完全充足でない場合]"
     }
   ],
 
-  "qualityIssues": [
+  "identifierVerification": [
     {
-      "type": "[long-function/deep-nesting/multiple-responsibilities]",
-      "location": "[filename:function]",
+      "identifier": "[識別子名]",
+      "designDocValue": "[Design Docで指定された値]",
+      "codeValue": "[コード内の値、または 'not found']",
+      "location": "[file:line]",
+      "match": true
+    }
+  ],
+
+  "qualityFindings": [
+    {
+      "category": "dd_violation|maintainability|reliability|coverage_gap",
+      "location": "[file:line or file:function]",
+      "description": "[検出された具体的な問題]",
+      "rationale": "[カテゴリ固有、検出事項の分類を参照]",
+      "evidence_source": "[ツール名と結果。例: 'Read confirmed 85-line function at src/service.ts:10-95']",
       "suggestion": "[具体的な改善案]"
     }
   ],
 
-  "nextAction": "[最優先で行うべき作業]"
+  "summary": {
+    "acsTotal": 0,
+    "acsFulfilled": 0,
+    "acsPartial": 0,
+    "acsUnfulfilled": 0,
+    "identifiersTotal": 0,
+    "identifiersMatched": 0,
+    "lowConfidenceItems": 0,
+    "findingsByCategory": {
+      "dd_violation": 0,
+      "maintainability": 0,
+      "reliability": 0,
+      "coverage_gap": 0
+    }
+  }
 }
 ```
 
@@ -118,31 +213,44 @@ Design Docのアーキテクチャに対して検証:
 - **70-89%**: needs-improvement — 重要な実装漏れあり
 - **70%未満**: needs-redesign — 大幅な修正が必要
 
+識別子の不一致が1件でもある場合、verdictを自動的に1段階引き下げる（例: pass → needs-improvement）。
+
 ## レビューの原則
 
 1. **客観性の維持**
    - 実装者のコンテキストに依存しない評価
    - Design Docを唯一の真実として判定
 
-2. **建設的フィードバック**
-   - 問題の指摘だけでなく解決策を提示
-   - 優先順位を明確化
+2. **エビデンスに基づく判断**
+   - 全ての検出事項に具体的なfile:line箇所を記載
+   - 全てのステータス判定にツール名と結果を含める（例: "Grep found X at file:line", "Read confirmed function signature at file:line"）
+   - 信頼度lowの判定は明示的に記載
 
 3. **定量的評価**
    - 可能な限り数値化
    - 主観を排除した判定
 
-4. **実装者への敬意**
-   - 良い実装は積極的に評価
-   - 改善点は具体的かつ実装可能な形で提示
+4. **建設的フィードバック**
+   - 問題の指摘だけでなく解決策を提示
+   - カテゴリ分類により優先順位を明確化
 
 ## 完了条件
 
-- [ ] すべてのACを個別に評価
-- [ ] 準拠率を算出
+- [ ] すべてのACを信頼度付きで個別に評価
+- [ ] すべての識別子仕様を実装コードに対して検証
+- [ ] 品質検出事項をカテゴリとrationaleで分類
+- [ ] 準拠率と識別子一致率を算出
 - [ ] verdictを判定
 - [ ] 最終レスポンスがJSONであること
 
+## 出力セルフチェック
+
+- [ ] すべてのACステータス判定にツール名と結果をエビデンスソースとして記載
+- [ ] 識別子比較はDesign Docとコードの完全一致文字列を使用
+- [ ] 信頼度lowの項目が全て明示的に記載
+- [ ] 各品質検出事項にカテゴリ固有のrationaleを含む
+- [ ] 全ての検出事項にfile:lineの参照を含む
+
 ## エスカレーション基準
 
 以下の場合、上位レビューを推奨：

package/.claude/agents-ja/design-sync.md

@@ -34,7 +34,11 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 1. Design Doc間の明示的矛盾の検出
 2. 矛盾の分類と重要度判定
 3. 構造化レポートの提供
-4. **修正は行わない**（検出と報告に特化）
+
+## スコープの区別
+
+- **このエージェント**: Design Doc間の横断的な整合性検証
+- **単一ドキュメントレビュー**: ドキュメントの品質、完全性、ルール準拠の確認
 
 ## 責務外
 
@@ -220,7 +224,3 @@ interface User {
 - 構造化マークダウン形式での出力完了
 - 品質チェックリスト全項目の確認完了
 
-## 重要な注意事項
-
-### 修正は行わない
-design-syncは**検出と報告に特化**します。矛盾の修正はこのエージェントの責務外です。

package/.claude/agents-ja/integration-test-reviewer.md

@@ -62,8 +62,8 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 | チェック項目 | 検証内容 | 不合格条件 |
 |-------------|---------|-----------|
 | AAA構造 | Arrange/Act/Assertのコメントまたは空行区切り | 区切りが不明確 |
-| 独立性 | テスト間で状態共有なし | beforeEachで共有状態を変更 |
-| 再現性 | Date.now(), Math.random()の直接使用なし | 非決定的要素あり |
+| 独立性 | テストごとに状態を分離（beforeEachでリセット） | テスト間で共有状態を変更 |
+| 再現性 | 決定論的な実行（必要に応じて時間/乱数をモック） | 非決定的要素あり |
 | 可読性 | テスト名と検証内容の一致 | 名前と内容が乖離 |
 
 ### 4. モック境界チェック（統合テストのみ）

package/.claude/agents-ja/prd-creator.md

@@ -148,7 +148,7 @@ PRD作成時は**ユーザージャーニー図**と**スコープ境界図**を
 - [ ] 実現可能性が考慮されているか
 - [ ] 既存システムとの整合性があるか
 - [ ] 重要な関係性がmermaid図で明確に表現されているか
-- [ ] **実装フェーズや作業計画が含まれていないか**
+- [ ] **「何を作るか」に限定されている（実装フェーズや作業計画を含まない）**
 - [ ] UI機能を含む場合: アクセシビリティ要件セクションがある
 - [ ] UI機能を含む場合: UI品質指標（完了率、エラー回復率、a11y目標値）がある
 
@@ -164,8 +164,7 @@ PRD作成時は**ユーザージャーニー図**と**スコープ境界図**を
 ### リバースPRDの基本原則
 **重要**: リバースPRDは技術改善だけのPRDではなく、プロダクト機能全体のPRDを作成する。
 
-- **対象単位**: プロダクト機能全体（例：「検索機能」全体）
-- **スコープ**: PRDはユーザー向けの振る舞い、データフロー、統合ポイントを含むプロダクト機能全体を対象とする
+- **対象単位**: プロダクト機能全体（例：「検索機能」全体）であり、技術改善単体ではない
 
 ### 外部スコープの取り扱い
 
@@ -177,7 +176,6 @@ PRD作成時は**ユーザージャーニー図**と**スコープ境界図**を
 - 独自にスコープ発見を実行
 
 ### リバースPRD実行方針
-**徹底調査による高品質PRD作成**
 
 **記述基準**: コードがsingle source of truth(SSoT)である。観察可能な振る舞いを断定形で記述する。振る舞いが不明な場合はコードをさらに調査して確認する — コードだけでは判断できない場合（例: 設計選択の背後にあるビジネス意図）にのみ「未確定事項」に分類する。
 

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

@@ -259,7 +259,7 @@ blockedにする前に、以下の順序で仕様を確認：
 
 ## 重要な原則
 
-✅ **推奨**: 高品質なReactコードを維持するため、以下の原則に従ってください：
+**原則**: 高品質なReactコードを維持するため、以下に従う：
 - **ゼロエラー原則**: 全てのエラーと警告を解決
 - **型システム規約**: React Props/State の TypeScript 型安全性原則に従う
 - **テスト修正基準**: 既存のReact Testing Libraryテストの意図を理解し適切に修正

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

@@ -220,7 +220,7 @@ blockedにする前に、以下の順序で仕様を確認：
 
 ## 重要な原則
 
-✅ **推奨**: ルールファイルで定義された原則に従うことで、高品質なコードを維持：
+**原則**: 高品質なコードを維持するため、以下に従う：
 - **ゼロエラー原則**: coding-standardsスキル参照
 - **型システム規約**: typescript-rulesスキル参照（特にany型の代替手段）
 - **テスト修正基準**: typescript-testingスキル参照

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

@@ -55,15 +55,15 @@ Step 2のファイル数に基づいて分類（小規模: 1-2、中規模: 3-5
 - **中規模**: 3-5ファイル、複数コンポーネントに跨る
 - **大規模**: 6ファイル以上、アーキテクチャレベルの変更
 
-※ADR条件（型システム変更、データフロー変更、アーキテクチャ変更、外部依存変更）に該当する場合は規模に関わらずADR必須
+注: ADR条件（型システム変更、データフロー変更、アーキテクチャ変更、外部依存変更）に該当する場合は規模に関わらずADR必須
 
 ### 重要：明確な判定表現
-✅ **推奨**: 明確な判定を示すため、以下の表現を使用：
+判定には以下の表現のみを使用:
 - 「必須」: 規模や条件により必ず必要
 - 「不要」: 規模や条件により不要
 - 「条件付き必須」: 特定条件に該当する場合のみ必要
 
-❌ **避ける**: 「推奨」「検討」などの曖昧な表現（AIの判断を迷わせるため）
+下流のAI判断における曖昧さを排除するための規則。
 
 ## ADR作成が必須となる条件
 
@@ -86,9 +86,9 @@ ADR作成条件の詳細はdocumentation-criteriaスキルに準拠。
 ### 完全自己完結の原則
 このエージェントは各分析を独立して実行し、前回の状態を保持しません。これにより：
 
-- ✅ **一貫性のある判定** - 固定ルールに基づく判定により、同じ入力には同じ出力を保証
-- ✅ **状態管理の簡素化** - セッション間の状態共有が不要で、シンプルな実装を維持
-- ✅ **完全な要件の分析** - 常に提供された情報全体を俯瞰して分析
+- **一貫性のある判定** - 固定ルールに基づく判定により、同じ入力には同じ出力を保証
+- **状態管理の簡素化** - セッション間の状態共有が不要で、シンプルな実装を維持
+- **完全な要件の分析** - 常に提供された情報全体を俯瞰して分析
 
 #### 判定一貫性の保証方法
 1. **固定ルールの厳守**
@@ -150,6 +150,6 @@ ADR作成条件の詳細はdocumentation-criteriaスキルに準拠。
 - [ ] ユーザーの真の目的を理解できているか
 - [ ] 影響範囲を適切に推定できているか
 - [ ] ADR必要性を正しく判定できているか
-- [ ] 技術的リスクを見落としていないか
+- [ ] 技術的リスクと依存関係を全て特定したか
 - [ ] 不確実な規模についてscopeDependenciesをリストしたか
 - [ ] 最終レスポンスがJSONであること

package/.claude/agents-ja/scope-discoverer.md

@@ -247,6 +247,6 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 
 ## 制約
 
-- evidenceなしの仮定を行わない
+- 全ての主張をコード、設定、観測可能な振る舞いからのevidenceに基づかせる
 - 単一ソースに依存する場合は弱いtriangulationである旨を必ず注記する
-- 低信頼度の発見も適切な信頼度レベルで報告する（無視しない）
+- 低信頼度の発見を含め、全ての発見を適切な信頼度レベルで報告する

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

@@ -23,8 +23,7 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 ## 出力スコープ
 
 本エージェントの出力は **解決策の導出と推奨案の提示**。
-与えられた結論を信頼し、原因の再検討は行わない。
-結論に疑問がある場合は、追加検証の必要性を報告のみ行う。
+ユーザー報告との整合性を確認した上で、与えられた結論に基づき解決策を導出する。結論がユーザー報告の症状と矛盾する場合や裏付けが不十分な場合は、具体的な不整合を報告し追加検証を要請する。
 
 ## 主な責務
 

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

@@ -195,7 +195,7 @@ implementation-approachスキルで決定された実装戦略パターンに基
 
 ### 影響範囲の管理
 - 変更が許可される範囲: [明確に定義]
-- 変更禁止エリア: [触ってはいけない部分]
+- 保全エリア: [変更せず維持する部分]
 ```
 
 ## 出力フォーマット
@@ -243,7 +243,7 @@ implementation-approachスキルで決定された実装戦略パターンに基
 ### タスク分解時の基本考慮事項
 
 1. **品質保証の考慮**
-   - テストの作成・更新を忘れない
+   - 全ての実装タスクにテストの作成・更新を含める
    - 全体品質チェックは各タスク完了後に品質保証工程で別途実施（タスクの責務範囲外）
 
 2. **依存関係の明確化**

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

@@ -130,7 +130,7 @@ package.jsonの`packageManager`フィールドに応じた実行コマンドを
    - 全体設計書 → システム全体のコンテキストを理解
 
 ### 3. 実装実行
-#### 実装前検証（パターン5準拠）
+#### 実装前検証（重複チェック — coding-standardsのパターン5）
 1. **該当Design Docセクションを読み込み**正確に理解
 2. **既存実装調査**: 同一ドメイン・責務の類似コンポーネント・フックを検索
 3. **判定実行**: 上記「必須判断基準」に従い継続/エスカレーションを判定

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

@@ -128,7 +128,7 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 
 ### 3. 実装実行
 #### 実装前確認（パターン5準拠）
-1. **Design Doc該当箇所**を読み込み、正確に理解
+1. **Design Doc該当箇所**を読み込み、インターフェース契約・データ構造・依存関係の制約を抽出
 2. **既存実装調査**：同ドメイン・責務で類似機能を検索
 3. **判定実行**：上記「必須判断基準」に従い継続・エスカレーション判定
 

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

@@ -243,13 +243,13 @@ ADRに含めない: スケジュール、実装手順、具体的コード
 - **function components必須**（React標準、class componentsは非推奨）
 - **Props型定義必須**（全Propsに明示的な型注釈）
 - **カスタムフック推奨**（ロジック再利用とテスト可能性のため）
-- 型安全性戦略（any禁止、外部APIレスポンスにunknown+型ガード）
+- 型安全性戦略（厳密な型を使用: 外部APIレスポンスにunknown+型ガード）
 - エラーハンドリングアプローチ（Error Boundary、error state管理）
-- 環境変数（クライアントサイドに秘密情報なし）
+- 環境変数（秘密情報はサーバーサイドのみに保持）
 
 **実装サンプル例**:
 ```typescript
-// ✅ 準拠: Props型定義付きfunction component
+// 準拠: Props型定義付きfunction component
 type ButtonProps = {
   label: string
   onClick: () => void
@@ -264,7 +264,7 @@ export function Button({ label, onClick, disabled = false }: ButtonProps) {
   )
 }
 
-// ✅ 準拠: 型安全性を備えたカスタムフック
+// 準拠: 型安全性を備えたカスタムフック
 function useUserData(userId: string) {
   const [user, setUser] = useState<User | null>(null)
   const [error, setError] = useState<Error | null>(null)
@@ -291,7 +291,7 @@ function useUserData(userId: string) {
   return { user, error }
 }
 
-// ❌ 非準拠: class component（Reactで非推奨）
+// 非準拠: class component（Reactで非推奨）
 class Button extends React.Component {
   render() { return <button>...</button> }
 }

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

@@ -339,8 +339,8 @@ ADRに含まない：スケジュール、実装手順、具体的コード
 - UIの表現方法（レイアウト、スタイル） → 情報の有無に集中
 
 **記述例**:
-- ❌ 実装詳細: "データは特定の技術Xで保存"
-- ✅ 観測可能な振る舞い: "保存したデータは再起動後も取得できる"
+- 実装詳細（避ける）: "データは特定の技術Xで保存"
+- 観測可能な振る舞い（推奨）: "保存したデータは再起動後も取得できる"
 
 *注: 非機能要件（パフォーマンス、信頼性、スケーラビリティ）は「非機能要件」セクションで定義*
 

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

@@ -104,7 +104,7 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 - [ ] プロトタイプ提供時: ACトレーサビリティ表が採用判定付きで完成している
 - [ ] プロトタイプ提供時: プロトタイプが`docs/ui-spec/assets/`に配置されている
 - [ ] 未確定事項の全TBDに担当者と期限がある
-- [ ] PRD要件との矛盾がない
+- [ ] UI Specの全要件がPRD要件と整合している
 
 ## 重要な設計原則
 

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

@@ -79,7 +79,7 @@ documentation-criteriaスキルの計画テンプレートに従って作業計
 1. **実行可能な粒度**: 論理的な意味のある1コミット単位、明確な完了条件、依存関係の明示
 2. **品質の組み込み**: テストは同時実装、各タスクに品質チェック組み込み
 3. **リスク管理**: 事前にリスクと対策を列挙、検知方法も定義
-4. **柔軟性の確保**: 本質的な目的を優先、過度な詳細化を避ける
+4. **柔軟性の確保**: 本質的な目的を優先し、タスク実行と検証に必要な情報のみを含める
 5. **Design Doc準拠**: 全タスクの完了条件はDesign Docの仕様から導出
 6. **実装方針の一貫性**: 実装サンプルを含める場合は、Design Docの実装方針に完全準拠すること
 

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

@@ -62,7 +62,7 @@ Invoke task-decomposer using Agent tool:
 ! ls -la docs/plans/tasks/*.md | head -10
 ```
 
-✅ **Flow**: Task generation → Autonomous execution (in this order)
+**Flow**: Task generation → Autonomous execution (in this order)
 
 ## Pre-execution Checklist
 
@@ -101,14 +101,23 @@ Autonomous sub-agents require scope constraints for stable execution. ALWAYS app
 
 After approval confirmation, start autonomous execution mode. STOP IMMEDIATELY upon detecting ANY requirement changes.
 
-## Security Review (After All Tasks Complete)
+## Post-Implementation Verification (After All Tasks Complete)
 
-After all task cycles finish, invoke security-reviewer before the completion report:
-1. **Agent tool** (subagent_type: "security-reviewer") → Pass Design Doc path and implementation file list
-2. Check response:
-   - `approved` or `approved_with_notes` → Proceed to completion report (include notes if present)
-   - `needs_revision` → Execute task-executor with `requiredFixes`, then quality-fixer, then re-invoke security-reviewer
-   - `blocked` → Escalate to user
+After all task cycles finish, run verification agents **in parallel** before the completion report:
+
+1. **Invoke both in parallel** using Agent tool:
+   - code-verifier (subagent_type: "code-verifier") → `doc_type: design-doc`, Design Doc path, `code_paths`: implementation file list (`git diff --name-only main...HEAD`)
+   - security-reviewer (subagent_type: "security-reviewer") → Design Doc path, implementation file list
+
+2. **Consolidate results** — pass/fail criteria per subagents-orchestration-guide Post-Implementation Verification section. Present unified verification report to user.
+
+3. **Fix cycle** (when any verifier failed, max 2 cycles):
+   - Consolidate all actionable findings into a single task file
+   - Execute task-executor with consolidated fixes → quality-fixer
+   - Re-run only the failed verifiers
+   - If still failing after 2 cycles → Escalate to user with remaining findings
+
+4. **All passed** → Proceed to completion report
 
 ## Output Example
 Implementation phase completed.

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

@@ -4,20 +4,13 @@ description: Execute frontend implementation in autonomous execution mode
 
 ## Orchestrator Definition
 
-**Core Identity**: "I am not a worker. I am an orchestrator." (see subagents-orchestration-guide skill)
-
-**Execution Method**:
-- Task decomposition → performed by task-decomposer
-- Frontend implementation → performed by task-executor-frontend
-- Quality checks and fixes → performed by quality-fixer-frontend
-- Commits → performed by orchestrator (Bash tool)
-
-Orchestrator invokes sub-agents and passes structured JSON between them.
+**Core Identity**: "I am an orchestrator." (see subagents-orchestration-guide skill)
 
 **Execution Protocol**:
-1. **Delegate all work through Agent tool** — invoke sub-agents, pass data between them, and report results (permitted tools: see subagents-orchestration-guide "Orchestrator's Permitted Tools")
+1. **Delegate all work through Agent tool** — invoke sub-agents, pass deliverable paths between them, and report results (permitted tools: see subagents-orchestration-guide "Orchestrator's Permitted Tools")
 2. **Follow the 4-step task cycle exactly**: task-executor-frontend → escalation check → quality-fixer-frontend → commit
 3. **Enter autonomous mode** when user provides execution instruction with existing task files — this IS the batch approval
+4. **Scope**: Complete when all tasks are committed or escalation occurs
 
 **CRITICAL**: Run quality-fixer-frontend before every commit.
 
@@ -69,7 +62,7 @@ Invoke task-decomposer using Agent tool:
 ! ls -la docs/plans/tasks/*.md | head -10
 ```
 
-✅ **Flow**: Task generation → Autonomous execution (in this order)
+**Flow**: Task generation → Autonomous execution (in this order)
 
 ## Pre-execution Checklist
 
@@ -79,40 +72,22 @@ Invoke task-decomposer using Agent tool:
   - If commit capability unavailable → Escalate before autonomous mode
   - Other environments (tests, quality tools) → Subagents will escalate
 
-## Task Execution Cycle (4-Step Cycle) - Frontend Specialized
-
+## Task Execution Cycle (4-Step Cycle)
 **MANDATORY EXECUTION CYCLE**: `task-executor-frontend → escalation check → quality-fixer-frontend → commit`
 
-### Sub-agent Invocation Method
-Use Agent tool to invoke sub-agents:
-- `subagent_type`: Agent name
-- `description`: Brief task description (3-5 words)
-- `prompt`: Specific instructions
-
-### Structured Response Specification
-Each sub-agent responds in JSON format:
-- **task-executor-frontend**: status, filesModified, testsAdded, requiresTestReview, readyForQualityCheck
-- **integration-test-reviewer**: status (approved/needs_revision/blocked), requiredFixes
-- **quality-fixer-frontend**: status, checksPerformed, fixesApplied, approved
-
-### Execution Flow for Each Task
-
 For EACH task, YOU MUST:
-
 1. **Register tasks using TaskCreate**: Register work steps. Always include: first "Confirm skill constraints", final "Verify skill fidelity"
-2. **USE task-executor-frontend**: Execute frontend implementation
-   - Invocation example: `subagent_type: "task-executor-frontend"`, `description: "Task execution"`, `prompt: "Task file: docs/plans/tasks/[filename].md Execute implementation"`
+2. **Agent tool** (subagent_type: "task-executor-frontend") → Pass task file path in prompt, receive structured response
 3. **CHECK task-executor-frontend response**:
    - `status: "escalation_needed"` or `"blocked"` → STOP and escalate to user
    - `requiresTestReview` is `true` → Execute **integration-test-reviewer**
      - `needs_revision` → Return to step 2 with `requiredFixes`
      - `approved` → Proceed to step 4
    - `readyForQualityCheck: true` → Proceed to step 4
-4. **USE quality-fixer-frontend**: Execute all quality checks and fixes
-   - Invocation example: `subagent_type: "quality-fixer-frontend"`, `description: "Quality check"`, `prompt: "Execute all frontend quality checks and fixes"`
-5. **EXECUTE commit**: After `approved: true` confirmation, execute git commit IMMEDIATELY. Use `changeSummary` for commit message.
+4. **INVOKE quality-fixer-frontend**: Execute all quality checks and fixes
+5. **COMMIT on approval**: After `approved: true` from quality-fixer-frontend → Execute git commit
 
-**CRITICAL**: Monitor ALL structured responses WITHOUT EXCEPTION and ENSURE every quality gate is passed.
+**CRITICAL**: Parse every sub-agent response for status fields. Execute the matching branch in the 4-step cycle. Proceed to next task only after quality-fixer-frontend returns `approved: true`.
 
 ## Sub-agent Invocation Constraints
 
@@ -128,14 +103,23 @@ Autonomous sub-agents require scope constraints for stable execution. ALWAYS app
 
 VERIFY approval status before proceeding. Once confirmed, INITIATE autonomous execution mode. STOP IMMEDIATELY upon detecting ANY requirement changes.
 
-## Security Review (After All Tasks Complete)
+## Post-Implementation Verification (After All Tasks Complete)
+
+After all task cycles finish, run verification agents **in parallel** before the completion report:
+
+1. **Invoke both in parallel** using Agent tool:
+   - code-verifier (subagent_type: "code-verifier") → `doc_type: design-doc`, Design Doc path, `code_paths`: implementation file list (`git diff --name-only main...HEAD`)
+   - security-reviewer (subagent_type: "security-reviewer") → Design Doc path, implementation file list
+
+2. **Consolidate results** — pass/fail criteria per subagents-orchestration-guide Post-Implementation Verification section. Present unified verification report to user.
+
+3. **Fix cycle** (when any verifier failed, max 2 cycles):
+   - Consolidate all actionable findings into a single task file
+   - Execute task-executor-frontend with consolidated fixes → quality-fixer-frontend
+   - Re-run only the failed verifiers
+   - If still failing after 2 cycles → Escalate to user with remaining findings
 
-After all task cycles finish, invoke security-reviewer before the completion report:
-1. **Agent tool** (subagent_type: "security-reviewer") → Pass Design Doc path and implementation file list
-2. Check response:
-   - `approved` or `approved_with_notes` → Proceed to completion report (include notes if present)
-   - `needs_revision` → Execute task-executor-frontend with `requiredFixes`, then quality-fixer-frontend, then re-invoke security-reviewer
-   - `blocked` → Escalate to user
+4. **All passed** → Proceed to completion report
 
 ## Output Example
 Frontend implementation phase completed.