create-ai-project 1.20.2 → 1.20.4

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

@@ -80,7 +80,7 @@ Execute file output immediately (considered approved at execution).
 1. **Executable Granularity**: Each task as logical 1-commit unit, clear completion criteria, explicit dependencies
 2. **Built-in Quality**: Simultaneous test implementation, quality checks in each phase
 3. **Risk Management**: List risks and countermeasures in advance, define detection methods
-4. **Ensure Flexibility**: Prioritize essential purpose, avoid excessive detail
+4. **Ensure Flexibility**: Prioritize essential purpose, include only information required for task execution and verification
 5. **Design Doc Compliance**: All task completion criteria derived from Design Doc specifications
 6. **Implementation Pattern Consistency**: When including implementation samples, MUST ensure strict compliance with Design Doc implementation approach
 

package/.claude/agents-ja/acceptance-test-generator.md

@@ -210,7 +210,8 @@ it.todo('[AC番号]-property: [不変条件を自然言語で記述]')
 ## 制約と品質基準
 
 **必須準拠事項**:
-- `it.todo`のみ出力（実装コード、expect、モック実装は禁止）
+- `it.todo`スケルトンのみ出力: 各スケルトン内にコメントとして検証観点、期待結果、合格基準を記述。
+  実装コード、アサーション(`expect`)、モックセットアップは含めない — 下流エージェント(work-planner, integration-test-reviewer)が`it.todo`の有無でフェーズ配置やレビュー判定を行うため。
 - 各テストの検証観点、期待結果、合格基準を明確に記述
 - コメントに元のAC文を保持（トレーサビリティ確保）
 - テスト上限設定内に収める；重要テストに上限超過の場合は報告
@@ -241,7 +242,7 @@ it.todo('[AC番号]-property: [不変条件を自然言語で記述]')
 - フレームワーク/言語: 既存テストファイルから自動検出
 - 配置: `**/*.{test,spec}.{ts,js}`パターンでGlobを使用してテストディレクトリを特定
 - 命名: 既存のファイル命名規則に従う
-- 出力: `it.todo`のみ（実装コードは除外）
+- 出力: `it.todo`スケルトンのみ（境界は制約セクション参照）
 
 **ファイル操作**:
 - 既存ファイル: 末尾に追記、重複を防止（Grepでチェック）

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/codebase-analyzer.md

@@ -44,15 +44,19 @@ skills: coding-standards, project-context, technical-spec
 
 `affectedFiles`の各ファイルに対して:
 
-1. **ファイルを読み込み**、以下を抽出:
-   - publicインターフェース、型、関数シグネチャ、クラス定義
-   - コード上の正確な名前とシグネチャを記録
-2. **1階層の依存関係をトレース**: モジュールの依存宣言（import文、use宣言、includeディレクティブ — プロジェクト言語に適応）から直接依存先を特定。各インポートモジュールのpublicインターフェースを読み込み
-3. **パターン検出**（プロジェクト規約に合わせて検索語を適応）:
+1. **ファイルを全文読み込み**、全可視性レベル（public, private, internal — 用語はプロジェクト言語に適応）のインターフェース、型、関数シグネチャ、クラス定義、メソッド定義をすべて抽出する。コード上の正確な名前、可視性、シグネチャを記録
+2. **コールチェーンのトレース**（可視性の用語はプロジェクト言語に適応 — 例: public/private, exported/unexported, pub/pub(crate)）:
+   - 同一モジュール内の関数/メソッド: チェーンが終端するまで（return、外部への委譲、リーフ到達）すべての呼び出しを再帰的にたどる。チェーンが10個を超えるユニークな関数にまたがる場合、トレース済み部分を記録し残りを`limitations`に記載
+   - 外部依存（インポートされたモジュール、他パッケージ）: publicインターフェースのみ読み込み（シグネチャ、コントラクト）。統合ポイントとして記録するが、外部モジュール内部へのトレースは行わない
+3. **データ変換パイプラインの検出**: 要件に関連するエントリポイント（`affectedFiles`と`purpose`で特定されたもの）を優先する。モジュール外部から入力を受け取る各該当エントリポイント（APIハンドラー、他モジュールから呼び出されるエクスポート済みサービス関数、CLIエントリポイント）について、コールチェーンを通じて入力データがどう変換されるかをステップごとにトレースする。同じ出力パスや変換ロジックを共有する追加エントリポイントが発見された場合は含めるか、`limitations`に記録:
+   - 各変換ステップを記録（何が変わるか、どのようなフォーマット/値のマッピングが行われるか）
+   - 値を変更する外部リソース参照を記録（マスタテーブル参照、設定値の参照、定数の置換）
+   - 中間データフォーマットを記録（最終出力前に別の表現を経由する場合）
+4. **パターン検出**（プロジェクト規約に合わせて検索語を適応）:
    - データアクセス: データベース操作を示すパターンをGrep（query, select, insert, update, delete, find, save, create, repository, model, schema, migration, table, column, entity, record）
    - 外部統合: 外部呼び出しを示すパターンをGrep（http, fetch, client, api, endpoint, request, response）
    - バリデーション: 制約を示すパターンをGrep（validate, check, assert, constraint, rule, require, ensure）
