@k2works/claude-code-booster 6.3.1 → 6.4.0

package/lib/assets/.claude/skills/killing-processes/SKILL.md

@@ -1,44 +1,44 @@
----
-name: killing-processes
-description: 開発サーバーや Node.js プロセスを強制終了。ポート競合の解消やプロセスリセットに対応する。「プロセスを止めたい」「ポートが使われている」「開発サーバーを再起動したい」「Port already in use を解決したい」といった場面で発動する。
----
-
-# プロセス強制終了
-
-開発サーバーや Node.js プロセスを強制終了する。複数ポートで起動している開発プロセスを一括停止できる。
-
-## オプション
-
-| オプション | 説明 |
-|-----------|------|
-| なし | すべての Node.js 開発プロセスを強制終了 |
-| `--port <ポート番号>` | 特定のポートのプロセスのみ終了 |
-| `--check` | プロセス状況の確認のみ（終了せず） |
-
-## 実行コマンド
-
-```bash
-# ポート範囲でのプロセス検索・終了
-netstat -ano | findstr ":300[0-9]" | findstr LISTENING
-taskkill //F //PID <PID>
-```
-
-## 出力例
-
-```
-現在起動中の開発プロセス:
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-ポート 3000: PID 34348 (Node.js)
-ポート 3001: PID 16676 (Node.js)
-
-プロセス終了中...
-PID 34348 を終了しました
-PID 16676 を終了しました
-すべての開発プロセスを停止しました。
-```
-
-## 注意事項
-
-- Windows 環境（taskkill コマンド使用）が前提。管理者権限が必要な場合がある
-- 重要な作業中は事前にファイルを保存する
-- まず `--check` で状況確認してから終了する。必要に応じて `--port` で特定ポートのみ終了する
+---
+name: killing-processes
+description: 開発サーバーや Node.js プロセスを強制終了。ポート競合の解消やプロセスリセットに対応する。「プロセスを止めたい」「ポートが使われている」「開発サーバーを再起動したい」「Port already in use を解決したい」といった場面で発動する。
+---
+
+# プロセス強制終了
+
+開発サーバーや Node.js プロセスを強制終了する。複数ポートで起動している開発プロセスを一括停止できる。
+
+## オプション
+
+| オプション | 説明 |
+|-----------|------|
+| なし | すべての Node.js 開発プロセスを強制終了 |
+| `--port <ポート番号>` | 特定のポートのプロセスのみ終了 |
+| `--check` | プロセス状況の確認のみ（終了せず） |
+
+## 実行コマンド
+
+```bash
+# ポート範囲でのプロセス検索・終了
+netstat -ano | findstr ":300[0-9]" | findstr LISTENING
+taskkill //F //PID <PID>
+```
+
+## 出力例
+
+```
+現在起動中の開発プロセス:
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+ポート 3000: PID 34348 (Node.js)
+ポート 3001: PID 16676 (Node.js)
+
+プロセス終了中...
+PID 34348 を終了しました
+PID 16676 を終了しました
+すべての開発プロセスを停止しました。
+```
+
+## 注意事項
+
+- Windows 環境（taskkill コマンド使用）が前提。管理者権限が必要な場合がある
+- 重要な作業中は事前にファイルを保存する
+- まず `--check` で状況確認してから終了する。必要に応じて `--port` で特定ポートのみ終了する

package/lib/assets/.claude/skills/migrating-ai-dlc/evals/evals.json

