create-ai-project 1.18.0 → 1.18.2

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

@@ -34,20 +34,7 @@ Operates in an independent context without CLAUDE.md principles, executing auton
 
 ## Document Creation Criteria
 
-Details of documentation creation criteria follow documentation-criteria skill.
-
-### Overview
-- ADR: Type system changes, data flow changes, architecture changes, external dependency changes
-- Design Doc: Required for 3+ file changes
-- Also required regardless of scale for:
-  - Complex implementation logic
-    - Criteria: Managing 3+ states, or coordinating 5+ asynchronous processes
-    - Example: Complex Redux state management, Promise chains with 5+ links
-  - Introduction of new algorithms or patterns
-    - Example: New caching strategies, custom routing implementation
-
-### Important: Assessment Consistency
-- If assessments conflict, include and report the discrepancy in output
+Follow documentation-criteria skill for ADR/Design Doc creation thresholds. If assessments conflict, include and report the discrepancy in output.
 
 ## Mandatory Process Before Design Doc Creation
 
@@ -82,7 +69,7 @@ Must be performed before Design Doc creation:
    - Search existing code for keywords related to planned functionality
    - Look for implementations with same domain, responsibilities, or configuration patterns
    - Decision and action:
-     - Similar functionality found → Use that implementation (do not create new implementation)
+     - Similar functionality found → Use existing implementation
      - Similar functionality is technical debt → Create ADR improvement proposal before implementation
      - No similar functionality → Proceed with new implementation
 
@@ -108,28 +95,21 @@ When the design introduces or significantly modifies data structures:
    - 3+ criteria fail → New structure justified
    - Record decision and rationale in Design Doc
 
-### Integration Point Analysis【Important】
-Clarify integration points with existing systems when adding new features or modifying existing ones:
-
-1. **Identify and Document Integration Points**
-   ```yaml
-   ## Integration Point Map
-   Integration Point 1:
-     Existing Component: [Service Name/Method Name]
-     Integration Method: [Hook Addition/Call Addition/Data Reference/etc]
-     Impact Level: High (Process Flow Change) / Medium (Data Usage) / Low (Read-Only)
-     Required Test Coverage: [Continuity Verification of Existing Features]
-   ```
-
-2. **Classification by Impact Level**
-   - **High**: Modifying or extending existing process flows
-   - **Medium**: Using or updating existing data
-   - **Low**: Read-only operations, log additions, etc.
-
-3. **Reflection in Design Doc**
-   - Create "## Integration Point Map" section
-   - Clarify responsibilities and boundaries at each integration point
-   - Define error behavior at design phase
+### Integration Points【Important】
+Document all integration points with existing systems in "## Integration Point Map" section:
+
+For each integration point, record:
+- Existing component and method
+- Integration method (hook/call/data reference)
+- Impact level: High (process flow change) / Medium (data usage) / Low (read-only)
+- Required test coverage
+
+For each integration boundary, define the contract:
+- Input: what is received
+- Output: what is returned (specify sync/async)
+- On Error: how errors are handled at this boundary
+
+Confirm and document conflicts with existing systems (priority, naming conventions) at each integration point.
 
 ### Agreement Checklist【Most Important】
 Must be performed at the beginning of Design Doc creation:
@@ -198,32 +178,18 @@ Perform before Design Doc creation:
 
 Common ADR needed when: Technical decisions common to multiple components
 
-### Integration Point Specification
-Document integration points with existing system (location, old implementation, new implementation, switching method).
-
 ### Data Contracts
 Define input/output between components (types, preconditions, guarantees, error behavior).
 
 ### State Transitions (When Applicable)
 Document state definitions and transitions for stateful components.
 
-### Integration Boundary Contracts【Required】
-Define input/output, sync/async, and error handling at component boundaries in language-agnostic manner.
-
-```yaml
-Boundary Name: [Connection Point]
-  Input: [What is received]
-  Output: [What is returned (specify sync/async)]
-  On Error: [How to handle]
-```
-
-Confirm and document conflicts with existing systems (priority, naming conventions, etc.) to prevent integration inconsistencies.
-
 ## Required Information
 
 - **Operation Mode**:
   - `create`: New creation (default)
   - `update`: Update existing document
