@k2works/claude-code-booster 4.9.0 → 4.11.0

package/lib/assets/.claude/skills/syncing-github-project/SKILL.md

@@ -1,151 +1,151 @@
----
-name: syncing-github-project
-description: リリース計画を GitHub Project・Issue・Milestone に反映し一元管理。初回の一括同期から差異検出・自動同期まで対応する。「GitHub Project に同期したい」「Issue を作成したい」「計画と GitHub の差異を確認したい」「Milestone を設定したい」といった場面で発動する。計画ドキュメントを Single Source of Truth とし GitHub に自動反映することで、二重管理の手間と不整合を排除する。
----
-
-# GitHub Project 同期
-
-リリース計画を GitHub Project・Issue・Milestone に反映し、プロジェクト管理を GitHub 上で一元化する。
-
-`docs/development/release_plan.md` を正とし、GitHub は同期先として扱う。手動で GitHub を直接更新するのではなく、計画ドキュメントを更新してから `--sync` で反映する。
-
-## オプション
-
-| オプション | 説明 |
-|-----------|------|
-| なし | 全体の同期を実行（Project・Issue・フィールド・Milestone） |
-| `--project` | GitHub Project のみを作成 |
-| `--issues` | Issue のみを作成（Project 存在が前提） |
-| `--fields` | 各 Issue に対して Project フィールド値を設定 |
-| `--milestones` | Milestone のみを作成し Issue に割り当て |
-| `--sync` | release_plan.md と GitHub の差異を確認し同期 |
-| `--status` | 現在の GitHub Project 状態を表示 |
-
-## GitHub Project の作成
-
-release_plan.md に基づいて Project を作成し、カスタムフィールドを設定する。
-
-**標準フィールド構成**:
-
-| フィールド | タイプ | 説明 |
-|-----------|--------|------|
-| Status | Single Select | Todo / In Progress / Done |
-| リリース | Single Select | release_plan.md のリリースフェーズに対応 |
-| 優先度 | Single Select | ストーリーの優先度 |
-| SP | Number | ストーリーポイント |
-| イテレーション | Iteration | スプリント期間（開始日・期間付き） |
-
-```bash
-# Single Select フィールドの作成
-gh project field-create <PROJECT_NUMBER> --owner <OWNER> \
-  --name "<フィールド名>" --data-type "SINGLE_SELECT" \
-  --single-select-options "<選択肢1>,<選択肢2>"
-
-# Number フィールドの作成
-gh project field-create <PROJECT_NUMBER> --owner <OWNER> \
-  --name "SP" --data-type "NUMBER"
-```
-
-## Issue の作成
-
-ユーザーストーリーを GitHub Issue として作成し、Project に追加する。
-
-- **タイトル**: `[ストーリーID] ストーリー名`
-- **本文**: ユーザーストーリー、サブタスク、受入条件、見積もり情報
-- **Milestone**: リリースフェーズに対応する Milestone に割り当て
-
-```bash
-gh issue create --repo <OWNER>/<REPO> \
-  --title "<ストーリーID>: <ストーリー名>" \
-  --milestone "<Milestone 名>" --body "..."
-
-gh project item-add <PROJECT_NUMBER> --owner <OWNER> \
-  --url "https://github.com/<OWNER>/<REPO>/issues/<NUMBER>"
-```
-
-## Iteration フィールドの作成と設定
-
-Iteration フィールドは Single Select ではなく **Iteration 型** で作成する。GraphQL API で `iterationConfiguration` を含めることで、フィールド作成と同時にイテレーション期間を設定できる。
-
-```bash
-# Iteration フィールドの作成
-gh api graphql -f query='
-mutation {
-  createProjectV2Field(input: {
-    projectId: "<PROJECT_ID>"
-    dataType: ITERATION
-    name: "イテレーション"
-    iterationConfiguration: {
-      startDate: "<開始日 YYYY-MM-DD>"
-      duration: <デフォルト期間（日数）>
-      iterations: [
-        { title: "<IT名>", startDate: "<開始日>", duration: <日数> }
-      ]
-    }
-  }) { projectV2Field { ... on ProjectV2IterationField { id } } }
-}'
-
-# 各 Issue への Iteration 値の設定
-gh api graphql -f query='
-mutation {
-  updateProjectV2ItemFieldValue(input: {
-    projectId: "<PROJECT_ID>"
-    itemId: "<ITEM_ID>"
-    fieldId: "<ITERATION_FIELD_ID>"
-    value: { iterationId: "<ITERATION_ID>" }
-  }) { projectV2Item { id } }
-}'
-```
-
-## 差異確認と同期（--sync）
-
-release_plan.md と GitHub の整合性を確認し、差異があれば同期を実行する。
-
-**確認項目**: ストーリー数、SP、リリース/Milestone 割り当て、優先度、イテレーション割り当て、Status
-
-**同期動作**:
-
-- **新規ストーリー**: Issue を作成し Project に追加する
-- **変更されたストーリー**: Issue のフィールド値を更新する
-- **削除されたストーリー**: Issue をクローズする（削除はしない）
-
-## 同期フロー
-
-```mermaid
-graph TD
-    A[release_plan.md] --> B{同期開始}
-    B --> C[GitHub Project 作成]
-    C --> D[カスタムフィールド設定]
-    D --> E[Issue 作成]
-    E --> F[Project に Item 追加]
-    F --> G[フィールド値設定]
-    G --> H[Milestone 作成・割当]
-    H --> I[同期完了]
-```
-
-## 途中から再開
-
-同期作業の途中から再開する場合は、まず現在の GitHub 状態を確認する。
-
-**Example:**
-
-```
-ユーザー: 「Project と Issue は作成済み。フィールド値を設定したい」
-回答: --status で現在の GitHub 状態を確認する。
-      --fields でフィールド値を一括設定する。
-      設定後に --sync で release_plan.md との整合性を検証する。
-```
-
-## 注意事項
-
-- `docs/development/release_plan.md` が存在すること、`gh` CLI がインストールされ認証済みであること、Project API スコープが有効であること（前提条件）
-- 既存の Project/Issue がある場合は重複作成に注意する
-- Iteration フィールドの期間変更は GraphQL API または Web UI で実施する
-- 初回は `--sync` で差異確認してから同期する。大規模変更前にはバックアップを推奨する
-
-## 関連スキル
-
-- `planning-releases` — リリース計画とイテレーション計画の作成
-- `tracking-progress` — 進捗状況の確認と更新
-- `orchestrating-project` — 計画・進捗管理フェーズ全体のオーケストレーション
-- `git-commit` — 変更のコミット
+---
+name: syncing-github-project
+description: リリース計画を GitHub Project・Issue・Milestone に反映し一元管理。初回の一括同期から差異検出・自動同期まで対応する。「GitHub Project に同期したい」「Issue を作成したい」「計画と GitHub の差異を確認したい」「Milestone を設定したい」といった場面で発動する。計画ドキュメントを Single Source of Truth とし GitHub に自動反映することで、二重管理の手間と不整合を排除する。
+---
+
+# GitHub Project 同期
+
+リリース計画を GitHub Project・Issue・Milestone に反映し、プロジェクト管理を GitHub 上で一元化する。
+
+`docs/development/release_plan.md` を正とし、GitHub は同期先として扱う。手動で GitHub を直接更新するのではなく、計画ドキュメントを更新してから `--sync` で反映する。
+
+## オプション
+
+| オプション | 説明 |
+|-----------|------|
+| なし | 全体の同期を実行（Project・Issue・フィールド・Milestone） |
+| `--project` | GitHub Project のみを作成 |
+| `--issues` | Issue のみを作成（Project 存在が前提） |
+| `--fields` | 各 Issue に対して Project フィールド値を設定 |
+| `--milestones` | Milestone のみを作成し Issue に割り当て |
+| `--sync` | release_plan.md と GitHub の差異を確認し同期 |
+| `--status` | 現在の GitHub Project 状態を表示 |
+
+## GitHub Project の作成
+
+release_plan.md に基づいて Project を作成し、カスタムフィールドを設定する。
+
+**標準フィールド構成**:
+
+| フィールド | タイプ | 説明 |
+|-----------|--------|------|
+| Status | Single Select | Todo / In Progress / Done |
+| リリース | Single Select | release_plan.md のリリースフェーズに対応 |
+| 優先度 | Single Select | ストーリーの優先度 |
+| SP | Number | ストーリーポイント |
+| イテレーション | Iteration | スプリント期間（開始日・期間付き） |
+
+```bash
+# Single Select フィールドの作成
+gh project field-create <PROJECT_NUMBER> --owner <OWNER> \
+  --name "<フィールド名>" --data-type "SINGLE_SELECT" \
+  --single-select-options "<選択肢1>,<選択肢2>"
+
+# Number フィールドの作成
+gh project field-create <PROJECT_NUMBER> --owner <OWNER> \
+  --name "SP" --data-type "NUMBER"
+```
+
+## Issue の作成
+
+ユーザーストーリーを GitHub Issue として作成し、Project に追加する。
+
+- **タイトル**: `[ストーリーID] ストーリー名`
+- **本文**: ユーザーストーリー、サブタスク、受入条件、見積もり情報
+- **Milestone**: リリースフェーズに対応する Milestone に割り当て
+
+```bash
+gh issue create --repo <OWNER>/<REPO> \
+  --title "<ストーリーID>: <ストーリー名>" \
+  --milestone "<Milestone 名>" --body "..."
+
+gh project item-add <PROJECT_NUMBER> --owner <OWNER> \
+  --url "https://github.com/<OWNER>/<REPO>/issues/<NUMBER>"
+```
+
+## Iteration フィールドの作成と設定
+
+Iteration フィールドは Single Select ではなく **Iteration 型** で作成する。GraphQL API で `iterationConfiguration` を含めることで、フィールド作成と同時にイテレーション期間を設定できる。
+
+```bash
+# Iteration フィールドの作成
+gh api graphql -f query='
+mutation {
+  createProjectV2Field(input: {
+    projectId: "<PROJECT_ID>"
+    dataType: ITERATION
+    name: "イテレーション"
+    iterationConfiguration: {
+      startDate: "<開始日 YYYY-MM-DD>"
+      duration: <デフォルト期間（日数）>
+      iterations: [
+        { title: "<IT名>", startDate: "<開始日>", duration: <日数> }
+      ]
+    }
+  }) { projectV2Field { ... on ProjectV2IterationField { id } } }
+}'
+
+# 各 Issue への Iteration 値の設定
+gh api graphql -f query='
+mutation {
+  updateProjectV2ItemFieldValue(input: {
+    projectId: "<PROJECT_ID>"
+    itemId: "<ITEM_ID>"
+    fieldId: "<ITERATION_FIELD_ID>"
+    value: { iterationId: "<ITERATION_ID>" }
+  }) { projectV2Item { id } }
+}'
+```
+
+## 差異確認と同期（--sync）
+
+release_plan.md と GitHub の整合性を確認し、差異があれば同期を実行する。
+
+**確認項目**: ストーリー数、SP、リリース/Milestone 割り当て、優先度、イテレーション割り当て、Status
+
+**同期動作**:
+
+- **新規ストーリー**: Issue を作成し Project に追加する
+- **変更されたストーリー**: Issue のフィールド値を更新する
+- **削除されたストーリー**: Issue をクローズする（削除はしない）
+
+## 同期フロー
+
+```mermaid
+graph TD
+    A[release_plan.md] --> B{同期開始}
+    B --> C[GitHub Project 作成]
+    C --> D[カスタムフィールド設定]
+    D --> E[Issue 作成]
+    E --> F[Project に Item 追加]
+    F --> G[フィールド値設定]
+    G --> H[Milestone 作成・割当]
+    H --> I[同期完了]
+```
+
+## 途中から再開
+
+同期作業の途中から再開する場合は、まず現在の GitHub 状態を確認する。
+
+**Example:**
+
+```
+ユーザー: 「Project と Issue は作成済み。フィールド値を設定したい」
+回答: --status で現在の GitHub 状態を確認する。
+      --fields でフィールド値を一括設定する。
+      設定後に --sync で release_plan.md との整合性を検証する。
+```
+
+## 注意事項
+
+- `docs/development/release_plan.md` が存在すること、`gh` CLI がインストールされ認証済みであること、Project API スコープが有効であること（前提条件）
+- 既存の Project/Issue がある場合は重複作成に注意する
+- Iteration フィールドの期間変更は GraphQL API または Web UI で実施する
+- 初回は `--sync` で差異確認してから同期する。大規模変更前にはバックアップを推奨する
+
+## 関連スキル
+
+- `planning-releases` — リリース計画とイテレーション計画の作成
+- `tracking-progress` — 進捗状況の確認と更新
+- `orchestrating-project` — 計画・進捗管理フェーズ全体のオーケストレーション
+- `git-commit` — 変更のコミット