-4. 発見した各要素をファイルパスと行番号付きで記録
+5. 発見した各要素をファイルパスと行番号付きで記録
 
 ### ステップ3: スキーマとデータモデルの発見
 
@@ -95,9 +99,10 @@ skills: coding-standards, project-context, technical-spec
   },
   "existingElements": [
     {
-      "category": "interface|type|function|class|constant|configuration",
+      "category": "interface|type|function|method|class|constant|configuration",
       "name": "要素名",
       "filePath": "path/to/file:行番号",
+      "visibility": "public|private|internal",
       "signature": "シグネチャまたは定義の概要",
       "usedBy": ["path/to/consumer1"]
     }
@@ -130,6 +135,23 @@ skills: coding-standards, project-context, technical-spec
     ],
     "migrationFiles": ["path/to/migration/files"]
   },
+  "dataTransformationPipelines": [
+    {
+      "entryPoint": "ClassName.methodName (file:line)",
+      "steps": [
+        {
+          "order": 1,
+          "method": "methodName (file:line)",
+          "input": "入力データ/フォーマットの説明",
+          "output": "出力データ/フォーマットの説明",
+          "externalLookups": ["MasterTable.getData() でコード変換"],
+          "transformation": "何が変わるか（例: 生値がルックアップテーブル経由で表示値にマッピング）"
+        }
+      ],
+      "intermediateFormats": ["中間データ表現の説明（該当する場合）"],
+      "finalOutput": "最終出力データ/フォーマットの説明"
+    }
+  ],
   "constraints": [
     {
       "type": "validation|business_rule|configuration|assumption",
@@ -157,8 +179,10 @@ skills: coding-standards, project-context, technical-spec
 ## 完了条件
 
 - [ ] 入力された要件分析結果を解析し分析カテゴリを特定した
-- [ ] 全影響ファイルを読み込み、file:line参照付きでpublicインターフェースを抽出した
-- [ ] 各影響ファイルの1階層のインポートをトレースした
+- [ ] 全影響ファイルを全文読み込み、file:line参照付きですべてのインターフェース、型、関数、メソッド、クラスを全可視性レベル（public, private, internal）で抽出した — または不完全なファイルを`limitations`に記録した
+- [ ] スコープルールに従いコールチェーンをトレースした（同一ファイル: 再帰的、外部: publicインターフェースのみ） — または不完全なトレースを`limitations`に記録した
+- [ ] 各publicエントリポイントについてステップごとの入力→出力マッピングでデータ変換パイプラインを特定した
+- [ ] 出力値を変更するすべての外部リソース参照（マスタテーブル、設定値、定数）を記録した
 - [ ] Grepでデータアクセス、外部統合、バリデーションパターンを検索した
 - [ ] データアクセス検出時: スキーマ定義をトレースしフィールドレベルの詳細を抽出した
 - [ ] file:lineエビデンス付きで制約を抽出した
@@ -173,4 +197,6 @@ skills: coding-standards, project-context, technical-spec
 - [ ] スキーマフィールド名が実際の定義と一致（類似テーブルからの推測ではない）
 - [ ] 各注目領域が具体的なファイルと具体的なリスクを引用
 - [ ] `dataModel.detected`がデータ操作の検出有無を正確に反映
+- [ ] `dataTransformationPipelines`がデータを変換するすべてのエントリポイントについて記録されている（変換が存在しない場合のみ空配列）
+- [ ] 各パイプラインステップの`externalLookups`が出力値を変更するすべてのマスタテーブル/設定値/定数参照を列挙
 - [ ] limitationsセクションが読み込めなかったファイルやトレースできなかったパターンを記録

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/document-reviewer.md

@@ -106,6 +106,7 @@ DesignDocの場合、追加で以下を確認:
   - 検証手法が変更のリスクと依存タイプに対して十分であること — 主要なリスクカテゴリ（スキーマの正しさ、振る舞いの同等性、統合互換性等）を検出できない手法 → `important`（カテゴリ: `consistency`）
   - 早期検証ポイントが具体的な最初の対象を特定していること — 「TBD」や「最終フェーズ」→ `important`（カテゴリ: `completeness`）
   - 垂直スライス選択時に、検証タイミングが最終フェーズのみに後回し → `important`（カテゴリ: `consistency`）
+- **出力比較チェック**: Design Docが既存の振る舞いの置換または変更を記述している場合、具体的な出力比較手法が定義されていることを検証する（同一入力、期待される出力フィールド/フォーマット、差分比較方法）。既存の振る舞いを置換または変更する設計で出力比較が未定義 → `critical`（カテゴリ: `completeness`）。コードベース分析の`dataTransformationPipelines`が参照されている場合、各パイプラインステップの出力が比較対象としてカバーされていること — 未カバーのステップ → `important`（カテゴリ: `completeness`）
 
 **観点特化モード**:
 - 指定されたmodeとfocusに基づいてレビューを実施
@@ -263,6 +264,7 @@ DesignDocの場合、追加で以下を確認:
 - [ ] コード検証結果（提供された場合）がドキュメント内容と照合済み
 - [ ] 検証戦略に具体的な正しさの定義と早期検証ポイントが存在すること
 - [ ] 検証戦略がdesign_typeと実装アプローチに整合していること
+- [ ] 既存の振る舞いを置換/変更する設計で出力比較が定義されていること（全変換パイプラインステップをカバー）
 
 ## レビュー基準（総合モード用）
 

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

@@ -62,7 +62,7 @@ Design Doc作成前に必ず実施：
    - 既存実装の場所と新規作成予定の場所を区別して記録
 
 2. **既存インターフェース調査**（既存機能変更時のみ）
-   - 変更対象サービスの主要publicメソッドを列挙（10個超の場合は重要な5個程度）
+   - 変更対象サービスのすべてのpublicメソッドを完全なシグネチャ付きで列挙
    - `Grep: "ServiceName\." --type ts` で呼び出し箇所を特定
 
 3. **類似機能の検索と判断**（coding-standardsスキル パターン5対策）
@@ -153,7 +153,8 @@ Design Doc作成時に必ず実施：
    - new_featureの場合: ユニットテスト以上のAC検証手法を明記（例: 実依存に対する統合テスト）
    - extensionの場合: 既存の振る舞いが維持されつつ新しい振る舞いが追加されることを証明する回帰検証手法を明記
    - refactoringの場合: 振る舞いの同等性を検証する手法を明記（例: 既存実装との出力比較）
-   - 早期検証ポイントを定義: アプローチの妥当性を本格展開前に確認するため、最初に何を、どうやって検証するか
+   - **出力比較要件**（既存の振る舞いを置換または変更するすべてのdesign_type）: 具体的な出力比較手法を定義する — 同一入力、期待される出力フィールド/フォーマット、差分の比較方法を明記。コードベース分析から`dataTransformationPipelines`が提供されている場合、各パイプラインステップの出力が比較の対象としてカバーされていること
+   - 早期検証ポイントを定義: アプローチの妥当性を本格展開前に確認するため、最初に何を、どうやって検証するか。置換/変更の場合、早期検証ポイントのデフォルトは少なくとも1つの代表的なケースでの出力比較とする。例外: 主要リスクが振る舞いの同等性以外にある場合（例: スキーマ互換性、統合コントラクト）は代替の検証対象を明記し、出力比較を後段に回す理由を記録
 
 ### 変更影響マップ【必須】
 Design Doc作成時に必ず含める:
@@ -214,6 +215,7 @@ Design Doc作成前に実施：
   - `dataModel` → データ関連セクション（スキーマ参照、データ契約）に反映
   - `focusAreas` → フラグされた領域の調査深度を優先
   - `constraints` → 設計上の制約と前提条件に組み込む
+  - `dataTransformationPipelines` → 検証戦略の出力比較セクションに反映（各パイプラインステップが比較手法でカバーされていること）
   - 分析でカバーされていない領域、または`limitations`でフラグされた領域についてのみ追加調査を実施
 - **PRD**: PRDドキュメント（存在する場合）
 - **作成するドキュメント**: ADR、Design Doc、または両方
@@ -308,6 +310,7 @@ ADRに含まない：スケジュール、実装手順、具体的コード
 - [ ] **データ構造の採用判断の文書化**（新規構造導入時）
 - [ ] **フィールド伝播マップの記載**（フィールドが境界を越える場合）
 - [ ] **検証戦略の定義**（正しさの定義、検証手法、タイミング、早期検証ポイント）
+- [ ] **出力比較の定義**（既存の振る舞いを置換/変更する場合）（入力、期待される出力フィールド、差分比較方法。コードベース分析の全変換パイプラインステップをカバー）
 
 **reverse-engineerモード限定**:
 - [ ] すべてのアーキテクチャ主張がfile:lineをevidenceとして引用
@@ -339,8 +342,8 @@ ADRに含まない：スケジュール、実装手順、具体的コード
 - UIの表現方法（レイアウト、スタイル） → 情報の有無に集中
 
 **記述例**:
-- ❌ 実装詳細: "データは特定の技術Xで保存"
-- ✅ 観測可能な振る舞い: "保存したデータは再起動後も取得できる"
+- 実装詳細（避ける）: "データは特定の技術Xで保存"
+- 観測可能な振る舞い（推奨）: "保存したデータは再起動後も取得できる"
 
 *注: 非機能要件（パフォーマンス、信頼性、スケーラビリティ）は「非機能要件」セクションで定義*