@k2works/claude-code-booster 4.9.0 → 4.12.0

package/lib/assets/.claude/README.md

@@ -70,9 +70,13 @@ Claude Code をより効率的に使うための基本設定テンプレート
 | スキル | 説明 |
 | :--- | :--- |
 | `planning-releases` | アジャイルなリリース計画とイテレーション計画を作成・管理。 |
+| `opening-iteration` | イテレーションを開発着手できる状態まで準備する 6 ステップ（前 IT ふりかえり反映→計画作成→詳細整合性検証→横断整合性検証→GitHub 同期→ドキュメント同期）を案内。 |
+| `closing-iteration` | イテレーションを漏れなくクローズする 7 ステップ（レビュー→品質ゲート→進捗反映→ふりかえり→完了報告書→GitHub 同期→ドキュメント同期）を案内。 |
+| `creating-development-strategy` | 開発戦略ドキュメントを作成。リリース計画のイテレーションを序盤・中盤・終盤に分け、TDD アプローチ（アウトサイドイン／インサイドアウト）とウォーキングスケルトン、設計ドキュメント整合方針を定義。 |
 | `syncing-github-project` | リリース計画を GitHub Project・Issue・Milestone に同期。 |
 | `tracking-progress` | プロジェクトの開発進捗を包括的に分析しレポート生成。 |
 | `validating-iteration-plan` | イテレーション計画と上流設計ドキュメント群との整合性を検証。 |
+| `validating-design` | 開発戦略・イテレーション計画・設計ドキュメント・過去計画の間で設計トピックの整合性を横断検証。 |
 | `validating-operating-setup` | 環境セットアップ手順書の実施状況を監査し、未対応項目を報告。 |
 
 #### 運用系
@@ -213,6 +217,7 @@ Claude Code をより効率的に使うための基本設定テンプレート
 │   ├── tracking-progress/SKILL.md
 │   ├── syncing-github-project/SKILL.md
 │   ├── planning-releases/SKILL.md
+│   ├── creating-development-strategy/SKILL.md
 │   ├── creating-journal/SKILL.md
 │   ├── creating-slides/SKILL.md
 │   ├── creating-release-report/SKILL.md
@@ -222,6 +227,7 @@ Claude Code をより効率的に使うための基本設定テンプレート
 │   ├── orchestrating-operation/SKILL.md
 │   ├── orchestrating-project/SKILL.md
 │   ├── validating-iteration-plan/SKILL.md
+│   ├── validating-design/SKILL.md
 │   ├── validating-operating-setup/SKILL.md
 │   └── practicing-getting-start-tdd/SKILL.md
 ├── README.md

package/lib/assets/.claude/skills/closing-iteration/SKILL.md