@@ -1,60 +1,60 @@
-{
-  "skill_name": "migrating-ai-dlc",
-  "evals": [
-    {
-      "id": 1,
-      "prompt": "booster を更新したら docs/reference に AI-DLC 版のガイドが入ってた。うちの受注管理プロジェクト（docs/requirements/order/ にストーリー 12 本、docs/development/order/ に release_plan.md と進行中の iteration_plan-3.md、apps/order/ に Spring Boot のコードあり）を AI-DLC に移行したい。まず何をどう変えるか計画を出して。",
-      "expected_output": "--plan として、まず aidlc_check.py で移行前の状態（ERROR/WARN の件数）を測り、現状を棚卸しする。docs/development/order/aidlc_migration_plan.md に、検査結果・現状・チェックボックス付きの 10 ステップ（CLAUDE.md、リスク台帳、用語集、静的・動的モデル、受入条件、Unit 分解、release_plan 追記、iteration_plan-3 → bolt_plan-3、ガードレール、OKF 適用）・AI の仮定・要確認を書く。Unit 案・依存 DAG・ストーリーマップ・リスク台帳の表・静的モデル・Bolt 計画案などの後続ステップの成果物は計画に書かず、候補は要確認に 1 行で残す。既存のストーリーと計画は変更しない",
-      "files": [],
-      "assertions": [
-        "移行計画がチェックボックス付き Markdown で作られている",
-        "移行計画が既定のパス docs/development/order/aidlc_migration_plan.md にある",
-        "計画に Unit 分解と iteration_plan → bolt_plan の読み替えが含まれる",
-        "ブラウンフィールドとして既存コードの静的・動的モデル昇格が含まれる",
-        "リスク台帳と AI に渡せる範囲（In/Out）の作成が含まれる",
-        "Unit 境界などの判断を要確認として人に戻している",
-        "--plan では既存のストーリー・計画ファイルを変更していない",
-        "CLAUDE.md への AI-DLC 採用の明記が含まれる",
-        "移行前の状態を aidlc_check.py で測り、ERROR/WARN の件数を計画に記録している",
-        "後続ステップの成果物（Unit 案・依存 DAG・ストーリーマップ・リスク台帳・静的／動的モデル・Bolt 計画案など）を計画の節として先取りしていない"
-      ]
-    },
-    {
-      "id": 2,
-      "prompt": "移行計画は承認した。ステップ 6 の Unit 分解をやって。docs/requirements/order/ のストーリーを Unit にまとめて、依存関係とストーリーマップも作って。決済まわりは外部サービスだから本番キーは絶対 AI に渡さない前提で。",
-      "expected_output": "docs/requirements/order/units.md に、各 Unit の目的・含まれるストーリー・NFR・リスク（リスク台帳の ID で参照、未作成なら暫定 ID）・測定基準・推奨 Bolt・エントロピー評価・AI の仮定、依存 DAG、ユースケース × Unit × ストーリーの対応表、未配置ストーリーを書く。決済は独立 Unit にし、本番キーを渡さない前提をリスク ID で対応づける。ガードレールの本文は units.md に書き写さない。Unit の境界は案として示し承認を求める。apply-okf（git 管理外なら手書き）でフロントマターと index/log を更新し、aidlc_check.py で units.md の項目を検証して報告する",
-      "files": [],
-      "assertions": [
-        "docs/requirements/order/units.md が作られている",
-        "各 Unit に目的・ストーリー・NFR・リスク・測定基準・推奨 Bolt がある",
-        "依存 DAG とストーリーマップがある",
-        "決済が独立 Unit で、本番キーを AI に渡さない前提と対応づいている",
-        "12 ストーリーすべてが配置または未配置として言及されている",
-        "units.md に OKF フロントマターがある",
-        "docs/log.md に記録がある",
-        "Unit 境界を案として示し承認を求めている",
-        "すべての Unit に「AI の仮定」がある",
-        "Unit のリスクをリスク台帳（risk_register.md）の ID で参照している",
-        "aidlc_check.py で units.md を検証し、結果を報告している"
-      ]
-    },
-    {
-      "id": 3,
-      "prompt": "AI-DLC への移行は一通り終わったつもりなんだけど、ちゃんと揃ってるか確認して。プロジェクトは order。",
-      "expected_output": "--check として aidlc_check.py --project order を実行し、ERROR/WARN の件数と各項目を報告する（受入条件はストーリー単位、フロントエンドの無いプロジェクトでは developing-frontend を対象外、verified・index 登録・未配置ストーリーの計画混入も含む）。続けてスクリプトが見ない点（成果物同士の矛盾、リスク台帳・用語集の中身、コードと受入条件の整合）を読んで確かめ、不足ごとに移行ステップ番号と直し方を示す。ファイルは変更しない",
-      "files": [],
-      "assertions": [
-        "U-03 決済連携の推奨 Bolt 欠けを指摘している",
-        "release_plan.md のテスト戦略欠けを指摘している",
-        "bolt_plan-3.md のゲート密度欠けを指摘している",
-        "受入条件の不足をストーリー単位（12 本中 3 本）で数えている",
-        "受入条件の Given/When/Then 不足を指摘している",
-        "存在する成果物（units/risk_register/glossary）を誤って欠けとしていない",
-        "不足を移行ステップに対応づけている",
-        "aidlc_check.py を実行し、ERROR/WARN の件数を報告している",
-        "AI 生成の移行成果物に人の承認記録（verified）が無いことを指摘している",
-        "未配置の US-11・US-12 がリリース計画に割り当てられている矛盾を指摘している"
-      ]
-    }
-  ]
+{
+  "skill_name": "migrating-ai-dlc",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "booster を更新したら docs/reference に AI-DLC 版のガイドが入ってた。うちの受注管理プロジェクト（docs/requirements/order/ にストーリー 12 本、docs/development/order/ に release_plan.md と進行中の iteration_plan-3.md、apps/order/ に Spring Boot のコードあり）を AI-DLC に移行したい。まず何をどう変えるか計画を出して。",
+      "expected_output": "--plan として、まず aidlc_check.py で移行前の状態（ERROR/WARN の件数）を測り、現状を棚卸しする。docs/development/order/aidlc_migration_plan.md に、検査結果・現状・チェックボックス付きの 10 ステップ（CLAUDE.md、リスク台帳、用語集、静的・動的モデル、受入条件、Unit 分解、release_plan 追記、iteration_plan-3 → bolt_plan-3、ガードレール、OKF 適用）・AI の仮定・要確認を書く。Unit 案・依存 DAG・ストーリーマップ・リスク台帳の表・静的モデル・Bolt 計画案などの後続ステップの成果物は計画に書かず、候補は要確認に 1 行で残す。既存のストーリーと計画は変更しない",
+      "files": [],
+      "assertions": [
+        "移行計画がチェックボックス付き Markdown で作られている",
+        "移行計画が既定のパス docs/development/order/aidlc_migration_plan.md にある",
+        "計画に Unit 分解と iteration_plan → bolt_plan の読み替えが含まれる",
+        "ブラウンフィールドとして既存コードの静的・動的モデル昇格が含まれる",
+        "リスク台帳と AI に渡せる範囲（In/Out）の作成が含まれる",
+        "Unit 境界などの判断を要確認として人に戻している",
+        "--plan では既存のストーリー・計画ファイルを変更していない",
+        "CLAUDE.md への AI-DLC 採用の明記が含まれる",
+        "移行前の状態を aidlc_check.py で測り、ERROR/WARN の件数を計画に記録している",
+        "後続ステップの成果物（Unit 案・依存 DAG・ストーリーマップ・リスク台帳・静的／動的モデル・Bolt 計画案など）を計画の節として先取りしていない"
+      ]
+    },
+    {
+      "id": 2,
+      "prompt": "移行計画は承認した。ステップ 6 の Unit 分解をやって。docs/requirements/order/ のストーリーを Unit にまとめて、依存関係とストーリーマップも作って。決済まわりは外部サービスだから本番キーは絶対 AI に渡さない前提で。",
+      "expected_output": "docs/requirements/order/units.md に、各 Unit の目的・含まれるストーリー・NFR・リスク（リスク台帳の ID で参照、未作成なら暫定 ID）・測定基準・推奨 Bolt・エントロピー評価・AI の仮定、依存 DAG、ユースケース × Unit × ストーリーの対応表、未配置ストーリーを書く。決済は独立 Unit にし、本番キーを渡さない前提をリスク ID で対応づける。ガードレールの本文は units.md に書き写さない。Unit の境界は案として示し承認を求める。apply-okf（git 管理外なら手書き）でフロントマターと index/log を更新し、aidlc_check.py で units.md の項目を検証して報告する",
+      "files": [],
+      "assertions": [
+        "docs/requirements/order/units.md が作られている",
+        "各 Unit に目的・ストーリー・NFR・リスク・測定基準・推奨 Bolt がある",
+        "依存 DAG とストーリーマップがある",
+        "決済が独立 Unit で、本番キーを AI に渡さない前提と対応づいている",
+        "12 ストーリーすべてが配置または未配置として言及されている",
+        "units.md に OKF フロントマターがある",
+        "docs/log.md に記録がある",
+        "Unit 境界を案として示し承認を求めている",
+        "すべての Unit に「AI の仮定」がある",
+        "Unit のリスクをリスク台帳（risk_register.md）の ID で参照している",
+        "aidlc_check.py で units.md を検証し、結果を報告している"
+      ]
+    },
+    {
+      "id": 3,
+      "prompt": "AI-DLC への移行は一通り終わったつもりなんだけど、ちゃんと揃ってるか確認して。プロジェクトは order。",
+      "expected_output": "--check として aidlc_check.py --project order を実行し、ERROR/WARN の件数と各項目を報告する（受入条件はストーリー単位、フロントエンドの無いプロジェクトでは developing-frontend を対象外、verified・index 登録・未配置ストーリーの計画混入も含む）。続けてスクリプトが見ない点（成果物同士の矛盾、リスク台帳・用語集の中身、コードと受入条件の整合）を読んで確かめ、不足ごとに移行ステップ番号と直し方を示す。ファイルは変更しない",
+      "files": [],
+      "assertions": [
+        "U-03 決済連携の推奨 Bolt 欠けを指摘している",
+        "release_plan.md のテスト戦略欠けを指摘している",
+        "bolt_plan-3.md のゲート密度欠けを指摘している",
+        "受入条件の不足をストーリー単位（12 本中 3 本）で数えている",
+        "受入条件の Given/When/Then 不足を指摘している",
+        "存在する成果物（units/risk_register/glossary）を誤って欠けとしていない",
+        "不足を移行ステップに対応づけている",
+        "aidlc_check.py を実行し、ERROR/WARN の件数を報告している",
+        "AI 生成の移行成果物に人の承認記録（verified）が無いことを指摘している",
+        "未配置の US-11・US-12 がリリース計画に割り当てられている矛盾を指摘している"
+      ]
+    }
+  ]
 }

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

