@k2works/claude-code-booster 4.13.0 → 4.15.0

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

@@ -0,0 +1,156 @@
+---
+name: creating-article
+description: 動くサンプルコードを伴う技術記事・連載シリーズ・チュートリアルの執筆を支援する。「技術記事を書きたい」「連載記事を追加したい」「チュートリアルを執筆して」「解説記事をサンプルコードごと用意して」「既存の記事シリーズに新しい言語／フレームワークを追加して」「〈対象〉版を一式そろえて」「記事の章を増補したい」「記事の執筆計画を立てたい」といった場面で必ず発動する。計画（アウトライン）・骨子（目次とサイト構成）・サンプル実装の実行環境・章ごとの執筆と実装の同期・横断解説への反映・サンプルコードを検証する CI までを一貫して扱う。エンドユーザー向け操作手順書は `creating-manual`、設計判断の記録は `creating-adr`、開発ジャーナルは `creating-journal`、スライドは `creating-slides` を使う。特定の言語・フレームワーク・サイトジェネレーター・CI サービスに依存しない汎用スキルであり、記事ディレクトリ・サンプル実装の配置・環境定義・サイト設定・CI 定義は対象プロジェクトの実構成に合わせて解決する。
+---
+
+# 技術記事の執筆
+
+動くサンプルコードを伴う技術記事を執筆・更新する。読者は「読んで理解する人」ではなく **「同じ手順を自分の手元で再現しようとする人」** である。
+
+だからこのスキルの中心は文章術ではなく **記事とコードの同期** にある。記事に載せるコードは必ず実際に動作確認済みの実装から転記する。憶測で書いたコードは読者の手元で必ず動かず、記事全体の信頼を失わせる。
+
+本スキルは特定の言語・フレームワーク・サイトジェネレーター・CI サービスに依存しない。記事の配置・サンプル実装の配置・環境定義の方式・サイトのナビゲーション設定は、対象プロジェクトの実構成を確認して当てはめる（憶測で書かない）。
+
+## 適用範囲
+
+| 対象 | 使い方 |
+| :--- | :--- |
+| 単発の技術記事 | ステップ 1・4・（必要なら 3）だけを使う |
+| 連載シリーズの新規立ち上げ | ステップ 1〜6 を通しで使う |
+| 既存シリーズへの新しい対象の追加 | ステップ 1〜6 を通しで使う（主な用途） |
+| 既存記事の章の増補・更新 | ステップ 4 と、影響する索引の更新 |
+
+「新しい対象の追加」とは、同じ章構成を別の切り口で書き起こす作業を指す（言語別・フレームワーク別・プラットフォーム別など、シリーズの軸に応じる）。
+
+## 全体フロー
+
+```mermaid
+graph TD
+    A[1. 計画: アウトラインと執筆計画] --> B[2. 骨子: 索引・目次・サイト構成]
+    B --> C[3. 環境準備: サンプル実装が動く最小構成]
+    C --> D[4. 章ごとの執筆と実装の同期]
+    D --> E[5. 横断・比較コンテンツへの反映]
+    E --> F[6. CI: サンプルコードの継続的検証]
+```
+
+区切りごとに、記事（`docs:`）と実装・環境・CI（`feat:` / `chore:` / `ci:`）を分けてコミットする（`git-commit` 準拠、1 コミット 1 目的）。記事と実装を 1 コミットに混ぜると、コードだけを追う読者もレビュアーも差分を追えなくなる。
+
+## 0. 既存構成の把握（着手前に必ず行う）
+
+新規に書き始める前に、対象プロジェクトの実構成を特定する。**既存記事を最低 1 本、できれば性質の近いものを通読する。** 型は説明されるより実物を見るほうが早く揃う。
+
+| 特定する項目 | 例 |
+| :--- | :--- |
+| 記事ルート | `docs/article/` `docs/blog/` `content/posts/` |
+| 計画・目次の一次情報 | `outline.md` `index.md` `workflow.md` |
+| サンプル実装の配置 | `apps/{target}/` `examples/{target}/` |
+| 実行環境の定義方式 | Nix devShell / Docker / 言語標準のバージョン管理 |
+| サイトのナビゲーション | `mkdocs.yml` の nav / `_sidebar.md` / フロントマター |
+| CI 定義 | `.github/workflows/*.yml` など |
+| 執筆フォーマットの規約 | 記事ルートの `index.md` / `workflow.md` |
+
+既存の規約ドキュメント（`workflow.md` 等）がある場合は **それが一次情報**。本スキルの記述と食い違うときは規約側を正とし、必要なら規約側を更新してから執筆する。
+
+## 1. 計画 — アウトラインと執筆計画
+
+シリーズの計画ドキュメント（例: `outline.md`）に、対象と執筆計画を追加する。
+
+- 対象一覧の表に行を追加する（対象名・環境・章数・備考）。**冒頭の件数表記など、対象数に依存する記述も併せて更新する**（更新漏れが最も起きやすい箇所）。
+- シリーズの軸ごとに扱いが変わる部分（対応範囲、省略する章、代替の題材）があれば、その方針を明記する。対象の性質上そのまま書けない章は、**書かないと決めた理由ごと** 残す。
+- ファイル構成の図に、記事ディレクトリとサンプル実装ディレクトリを追加する。
+- 対象専用の執筆計画の節を設ける。**前提整備**（実行環境・実装雛形・テスト基盤・記事ディレクトリ）と、**章別計画**（各章 1 行で、その対象固有の焦点）を表で示す。
+
+## 2. 骨子への反映
+
+計画に沿って索引を一括で更新する。ここを飛ばすと、記事を書いても読者が辿り着けない。
+
+- **シリーズの索引**: 対象別の一覧と、全章構成の表に行・列を追加。ファイル名は既存対象の命名を踏襲する。
+- **進捗管理表**（あれば）: 着手状態と、実行環境の一覧に追記。
+- **サイトのナビゲーション**: 対象のセクション見出しを追加する。章は書けたぶんだけ随時追加していく。
+- **対象の記事トップ**（`{記事ルート}/{target}/index.md` 等）: 開発環境・章の目次・サンプルコードへのリンク。既存対象の同ファイルを雛形にする。
+
+命名・章構成・体裁は、必ず既存対象の実ファイルを開いて合わせる。
+
+## 3. 環境準備 — サンプル実装が動く最小構成
+
+記事を書き始める前に、TDD サイクルが回る最小構成を用意する。**「最小の 1 テストが通る」ところまで確認してからコミットする。** 環境が整う前に書き始めた記事は、後で必ずコードと食い違う。
+
+- **実行環境の定義**: プロジェクトの方式（Nix devShell / Docker / 言語標準のツール）に合わせ、既存対象の定義を雛形にする。共通のベース環境がある場合はそれを継承し、対象固有のツールチェーンだけを足す。
+- **環境の登録**: 環境一覧（flake の `devShells`、Compose のサービス定義など）に追加し、**一覧コマンドでエラーなく認識されることを確認する**。
+- **実装雛形**: 対象の標準的な初期化コマンドでプロジェクトを作り、パッケージ定義・`src/`・テストディレクトリ・`.gitignore`・タスク定義（`build` / `test` / `check` / `format` 等）を既存対象に倣って整える。
+- **除外設定**: 復元可能なビルド成果物・大きなバイナリ・秘匿情報は `.gitignore` に入れる。
+
+ツールが標準のパッケージ配布に無い場合は、ランタイムだけを提供して初期化時に成果物を取得し、ラッパーを定義する方式でよい。その回避策は記事の環境構築の章にも書く（読者も同じ壁に当たる）。
+
+## 4. 章ごとの執筆と実装の同期
+
+**章単位で「実装 → 執筆」の順に進める。** 逆順にすると、記事に書いたコードを後から実装が裏切る。区切りの良い単位（部・数章）でまとめると進捗が見える。
+
+各章のサイクル:
+
+1. **参照章を読む** — 性質の近い既存対象の同じ章を開き、テーマ・追加仕様・段階の流れを把握する。
+2. **サンプル実装（先に手を動かす）** — Red → Green → Refactor を回す（`developing-backend` 参照）。その章で追加する仕様も実装する。
+3. **記事執筆** — 参照章と同じ節構成・粒度に合わせつつ、その対象固有の観点（型システム・構文・パラダイム・エコシステム上の強み）を各所で解説する。**コード例は実装と一字一句一致させる。**
+4. **サイト反映** — ナビゲーションにその章を追加する。
+5. **コミット** — 実装（`feat({target}): ...`）と記事（`docs({target}): ...`）を分ける。進捗管理表も更新する。
+
+### 執筆フォーマット
+
+規約ドキュメントがあればそれに従う。無い場合の既定:
+
+- 見出しは階層を飛ばさない。章内の節構成は既存章と揃える
+- コードブロックには言語を明示する。差分を示すときは変更箇所が分かる粒度で切る
+- 長い完成コードは折りたたみ（`<details>`）に入れ、本文には差分だけを載せる
+- 日本語と半角英数字の間に半角スペース。文体はですます調。技術用語は英語のまま
+- 読者が実行するコマンドは、コピーしてそのまま動く形で書く（プロンプト記号を混ぜない）
+
+## 5. 横断・比較コンテンツへの反映
+
+シリーズに横断解説（対象間の比較・まとめ）がある場合、新しい対象を全ファイルに反映する。作業量が多いので、`Explore` で対象箇所を洗い出してから一括反映するとよい。
+
+- 索引の対象一覧と、冒頭の列挙・件数表記
+- 分類表（パラダイム・型システム・ランタイム等、シリーズの軸に応じた分類）
+- 各比較章の表・コード例・概念マップ
+- その対象固有の強みを、対応する比較節に 1 項目として立てる
+
+反映後は **各表の行・列の整合** と、**旧件数表記の残存が無いこと** を確認する。実在しない事実は書かない。
+
+## 6. CI — サンプルコードの継続的検証
+
+記事のコードは放置すると壊れる。サンプル実装を CI で検証する。既存対象の CI 定義を雛形にする。
+
+- トリガーの `paths` を、その対象のサンプル実装・当ワークフロー・環境定義に絞る（無関係な変更で全対象が回らないように）
+- 環境定義と同じ方式でツールチェーンを用意し、キャッシュを効かせる
+- 各ステップは環境定義経由で実行し、ローカルと同じコマンドを使う（ローカルと CI でコマンドが違うと、どちらかが必ず腐る）
+- 既存 CI と構造・ステップ数を突き合わせてからコミットする（`ci({target}): ...`）
+
+## 完了確認チェックリスト
+
+- [ ] 計画ドキュメントに対象と執筆計画がある（前提整備の状態も更新済み）
+- [ ] シリーズ索引の全章構成表・対象別一覧に反映
+- [ ] 進捗管理表・環境一覧に反映
+- [ ] 記事ディレクトリに index と計画したすべての章
+- [ ] サンプル実装の全テストが通り、記事のコード例と一致
+- [ ] サイトのナビゲーションに全章
+- [ ] 実行環境が定義・登録され、一覧コマンドで認識される
+- [ ] 横断・比較コンテンツに反映（表の整合・件数表記を確認）
+- [ ] CI が追加され、グリーン
+- [ ] 記事と実装・環境・CI を分けてコミット済み
+
+## 注意事項
+
+- 記事に載せるコードは、必ず動作確認済みの実装から転記する。憶測のコードを書かない
+- 執筆前に既存記事を 1 本通読する。型は実物を見るほうが早く揃う
+- 件数・対象数に依存する記述（冒頭の言語数、章数、比較表の列）は追加のたびに全箇所を更新する
+- 個人情報・トークン・社内 URL を記事にもサンプルコードにも残さない
+- 章を追加・削除したら、索引・進捗表・サイトナビゲーションを必ず揃える
+- 完了後に `operating-docs` の Markdown Lint を通す
+
+## 関連スキル
+
+- `orchestrating-development` — 章単位の執筆・実装の同期
+- `developing-backend` — サンプル実装の TDD サイクル
+- `operating-docs` — ドキュメント管理・Markdown Lint
+- `creating-manual` — エンドユーザー向け操作手順書（読者と目的が異なる）
+- `creating-adr` — 設計判断の記録
+- `git-commit` — Conventional Commits 準拠のコミット

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

@@ -1,127 +1,127 @@
----
-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` — 作成後のコミット
+---
+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` — 作成後のコミット