@k2works/claude-code-booster 4.9.0 → 4.11.0

package/lib/assets/.claude/skills/creating-adr/SKILL.md

@@ -1,113 +1,113 @@
----
-name: creating-adr
-description: Architecture Decision Record（ADR）の作成・管理を支援。技術的意思決定の背景・決定・影響をテンプレートに沿って記録する。「ADR を作成したい」「アーキテクチャの決定を記録したい」「技術選定の理由を残したい」「設計判断を文書化したい」といった場面で発動する。意思決定の経緯を記録することで、将来「なぜこの技術を選んだのか」が追跡可能になり、同じ議論の繰り返しを防ぐ。
----
-
-# ADR 作成
-
-アーキテクチャ決定記録（ADR）を作成・管理する。技術的意思決定のコンテキスト・決定内容・影響を構造化して記録する。
-
-ADR の価値は「決定そのもの」ではなく「なぜその決定に至ったか」を残すこと。代替案と却下理由を含めることで、将来の見直し時に同じ検討を繰り返さずに済む。
-
-## ADR テンプレート
-
-```markdown
-# ADR-NNN: タイトル
-
-簡潔な説明（1 行で決定内容を要約）。
-
-日付: YYYY-MM-DD
-
-## ステータス
-
-提案中 | 承認済み | 廃止 | 置換（ADR-XXX で置換）
-
-## コンテキスト
-
-この決定が必要になった背景・状況を説明。
-
-- 現在の課題や制約
-- 関連するシステムやサービス
-- ビジネス要件
-
-## 決定
-
-**何を決定したか** を明確に記述。
-
-### 変更箇所
-
-具体的な実装変更がある場合は記載。
-
-### 代替案
-
-検討した代替案とその却下理由。
-
-## 影響
-
-### ポジティブ
-
-- 良い影響
-
-### ネガティブ
-
-- 悪い影響や注意点
-
-## コンプライアンス
-
-決定が正しく実装されていることを確認する方法。
-
-## 備考
-
-- 著者: 担当者名
-- 関連コミット: コミットハッシュ
-- 関連 ADR: ADR-XXX
-```
-
-## ステータスの種類
-
-| ステータス | 説明 |
-|-----------|------|
-| 提案中 | レビュー待ちの ADR |
-| 承認済み | 採用された決定 |
-| 廃止 | 無効になった決定 |
-| 置換 | 別の ADR で置き換えられた |
-
-## 作成の進め方
-
-### 新規 ADR の作成
-
-1. `docs/adr/` ディレクトリ内の既存 ADR の最大番号を確認する
-2. 次の連番でテンプレートに基づいて ADR を作成する
-3. `docs/index.md` と `mkdocs.yml` を更新する
-
-### 既存設計からの ADR 抽出
-
-1. アーキテクチャ設計ドキュメントを読み込む
-2. 主要な技術的意思決定を識別する
-3. 各決定を ADR として記録する
-
-## 途中から再開・更新
-
-既存の ADR がある場合は `docs/adr/` の内容を確認する。ステータス変更や新規 ADR の追記のみを行う。
-
-**Example:**
-
-```
-ユーザー: 「フレームワークを変更する決定を記録したい」
-回答: docs/adr/ の最大番号を確認し、次の連番で ADR を作成する。
-      既存の関連 ADR があればステータスを「置換」に変更し、
-      新しい ADR の「コンテキスト」に経緯を記載する。
-```
-
-## 注意事項
-
-- 採番は `001` から連番。ファイル名は `NNN-kebab-case-title.md` 形式（例: `006-cache-strategy.md`）
-- 配置場所は必ず `docs/adr/`。新規作成時は `docs/index.md` と `mkdocs.yml` も更新する
-- ユーザーの指示があるまでコミットしない
-- コンテキストの明確化・代替案の記録・影響の両面記載・コンプライアンス項目を必ず含める
-
-## 関連スキル
-
-- `analyzing-architecture` — アーキテクチャ設計（ADR の主な発生源）
-- `analyzing-tech-stack` — 技術スタック選定（ADR として記録すべき決定）
-- `git-commit` — ADR 作成後のコミット
+---
+name: creating-adr
+description: Architecture Decision Record（ADR）の作成・管理を支援。技術的意思決定の背景・決定・影響をテンプレートに沿って記録する。「ADR を作成したい」「アーキテクチャの決定を記録したい」「技術選定の理由を残したい」「設計判断を文書化したい」といった場面で発動する。意思決定の経緯を記録することで、将来「なぜこの技術を選んだのか」が追跡可能になり、同じ議論の繰り返しを防ぐ。
+---
+
+# ADR 作成
+
+アーキテクチャ決定記録（ADR）を作成・管理する。技術的意思決定のコンテキスト・決定内容・影響を構造化して記録する。
+
+ADR の価値は「決定そのもの」ではなく「なぜその決定に至ったか」を残すこと。代替案と却下理由を含めることで、将来の見直し時に同じ検討を繰り返さずに済む。
+
+## ADR テンプレート
+
+```markdown
+# ADR-NNN: タイトル
+
+簡潔な説明（1 行で決定内容を要約）。
+
+日付: YYYY-MM-DD
+
+## ステータス
+
+提案中 | 承認済み | 廃止 | 置換（ADR-XXX で置換）
+
+## コンテキスト
+
+この決定が必要になった背景・状況を説明。
+
+- 現在の課題や制約
+- 関連するシステムやサービス
+- ビジネス要件
+
+## 決定
+
+**何を決定したか** を明確に記述。
+
+### 変更箇所
+
+具体的な実装変更がある場合は記載。
+
+### 代替案
+
+検討した代替案とその却下理由。
+
+## 影響
+
+### ポジティブ
+
+- 良い影響
+
+### ネガティブ
+
+- 悪い影響や注意点
+
+## コンプライアンス
+
+決定が正しく実装されていることを確認する方法。
+
+## 備考
+
+- 著者: 担当者名
+- 関連コミット: コミットハッシュ
+- 関連 ADR: ADR-XXX
+```
+
+## ステータスの種類
+
+| ステータス | 説明 |
+|-----------|------|
+| 提案中 | レビュー待ちの ADR |
+| 承認済み | 採用された決定 |
+| 廃止 | 無効になった決定 |
+| 置換 | 別の ADR で置き換えられた |
+
+## 作成の進め方
+
+### 新規 ADR の作成
+
+1. `docs/adr/` ディレクトリ内の既存 ADR の最大番号を確認する
+2. 次の連番でテンプレートに基づいて ADR を作成する
+3. `docs/index.md` と `mkdocs.yml` を更新する
+
+### 既存設計からの ADR 抽出
+
+1. アーキテクチャ設計ドキュメントを読み込む
+2. 主要な技術的意思決定を識別する
+3. 各決定を ADR として記録する
+
+## 途中から再開・更新
+
+既存の ADR がある場合は `docs/adr/` の内容を確認する。ステータス変更や新規 ADR の追記のみを行う。
+
+**Example:**
+
+```
+ユーザー: 「フレームワークを変更する決定を記録したい」
+回答: docs/adr/ の最大番号を確認し、次の連番で ADR を作成する。
+      既存の関連 ADR があればステータスを「置換」に変更し、
+      新しい ADR の「コンテキスト」に経緯を記載する。
+```
+
+## 注意事項
+
+- 採番は `001` から連番。ファイル名は `NNN-kebab-case-title.md` 形式（例: `006-cache-strategy.md`）
+- 配置場所は必ず `docs/adr/`。新規作成時は `docs/index.md` と `mkdocs.yml` も更新する
+- ユーザーの指示があるまでコミットしない
+- コンテキストの明確化・代替案の記録・影響の両面記載・コンプライアンス項目を必ず含める
+
+## 関連スキル
+
+- `analyzing-architecture` — アーキテクチャ設計（ADR の主な発生源）
+- `analyzing-tech-stack` — 技術スタック選定（ADR として記録すべき決定）
+- `git-commit` — ADR 作成後のコミット

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