@@ -1,124 +1,124 @@
----
-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 を「返済枠」や成功基準として明示的に組み込む
-- **画面を伴う IT は、ユーザーマニュアル更新（`creating-manual`）をタスクと DoD に含める**。対象章・節と画面キャプチャの撮り直しまでを見積もりに入れる。クローズ時（`closing-iteration` ステップ 6.5）に初めて思い出すと、計画外の作業がイテレーション末に積み上がる。画面を伴わない IT ではその旨を明記して省く
-
-### ステップ 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`: イテレーション計画をナビゲーションに追加
-- 追加行のインデントが既存ナビと一致しているか確認する
-
-### ステップ 6.5: OKF 適用（`apply-okf`）
-
-`docs/` が OKF バンドル（ルート `index.md` に `okf_version`）なら、このフローで作成・更新した文書に規約を適用する。
-
-```bash
-python .claude/skills/apply-okf/scripts/okf_apply.py apply docs --changed --by <agent>
-gulp okf:check
-```
-
-- `iteration_plan-N.md` は新規なので `type: Plan`・`status: draft` で登録される。ステップ 3・4 の検証を通し、ユーザーが計画を承認したら `verify --by human:<id>` で `stable` に昇格させる（検証済みの計画だけが開発の根拠になる）
-- ステップ 1 で更新した前イテレーションの文書は本文が変わっているので `generated` が更新される
-- `gulp okf:check` が ERROR 0 であることを確認してからコミットする
-
-## 開始準備完了チェックリスト
-
-すべて満たしたらイテレーションは開発着手可能な状態とみなす。
-
-- [ ] 前イテレーションふりかえりの Try・引き継ぎを計画に反映
-- [ ] `iteration_plan-N.md` 作成（ゴール・ストーリー・タスク・設計 4 図・DoD）
-- [ ] 画面を伴う IT なら、マニュアル更新タスクを計画・DoD に計上（伴わないなら明記して省略）
-- [ ] `validating-iteration-plan` 実施・不整合を修正
-- [ ] `validating-design` 実施・3 軸の不整合を修正（BC 独立性・設計反映漏れ含む）
-- [ ] GitHub Issue 確認・Project イテレーション割当
-- [ ] `docs/development/index.md` / `release_plan.md` / `mkdocs.yml` 同期
-- [ ] OKF バンドルなら `apply-okf` 適用・計画承認後に `verify`・`gulp okf:check` ERROR 0
-- [ ] 各ステップの成果を意味のある単位でコミット（`git-commit`）
-
-これらが揃ったら、`orchestrating-development` で開発フェーズ（TDD サイクル）に進む。
-
-## 注意事項
-
-- **順序を守る**: 計画を作る前にふりかえりを読む（学びの反映）。GitHub に反映する前に検証を通す（不整合を GitHub に持ち込まない）
-- **検証を省かない**: 開始準備は計画作成だけで満足しがちだが、`validating-iteration-plan` と `validating-design` こそが着手前の安全網。ここで潰す不整合（BC 独立性違反・設計反映漏れ）は、実装後に直すと数倍のコストになる
-- **マニュアルは計画時に見積もる**: 画面を伴う IT でマニュアル更新をタスクに入れ忘れると、クローズ時に計画外の作業として現れ、締めが遅れるか更新自体が飛ばされる。計画段階で枠を取っておくことが実装とマニュアルの乖離を防ぐ
-- **設計が正**: 検証で見つかった不整合は原則計画側を直す。設計ドキュメントの欠落は「注」で明記し当該 IT で反映する（実装と設計の同時反映が、先行乖離を防ぐ）
-
-## 関連スキル
-
-- `closing-iteration` — イテレーションの締め（本スキルと対になるクローズ側）
-- `orchestrating-project` — 計画・進捗管理フェーズ全体のオーケストレーション（本スキルはその「イテレーション開始時」を詳細化したもの）
-- `planning-releases` — イテレーション計画の作成（ステップ 2）
-- `creating-manual` — ユーザーマニュアルの更新（ステップ 2 でタスク・DoD に計上する対象）
-- `validating-iteration-plan` — 計画と上流設計のフィールド単位の詳細突合（ステップ 3）
-- `validating-design` — 開発戦略・過去計画との横断整合検証（ステップ 4）
-- `syncing-github-project` — GitHub 同期（ステップ 5）
-- `operating-docs` — ドキュメントインデックス更新・Lint（ステップ 6）
-- `apply-okf` — 計画への OKF 規約適用と承認後の `verify`（ステップ 6.5）
-- `orchestrating-development` — 開始準備完了後の開発フェーズ
-- `git-commit` — 各ステップ成果のコミット
+---
+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 を「返済枠」や成功基準として明示的に組み込む
+- **画面を伴う IT は、ユーザーマニュアル更新（`creating-manual`）をタスクと DoD に含める**。対象章・節と画面キャプチャの撮り直しまでを見積もりに入れる。クローズ時（`closing-iteration` ステップ 6.5）に初めて思い出すと、計画外の作業がイテレーション末に積み上がる。画面を伴わない IT ではその旨を明記して省く
+
+### ステップ 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`: イテレーション計画をナビゲーションに追加
+- 追加行のインデントが既存ナビと一致しているか確認する
+
+### ステップ 6.5: OKF 適用（`apply-okf`）
+
+`docs/` が OKF バンドル（ルート `index.md` に `okf_version`）なら、このフローで作成・更新した文書に規約を適用する。
+
+```bash
+python .claude/skills/apply-okf/scripts/okf_apply.py apply docs --changed --by <agent>
+gulp okf:check
+```
+
+- `iteration_plan-N.md` は新規なので `type: Plan`・`status: draft` で登録される。ステップ 3・4 の検証を通し、ユーザーが計画を承認したら `verify --by human:<id>` で `stable` に昇格させる（検証済みの計画だけが開発の根拠になる）
+- ステップ 1 で更新した前イテレーションの文書は本文が変わっているので `generated` が更新される
+- `gulp okf:check` が ERROR 0 であることを確認してからコミットする
+
+## 開始準備完了チェックリスト
+
+すべて満たしたらイテレーションは開発着手可能な状態とみなす。
+
+- [ ] 前イテレーションふりかえりの Try・引き継ぎを計画に反映
+- [ ] `iteration_plan-N.md` 作成（ゴール・ストーリー・タスク・設計 4 図・DoD）
+- [ ] 画面を伴う IT なら、マニュアル更新タスクを計画・DoD に計上（伴わないなら明記して省略）
+- [ ] `validating-iteration-plan` 実施・不整合を修正
+- [ ] `validating-design` 実施・3 軸の不整合を修正（BC 独立性・設計反映漏れ含む）
+- [ ] GitHub Issue 確認・Project イテレーション割当
+- [ ] `docs/development/index.md` / `release_plan.md` / `mkdocs.yml` 同期
+- [ ] OKF バンドルなら `apply-okf` 適用・計画承認後に `verify`・`gulp okf:check` ERROR 0
+- [ ] 各ステップの成果を意味のある単位でコミット（`git-commit`）
+
+これらが揃ったら、`orchestrating-development` で開発フェーズ（TDD サイクル）に進む。
+
+## 注意事項
+
+- **順序を守る**: 計画を作る前にふりかえりを読む（学びの反映）。GitHub に反映する前に検証を通す（不整合を GitHub に持ち込まない）
+- **検証を省かない**: 開始準備は計画作成だけで満足しがちだが、`validating-iteration-plan` と `validating-design` こそが着手前の安全網。ここで潰す不整合（BC 独立性違反・設計反映漏れ）は、実装後に直すと数倍のコストになる
+- **マニュアルは計画時に見積もる**: 画面を伴う IT でマニュアル更新をタスクに入れ忘れると、クローズ時に計画外の作業として現れ、締めが遅れるか更新自体が飛ばされる。計画段階で枠を取っておくことが実装とマニュアルの乖離を防ぐ
+- **設計が正**: 検証で見つかった不整合は原則計画側を直す。設計ドキュメントの欠落は「注」で明記し当該 IT で反映する（実装と設計の同時反映が、先行乖離を防ぐ）
+
+## 関連スキル
+
+- `closing-iteration` — イテレーションの締め（本スキルと対になるクローズ側）
+- `orchestrating-project` — 計画・進捗管理フェーズ全体のオーケストレーション（本スキルはその「イテレーション開始時」を詳細化したもの）
+- `planning-releases` — イテレーション計画の作成（ステップ 2）
+- `creating-manual` — ユーザーマニュアルの更新（ステップ 2 でタスク・DoD に計上する対象）
+- `validating-iteration-plan` — 計画と上流設計のフィールド単位の詳細突合（ステップ 3）
+- `validating-design` — 開発戦略・過去計画との横断整合検証（ステップ 4）
+- `syncing-github-project` — GitHub 同期（ステップ 5）
+- `operating-docs` — ドキュメントインデックス更新・Lint（ステップ 6）
+- `apply-okf` — 計画への OKF 規約適用と承認後の `verify`（ステップ 6.5）
+- `orchestrating-development` — 開始準備完了後の開発フェーズ
+- `git-commit` — 各ステップ成果のコミット

