@k2works/claude-code-booster 3.7.0 → 3.8.1

package/lib/assets/.claude/skills/orchestrating-development/SKILL.md

@@ -1,162 +1,168 @@
----
-name: orchestrating-development
-description: 開発フェーズ全体の TDD ワークフローをオーケストレーション。バックエンド・フロントエンドの開発順序と TDD サイクルの実践方法を案内し、Codex 分業体制もサポートする。「開発を始めたい」「TDD の進め方を知りたい」「Codex と分業で開発したい」「開発フェーズの全体像を把握したい」といった場面で発動する。開発フローを標準化することで、品質のブレを防ぎチーム全体の生産性を底上げする。
----
-
-# 開発フェーズオーケストレーション
-
-開発フェーズ全体のワークフローを案内する。TDD サイクルに従い、バックエンド→フロントエンドの順序で品質を担保しながら開発を進める。
-
-## オプション
-
-| オプション | 説明 |
-|-----------|------|
-| なし | 開発フェーズ全体のワークフローを表示 |
-| `--codex` | Claude（計画・設計・受入）と Codex（実装）の分業体制で開発 |
-
-## 開発フェーズの全体像
-
-1. **バックエンド開発** (Skill: `developing-backend`) — インサイドアウトアプローチ推奨
-2. **フロントエンド開発** (Skill: `developing-frontend`) — アウトサイドインアプローチ推奨
-
-各開発で Red-Green-Refactor サイクルを厳密に実行する。テストなしでプロダクションコードを書かない。
-
-### レビューポイント
-
-コーディングとテストガイドのイテレーション開発フローに準拠し、以下のタイミングでレビュースキルを発動する。
-
-| タイミング | スキル | 説明 |
-|-----------|--------|------|
-| TODO 完了時（コードレビュー） | `developing-review` | TDD サイクルで TODO を完了するたびにコード品質・テスト品質・設計整合性をレビュー |
-| 受け入れ前（品質チェック） | `operating-qt` | SonarQube によるコード品質分析・Quality Gate 確認を実施し、品質基準を満たしていることを検証 |
-| イテレーション完了時（ユーザーレビュー） | `analyzing-review` | 受け入れフェーズでユーザー視点・プロダクト視点からの成果物レビュー |
-
-## TDD サイクル
-
-TDD は「テストを書いてからコードを書く」手順ではなく、「設計を小さなフィードバックループで検証する」手法。10-15 分で 1 サイクルを完了させる。
-
-1. **Red**: 失敗するテストを最初に書く
-2. **Green**: テストを通す最小限のコードを実装する
-3. **Refactor**: 重複を除去し設計を改善する
-4. @docs/reference/コーディングとテストガイド.md のワークフローに従う
-
-## 参照ドキュメント
-
-- @docs/reference/コーディングとテストガイド.md — TDD ワークフロー詳細
-- @docs/reference/CodexCLIMCPアプリケーション開発フロー.md — Codex 連携フロー
-- @docs/design/architecture.md, @docs/design/architecture_backend.md, @docs/design/architecture_frontend.md
-- @docs/design/data-model.md, @docs/design/domain-model.md, @docs/design/tech_stack.md
-- @docs/design/ui-design.md, @docs/design/test_strategy.md
-- 作業開始前に対象の @docs/development/iteration_plan-N.md の内容を確認する
-- 作業完了後に対象の @docs/development/iteration_plan-N.md の進捗を更新する
-
-## Codex 分業モード（--codex）
-
-Claude と Codex の役割を分離し、計画・設計・受入を Claude が担い、実装を Codex に委譲する。
-
-**前提条件**: Codex MCP サーバーが設定済みであること（@docs/reference/CodexCLIMCPサーバー設定手順.md 参照）
-
-### 役割分担
-
-| フェーズ | 担当 | 責務 |
-|---------|------|------|
-| 計画 | Claude | 要件分析、タスク分解、優先度決定 |
-| 設計 | Claude | API 設計、UI 設計、データモデル設計 |
-| 実装 | Codex | コード実装、ユニットテスト作成 |
-| 受入 | Claude | 設計レビュー、E2E テスト作成・実行、品質確認 |
-
-### 開発フロー
-
-```mermaid
-graph LR
-    A[計画] --> B[設計]
-    B --> C[実装指示]
-    C --> D[受入]
-    subgraph Claude
-    A
-    B
-    D
-    end
-    subgraph Codex
-    C
-    end
-```
-
-### 指示サイズ
-
-| 粒度 | 推奨度 | 説明 |
-|------|--------|------|
-| タスク単位（1-3 ファイル） | 推奨 | 1 つのコンポーネントや機能単位 |
-| 機能単位（3-5 ファイル） | 注意 | 進捗確認を頻繁に行う |
-| ユーザーストーリー単位 | 非推奨 | タスクに分割して実行する |
-
-### Codex への指示例
-
-```
-mcp__codex__codex
-  prompt: |
-    お知らせ管理機能を実装してください。
-    ## 開発ガイド
-    docs/reference/コーディングとテストガイド.md に従って実装すること。
-    特に TDD サイクル（Red-Green-Refactor）を厳守すること。
-    ## タスク
-    1. AuthContext に role と canManageAnnouncements を追加
-    2. API クライアントに create/update/delete 関数を追加
-    ## 完了条件
-    - ESLint エラーなし
-    - 既存テストがパス
-    - TDD サイクルに従って実装
-  sandbox: danger-full-access
-  approval-policy: never
-  cwd: プロジェクトルート
-```
-
-### 受入基準
-
-- [ ] すべての受入条件が満たされている
-- [ ] E2E テストがすべてパス
-- [ ] ESLint エラーがない
-- [ ] 既存テストが壊れていない
-
-### Codex が書き込みできない場合
-
-1. Claude が勝手に直接編集を進めてはいけない
-2. ユーザーに状況を報告し、確認を待つ
-3. ユーザーの許可を得てから代替手段を実行する
-
-## 途中から再開
-
-開発セッションの途中から再開する場合は、まず現在の実装状況を確認する。
-
-**Example:**
-
-```
-ユーザー: 「バックエンドの認証機能は実装済み。次の機能に進みたい」
-回答: イテレーション計画を確認し、次のユーザーストーリーを特定する。
-      既存コードのテスト結果を確認し、Green 状態であることを検証してから
-      次のタスクの Red フェーズに進む。
-```
-
-## コンテキスト管理
-
-タスクの区切りごとに `/compact` を実施して Context limit reached エラーを回避する。
-
-- ユーザーストーリー 1 件の実装完了時、TDD サイクルを数回繰り返した後、コミット完了後に実施する
-- `/compact` 前に現在の作業状態と次のタスクをメモとして出力する
-
-## 注意事項
-
-- プロジェクトのテスト環境が設定済みであること（前提条件）
-- TDD の三原則を厳密に守る。テストなしでプロダクションコードを書かない
-- コミット前に必ず品質チェックリストを実行する
-- TODO 駆動開発でタスクを細かく分割してから実装を開始する
-- Rule of Three: 同じコードが 3 回現れたらリファクタリングする
-
-## 関連スキル
-
-- `developing-backend` — バックエンド TDD 開発
-- `developing-frontend` — フロントエンド TDD 開発
-- `developing-review` — 開発成果物のマルチパースペクティブレビュー（TODO 完了時のコードレビュー）
-- `analyzing-review` — 分析成果物のマルチパースペクティブレビュー（イテレーション完了時のユーザーレビュー）
-- `operating-qt` — コード品質管理（受け入れ前の SonarQube 品質チェック）
-- `developing-release` — リリースワークフロー（品質ゲート・バージョン管理・CHANGELOG）
+---
+name: orchestrating-development
+description: 開発フェーズ全体の TDD ワークフローをオーケストレーション。バックエンド・フロントエンドの開発順序と TDD サイクルの実践方法を案内し、Codex 分業体制もサポートする。「開発を始めたい」「TDD の進め方を知りたい」「Codex と分業で開発したい」「開発フェーズの全体像を把握したい」といった場面で発動する。開発フローを標準化することで、品質のブレを防ぎチーム全体の生産性を底上げする。
+---
+
+# 開発フェーズオーケストレーション
+
+開発フェーズ全体のワークフローを案内する。TDD サイクルに従い、バックエンド→フロントエンドの順序で品質を担保しながら開発を進める。
+
+## オプション
+
+| オプション | 説明 |
+|-----------|------|
+| なし | 開発フェーズ全体のワークフローを表示 |
+| `--codex` | Claude（計画・設計・受入）と Codex（実装）の分業体制で開発 |
+
+## 開発フェーズの全体像
+
+1. **バックエンド開発** (Skill: `developing-backend`) — インサイドアウトアプローチ推奨
+2. **フロントエンド開発** (Skill: `developing-frontend`) — アウトサイドインアプローチ推奨
+
+各開発で Red-Green-Refactor サイクルを厳密に実行する。テストなしでプロダクションコードを書かない。
+
+### レビューポイント
+
+コーディングとテストガイドのイテレーション開発フローに準拠し、以下のタイミングでレビュースキルを発動する。
+
+| タイミング | スキル | 説明 |
+|-----------|--------|------|
+| TODO 完了時（コードレビュー） | `developing-review` | TDD サイクルで TODO を完了するたびにコード品質・テスト品質・設計整合性をレビュー |
+| 受け入れ前（品質チェック） | `operating-qt` | SonarQube によるコード品質分析・Quality Gate 確認を実施し、品質基準を満たしていることを検証 |
+| イテレーション完了時（ユーザーレビュー） | `analyzing-review` | 受け入れフェーズでユーザー視点・プロダクト視点からの成果物レビュー |
+
+## TDD サイクル
+
+TDD は「テストを書いてからコードを書く」手順ではなく、「設計を小さなフィードバックループで検証する」手法。10-15 分で 1 サイクルを完了させる。
+
+1. **Red**: 失敗するテストを最初に書く
+2. **Green**: テストを通す最小限のコードを実装する
+3. **Refactor**: 重複を除去し設計を改善する
+4. @docs/reference/コーディングとテストガイド.md のワークフローに従う
+
+## 参照ドキュメント
+
+- @docs/reference/コーディングとテストガイド.md — TDD ワークフロー詳細
+- @docs/reference/CodexCLIMCPアプリケーション開発フロー.md — Codex 連携フロー
+- @docs/design/architecture.md, @docs/design/architecture_backend.md, @docs/design/architecture_frontend.md
+- @docs/design/data-model.md, @docs/design/domain-model.md, @docs/design/tech_stack.md
+- @docs/design/ui-design.md, @docs/design/test_strategy.md
+- 作業開始前に対象の @docs/development/iteration_plan-N.md の内容を確認する
+- 作業完了後に対象の @docs/development/iteration_plan-N.md の進捗を更新する
+
+## Codex 分業モード（--codex）
+
+Claude と Codex の役割を分離し、計画・設計・受入を Claude が担い、実装を Codex に委譲する。
+
+**前提条件**: Codex MCP サーバーが設定済みであること（@docs/reference/CodexCLIMCPサーバー設定手順.md 参照）
+
+### 役割分担
+
+| フェーズ | 担当 | 責務 |
+|---------|------|------|
+| 計画 | Claude | 要件分析、タスク分解、優先度決定 |
+| 設計 | Claude | API 設計、UI 設計、データモデル設計 |
+| 実装 | Codex | コード実装、ユニットテスト作成 |
+| 受入 | Claude | 設計レビュー、E2E テスト作成・実行、品質確認 |
+
+### 開発フロー
+
+```mermaid
+graph LR
+    A[計画] --> B[設計]
+    B --> C[実装指示]
+    C --> D[受入]
+    subgraph Claude
+    A
+    B
+    D
+    end
+    subgraph Codex
+    C
+    end
+```
+
+### 指示サイズ
+
+| 粒度 | 推奨度 | 説明 |
+|------|--------|------|
+| 1 ファイル単位 | 推奨 | コード全文を含めた具体的な指示。最も確実 |
+| タスク単位（2-3 ファイル） | 注意 | タイムアウトリスクあり。順次実行を推奨 |
+| 機能・ストーリー単位 | 非推奨 | タイムアウトする。必ず分割して実行する |
+
+### Codex への指示原則
+
+1. **1 ファイル 1 指示**: 複数ファイルの同時指示はタイムアウトする（IT1 実績: 6 ファイル同時→タイムアウト、1 ファイルずつ→各 15-35 秒で成功）
+2. **コード全文を渡す**: 自然言語の説明より、作成すべきファイルの完全なコードを指示に含める
+3. **「既存コードは変更しないでください」を明記**: 追記指示時に Codex が他の箇所を無断で書き換えるのを防ぐ
+4. **`--write` フラグを含める**: 書き込みが必要な場合は prompt 冒頭に `--write` を付ける
+
+### Codex への指示例
+
+```
+codex:codex-rescue に以下を委譲:
+
+--write apps/sms/backend/src/main/java/.../HomeSummaryResponse.java に以下の record を作成してください。
+
+（ファイルの完全なコードをここに記載）
+```
+
+### 受入基準
+
+- [ ] `git diff` で意図しない変更がないことを確認（Codex は指示外のコードを書き換えることがある）
+- [ ] すべての受入条件が満たされている
+- [ ] 既存テストが壊れていない（Codex の変更で `localStorage` → `sessionStorage` 等の無断変更がないか）
+- [ ] E2E テストがすべてパス
+- [ ] ESLint / Prettier / 品質チェックがパス
+
+### Codex の既知の問題と対策
+
+| 問題 | 事例 | 対策 |
+|------|------|------|
+| タイムアウト | 6 ファイル同時指示で応答なし | 1 ファイルずつ順次指示 |
+| 既存コードの無断変更 | `localStorage` → `sessionStorage` に書き換え | 「既存コードは変更しない」を明記 + `git diff` で検証 |
+| API パターンの変更 | headers マージ方式をスプレッドから `Object.assign` に変更 | コード全文を渡して曖昧さを排除 |
+| Spring Boot 4.0 パッケージ名の誤り | `@WebMvcTest` の import パスが旧バージョン | 既存テストの import パターンをコード全文に含める |
+
+### Codex が書き込みできない場合
+
+1. Claude が勝手に直接編集を進めてはいけない
+2. ユーザーに状況を報告し、確認を待つ
+3. ユーザーの許可を得てから代替手段を実行する
+
+## 途中から再開
+
+開発セッションの途中から再開する場合は、まず現在の実装状況を確認する。
+
+**Example:**
+
+```
+ユーザー: 「バックエンドの認証機能は実装済み。次の機能に進みたい」
+回答: イテレーション計画を確認し、次のユーザーストーリーを特定する。
+      既存コードのテスト結果を確認し、Green 状態であることを検証してから
+      次のタスクの Red フェーズに進む。
+```
+
+## コンテキスト管理
+
+タスクの区切りごとに `/compact` を実施して Context limit reached エラーを回避する。
+
+- ユーザーストーリー 1 件の実装完了時、TDD サイクルを数回繰り返した後、コミット完了後に実施する
+- `/compact` 前に現在の作業状態と次のタスクをメモとして出力する
+
+## 注意事項
+
+- プロジェクトのテスト環境が設定済みであること（前提条件）
+- TDD の三原則を厳密に守る。テストなしでプロダクションコードを書かない
+- コミット前に必ず品質チェックリストを実行する
+- TODO 駆動開発でタスクを細かく分割してから実装を開始する
+- Rule of Three: 同じコードが 3 回現れたらリファクタリングする
+
+## 関連スキル
+
+- `developing-backend` — バックエンド TDD 開発
+- `developing-frontend` — フロントエンド TDD 開発
+- `developing-review` — 開発成果物のマルチパースペクティブレビュー（TODO 完了時のコードレビュー）
+- `analyzing-review` — 分析成果物のマルチパースペクティブレビュー（イテレーション完了時のユーザーレビュー）
+- `operating-qt` — コード品質管理（受け入れ前の SonarQube 品質チェック）
+- `developing-release` — リリースワークフロー（品質ゲート・バージョン管理・CHANGELOG）