@@ -0,0 +1,129 @@
+---
+name: closing-iteration
+description: イテレーション（IT）を漏れなくクローズするための手順を順序立てて案内する。レビュー→品質ゲート→進捗反映→ふりかえり→完了報告書→GitHub 同期→ドキュメント同期の 7 ステップをチェックリストとして提示し、抜けを防ぐ。「イテレーションをクローズしたい」「IT2 を締めたい」「イテレーションの締め作業をしたい」「開発が終わったので締めの作業をしたい」「ふりかえりから報告書・同期まで一通りやりたい」といった場面で必ず発動する。実装が終わった直後・イテレーション末・「次のイテレーションに進む前に」といった局面でも積極的に提案する。クローズ作業は工程が多く順序依存があるため、抜けやすい完了報告書・GitHub 同期・ドキュメント同期を含めて標準化することで、イテレーションの区切りを確実にする。
+---
+
+# イテレーションクローズ
+
+イテレーション（IT）の開発が一段落したあと、成果を確定し次イテレーションへ引き継ぐための締め作業を、順序立てて漏れなく実施する。
+
+クローズ作業は工程が多く（レビュー・品質確認・ふりかえり・報告書・GitHub・ドキュメント）、かつ順序に依存がある。ひとつでも抜けると「実装は終わったのに Issue が Open のまま」「報告書がなく実績が追えない」「ドキュメントインデックスと実体が乖離」といった負債が残る。本スキルはその抜けを防ぐためのチェックリストとオーケストレーションを提供する。
+
+## クローズの前提
+
+以下が揃っていることを確認してから着手する。揃っていなければ、まず開発（`orchestrating-development`）に戻る。
+
+- 対象イテレーションの全ユーザーストーリーが実装完了している
+- `docs/development/iteration_plan-N.md` が存在する（クローズ対象の計画）
+
+## クローズフロー（7 ステップ）
+
+順序には理由がある。レビュー指摘を反映してから品質ゲートを固め（ローカル＋CI の両方で緑を確認）、実績が確定してからふりかえり・報告書を書き、ドキュメントが整ってから GitHub とインデックスに同期する。上から順に実施する。
+
+> ステップ番号は 7 だが、品質ゲート（ステップ 2）にはローカル検証（2）と CI 確認（2.5）が含まれる。ローカル緑だけでは不十分で、CI が緑であって初めて品質ゲートを通過とみなす。
+
+### ステップ 1: マルチパースペクティブレビュー（`developing-review`）
+
+実装成果物を 5 つの XP 視点（programmer / tester / architect / technical-writer / user-representative）で並列レビューし、統合レポートを `docs/review/<対象名>_review_<YYYYMMDD>.md` に保存する。
+
+- **高優先度の指摘は原則クローズ前に対応する**（受入基準のテスト漏れ・設計整合・セキュリティなど）。対応できないものは「許容 / 保留 / 次イテレーション対応」の方針を明記する
+- レビュー→改善のループを 1 回まわしてからクローズに進むことで、負債を次イテレーションに持ち越さない
+- `docs/review/index.md` にレビュー行を追加する
+
+### ステップ 2: 品質ゲート
+
+「変更を楽に安全にできる」状態を数値と自動チェックで確認する。イテレーションの成果が緑であることを、この時点で確定させる。
+
+- 全テストが green（単体・統合・HTTP フロー / E2E）
+- Lint・フォーマットがクリーン（このプロジェクトでは `cargo clippy --workspace --all-targets -- -D warnings` と `cargo fmt --check`）
+- カバレッジを計測し目標との差分を把握する（`operating-qt` の SonarQube 品質ゲート、または `cargo llvm-cov`）
+- ゲートを通らない場合はクローズを止め、修正してから再度ここに戻る
+- **CI と同じツールチェーンで検証する**: ローカルの clippy が古いと CI（`.github/workflows/rust-ci.yml` は `dtolnay/rust-toolchain@stable` を使用）だけが新 lint で落ちる。ローカルの stable が CI より古い可能性があるため、`rustup update stable` してから `cargo +stable clippy --workspace --all-targets -- -D warnings` / `cargo +stable fmt --check` を実行し、ツールチェーンの乖離による「ローカル緑・CI 赤」を防ぐ
+
+### ステップ 2.5: CI 確認（`gh run`）
+
+ローカルのゲートが緑でも、CI で落ちていればイテレーションは緑ではない。**このステップは忘れやすい**（ローカルで達成感が出た後、push 後の CI 結果を見ないまま次に進みやすい）。
+
+- 対象ブランチの最新 CI 結果を確認する（`gh run list --branch <branch> --limit 5`）。直近が `failure` なら `gh run view <run-id> --log-failed` で原因を特定し、修正してステップ 2 に戻る
+- push 前にクローズ作業を進める場合も、過去コミットで CI が赤のまま放置されていないかを必ず確認する（赤を「完了」と宣言しない）
+- 修正後は再 push し、CI が緑に戻ることを確認してからクローズを確定する
+
+### ステップ 3: 進捗反映（`tracking-progress --update`）
+
+実績データ（git ログ・テスト結果・カバレッジ）を集計し、計画ドキュメントを実績で更新する。
+
+- `docs/development/release_plan.md`: 進捗状況テーブル（実績 SP・達成率・状態）、バーンダウン実績値
+- `docs/development/iteration_plan-N.md`: 成功基準・DoD のチェック、タスク状態、進捗率、実績注記
+- **未達・スコープ調整は正直に記録する**（「完了扱いだが受入基準の一部は次 IT」など）。ごまかすと後続の計画精度が落ちる
+
+### ステップ 4: ふりかえり（`planning-releases --retrospective`）
+
+KPT（Keep / Problem / Try）で振り返り、`docs/development/retrospective-N.md` に保存する。
+
+- **Keep**: 技術的・プロセス的にうまくいったこと
+- **Problem**: 未完了・見積もりのズレ・技術的負債の発生源
+- **Try**: 具体的な改善アクション（担当・期限・期待効果付き）。次イテレーション計画に反映できる粒度にする
+- 次イテレーションへの引き継ぎ（持ち越し事項）を明記する
+
+### ステップ 5: 完了報告書（`planning-releases --report` → `creating-iteration-report`）
+
+`docs/development/iteration_report-N.md` を作成する。**このステップは工程の後半にあり最も忘れやすい**。エグゼクティブサマリー・達成状況・技術的成果・品質指標・レビュー結果・課題と残作業・次イテレーション引き継ぎを、実績データから記述する。
+
+### ステップ 6: GitHub 同期（`syncing-github-project --sync`）
+
+`release_plan.md` を正として GitHub に反映する。
+
+- 完了ストーリーの Issue をクローズ（完了コメント付き）
+- GitHub Project のカスタムフィールド（Status → Done 等）を更新
+- マイルストーンの open/closed 件数を確認し、リリース進捗を把握する
+
+### ステップ 7: ドキュメント同期（`operating-docs --update`）
+
+ドキュメントインデックスを成果物の実体に合わせる。
+
+- `docs/development/index.md`: イテレーション行にふりかえり・完了報告書のリンクを追加、状態を「完了」に
+- `docs/index.md`: 開発の状態・レビュー件数・ADR 件数などのサマリーを更新
+- `mkdocs.yml`: ふりかえり・完了報告書・新規レビュー・新規 ADR をナビゲーションに追加
+- 追加行のインデントが既存ナビと一致しているか確認する
+
+### （任意）ステップ 8: ジャーナル（`creating-journal`）
+
+長いセッションや区切りとして、判断・詰まり・学びを `docs/journal/YYYYMMDD.md` に残すと、コミットログに載らない意思決定の経緯を追跡できる。
+
+## クローズ完了チェックリスト
+
+すべて満たしたらイテレーションはクローズ済みとみなす。
+
+- [ ] `developing-review` 実施・レポート保存・高優先度対応（または方針明記）
+- [ ] 全テスト green・Lint/フォーマットクリーン（CI と同じ `+stable` ツールチェーンで確認）・カバレッジ把握
+- [ ] **CI が緑**（`gh run list` で対象ブランチの最新実行が success・赤なら修正して再確認）
+- [ ] `release_plan.md` / `iteration_plan-N.md` を実績で更新
+- [ ] `retrospective-N.md`（KPT）作成
+- [ ] `iteration_report-N.md`（完了報告書）作成
+- [ ] GitHub Issue クローズ・Project Status 更新
+- [ ] `docs/index.md` / `docs/development/index.md` / `mkdocs.yml` 同期
+- [ ] 各ステップの成果を意味のある単位でコミット（`git-commit`）
+
+## コミットの区切り
+
+各ステップの成果は個別にコミットする（`git-commit`）。ドキュメント系は `docs(...)` タイプで、対象と目的が分かるメッセージにする。1 コミット 1 目的を守ることで、後から特定のクローズ作業だけを追跡・ロールバックできる。
+
+## 注意事項
+
+- **順序を守る**: レビュー指摘の反映前に報告書を書くと、報告書が実態とずれる。品質ゲートを通す前に GitHub をクローズすると、緑でない成果を「完了」と宣言してしまう
+- **抜けやすいのはステップ 5-7**（報告書・GitHub・ドキュメント）。実装とレビューで達成感が出た後の事務作業のため後回しにされやすい。チェックリストで機械的に確認する
+- **ローカル緑を CI 緑と混同しない**（ステップ 2.5）。ローカルのツールチェーンが CI（`@stable`）より古いと、新しい clippy lint がローカルをすり抜けて CI だけ赤になる。クローズ確定前に `gh run` で CI の実結果を必ず確認し、赤なら緑に戻す
+- **正直さを優先する**: 未達・スコープ調整・DoD の未チェック項目は隠さず記録する。次イテレーションの計画精度とベロシティの信頼性はこの正直さに依存する
+
+## 関連スキル
+
+- `orchestrating-project` — 計画・進捗管理フェーズ全体のオーケストレーション（本スキルはその「イテレーション終了時」を詳細化したもの）
+- `developing-review` — 開発成果物のマルチパースペクティブレビュー（ステップ 1）
+- `operating-qt` — SonarQube による品質ゲート確認（ステップ 2）
+- `tracking-progress` — 進捗分析・ドキュメント更新（ステップ 3）
+- `planning-releases` — ふりかえり・完了報告書（ステップ 4-5）
+- `creating-iteration-report` — 完了報告書の作成（ステップ 5 の委譲先）
+- `syncing-github-project` — GitHub 同期（ステップ 6）
+- `operating-docs` — ドキュメントインデックス更新・Lint（ステップ 7）
+- `creating-journal` — セッション記録（任意ステップ 8）
+- `git-commit` — 各ステップ成果のコミット

