@k2works/claude-code-booster 4.11.0 → 4.13.0

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

@@ -0,0 +1,146 @@
+---
+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）・SonarQube 品質ゲート（2.6）が含まれる。ローカル緑だけでは不十分で、CI が緑かつ SonarQube の Quality Gate が PASS であって初めて品質ゲートを通過とみなす。
+
+### ステップ 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`）
+- カバレッジを計測し目標との差分を把握する（静的解析の合否判定はステップ 2.6 の SonarQube 品質ゲートで確定する）
+- ゲートを通らない場合はクローズを止め、修正してから再度ここに戻る
+- **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 が緑に戻ることを確認してからクローズを確定する
+
+### ステップ 2.6: SonarQube 品質ゲート（`operating-qt`）
+
+テスト・Lint が緑でも、静的解析の品質基準（Bug・Vulnerability・Code Smell・重複・カバレッジ）を満たしていなければクローズしない。`operating-qt` で SonarQube スキャンを実行し、**Quality Gate が PASS であること**を確定させる。
+
+- **前提**: ローカル SonarQube が起動済み（`npx gulp sonar-local:status`）で `.env` に有効な `SONAR_TOKEN` が設定されていること。未起動なら `npx gulp sonar-local:setup`
+- **カバレッジ連携**: スキャン前に対象言語のカバレッジレポートを生成する（例: Go は `go test -coverprofile=coverage.out -covermode=atomic ./...`、`sonar-project.properties` の `sonar.*.coverage.reportPaths` で連携）
+- **実行**: `npx gulp sonar-local:scan` → `npx gulp sonar-local:gate`（または一連の `npx gulp sonar-local:check`）
+- **合格基準**（[テスト戦略](../../../docs/design/test_strategy.md) の Quality Gate に準拠）:
+  - Quality Gate: **PASS**
+  - Bug: **0** / Vulnerability: **0**
+  - 重複率: **3% 未満**
+  - Code Smell: 可能な限り **0**（残す場合は方針を明記）
+  - カバレッジ: 新規コード 80% 以上（ドメイン層は 90% を目標）
+- **不合格なら**: `npx gulp sonar-local:issues` で指摘を特定し、修正してステップ 2 に戻る。ゲートが PASS になるまでクローズを止める
+
+### ステップ 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 と同じツールチェーンで確認）・カバレッジ把握
+- [ ] **CI が緑**（`gh run list` で対象ブランチの最新実行が success・赤なら修正して再確認）
+- [ ] **SonarQube Quality Gate が PASS**（Bug 0・Vulnerability 0・重複 3% 未満・Code Smell 方針明記・カバレッジ目標達成）
+- [ ] `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 より古いと、新しい lint がローカルをすり抜けて CI だけ赤になる。クローズ確定前に `gh run` で CI の実結果を必ず確認し、赤なら緑に戻す
+- **品質ゲートは「テスト緑」で終わりにしない**（ステップ 2.6）。テストと Lint が緑でも SonarQube の Quality Gate（Bug・脆弱性・重複・カバレッジ・Code Smell）が赤ならクローズしない。スキャン→ゲート PASS までを品質ゲートの完了条件とする
+- **正直さを優先する**: 未達・スコープ調整・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-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

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