package/lib/assets/.claude/skills/validating-iteration-plan/SKILL.md

@@ -9,21 +9,43 @@ description: イテレーション計画と上流設計ドキュメント群（
 
 ## 検証対象ドキュメント
 
-| # | 検証対象 | パス | 検証内容 |
-|---|---------|------|---------|
-| 1 | ユーザーストーリー | `docs/requirements/user_story.md` | ストーリー ID・タイトル・アクター・受入基準の一致 |
-| 2 | ドメインモデル | `docs/design/domain-model.md` | 集約・エンティティ・値オブジェクトの名称・構造・関連の一致 |
-| 3 | データモデル | `docs/design/data-model.md` | テーブル名・カラム名・型・制約・命名規約の一致 |
-| 4 | UI 設計（ビュー） | `docs/design/ui_design.md` | ワイヤーフレーム構造・ナビバー形式・テーブル表記・URL パスの一致 |
-| 5 | UI 設計（インタラクション） | `docs/design/ui_design.md` | 画面遷移・htmx パターン・PRG パターン・エラー処理・フィードバックメッセージの一致 |
-| 6 | ゴールの整合性 | イテレーション計画全体 | ゴール・ストーリー・設計・タスク・見積もりの内部整合性 |
-| 7 | 過去レビュー指摘事項 | `docs/review/` 内の最新レビューファイル | 高・中優先度の指摘がストーリーまたはタスクとして計画に反映されているか |
-
-## 検証手順
-
-7 ステップを順に実行する。各ステップは並列実行も可能。不整合を発見した場合はイテレーション計画を修正し、変更点を注記する。
-
-### ステップ 1: ユーザーストーリーとの整合性
+| # | 検証対象 | パス | 検証内容 |
+|---|---------|------|---------|
+| 1 | テンプレートフォーマット | `docs/template/イテレーション計画.md` | 見出し構成・必須セクション・表形式・コードブロック形式の一致 |
+| 2 | ユーザーストーリー | `docs/requirements/user_story.md` | ストーリー ID・タイトル・アクター・受入基準の一致 |
+| 3 | ドメインモデル | `docs/design/domain-model.md` | 集約・エンティティ・値オブジェクトの名称・構造・関連の一致 |
+| 4 | データモデル | `docs/design/data-model.md` | テーブル名・カラム名・型・制約・命名規約の一致 |
+| 5 | UI 設計（ビュー） | `docs/design/ui_design.md` | ワイヤーフレーム構造・ナビバー形式・テーブル表記・URL パスの一致 |
+| 6 | UI 設計（インタラクション） | `docs/design/ui_design.md` | 画面遷移・htmx パターン・PRG パターン・エラー処理・フィードバックメッセージの一致 |
+| 7 | ゴールの整合性 | イテレーション計画全体 | ゴール・ストーリー・設計・タスク・見積もりの内部整合性 |
+| 8 | 過去レビュー指摘事項 | `docs/review/` 内の最新レビューファイル | 高・中優先度の指摘がストーリーまたはタスクとして計画に反映されているか |
+
+## 検証手順
+
+8 ステップを順に実行する。各ステップは並列実行も可能。不整合を発見した場合はイテレーション計画を修正し、変更点を注記する。
+
+### ステップ 1: テンプレートフォーマットとの整合性
+
+イテレーション計画全体が `docs/template/イテレーション計画.md` のフォーマットに従っているかを確認する。以降の内容整合性チェックに入る前に、見出し構成・必須セクション・表形式・コードブロック形式がテンプレートから逸脱していないことを検証する。
+
+**チェック項目**:
+
+- [ ] 文書タイトルが `# イテレーション X 計画` 形式になっている
+- [ ] テンプレートの主要セクション（概要、ゴール、ユーザーストーリー、スケジュール、設計、リスクと対策、完了条件、更新履歴、関連ドキュメント）が揃っている
+- [ ] 各セクションの見出しレベルがテンプレートと一致している
+- [ ] 概要、対象ストーリー、タスク、リスク、更新履歴などの表形式がテンプレートの列構成に従っている
+- [ ] `mermaid`、`plantuml`、`prisma` などのコードブロック種別がテンプレートと一致している
+- [ ] 完了条件に `Definition of Done` と `デモ項目` が含まれている
+- [ ] 関連ドキュメント節に最低限の参照先が記載されている
+
+**よくある不整合**:
+
+- テンプレート必須セクションの欠落（例: 「更新履歴」がない）
+- 見出し名や階層の変更（例: 「ユーザーストーリー」ではなく独自見出しを使用）
+- 表の列不足や列名変更
+- コードブロックの種別未指定、またはテンプレートと異なる記法
+
+### ステップ 2: ユーザーストーリーとの整合性
 
 イテレーション計画の「ストーリー詳細」セクションと `user_story.md` を比較する。
 