package/lib/assets/.claude/skills/creating-development-strategy/SKILL.md

@@ -0,0 +1,101 @@
+---
+name: creating-development-strategy
+description: 開発戦略ドキュメント（docs/development/development_strategy.md）の作成・更新を支援。リリース計画のイテレーションを序盤・中盤・終盤の局面に分け、各局面で採用する TDD アプローチ（アウトサイドイン / インサイドアウト）、ウォーキングスケルトンの基盤化、イテレーションごとの設計ドキュメント整合方針を定義する。「開発戦略を作りたい」「開発の進め方を局面ごとに決めたい」「アウトサイドインとインサイドアウトをどう使い分けるか整理したい」「ウォーキングスケルトンの方針を文書化したい」「イテレーションと設計ドキュメントの整合方針を決めたい」といった場面で必ず発動する。リリース計画やイテレーション計画を作成した後、開発フェーズに着手する前に開発戦略を定めておくことで、局面が変わってもアーキテクチャと品質の一貫性を保った開発を進められる。
+---
+
+# 開発戦略作成
+
+リリース計画のイテレーション群を **序盤・中盤・終盤** の 3 局面に分け、各局面で採用する TDD アプローチと横断的な進め方を定義する開発戦略ドキュメントを作成する。
+
+開発戦略の価値は「どのイテレーションでどちらのアプローチを採るか」という戦略レイヤーを明文化することにある。個々の TDD サイクルは [コーディングとテストガイド](../../../docs/reference/コーディングとテストガイド.md) に従うため、本戦略はその上位で「テストの入口をどこに置き、レイヤーをどの順で貫通するか」を局面ごとに決める。局面が切り替わってもアーキテクチャ・品質・ユビキタス言語の一貫性を保つことが狙い。
+
+## 成果物
+
+- 配置場所: `docs/development/development_strategy.md`
+- 正となる参照元:
+  - アプローチ・手順・品質基準は [コーディングとテストガイド](../../../docs/reference/コーディングとテストガイド.md)（Single Source of Truth）
+  - イテレーション × ユーザーストーリー割り当ては [リリース計画](../../../docs/development/release_plan.md)（Single Source of Truth）
+  - 画面遷移・ナビゲーションは [UI 設計](../../../docs/design/ui_design.md)
+
+## 3 局面戦略の基本形
+
+局面ごとに変えるのは **テストの入口** と **レイヤー貫通の順序** のみ。Red-Green-Refactor サイクルそのものは全局面で不変とする。
+
+| 局面 | 対象イテレーション | 主アプローチ | 狙い |
+| :--- | :--- | :--- | :--- |
+| 序盤 | 最初の 1-2 IT | アウトサイドイン | 縦切りで「歩けるスケルトン」を通し、アーキテクチャ基盤の妥当性を早期検証 |
+| 中盤 | 中核ドメインの IT | インサイドアウト | 複雑なドメインロジックをデータ層・ドメイン層から堅牢に作り込み、貧血ドメインモデルを回避 |
+| 終盤 | 仕上げの IT | アウトサイドイン | 既存ドメインを業務シナリオ起点で結合し、リリース全体の一貫性を担保 |
+
+### アプローチ選択の根拠
+
+選択は [コーディングとテストガイドの実装アプローチ選択フロー](../../../docs/reference/コーディングとテストガイド.md#アプローチ戦略) に対応づけて説明する。理由を書くことで、局面が機械的な区切りでなく論理的必然であることを示す。
+
+- 序盤（アウトサイドイン）: API・基盤とも未実装 → UI/受け入れテストのニーズから API を導出し薄く貫通させるのが安全（「API 未実装 → アウトサイドイン活用」）。
+- 中盤（インサイドアウト）: 複雑ドメインで貧血モデルを避けたい → データ層・ドメイン層の基盤を固めてから上位へ展開（「基盤未確立 → インサイドアウト推奨」）。
+- 終盤（アウトサイドイン）: 基本実装済み × ドメイン複雑 → 既存集約を組み合わせ業務シナリオを受け入れテストで束ねる（「基本実装済み × 複雑 → アウトサイドイン推奨」）。
+
+## 作成の進め方
+
+1. **参照元を読む**: コーディングとテストガイド（アプローチのシーケンス図・品質基準・コミット規約）、リリース計画（イテレーション構成・DDD コンテキスト・SP）を読み込む。
+2. **局面を割り当てる**: リリース計画のイテレーションを 3 局面へ振り分ける。基盤・入口の IT を序盤、複雑ドメイン中核の IT を中盤、例外・請求など仕上げの IT を終盤とする。プロジェクトの中核が複雑なドメインを持たない場合は局面数や順序を調整してよい。
+3. **共通の TDD サイクル節を書く**: Red-Green-Refactor と品質チェック（該当プロジェクトのビルド/テストコマンド）、テストプロジェクトとレイヤーの対応表を記載する。
+4. **各局面の節を書く**: 目的・対象ユーザーストーリー・ワークフロー（ガイドのアウトサイドイン/インサイドアウト シーケンスに基づく PlantUML/Mermaid）・手順・完了条件を記述する。
+5. **横断方針を書く**: 局面移行時の一貫性維持と、アプローチが変わっても不変な規律（サイクル 3 原則・コミット単位・品質基準・アーキテクチャテスト常時グリーン）を明記する。
+6. **インデックスを同期する**: `operating-docs --update` で `docs/development/index.md` と `mkdocs.yml` に開発戦略を追加する。
+7. コミットは `git-commit`（ユーザー指示があるまでコミットしない）。
+
+## ドキュメント構成（推奨見出し）
+
+```markdown
+# 開発戦略 - <プロジェクト名>
+
+## 概要（参照元と Single Source of Truth の明記）
+## 戦略の全体像（局面 → アプローチの対応表・図）
+## 共通の TDD サイクル（Red-Green-Refactor・テストプロジェクト対応・品質チェック）
+## 序盤: アウトサイドイン（目的 / 対象 US / ワークフロー / 手順 / 完了条件）
+## 中盤: インサイドアウト（同上）
+## 終盤: アウトサイドイン（同上）
+## イテレーションごとの設計ドキュメント整合
+## 局面移行時の一貫性維持
+## 更新履歴
+```
+
+## 拡張トピック（プロジェクトに応じて追加）
+
+### ウォーキングスケルトンの基盤化
+
+序盤で認証などの横断基盤を構築した直後に、[UI 設計の画面遷移図](../../../docs/design/ui_design.md#画面遷移図) に従ったナビゲーション（ロール制御付き）と全ルートのプレースホルダ画面を一括作成し、これを骨格とする。認証・認可・PRG・フラッシュ・レイアウトといった横断関心事を業務ロジックが薄いうちに全画面で成立させ、以降の各 IT を「スタブを実画面へ差し替える」インクリメンタルな作業に落とす。対象ルート・表示ロール・担当 IT を対応表で明示する。
+
+### イテレーションごとの設計ドキュメント整合
+
+各 IT で `iteration_plan-N.md` の設計トピックと `docs/design/`（ドメイン/データモデル・UI 設計・アーキテクチャ・ADR）の整合を、着手時・実装中・完了時に確認する。イテレーション計画は局所ビュー、`docs/design/` は全体の「正」であり、実装で設計判断が変わったらその場で `docs/design/` を更新する（計画側だけに書いて放置しない）。着手時は `validating-iteration-plan` で検証し、構造変更はアーキテクチャテストとフルテストで裏取りする。
+
+## 途中から再開・更新
+
+既存の `docs/development/development_strategy.md` がある場合はまず内容を読み、局面割り当てやアプローチの追記・修正のみを行う。リリース計画のイテレーション構成が変わった場合は、局面への割り当て表と各局面の対象 US を追従させ、更新履歴に日付と変更内容を追記する。
+
+**Example:**
+
+```
+ユーザー: 「中盤にイテレーションを 1 つ追加したので開発戦略を更新したい」
+回答: development_strategy.md の中盤節の対象 US 表とワークフローに追加 IT を反映し、
+      戦略の全体像の対応表を更新。更新履歴に追記し、
+      operating-docs --update でインデックスを同期する。
+```
+
+## 注意事項
+
+- アプローチ選択は必ず [コーディングとテストガイドの選択フロー](../../../docs/reference/コーディングとテストガイド.md#アプローチ戦略) に理由づける。「なぜこの局面でこのアプローチか」を書かないと、単なる区切り表になり戦略の価値が失われる。
+- `ALWAYS`/`MUST` の羅列でなく、各局面の狙い（why）を説明する文体にする。局面が変わっても不変な規律（Red-Green-Refactor 3 原則・1 コミット 1 変更・品質基準・アーキテクチャテスト常時グリーン）は明記する。
+- 品質チェックコマンド・テストプロジェクト名は対象プロジェクトの実構成に合わせる（憶測で書かない。`*.sln`・`*.csproj` 等を確認する）。
+- 新規作成後は `docs/development/index.md` と `mkdocs.yml` を必ず同期する。ユーザーの指示があるまでコミットしない。
+
+## 関連スキル
+
+- `planning-releases` — リリース・イテレーション計画（局面割り当ての入力）
+- `orchestrating-development` — 開発フェーズ全体の TDD ワークフロー（本戦略の実行フェーズ）
+- `validating-iteration-plan` — イテレーション計画と設計ドキュメントの整合検証
+- `developing-backend` / `developing-frontend` — 各局面での TDD 実装
+- `operating-docs` — インデックス同期（`--update`）
+- `git-commit` — 作成後のコミット

package/lib/assets/.claude/skills/opening-iteration/SKILL.md

@@ -0,0 +1,105 @@
+---
+name: opening-iteration
+description: イテレーション（IT）を開発着手できる状態まで準備する手順を順序立てて案内する。前イテレーションふりかえりの反映→計画作成→詳細整合性検証→横断整合性検証→GitHub 同期→ドキュメント同期の 6 ステップをチェックリストとして提示し、着手前に計画と設計の不整合を潰す。「イテレーションを始めたい」「IT3 の計画を作って開始準備したい」「次のイテレーションの準備をしたい」「イテレーションを立ち上げたい」「開発に入る前の計画と検証を一通りやりたい」といった場面で必ず発動する。前イテレーションのクローズ直後・「次の IT に進む」「新しいスプリントを始める」局面でも積極的に提案する。開始準備は計画作成だけで終わりがちだが、着手前の整合性検証を省くと BC 独立性違反・設計反映漏れがそのまま実装の手戻りになるため、検証と同期まで含めて標準化することで開発を安全に始められる状態を作る。
+
+---
+
+# イテレーション開始準備
+
+イテレーション（IT）の開発に着手する前に、計画を立て、上流設計・過去計画との整合を検証し、GitHub とドキュメントに反映するまでの立ち上げ作業を、順序立てて漏れなく実施する。
+
+計画は複数の設計ドキュメントから情報を引用するため、作成しただけで着手すると不整合がそのまま実装の手戻りになる。特に「ドメイン層のクレート依存（BC 独立性）」「設計ドキュメントの反映漏れ」「前イテレーションのふりかえり Try の取りこぼし」は、計画段階では気づきにくく実装で初めて露見しやすい。本スキルは、着手前にこれらを潰すためのチェックリストとオーケストレーションを提供する。`closing-iteration`（締め）と対になる立ち上げ側のスキルである。
+
+## 開始の前提
+
+以下を確認してから着手する。揃っていなければ、まず前イテレーションのクローズ（`closing-iteration`）またはリリース計画（`planning-releases --release`）に戻る。
+
+- 前イテレーションがクローズ済み（ふりかえり・完了報告書がある）。初回イテレーションの場合は不要
+- `docs/development/release_plan.md` に対象イテレーションのスコープ（ストーリー・SP）が定義されている
+- `docs/development/development_strategy.md` に対象イテレーションの局面（序盤/中盤/終盤）とアプローチが定義されている
+
+## 開始準備フロー（6 ステップ）
+
+順序には理由がある。前 IT の学びを計画に織り込み、計画を作ってから上流設計・過去計画と突き合わせ、整合が取れてから GitHub とインデックスに反映する。上から順に実施する。
+
+### ステップ 1: 前イテレーションふりかえりの反映
+
+前イテレーションの `docs/development/retrospective-(N-1).md` を読み、Try（改善アクション）・持ち越し事項・次イテレーション引き継ぎを確認する。
+
+- これらは計画作成の**入力**になる。「受入基準をテストケースに 1:1 対応させる」「N+1 を SQL 絞り込みへ」「前 IT の未実装分を統合」といった Try を、次の計画のタスク・成功基準に具体的に落とし込む
+- ふりかえりを読まずに計画を書くと、改善のループが切れて同じ問題を繰り返す。この反映こそが計画を「生きた文書」にする
+
+### ステップ 2: イテレーション計画の作成（`planning-releases --iteration N`）
+
+`docs/development/iteration_plan-N.md` を作成する。
+
+- ゴール（1-2 行）・対象ストーリー（release_plan と一致）・受入条件・タスク分解（4-16 理想時間）・スケジュール・設計（対象スコープに絞った 4 図）・リスク・DoD を記述する
+- **設計 4 図**（ドメインモデル図・状態遷移図・ER 図・画面遷移図）は当該 IT スコープに絞って掲載する。状態を持たない対象なら状態遷移図を、画面を伴わない IT なら画面遷移図を省略し、その旨を明記する
+- 局面（開発戦略）に合ったアプローチ（序盤/終盤=アウトサイドイン、中盤=インサイドアウト）でタスクを並べる
+- ステップ 1 の Try を「返済枠」や成功基準として明示的に組み込む
+
+### ステップ 3: 詳細整合性検証（`validating-iteration-plan`）
+
+計画と上流設計ドキュメント（ユーザーストーリー・ドメインモデル・データモデル・UI 設計）をフィールド単位で突合する。
+
+- ストーリー ID・受入基準・集約/値オブジェクト名・テーブル名/カラム/命名規約・URL パス・htmx/PRG パターンの一致を確認する
+- **不整合は計画側を設計ドキュメントに合わせて修正する**（設計が正）。設計ドキュメント自体の欠落・先行実装が必要な要素は「注（設計への反映が必要）」として計画に明記し、当該 IT で反映する
+- 前イテレーションのレビュー指摘（`docs/review/` の最新）が計画に反映されているかも確認する
+
+### ステップ 4: 横断整合性検証（`validating-design`）
+
+開発戦略・過去のイテレーション計画との横断整合を 3 軸で検証する。
+
+- **軸 A（開発戦略）**: 局面・アプローチ・US 割当・段階実装方針の一致
+- **軸 B（設計トピックカバレッジ）**: 新規ドメインサービス・enum の要素表への追加、ナビゲーション整合、4 図の掲載
+- **軸 C（過去計画の連続性）**: 命名・BC 独立性パターン（コンテキスト固有型の踏襲）・共有カーネル再利用・認可/DIP パターン・前 IT 引き継ぎの反映
+- ここで **BC 独立性違反（例: domain-A が domain-B に依存する設計）や前 IT の設計反映漏れ**を検知できる。これらはコンパイル不能や手戻りに直結するため、着手前の検出価値が高い
+
+### ステップ 5: GitHub 同期（`syncing-github-project --sync`）
+
+`release_plan.md` を正として GitHub に反映する。
+
+- 対象ストーリーの Issue を確認（未作成なら作成）し、Project のイテレーションフィールドを対象 IT に割り当てる
+- SP・マイルストーンが正しいか確認する
+- Status は計画済み・未着手なら Todo のまま。開発着手時に In Progress へ更新する
+
+### ステップ 6: ドキュメント同期（`operating-docs --update`）
+
+ドキュメントインデックスに新しい計画を反映する。
+
+- `docs/development/index.md`: イテレーション行を追加（状態「計画済み」）
+- `docs/development/release_plan.md`: 該当イテレーションの概要リンクを有効化・進捗表の状態を「計画済み」に
+- `mkdocs.yml`: イテレーション計画をナビゲーションに追加
+- 追加行のインデントが既存ナビと一致しているか確認する
+
+## 開始準備完了チェックリスト
+
+すべて満たしたらイテレーションは開発着手可能な状態とみなす。
+
+- [ ] 前イテレーションふりかえりの Try・引き継ぎを計画に反映
+- [ ] `iteration_plan-N.md` 作成（ゴール・ストーリー・タスク・設計 4 図・DoD）
+- [ ] `validating-iteration-plan` 実施・不整合を修正
+- [ ] `validating-design` 実施・3 軸の不整合を修正（BC 独立性・設計反映漏れ含む）
+- [ ] GitHub Issue 確認・Project イテレーション割当
+- [ ] `docs/development/index.md` / `release_plan.md` / `mkdocs.yml` 同期
+- [ ] 各ステップの成果を意味のある単位でコミット（`git-commit`）
+
+これらが揃ったら、`orchestrating-development` で開発フェーズ（TDD サイクル）に進む。
+
+## 注意事項
+
+- **順序を守る**: 計画を作る前にふりかえりを読む（学びの反映）。GitHub に反映する前に検証を通す（不整合を GitHub に持ち込まない）
+- **検証を省かない**: 開始準備は計画作成だけで満足しがちだが、`validating-iteration-plan` と `validating-design` こそが着手前の安全網。ここで潰す不整合（BC 独立性違反・設計反映漏れ）は、実装後に直すと数倍のコストになる
+- **設計が正**: 検証で見つかった不整合は原則計画側を直す。設計ドキュメントの欠落は「注」で明記し当該 IT で反映する（実装と設計の同時反映が、先行乖離を防ぐ）
+
+## 関連スキル
+
+- `closing-iteration` — イテレーションの締め（本スキルと対になるクローズ側）
+- `orchestrating-project` — 計画・進捗管理フェーズ全体のオーケストレーション（本スキルはその「イテレーション開始時」を詳細化したもの）
+- `planning-releases` — イテレーション計画の作成（ステップ 2）
+- `validating-iteration-plan` — 計画と上流設計のフィールド単位の詳細突合（ステップ 3）
+- `validating-design` — 開発戦略・過去計画との横断整合検証（ステップ 4）
+- `syncing-github-project` — GitHub 同期（ステップ 5）
+- `operating-docs` — ドキュメントインデックス更新・Lint（ステップ 6）
+- `orchestrating-development` — 開始準備完了後の開発フェーズ
+- `git-commit` — 各ステップ成果のコミット

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` — 修正後のコミット

package/lib/assets/CLAUDE.md

@@ -68,9 +68,13 @@
 | スキル | 用途 |
 | :--- | :--- |
 | `planning-releases` | リリース・イテレーション計画 |
+| `opening-iteration` | イテレーション開始準備（計画作成・整合性検証・同期の 6 ステップ） |
+| `closing-iteration` | イテレーションクローズ（レビュー・ふりかえり・報告書・同期の 7 ステップ） |
+| `creating-development-strategy` | 開発戦略（局面別 TDD アプローチ・ウォーキングスケルトン）策定 |
 | `syncing-github-project` | GitHub Project 同期 |
 | `tracking-progress` | 進捗分析・レポート |
 | `validating-iteration-plan` | イテレーション計画の整合性検証 |
+| `validating-design` | 設計トピックの横断的整合性検証 |
 
 ### 運用
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@k2works/claude-code-booster",
-  "version": "4.9.0",
+  "version": "4.12.0",
   "description": "AI Agent Development Support Tool",
   "main": "main.js",
   "bin": {