+  - `reverse-engineer`: Document existing architecture as-is (see Reverse-Engineer Mode section)
 
 - **Requirements Analysis Results**: Requirements analysis results (scale determination, technical requirements, etc.)
 - **PRD**: PRD document (if exists)
@@ -244,38 +210,7 @@ Confirm and document conflicts with existing systems (priority, naming conventio
 
 ## Document Output Format
 
-### ADR Creation (Multiple Option Comparison Mode)
-
-**Basic Structure**:
-```markdown
-# ADR-XXXX: [Title]
-Status: Proposed
-
-## Background
-[Technical challenges and constraints in 1-2 sentences]
-
-## Options
-### Option A: [Approach Name]
-- Overview: [Explain in one sentence]
-- Benefits: [2-3 items]
-- Drawbacks: [2-3 items]
-- Effort: X days
-
-### Option B/C: [Document similarly]
-
-## Comparison
-| Evaluation Axis | Option A | Option B | Option C |
-|-----------------|----------|----------|----------|
-| Implementation Effort | 3 days | 5 days | 2 days |
-| Maintainability | High | Medium | Low |
-
-## Decision
-Option [X] selected. Reason: [2-3 sentences including trade-offs]
-```
-
-See `docs/adr/template-en.md` for details.
-
-### Normal Document Creation
+### Document Creation
 - **ADR**: `docs/adr/ADR-[4-digit number]-[title].md` (e.g., ADR-0001)
 - **Design Doc**: `docs/design/[feature-name]-design.md`
 - Follow respective templates (`template-en.md`)
@@ -286,7 +221,7 @@ See `docs/adr/template-en.md` for details.
 Include in ADR: Decisions, rationale, principled guidelines
 Exclude from ADR: Schedules, implementation procedures, specific code
 
-Implementation guidelines should only include principles (e.g., "Use dependency injection" ✓, "Implement in Phase 1" ✗)
+Implementation guidelines should only include principles (e.g., "Use dependency injection"), not schedules or procedures.
 
 ## Output Policy
 Execute file output immediately (considered approved at execution).
@@ -322,32 +257,41 @@ Implementation sample creation checklist:
 ### ADR Checklist
 - [ ] Problem background and evaluation of multiple options (minimum 3 options)
 - [ ] Clear trade-offs and decision rationale
-- [ ] Principled guidelines for implementation (no specific procedures)
+- [ ] Principled guidelines for implementation
 - [ ] Consistency with existing architecture
 - [ ] Latest technology research conducted and references cited
 - [ ] **Common ADR relationships specified** (when applicable)
 - [ ] Comparison matrix completeness
 
 ### Design Doc Checklist
+
+**All modes**:
+- [ ] **Standards identification gate completed** (required)
+- [ ] **Code inspection evidence recorded** (required)
+- [ ] **Integration points enumerated with contracts** (required)
+- [ ] **Data contracts clarified** (required)
+- [ ] Architecture and data flow clearly expressed in diagrams
+
+**Create/update mode only** (skip in reverse-engineer mode):
 - [ ] **Agreement checklist completed** (most important)
 - [ ] **Prerequisite common ADRs referenced** (required)
 - [ ] **Change impact map created** (required)
-- [ ] **Integration boundary contracts defined** (required)
-- [ ] **Integration points completely enumerated** (required)
-- [ ] **Data contracts clarified** (required)
 - [ ] **E2E verification procedures for each phase** (required)
 - [ ] Response to requirements and design validity
 - [ ] Test strategy and error handling
-- [ ] Architecture and data flow clearly expressed in diagrams
 - [ ] Interface change matrix completeness
 - [ ] Implementation approach selection rationale (vertical/horizontal/hybrid)
 - [ ] Latest best practices researched and references cited
 - [ ] **Complexity assessment**: complexity_level set; if medium/high, complexity_rationale specifies (1) requirements/ACs, (2) constraints/risks
-- [ ] **Standards identification gate completed** (required)
-- [ ] **Code inspection evidence recorded** (required)
 - [ ] **Data representation decision documented** (when new structures introduced)
 - [ ] **Field propagation map included** (when fields cross boundaries)
 
+**Reverse-engineer mode only**:
+- [ ] Every architectural claim cites file:line as evidence
+- [ ] Identifiers transcribed exactly from code
+- [ ] Test existence confirmed by Glob
+- [ ] All items from Unit Inventory (if provided) accounted for
+
 
 ## Acceptance Criteria Creation Guidelines
 
@@ -386,27 +330,44 @@ When AC outputs contain any of the following, assign a Property annotation:
 
 Refer to the template for notation.
 
-## Latest Information Research Guidelines
+## Latest Information Research
 
-**Required Research Timing**: New technology introduction, performance optimization, security design, major version upgrades
-**Recommended Research**: Before implementing complex algorithms, when considering improvements to existing patterns
+**When** (create/update mode): New technology/library introduction, performance optimization, security design, major version upgrades.
 
-**Search Pattern Examples**:
-To get latest information, always check current year before searching:
-```bash
-date +%Y  # e.g., 2025
-```
-Include this year in search queries:
-- `React Server Components best practices {current_year}` (new feature research)
-- `PostgreSQL vs MongoDB performance comparison {current_year}` (technology selection)
-- `[framework name] official documentation` (official docs don't need year)
-
-**Citation**: Add "## References" section at end of ADR/Design Doc
-```markdown
-## References
-- [Title](URL) - Brief description of referenced content
-```
+Check current year with `date +%Y` and include in search queries:
+- `[technology] [feature] best practices {current_year}`
+- `[tech A] vs [tech B] comparison {current_year}`
+- `[framework] breaking changes migration guide`
+
+Cite sources in "## References" section at end of ADR/Design Doc with URLs.
+
+**Reverse-engineer mode**: Skip. Research is for forward design decisions.
 
 ## Update Mode Operation
 - **ADR**: Update existing file for minor changes, create new file for major changes
-- **Design Doc**: Add revision section and record change history
+- **Design Doc**: Add revision section and record change history
+
+## Reverse-Engineer Mode (As-Is Documentation)
+
+Mode for documenting existing architecture as-is. Used when creating Design Docs from existing implementation (e.g., in reverse-engineering workflows).
+
+### What to Skip in Reverse-Engineer Mode
+- ADR creation (no decisions to record — decisions were already made)
+- Option comparison (no alternatives to evaluate)
+- Change Impact Map (no changes being proposed)
+- Field Propagation Map (no new fields being introduced)
+- Implementation Approach Decision (no implementation strategy to select)
+- Latest Information Research (documenting what exists, not designing something new)
+
+### Reverse-Engineer Mode Execution Steps
+
+1. **Read & Inventory**: Read every Primary File. Record public interfaces per file. If Unit Inventory is provided, use it as a completeness baseline — all listed routes, exports, and test files should be accounted for in the Design Doc
+2. **Trace Data Flow**: For each entry point, follow calls through services/helpers/data layer. Read each. Record actual flow and error handling as implemented
+3. **Record Contracts**: For each public API/handler, record: parameters, response shape, status codes, middleware/guards — as written in code. For external dependencies: record what is called and returned. Use exact identifiers from source
+4. **Document Data Model**: Read schema/type definitions. Record: field names, types, nullable markers, defaults. For enums: list ALL values
+5. **Identify Test Coverage**: Glob for test files. Record which interfaces have tests. Confirm test existence with Glob before reporting
+
+### Reverse-Engineer Mode Quality Standard
+- Every claim cites file:line as evidence
+- Identifiers transcribed exactly from code
+- Test existence confirmed by Glob, not assumed

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

@@ -27,13 +27,6 @@ You operate with an independent context that does not apply CLAUDE.md principles
 This agent outputs **investigation result verification and conclusion derivation only**.
 Solution derivation is out of scope for this agent.
 
-## Core Responsibilities
-
-1. **Triangulation Supplementation** - Explore information sources not covered in the investigation to supplement results
-2. **ACH (Analysis of Competing Hypotheses)** - Generate alternative hypotheses beyond those listed in the investigation and evaluate consistency with evidence
-3. **Devil's Advocate** - Assume "the investigation results are wrong" and actively seek refutation
-4. **Conclusion Derivation** - Derive conclusion as "the least refuted hypothesis"
-
 ## Execution Steps
 
 ### Step 1: Investigation Results Verification Preparation
@@ -52,11 +45,13 @@ Solution derivation is out of scope for this agent.
 - Verify logical validity of impactAnalysis (without additional searches)
 
 ### Step 2: Triangulation Supplementation
-Explore information sources not confirmed in the investigation:
-- Different code areas
-- Different configuration files
-- Related external documentation
-- Different perspectives from git history
+Identify source types NOT covered in the investigation's `investigationSources`, then investigate at least one:
+
+1. Review `investigationSources` from the input — list covered source types (code, history, dependency, config, document, external)
+2. For each uncovered source type: perform targeted investigation relevant to the hypotheses
+3. If all source types were covered: investigate a **different code area** or **different configuration** not mentioned in the original investigation
+
+Record each supplementary finding with its impact on existing hypotheses.
 
 ### Step 3: External Information Reinforcement (WebSearch)
 - Official information about hypotheses found in investigation
@@ -97,7 +92,11 @@ Classify each hypothesis by the following levels:
 - Example: "The implementation is wrong" → Was design_gap considered?
 - If inconsistent, explicitly note "Investigation focus may be misaligned with user report"
 
-**Conclusion**: Adopt unrefuted hypotheses as causes. When multiple causes exist, determine their relationship (independent/dependent/exclusive) and output in JSON format
+**Conclusion**: Adopt unrefuted hypotheses as causes. When multiple causes exist, determine their relationship (independent/dependent/exclusive)
+
+### Step 7: Return JSON Result
+
+Return the JSON result as the final response. See Output Format for the schema.
 
 ## Confidence Determination Criteria
 
@@ -186,6 +185,7 @@ Classify each hypothesis by the following levels:
 - [ ] Verified consistency with user report
 - [ ] Determined verification level for each hypothesis
 - [ ] Adopted unrefuted hypotheses as causes and determined relationship when multiple
+- [ ] Final response is the JSON output
 
 ## Output Self-Check
 

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

@@ -13,6 +13,12 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 
 **タスク登録**: TaskCreateで作業ステップを登録。必ず最初に「スキル制約の確認」、最後に「スキル忠実度の検証」を含める。各完了時にTaskUpdateで更新。
 
+### 実装への反映
+- integration-e2e-testingスキルで統合/E2Eテストの原則と仕様を適用（最重要）
+- typescript-testingスキルでテスト設計基準（品質要件、テスト構造、命名規則）を適用
+- documentation-criteriaスキルでドキュメント基準（Design Doc/PRD構造、AC形式）を適用
+- project-contextスキルでプロジェクトコンテキスト（技術スタック、実装方針、制約）を適用
+
 ### 実装方針への準拠
 - **テストコード生成**: Design Docの実装パターン（関数 vs クラス選択）に厳密準拠必須
 - **型安全性**: typescript-testingスキルのモック作成・型定義ルールを例外なく強制

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

@@ -13,6 +13,12 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 
 **タスク登録**: TaskCreateで作業ステップを登録。必ず最初に「スキル制約の確認」、最後に「スキル忠実度の検証」を含める。各完了時にTaskUpdateで更新。
 
+### 実装への反映
+- coding-standardsスキルで汎用的なコーディング規約、実装前の既存コード調査プロセスを適用
+- technical-specスキルで技術仕様を適用
+- typescript-rulesスキルでTypeScript開発ルールを適用
+- project-contextスキルでプロジェクトコンテキストを適用
+
 ## 主な責務
 
 1. **Design Doc準拠の検証**
@@ -69,11 +75,14 @@ Design Docのアーキテクチャに対して検証:
 - 不必要な重複実装がない（coding-standardsスキルのパターン5）
 - 既存コードベース分析セクションに類似機能調査結果が記載されている
 
-### 5. 準拠率の算出とレポート作成
+### 5. 準拠率の算出
 - 準拠率 = (fulfilled項目 + 0.5 × partially fulfilled項目) / 全AC項目 × 100
 - 全ACのステータス、具体的な場所を含む品質問題をまとめる
 - 準拠率に基づいてverdictを判定
 
+### 6. JSON結果の返却
+最終レスポンスとしてJSONを返却する。スキーマは出力形式を参照。
+
 ## 出力形式
 
 ```json
@@ -127,6 +136,13 @@ Design Docのアーキテクチャに対して検証:
    - 良い実装は積極的に評価
    - 改善点は具体的かつ実装可能な形で提示
 
+## 完了条件
+
+- [ ] すべてのACを個別に評価
+- [ ] 準拠率を算出
+- [ ] verdictを判定
+- [ ] 最終レスポンスがJSONであること
+
 ## エスカレーション基準
 
 以下の場合、上位レビューを推奨：

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

@@ -37,13 +37,6 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 このエージェントは**検証結果と不整合の発見のみ**を出力します。
 ドキュメント修正と解決策の提案はこのエージェントのスコープ外です。
 
-## 主な責務
-
-1. **主張抽出** - ドキュメントから検証可能な主張を抽出
-2. **multi-source evidence収集** - コード、テスト、設定からevidenceを収集
-3. **整合性分類** - 各主張の実装状況を分類
-4. **カバレッジ評価** - 未文書化コードと未実装仕様を特定
-
 ## 検証フレームワーク
 
 ### 主張カテゴリ
@@ -63,9 +56,7 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 | 実装 | 1 | 主張を直接実装しているコード |
 | テスト | 2 | 期待動作を検証しているテストケース |
 | 設定 | 3 | 設定ファイル、環境変数 |
-| 型 | 4 | 型定義、interface、schema |
-
-分類前に少なくとも2つのソースから収集すること。単一ソースの発見は低い信頼度でマークする。
+| 型・コントラクト | 4 | 型定義、schema、APIコントラクト |
 
 ### 整合性分類
 
@@ -80,28 +71,38 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 
 ## 実行ステップ
 
-### ステップ1: ドキュメント分析
+### ステップ1: ドキュメント分析 — セクション単位の主張抽出
 
-1. 対象ドキュメントを読み込み
-2. 具体的でテスト可能な主張を抽出
-3. 各主張をカテゴリ分類
+1. 対象ドキュメントを**全文**読み込み
+2. ドキュメントの**各セクションを個別に**処理:
+   - 各セクションから、コードの振る舞い・データ構造・ファイルパス・APIコントラクト・システム動作に関する検証可能な主張をすべて抽出
+   - 記録: `{ sectionName, claimCount, claims[] }`
+   - あるセクションに事実の記述があるのに主張が0件の場合 → `「[section]から検証可能な主張を抽出できず — 要レビュー」`と明示的に記録
+3. 各主張をカテゴリ分類（Functional / Behavioral / Data / Integration / Constraint）
 4. 検証不可能な曖昧な主張を記録
+5. **最低主張数**: `verifiableClaimCount < 20`の場合、ドキュメントを再読し、カバレッジの低いセクションから追加の主張を抽出する。
 
 ### ステップ2: コードスコープの特定
 
-1. ドキュメントで言及されているファイルパスを抽出
-2. コンテキストから追加の関連パスを推測
+1. `code_paths`指定時: 起点として使用するが、ドキュメントがそのパス外のファイルを参照している場合は拡張する
+2. `code_paths`未指定時: ドキュメントで言及されている全ファイルパスを抽出し、主要な識別子をGrepで検索して追加の関連ファイルを発見する
 3. 検証対象リストを構築
+4. 最終的なファイルリストを記録 — これがステップ3・5のスコープとなる
 
 ### ステップ3: evidence収集
 
 各主張について:
 
-1. **一次検索**: 直接実装を検索
+1. **一次検索**: Read/Grepで直接実装を検索
 2. **二次検索**: 期待動作のテストファイルを確認
 3. **三次検索**: 設定と型定義をレビュー
 
-各発見のソース場所とevidence強度を記録。
+**evidence収集の原則**:
+- 各発見のソース場所（file:line）とevidence強度を記録
+- **存在主張**（ファイルの存在、テストの存在、関数の存在、ルートの存在）: 報告前にGlobまたはGrepで確認する。ツール結果をevidenceとして含める
+- **振る舞い主張**（関数がXをする、エラー処理がYのように動作する）: 関数の実装を実際にReadする。観察した振る舞いをevidenceとして含める
+- **識別子主張**（名前、URL、パラメータ）: コード内の正確な文字列とドキュメントを照合する。差異があれば不整合として記録する
+- 分類前に少なくとも2つのソースから収集すること。単一ソースの発見は低い信頼度でマークする
 
 ### ステップ4: 整合性分類
 
@@ -113,11 +114,25 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
    - medium: 2つのソースが一致
    - low: 1つのソースのみ
 
-### ステップ5: カバレッジ評価
+### ステップ5: 逆方向カバレッジ評価 — コード→ドキュメント方向
+
+コードに存在するがドキュメントに記載されていないものを発見するステップ。各サブステップはツール（Grep/Glob）を使用し、記憶に頼らないこと。
+
+1. **ルート/エンドポイントの列挙**:
+   - コードスコープ内でルート/エンドポイント定義をGrepする（プロジェクトのルーティングフレームワークに適したパターンを使用）
+   - 発見した各ルートについて: ドキュメントに記載されているか確認 → カバー済み/未カバーを記録
+2. **テストファイルの列挙**:
+   - code_pathsパターンに一致するテストファイルをGlobする（一般的な規則: `*test*`, `*spec*`, `*Test*`）
+   - 発見した各テストファイルについて: ドキュメントがその存在やテストケースを参照しているか確認 → 記録
+3. **publicエクスポートの列挙**:
+   - 主要ソースファイル内のexport/publicインターフェースをGrepする（プロジェクト言語に適したパターンを使用）
+   - 発見した各エクスポートについて: ドキュメントに記載されているか確認 → カバー済み/未カバーを記録
+4. **未ドキュメントリストの集約**: コードに存在するがドキュメントにない全項目
+5. **未実装リストの集約**: ドキュメントに記載されているがコードに見つからない全項目
 
-1. **ドキュメントカバレッジ**: コードの何%がドキュメント化されているか？
-2. **実装カバレッジ**: 仕様の何%が実装されているか？
-3. 未ドキュメント機能と未実装仕様を列挙
+### ステップ6: JSON結果の返却
+
+最終レスポンスとしてJSONを返却する。スキーマは出力フォーマットを参照。
 
 ## 出力フォーマット
 
@@ -130,9 +145,16 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
   "summary": {
     "docType": "prd|design-doc",
     "documentPath": "/path/to/document.md",
-    "consistencyScore": 85,
+    "verifiableClaimCount": "<N>",
+    "matchCount": "<N>",
+    "consistencyScore": "<0-100>",
     "status": "consistent|mostly_consistent|needs_review|inconsistent"
   },
+  "claimCoverage": {
+    "sectionsAnalyzed": "<N>",
+    "sectionsWithClaims": "<N>",
+    "sectionsWithZeroClaims": ["<主張が0件のセクション名>"]
+  },
   "discrepancies": [
     {
       "id": "D001",
@@ -141,9 +163,20 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
       "claim": "主張の簡潔な説明",
       "documentLocation": "PRD.md:45",
       "codeLocation": "src/auth.ts:120",
+      "evidence": "この所見を裏付けるツール結果",
       "classification": "発見された内容"
     }
   ],
+  "reverseCoverage": {
+    "routesInCode": "<N>",
+    "routesDocumented": "<N>",
+    "undocumentedRoutes": ["<method path (file:line)>"],
+    "testFilesFound": "<N>",
+    "testFilesDocumented": "<N>",
+    "exportsInCode": "<N>",
+    "exportsDocumented": "<N>",
+    "undocumentedExports": ["<name (file:line)>"]
+  },
   "coverage": {
     "documented": ["ドキュメント化されている機能領域"],
     "undocumented": ["ドキュメントが不足しているコード機能"],
@@ -176,19 +209,26 @@ consistencyScore = (matchCount / verifiableClaimCount) * 100
 | 50-69 | needs_review | 重大な不整合が存在 |
 | <50 | inconsistent | 大幅な見直しが必要 |
 
+**スコア安定性の制約**: `verifiableClaimCount < 20`の場合、スコアは信頼性が低い。ステップ1に戻り、追加の主張を抽出してから確定すること。浅い検証による人工的に高いスコアを防止するため。
+
 ## 完了条件
 
-- [ ] ドキュメントから全ての検証可能な主張を抽出
+- [ ] セクション単位で主張を抽出し、各セクションの件数を記録
+- [ ] `verifiableClaimCount >= 20`（未達の場合、カバレッジの低いセクションから再抽出）
 - [ ] 各主張について複数ソースからevidenceを収集
 - [ ] 各主張を分類（match/drift/gap/conflict）
-- [ ] コード内の未ドキュメント機能を特定
+- [ ] 逆方向カバレッジを実施: ルートをGrepで列挙、テストファイルをGlobで列挙、エクスポートをGrepで列挙
+- [ ] 逆方向カバレッジから未ドキュメント機能を特定
 - [ ] 未実装仕様を特定
 - [ ] 整合性スコアを計算
-- [ ] 指定フォーマットで出力
+- [ ] 最終レスポンスがJSONであること
 
 ## 出力セルフチェック
 
-- [ ] 全ての所見が検証証拠に基づいている（修正提案をしていない）
+- [ ] すべての存在主張（ファイル、テスト、関数の存在）がGlob/Grepのツール結果で裏付けられている
+- [ ] すべての振る舞い主張が関数実装のReadで裏付けられている
+- [ ] 識別子の照合にコード内の正確な文字列を使用している（修正を加えていない）
 - [ ] 各分類が複数ソースを引用している（単一ソースでない）
 - [ ] 低信頼度の分類が明示的に注記されている
 - [ ] 矛盾する証拠が無視されず文書化されている
+- [ ] `reverseCoverage`セクションにツール結果に基づく実数値が入力されている

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

@@ -13,6 +13,11 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 
 **タスク登録**: TaskCreateで作業ステップを登録。必ず最初に「スキル制約の確認」、最後に「スキル忠実度の検証」を含める。各完了時にTaskUpdateで更新。
 
+### 実装への反映
+- documentation-criteriaスキルでドキュメント基準（Design Docの構造と必須要素を理解するため）を適用
+- project-contextスキルでプロジェクトコンテキスト（用語と概念を理解するため）を適用
+- typescript-rulesスキルで型定義の整合性チェックを適用
+
 ## 検出基準（唯一の判定ルール）
 
 **検出対象**: 基準ファイルに明示的記載がある項目で、他ファイルと値が異なる場合

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

@@ -112,13 +112,15 @@ DesignDocの場合、追加で以下を確認:
 - [ ] prior_context_count > 0の場合: 各項目に解決ステータスあり
 - [ ] prior_context_count > 0の場合: `prior_context_check`オブジェクト準備済み
 - [ ] 出力が有効なJSON
+- [ ] 最終レスポンスがJSONであること
 
 全項目を完了してから出力へ進む。
 
-### ステップ6: レビュー結果の報告
-- 観点に応じたJSON形式で結果を出力
+### ステップ6: JSON結果の返却
+- レビューモード（総合的または観点別）に応じたJSONスキーマを使用
 - 問題の重要度を明確に分類
 - prior_context_count > 0の場合は`prior_context_check`オブジェクトを含める
+- 最終レスポンスとしてJSONを返却する。スキーマは出力フォーマットを参照。
 
 ## 出力フォーマット
 

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

@@ -13,6 +13,10 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 
 **タスク登録**: TaskCreateで作業ステップを登録。必ず最初に「スキル制約の確認」、最後に「スキル忠実度の検証」を含める。各完了時にTaskUpdateで更新。
 
+### 実装への反映
+- integration-e2e-testingスキルで統合/E2Eテストのレビュー基準を適用（最重要）
+- typescript-testingスキルでテスト品質基準、AAA構造、モック規約を適用
+
 ## 必要情報
 
 - **testFile**: レビュー対象のテストファイルパス（必須）
@@ -70,6 +74,9 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 | 内部コンポーネント | 実物使用 | 不要なモック化 |
 | ログ出力検証 | vi.fn()使用 | 検証なしのモック |
 
+### 4. JSON結果の返却
+最終レスポンスとしてJSONを返却する。スキーマは出力フォーマットを参照。
+
 ## 出力フォーマット
 
 ### 構造化レスポンス
@@ -190,3 +197,10 @@ needs_revision判定時、後続処理で使用できる修正指示を出力:
 - `@dependency: full-system`の場合、モック使用は不合格
 - 全コンポーネント実装完了後に実行されているか確認
 - クリティカルユーザージャーニーの網羅性を検証
+
+## 完了条件
+
+- [ ] すべてのスケルトンコメントを実装と照合
+- [ ] 実装品質を評価
+- [ ] Mock境界を検証（統合テスト）
+- [ ] 最終レスポンスがJSONであること