@@ -41,7 +63,7 @@ description: イテレーション計画と上流設計ドキュメント群（
 - ストーリー文の一部省略（例: 「予約情報」-> 元は「予約情報（出発地・目的地・期限・貨物仕様）」）
 - 受入基準の列挙が省略されている（例: 制約条件の具体名が省略）
 
-### ステップ 2: ドメインモデルとの整合性
+### ステップ 3: ドメインモデルとの整合性
 
 イテレーション計画の「設計 > ドメインモデル」セクションと `domain-model.md` を比較する。
 
@@ -61,7 +83,7 @@ description: イテレーション計画と上流設計ドキュメント群（
 - 既存の集約構造（親子関係）を無視した新規モデル設計
 - 共有カーネル（`Location`）を参照せず、直接 `String` で locode を保持
 
-### ステップ 3: データモデルとの整合性
+### ステップ 4: データモデルとの整合性
 
 イテレーション計画の「設計 > データモデル」セクションと `data-model.md` を比較する。
 
@@ -85,7 +107,7 @@ description: イテレーション計画と上流設計ドキュメント群（
 - FK が業務キー参照（`REFERENCES voyages(voyage_number)`）-> 規約は `voyage.id` 参照
 - PostgreSQL 構文（`BIGSERIAL`）と MySQL 構文（`AUTO_INCREMENT`）の混在
 