package/lib/assets/.claude/skills/tracking-progress/SKILL.md

@@ -1,91 +1,91 @@
----
-name: tracking-progress
-description: プロジェクトの開発進捗を多角的に分析しレポートを生成。イテレーション達成度、技術実装状況、品質メトリクスを確認し、計画ドキュメントを自動更新する。「進捗を確認したい」「プロジェクトの状態を知りたい」「イテレーションの達成度を分析したい」「進捗ドキュメントを更新したい」といった場面で発動する。定期的な進捗可視化により、遅延や品質低下を早期に発見しプロジェクトの透明性を確保する。
----
-
-# 進捗追跡
-
-プロジェクトの開発進捗を多角的に分析し、現在の状況を定量的に報告する。Git 履歴・テスト結果・ドキュメントを総合的に分析して進捗を可視化する。
-
-## オプション
-
-| オプション | 説明 |
-|-----------|------|
-| なし | 全体的な進捗確認（デフォルト） |
-| `--brief` | 簡潔な進捗サマリー表示 |
-| `--detailed` | 詳細な進捗レポート生成 |
-| `--iteration <番号>` | 特定イテレーションの進捗確認 |
-| `--technical` | 技術的な実装状況に焦点 |
-| `--docs` | ドキュメント更新状況の確認 |
-| `--update` | `docs/development/` 内のドキュメントを現在の進捗に合わせて更新 |
-
-## 分析の観点
-
-- **イテレーション達成度**: 計画 vs 実績の比較分析（SP、ストーリー数、期間）
-- **技術実装状況**: 機能完成度・テスト結果・ビルド状態
-- **品質メトリクス**: テストカバレッジ、静的解析結果、コード複雑度
-- **ドキュメント整備**: 計画書・仕様書・手順書の最新性
-
-## --update オプションの詳細
-
-`docs/development/` 内のドキュメントを現在の進捗に合わせて自動更新する。
-
-**更新対象**:
-
-- `docs/development/release_plan.md` — 進捗状況テーブル、リリース条件チェック、バーンダウン実績値
-- `docs/development/iteration_plan-*.md` — 成功基準チェック、タスク状態、完了条件（DoD）、メトリクス実績値
-
-**更新判定の情報源**:
-
-```bash
-git log --oneline --since="2 weeks ago"   # 実装状況の分析
-dotnet test --logger trx                  # テスト結果の取得
-npm test -- --coverage                    # カバレッジの取得
-```
-
-## 出力例
-
-```
-プロジェクト進捗レポート
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-Overall Status: フルスタック実装完成 (MVP 準備段階)
-
-Iteration Progress:
-├─ Iteration 1 (認証・閲覧): 完了 (計画 10 日→実績 4 日)
-├─ Iteration 2 (予約機能): 計画済み
-├─ Iteration 3 (キャンセル): 待機中
-└─ Iteration 4 (運用準備): 待機中
-
-Technical Implementation:
-├─ Backend (.NET 9): 完全実装 (181 テスト全通過)
-├─ Frontend (React TS): 完全実装
-└─ API Integration: フルスタック連携確認
-```
-
-## 途中から再開
-
-進捗追跡の途中から再開する場合は、前回の追跡結果を確認する。
-
-**Example:**
-
-```
-ユーザー: 「イテレーション 2 の中間進捗を確認したい」
-回答: --iteration 2 で現在の達成状況を分析する。
-      計画 SP と完了 SP を比較し、残りの期間で完了可能か評価する。
-      遅延リスクがあれば早期に報告する。
-```
-
-## 注意事項
-
-- Git リポジトリ内で実行し、プロジェクト構造を理解していること（前提条件）
-- 実行時点での動的な状況を総合的に分析する
-- `--update` 使用時は更新前に Git でコミットしておくことを推奨する（ロールバック用）
-- イテレーション開始・終了時の定期実行を推奨する
-- `--update` 実行後、KPT セクションは手動で記入して振り返りを完了する
-
-## 関連スキル
-
-- `managing-docs` — ドキュメント一覧と進捗状況の確認
-- `git-commit` — 進捗に合わせた適切なコミット実行
-- `planning-releases` — イテレーション計画の作成・更新
+---
+name: tracking-progress
+description: プロジェクトの開発進捗を多角的に分析しレポートを生成。イテレーション達成度、技術実装状況、品質メトリクスを確認し、計画ドキュメントを自動更新する。「進捗を確認したい」「プロジェクトの状態を知りたい」「イテレーションの達成度を分析したい」「進捗ドキュメントを更新したい」といった場面で発動する。定期的な進捗可視化により、遅延や品質低下を早期に発見しプロジェクトの透明性を確保する。
+---
+
+# 進捗追跡
+
+プロジェクトの開発進捗を多角的に分析し、現在の状況を定量的に報告する。Git 履歴・テスト結果・ドキュメントを総合的に分析して進捗を可視化する。
+
+## オプション
+
+| オプション | 説明 |
+|-----------|------|
+| なし | 全体的な進捗確認（デフォルト） |
+| `--brief` | 簡潔な進捗サマリー表示 |
+| `--detailed` | 詳細な進捗レポート生成 |
+| `--iteration <番号>` | 特定イテレーションの進捗確認 |
+| `--technical` | 技術的な実装状況に焦点 |
+| `--docs` | ドキュメント更新状況の確認 |
+| `--update` | `docs/development/` 内のドキュメントを現在の進捗に合わせて更新 |
+
+## 分析の観点
+
+- **イテレーション達成度**: 計画 vs 実績の比較分析（SP、ストーリー数、期間）
+- **技術実装状況**: 機能完成度・テスト結果・ビルド状態
+- **品質メトリクス**: テストカバレッジ、静的解析結果、コード複雑度
+- **ドキュメント整備**: 計画書・仕様書・手順書の最新性
+
+## --update オプションの詳細
+
+`docs/development/` 内のドキュメントを現在の進捗に合わせて自動更新する。
+
+**更新対象**:
+
+- `docs/development/release_plan.md` — 進捗状況テーブル、リリース条件チェック、バーンダウン実績値
+- `docs/development/iteration_plan-*.md` — 成功基準チェック、タスク状態、完了条件（DoD）、メトリクス実績値
+
+**更新判定の情報源**:
+
+```bash
+git log --oneline --since="2 weeks ago"   # 実装状況の分析
+dotnet test --logger trx                  # テスト結果の取得
+npm test -- --coverage                    # カバレッジの取得
+```
+
+## 出力例
+
+```
+プロジェクト進捗レポート
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+Overall Status: フルスタック実装完成 (MVP 準備段階)
+
+Iteration Progress:
+├─ Iteration 1 (認証・閲覧): 完了 (計画 10 日→実績 4 日)
+├─ Iteration 2 (予約機能): 計画済み
+├─ Iteration 3 (キャンセル): 待機中
+└─ Iteration 4 (運用準備): 待機中
+
+Technical Implementation:
+├─ Backend (.NET 9): 完全実装 (181 テスト全通過)
+├─ Frontend (React TS): 完全実装
+└─ API Integration: フルスタック連携確認
+```
+
+## 途中から再開
+
+進捗追跡の途中から再開する場合は、前回の追跡結果を確認する。
+
+**Example:**
+
+```
+ユーザー: 「イテレーション 2 の中間進捗を確認したい」
+回答: --iteration 2 で現在の達成状況を分析する。
+      計画 SP と完了 SP を比較し、残りの期間で完了可能か評価する。
+      遅延リスクがあれば早期に報告する。
+```
+
+## 注意事項
+
+- Git リポジトリ内で実行し、プロジェクト構造を理解していること（前提条件）
+- 実行時点での動的な状況を総合的に分析する
+- `--update` 使用時は更新前に Git でコミットしておくことを推奨する（ロールバック用）
+- イテレーション開始・終了時の定期実行を推奨する
+- `--update` 実行後、KPT セクションは手動で記入して振り返りを完了する
+
+## 関連スキル
+
+- `managing-docs` — ドキュメント一覧と進捗状況の確認
+- `git-commit` — 進捗に合わせた適切なコミット実行
+- `planning-releases` — イテレーション計画の作成・更新