package/lib/assets/.claude/skills/operating-backup/SKILL.md

@@ -1,59 +1,59 @@
----
-name: operating-backup
-description: データベースのバックアップ・リストアを実行。AWS Backup による自動バックアップ、SSH トンネル経由の手動バックアップ、スナップショットからのリストア。バックアップやリストア、データ復旧時に使用。
----
-
-# バックアップ・リストア
-
-データベースのバックアップ・リストアを実行します。
-
-## Instructions
-
-### 1. AWS Backup（自動バックアップ）
-
-`Backup = "true"` タグが付与された RDS インスタンスに対して日次・週次でスナップショットを自動取得する。
-
-| ルール | スケジュール | 保持期間 |
-|--------|-------------|---------|
-| daily | 毎日 JST 0:00 | 7 日 |
-| weekly | 毎週日曜 JST 0:00 | 35 日 |
-
-### 2. 手動バックアップ（SSH トンネル経由）
-
-踏み台サーバー経由で RDS に接続し、スキーマ単位のバックアップを実行する。
-
-```bash
-# SSH トンネルを確立
-ssh -L 5432:<RDS エンドポイント>:5432 ec2-user@<踏み台 IP> -i <キーペア>.pem
-
-# スキーマ単位でバックアップ
-PGPASSWORD=<パスワード> pg_dump -h 127.0.0.1 -p 5432 -U <ユーザー名> -d <DB 名> -n <スキーマ名> -Fc -f <スキーマ名>_backup.dump
-```
-
-### 3. リストア
-
-```bash
-# pg_restore によるリストア
-PGPASSWORD=<パスワード> pg_restore -h 127.0.0.1 -p 5432 -U <ユーザー名> -d <DB 名> --clean --if-exists <ダンプファイル>
-```
-
-### 4. AWS Backup からのリストア
-
-1. AWS コンソール → AWS Backup → バックアップボールト → リカバリポイントを選択
-2. 「復元」をクリック → リストア先の DB インスタンス識別子を指定
-3. リストア完了後、アプリケーションの接続先を切り替え
-
-> **注意**: AWS Backup からのリストアは新しい RDS インスタンスとして作成されます。
-
-### 5. 基本例
-
-```bash
-# 「データベースをバックアップして」
-# 「SMS スキーマをバックアップして」
-# 「バックアップからリストアして」
-```
-
-### 関連スキル
-
-- `operating-deploy` : デプロイ前のバックアップ確認
-- `operating-provision` : AWS Backup リソースのプロビジョニング
+---
+name: operating-backup
+description: データベースのバックアップ・リストアを実行。AWS Backup による自動バックアップ、SSH トンネル経由の手動バックアップ、スナップショットからのリストア。バックアップやリストア、データ復旧時に使用。
+---
+
+# バックアップ・リストア
+
+データベースのバックアップ・リストアを実行します。
+
+## Instructions
+
+### 1. AWS Backup（自動バックアップ）
+
+`Backup = "true"` タグが付与された RDS インスタンスに対して日次・週次でスナップショットを自動取得する。
+
+| ルール | スケジュール | 保持期間 |
+|--------|-------------|---------|
+| daily | 毎日 JST 0:00 | 7 日 |
+| weekly | 毎週日曜 JST 0:00 | 35 日 |
+
+### 2. 手動バックアップ（SSH トンネル経由）
+
+踏み台サーバー経由で RDS に接続し、スキーマ単位のバックアップを実行する。
+
+```bash
+# SSH トンネルを確立
+ssh -L 5432:<RDS エンドポイント>:5432 ec2-user@<踏み台 IP> -i <キーペア>.pem
+
+# スキーマ単位でバックアップ
+PGPASSWORD=<パスワード> pg_dump -h 127.0.0.1 -p 5432 -U <ユーザー名> -d <DB 名> -n <スキーマ名> -Fc -f <スキーマ名>_backup.dump
+```
+
+### 3. リストア
+
+```bash
+# pg_restore によるリストア
+PGPASSWORD=<パスワード> pg_restore -h 127.0.0.1 -p 5432 -U <ユーザー名> -d <DB 名> --clean --if-exists <ダンプファイル>
+```
+
+### 4. AWS Backup からのリストア
+
+1. AWS コンソール → AWS Backup → バックアップボールト → リカバリポイントを選択
+2. 「復元」をクリック → リストア先の DB インスタンス識別子を指定
+3. リストア完了後、アプリケーションの接続先を切り替え
+
+> **注意**: AWS Backup からのリストアは新しい RDS インスタンスとして作成されます。
+
+### 5. 基本例
+
+```bash
+# 「データベースをバックアップして」
+# 「SMS スキーマをバックアップして」
+# 「バックアップからリストアして」
+```
+
+### 関連スキル
+
+- `operating-deploy` : デプロイ前のバックアップ確認
+- `operating-provision` : AWS Backup リソースのプロビジョニング