-### ステップ 4: UI 設計（ビュー）との整合性
+### ステップ 5: UI 設計（ビュー）との整合性
 
 イテレーション計画の「設計 > ユーザーインターフェース > ビュー」セクションと `ui_design.md` を比較する。
 
@@ -106,7 +128,7 @@ description: イテレーション計画と上流設計ドキュメント群（
 - URL パスが未定義
 - 既存画面との関係（拡張 vs 新規）が不明確
 
-### ステップ 5: UI 設計（インタラクション）との整合性
+### ステップ 6: UI 設計（インタラクション）との整合性
 
 イテレーション計画の「設計 > ユーザーインターフェース > インタラクション」セクションと `ui_design.md` の画面遷移図・htmx パターン・フィードバック規約を比較する。
 
@@ -127,9 +149,9 @@ description: イテレーション計画と上流設計ドキュメント群（
 - フィードバックメッセージの定義がない
 - 既存画面 state との遷移関係が切断されている
 
-### ステップ 6: ゴールの整合性（最終確認）
+### ステップ 7: ゴールの整合性（最終確認）
 
-イテレーション計画全体を俯瞰し、イテレーションのゴールと各ストーリー・設計・タスクが一貫しているかを確認する。ステップ 1-5 が個別ドキュメントとの突合であるのに対し、本ステップは計画内部の論理的整合性を検証する最終関門である。
+イテレーション計画全体を俯瞰し、イテレーションのゴールと各ストーリー・設計・タスクが一貫しているかを確認する。ステップ 1-6 がフォーマットおよび個別ドキュメントとの突合であるのに対し、本ステップは計画内部の論理的整合性を検証する最終関門である。
 
 **チェック項目**:
 