package/lib/assets/.claude/skills/validating-design/SKILL.md

@@ -0,0 +1,130 @@
+---
+name: validating-design
+description: 開発戦略・イテレーション計画・設計ドキュメント・過去のイテレーション計画の間で、設計トピックの整合性を横断検証する。3 軸で検証する — (A) 開発戦略（docs/development/development_strategy.md）とイテレーション計画の局面・アプローチ整合、(B) イテレーション計画と docs/design 設計ドキュメント群の整合、(C) 過去のイテレーション計画の設計トピックとの整合（命名・設計判断・ユビキタス言語の連続性）。「設計整合性をチェックして」「開発戦略とイテレーション計画がずれていないか確認したい」「イテレーション計画と docs/design の設計が一致しているか検証したい」「過去のイテレーションの設計と矛盾していないか確認したい」「設計トピックの一貫性を検証したい」といった場面で必ず発動する。イテレーション計画を作成・更新した直後や開発着手前に本検証を実施することで、局面をまたいでも設計判断とユビキタス言語の一貫性を保てる。単一計画とアップストリーム設計の詳細突合は validating-iteration-plan、本スキルはそれに戦略整合と過去計画との連続性検証を加えた広域版。
+---
+
+# 設計整合性の横断検証
+
+開発が複数イテレーションにまたがると、設計トピック（集約名・テーブル名・URL パス・アプローチ・ユビキタス言語）が、開発戦略・当該計画・設計ドキュメント・過去計画の間で少しずつずれていく。ずれは実装の不整合に直結するため、計画作成・更新の直後に横断検証して開発着手前に解消する。
+
+本スキルは 3 軸で検証する。各軸は独立に実行でき、不整合を見つけたら**設計ドキュメントと開発戦略を「正」とし**、イテレーション計画側を修正する（戦略や設計判断そのものを見直すべき重大なずれは、その旨を報告して判断を仰ぐ）。
+
+## 検証の 3 軸
+
+| 軸 | 検証対象 | 正となるドキュメント | 主眼 |
+| :--- | :--- | :--- | :--- |
+| A | 開発戦略 ↔ イテレーション計画 | `docs/development/development_strategy.md` | 局面割り当てとアプローチの一致 |
+| B | イテレーション計画 ↔ 設計ドキュメント | `docs/design/*` | 設計トピックの相互トレーサビリティ |
+| C | 今回計画 ↔ 過去のイテレーション計画 | `docs/development/iteration_plan-*.md`（既存分） | 命名・設計判断・ユビキタス言語の連続性 |
+
+> 軸 B のドキュメント単位の詳細突合（ドメイン/データモデル・UI のフィールド名・型・遷移）は `validating-iteration-plan` が担う。本スキルの軸 B は「設計トピックが計画と設計ドキュメントの双方向で欠落なく対応しているか」というカバレッジ観点に絞り、詳細突合が必要なら `validating-iteration-plan` に委譲する。
+
+## 軸 A: 開発戦略とイテレーション計画の整合
+
+開発戦略はイテレーションを序盤・中盤・終盤の局面に割り当て、各局面のアプローチ（アウトサイドイン / インサイドアウト）を定める。当該イテレーション計画の設計・タスクが、戦略が指定する局面・アプローチと一致しているかを検証する。
+
+**チェック項目**:
+
+- [ ] 当該イテレーション番号が、開発戦略の局面割り当て表でどの局面に属するかを特定できる
+- [ ] 計画の設計・タスクの進め方（テストの入口・レイヤー貫通順）が、その局面のアプローチと一致している（例: 中盤=インサイドアウトなのに、計画が受け入れテスト起点のアウトサイドイン手順になっていないか）
+- [ ] 序盤の場合、ウォーキングスケルトン基盤化（ナビゲーション一括作成等）の方針が計画に反映されているか
+- [ ] 戦略が定める「イテレーションごとの設計ドキュメント整合」フロー（着手時検証・実装中の docs/design 更新・完了時の取り込み）が計画の進め方と矛盾しないか
+- [ ] 戦略の対象ユーザーストーリー表と計画の対象ストーリーが一致している（局面をまたいで US が移動していないか）
+- [ ] 局面移行の境界イテレーションの場合、移行時の一貫性確認事項（前局面パターンの踏襲・リリース条件）が考慮されているか
+
+**よくある不整合**:
+
+- 戦略では中盤（インサイドアウト）の IT なのに、計画のワークフローがアウトサイドインで書かれている
+- 戦略の局面別 US 割り当てとリリース計画・計画の US がずれている（戦略更新漏れ）
+- 序盤 IT なのにウォーキングスケルトン基盤化への言及がない
+
+## 軸 B: イテレーション計画と設計ドキュメントの整合（トピックカバレッジ）
+
+計画の「設計」セクションに現れる各設計トピックが、`docs/design/` の該当ドキュメントに存在し、逆に当該ストーリーが要する設計ドキュメントの要素が計画に取り込まれているか、双方向で確認する。
+
+**チェック項目**:
+
+- [ ] 計画のドメインモデルトピック（集約・エンティティ・値オブジェクト）が `domain-model.md` に存在する
+- [ ] **【絶対項目】対象スコープの設計図が計画の「設計」節に含まれているか**: 当該 IT の実装対象に絞った (1) ドメインモデル図、(2) 状態遷移図、(3) ER 図、(4) 画面遷移図 の 4 図を PlantUML で「設計」節に掲載する（`docs/design/` の全体図をコピーせず、当該 IT スコープに絞る。後続 IT の要素は破線・コメントで区別し、`docs/design/` へ反映が要る新規要素は注記する）。状態を持たない集約が対象 IT に無い場合は状態遷移図を、画面を伴わない IT の場合は画面遷移図を省略可とし、その旨を明記する
+- [ ] **【ドリフト再発防止】新規追加した「ドメインサービス（Calculator/Policy 等）」「BC 固有の列挙型」が `domain-model.md` の要素表に定義行として載っているか**（集約・VO だけでなくドメインサービス・enum も要素表に含める。IT1/IT2/IT3 で反復したドリフトの防止）
+- [ ] **【ドリフト再発防止】`ui_design.md` の salt ワイヤーフレーム本体が仕様セクションと同期しているか**（仕様だけ更新して図が旧内容のまま、を防ぐ）
+- [ ] 計画のデータモデルトピック（テーブル・カラム）が `data-model.md` に存在する
+- [ ] 計画の UI トピック（画面・URL・遷移）が `ui_design.md`（画面一覧・画面遷移図）に存在する
+- [ ] **【絶対項目】ナビゲーション整合性**: 当該 IT で新規／実画面化する画面が `ui_design.md` のナビゲーション構成表に表示ロール付きで存在し、かつ計画に「navbar（`_Layout.cshtml`）とダッシュボード（`Home/Index.cshtml`）へロール条件付きで反映＋ナビ表示の検証テスト」がタスク／注記として含まれている（個別画面の整合性とナビゲーション整合性は両方確認する。片方だけでは不足）
+- [ ] 計画の API 設計・ディレクトリ構成が `architecture_backend.md` / `architecture_frontend.md` と整合している
+- [ ] 逆方向: 対象ストーリーの受入基準が要求する設計要素で、設計ドキュメントにあるのに計画に取り込まれていないものがないか
+- [ ] 実装で設計判断が変わった箇所が「注」として計画に明記され、`docs/design/` への反映要否が示されているか
+- [ ] ADR が必要な設計判断（構造変更）が計画の ADR 節に挙がっているか
+
+**詳細突合が必要な場合**: フィールド名・型・命名規約・遷移方式（GET/PRG）・htmx パターンまで踏み込む場合は `validating-iteration-plan` を実行する。本軸はトピックの過不足検出に留める。
+
+## 軸 C: 過去のイテレーション計画の設計トピックとの整合
+
+`docs/development/iteration_plan-*.md` の既存分（今回より前の全計画）を確認し、過去に確立した設計トピックと今回計画が矛盾していないかを検証する。設計ドキュメントに未反映の設計判断が過去計画にのみ残っている場合、それも「正」として扱う。
+
+**チェック項目**:
+
+- [ ] 集約・エンティティ・値オブジェクトの命名が過去計画と一致している（同じ概念に別名を当てていないか）
+- [ ] テーブル名・カラム名・命名規約（単複・サロゲートキー + UK・FK 参照先）が過去計画と一貫している
+- [ ] URL パス・画面名・ナビゲーション項目が過去計画・ウォーキングスケルトンと連続している
+- [ ] ユビキタス言語（用語）が過去計画と一致している（例: 請求書/精算書、追跡番号の呼称ブレ）
+- [ ] 過去計画で確立したパターン（ポート/ACL・UoW・イベント発行・スタブ契約）を今回も踏襲しているか、変える場合は理由と ADR があるか
+- [ ] 過去計画の「持ち越し事項」「次のステップ」「注」で今回対応と明記された設計事項が、今回計画に反映されているか
+- [ ] 集約フィールドの段階的追加（nullable/Maybe での導入等）の方針が過去の進め方と整合しているか
+
+**よくある不整合**:
+
+- 過去計画で `Location` 共有カーネルを使う設計だったのに、今回計画が locode を `string` 直持ちしている
+- 過去計画のテーブル命名（単数形・サロゲートキー）と今回が食い違う
+- 過去計画で定義済みの用語と別の用語を使う（ユビキタス言語の分岐）
+- 過去計画で「IT(N) で対応」と明記された設計事項が今回計画から漏れている
+
+## 検証手順
+
+1. 対象イテレーション番号を特定する（引数がなければ最新の `iteration_plan-*.md`）。
+2. 軸 A: `development_strategy.md` を読み、局面割り当てとアプローチを確認して計画と突合する。
+3. 軸 B: 計画の「設計」節を読み、`docs/design/` 各ドキュメントとトピックの過不足を突合する。あわせて対象スコープの 4 図（ドメインモデル図・状態遷移図・ER 図・画面遷移図）が「設計」節に掲載されているかを確認し、欠落があれば当該 IT スコープに絞って追加する。
+4. 軸 C: 今回より前の `iteration_plan-*.md` を全て読み、命名・設計判断・ユビキタス言語の連続性を突合する。
+5. 各軸は並列実行可能。サブエージェントが使える場合は 3 軸を並列に走らせると速い。
+6. 不整合を発見したら計画を修正する（設計ドキュメント・開発戦略・過去計画が正）。戦略や設計そのものの見直しが要る重大なずれは報告して判断を仰ぐ。
+
+## 検証結果の報告
+
+```markdown
+## 設計整合性検証結果
+
+### 検証対象
+- イテレーション計画: `docs/development/iteration_plan-N.md`
+- 局面（開発戦略）: 序盤 / 中盤 / 終盤（アプローチ: アウトサイドイン / インサイドアウト）
+
+### 検証結果サマリー
+
+| 軸 | 検証対象 | 結果 | 不整合件数 |
+|----|---------|------|-----------|
+| A | 開発戦略 ↔ 計画 | OK / NG | N 件 |
+| B | 計画 ↔ 設計ドキュメント | OK / NG | N 件 |
+| C | 計画 ↔ 過去計画 | OK / NG | N 件 |
+
+### 不整合一覧（NG の場合のみ）
+
+#### 軸 X: 〇〇との不整合
+
+| # | 不整合内容 | 計画の記述 | 正しい記述（正となる出典） | 出典 | 修正要否 |
+|---|----------|-----------|------------------------|------|---------|
+| 1 | ... | ... | ... | development_strategy.md / design/xxx.md / iteration_plan-M.md | 要修正 |
+```
+
+## 注意事項
+
+- 検証は計画の作成・更新直後、開発着手前に実施する。
+- 正の優先順位は「設計ドキュメント・開発戦略 > 過去計画 > 今回計画」。ただし設計ドキュメント未反映の設計判断が過去計画にのみ残る場合、その判断を正として扱い、必要なら `docs/design/` への反映を促す。
+- 単一計画のフィールド単位の詳細突合は `validating-iteration-plan` に委譲し、本スキルは戦略整合・トピックカバレッジ・過去計画との連続性に集中する（役割の重複を避ける）。
+- ユーザーの指示があるまでコミットしない。
+
+## 関連スキル
+
+- `validating-iteration-plan` — 単一計画とアップストリーム設計のフィールド単位の詳細突合（軸 B の詳細版）
+- `creating-development-strategy` — 開発戦略の作成・更新（軸 A の正の出典）
+- `planning-releases` — イテレーション計画の作成（検証対象の入力）
+- `operating-docs` — 検証で判明した設計ドキュメント更新後のインデックス同期
+- `git-commit` — 修正後のコミット