@@ -150,7 +172,7 @@ description: イテレーション計画と上流設計ドキュメント群（
 - タスク分割が設計セクションと対応していない（設計にあるがタスクにない、またはその逆）
 - ベロシティを超えるポイントが計画されている
 
-### ステップ 7: 過去レビュー指摘事項との整合性
+### ステップ 8: 過去レビュー指摘事項との整合性
 
 `docs/review/` 内の最新レビューファイルを確認し、前イテレーションで発見された指摘事項が今回の計画に適切に反映されているかを検証する。コードレビュー（`*_review_*.md`）・UI/UX レビュー（`*_uiux_review_*.md`）・分析レビュー（`*_review_*.md`）のいずれも対象とする。
 
@@ -188,15 +210,16 @@ description: イテレーション計画と上流設計ドキュメント群（
 
 ### 検証結果サマリー
 
-| ステップ | 検証対象 | 結果 | 不整合件数 |
-|---------|---------|------|-----------|
-| 1 | ユーザーストーリー | OK / NG | N 件 |
-| 2 | ドメインモデル | OK / NG | N 件 |
-| 3 | データモデル | OK / NG | N 件 |
-| 4 | UI 設計（ビュー） | OK / NG | N 件 |
-| 5 | UI 設計（インタラクション） | OK / NG | N 件 |
-| 6 | ゴールの整合性 | OK / NG | N 件 |
-| 7 | 過去レビュー指摘事項 | OK / NG | N 件 |
+| ステップ | 検証対象 | 結果 | 不整合件数 |
+|---------|---------|------|-----------|
+| 1 | テンプレートフォーマット | OK / NG | N 件 |
+| 2 | ユーザーストーリー | OK / NG | N 件 |
+| 3 | ドメインモデル | OK / NG | N 件 |
+| 4 | データモデル | OK / NG | N 件 |
+| 5 | UI 設計（ビュー） | OK / NG | N 件 |
+| 6 | UI 設計（インタラクション） | OK / NG | N 件 |
+| 7 | ゴールの整合性 | OK / NG | N 件 |
+| 8 | 過去レビュー指摘事項 | OK / NG | N 件 |
 
 ### 不整合一覧（NG の場合のみ）