@k2works/claude-code-booster 6.4.0 → 6.6.0

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 リソースのプロビジョニング

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

@@ -1,54 +1,54 @@
----
-name: operating-cicd
-description: CI/CD パイプラインを構築。CI（Lint・テスト・ビルド・セキュリティスキャン）と CD（環境別デプロイ・OIDC 認証）の設計・実装。CI/CD パイプラインの構築やデプロイ自動化の設定時に使用。
----
-
-# CI/CD パイプライン構築
-
-継続的インテグレーション・デプロイのパイプラインを構築します。
-
-## Instructions
-
-### 1. CI パイプライン
-
-ビルド・テスト・品質チェックを自動化する。
-
-| 段階 | 内容 | 目的 |
-|------|------|------|
-| ソースチェックアウト | リポジトリのコード取得 | 最新コードの取得 |
-| 依存関係インストール | パッケージのインストール | ビルド環境の準備 |
-| 静的解析 | Lint、型チェック | コード品質の担保 |
-| テスト | 単体・統合テストの実行 | 機能の正しさの検証 |
-| ビルド | アプリケーションのビルド | デプロイ可能な成果物の生成 |
-| セキュリティスキャン | 依存関係の脆弱性チェック | セキュリティリスクの排除 |
-
-### 2. CD パイプライン
-
-環境別のデプロイを自動化する。
-
-| 環境 | トリガー | 方式 | 承認 |
-|------|---------|------|------|
-| Development | `develop` ブランチ push | 即座デプロイ | 不要 |
-| Staging | `main` ブランチ push | 自動デプロイ | 不要 |
-| Production | リリースタグ作成 | ローリング or Blue/Green | 必須 |
-
-### 3. OIDC 認証
-
-クラウド環境へのデプロイではシークレットキーの直接管理を避け、OIDC（OpenID Connect）認証を使用する。
-
-- **AWS**: GitHub Actions OIDC Provider + IAM Role
-- **GCP**: Workload Identity Federation
-- **Azure**: Federated Identity Credentials
-
-### 4. ベストプラクティス
-
-- **高速フィードバック**: Lint → テスト → ビルドの順で失敗を早期検知
-- **キャッシュ活用**: 依存関係のキャッシュで実行時間を短縮
-- **並列実行**: 独立したジョブは並列で実行
-- **段階的導入**: CI 基盤 → 開発環境 CD → ステージング CD → 本番 CD の順
-
-### 関連スキル
-
-- `operating-deploy` : デプロイの実行
-- `operating-provision` : OIDC 用 IAM ロールのプロビジョニング
-- `orchestrating-operation` : 運用フェーズ全体のワークフロー案内
+---
+name: operating-cicd
+description: CI/CD パイプラインを構築。CI（Lint・テスト・ビルド・セキュリティスキャン）と CD（環境別デプロイ・OIDC 認証）の設計・実装。CI/CD パイプラインの構築やデプロイ自動化の設定時に使用。
+---
+
+# CI/CD パイプライン構築
+
+継続的インテグレーション・デプロイのパイプラインを構築します。
+
+## Instructions
+
+### 1. CI パイプライン
+
+ビルド・テスト・品質チェックを自動化する。
+
+| 段階 | 内容 | 目的 |
+|------|------|------|
+| ソースチェックアウト | リポジトリのコード取得 | 最新コードの取得 |
+| 依存関係インストール | パッケージのインストール | ビルド環境の準備 |
+| 静的解析 | Lint、型チェック | コード品質の担保 |
+| テスト | 単体・統合テストの実行 | 機能の正しさの検証 |
+| ビルド | アプリケーションのビルド | デプロイ可能な成果物の生成 |
+| セキュリティスキャン | 依存関係の脆弱性チェック | セキュリティリスクの排除 |
+
+### 2. CD パイプライン
+
+環境別のデプロイを自動化する。
+
+| 環境 | トリガー | 方式 | 承認 |
+|------|---------|------|------|
+| Development | `develop` ブランチ push | 即座デプロイ | 不要 |
+| Staging | `main` ブランチ push | 自動デプロイ | 不要 |
+| Production | リリースタグ作成 | ローリング or Blue/Green | 必須 |
+
+### 3. OIDC 認証
+
+クラウド環境へのデプロイではシークレットキーの直接管理を避け、OIDC（OpenID Connect）認証を使用する。
+
+- **AWS**: GitHub Actions OIDC Provider + IAM Role
+- **GCP**: Workload Identity Federation
+- **Azure**: Federated Identity Credentials
+
+### 4. ベストプラクティス
+
+- **高速フィードバック**: Lint → テスト → ビルドの順で失敗を早期検知
+- **キャッシュ活用**: 依存関係のキャッシュで実行時間を短縮
+- **並列実行**: 独立したジョブは並列で実行
+- **段階的導入**: CI 基盤 → 開発環境 CD → ステージング CD → 本番 CD の順
+
+### 関連スキル
+
+- `operating-deploy` : デプロイの実行
+- `operating-provision` : OIDC 用 IAM ロールのプロビジョニング
+- `orchestrating-operation` : 運用フェーズ全体のワークフロー案内

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

@@ -1,67 +1,67 @@
----
-name: operating-deploy
-description: 各環境へのデプロイを実行。Docker イメージのビルド・プッシュ、ローリングデプロイ、Blue/Green デプロイ、ロールバック、ステータス確認、ログ取得。デプロイやロールバック、サービス状態確認時に使用。
----
-
-# デプロイ
-
-各環境へのデプロイ、ロールバック、ステータス確認を実行します。
-
-## Instructions
-
-### 1. デプロイフロー
-
-```
-Docker ビルド → Registry プッシュ → 対象環境でプル → サービス更新 → ヘルスチェック
-```
-
-### 2. デプロイ方式
-
-| 方式 | 説明 | 用途 |
-|------|------|------|
-| Docker イメージ配布 | Registry 経由でイメージをプル | 開発環境 |
-| ローリングデプロイ | 段階的にインスタンスを更新 | ECS ステージング・本番 |
-| Blue/Green | 新旧環境を切り替え | RDS アップグレード |
-
-### 3. 環境別デプロイ
-
-```bash
-# 開発環境: Docker イメージ配布
-# 「開発環境にデプロイして」
-
-# ステージング環境: ECS ローリングデプロイ
-# 「ステージングにデプロイして」
-
-# 本番環境: 承認後デプロイ
-# 「本番にデプロイして」
-```
-
-### 4. ロールバック
-
-問題発生時は前バージョンに切り戻す。
-
-```bash
-# 「開発環境をロールバックして」
-# 「本番を前バージョンに戻して」
-```
-
-### 5. ステータス確認・ログ
-
-```bash
-# 「開発環境の状態を確認して」
-# 「ステージングのログを見せて」
-# 「全環境の状態を確認して」
-```
-
-### 6. 注意事項
-
-- **段階的デプロイ**: Development → Staging → Production の順序を厳守
-- **ステージング検証**: 本番デプロイ前にステージングで十分に検証
-- **ロールバック準備**: デプロイ前にロールバック手順を確認
-- **ヘルスチェック**: デプロイ後に必ず動作確認を実施
-
-### 関連スキル
-
-- `operating-cicd` : CI/CD パイプライン構築
-- `operating-backup` : デプロイ前のバックアップ
-- `developing-release` : リリースワークフロー
+---
+name: operating-deploy
+description: 各環境へのデプロイを実行。Docker イメージのビルド・プッシュ、ローリングデプロイ、Blue/Green デプロイ、ロールバック、ステータス確認、ログ取得。デプロイやロールバック、サービス状態確認時に使用。
+---
+
+# デプロイ
+
+各環境へのデプロイ、ロールバック、ステータス確認を実行します。
+
+## Instructions
+
+### 1. デプロイフロー
+
+```
+Docker ビルド → Registry プッシュ → 対象環境でプル → サービス更新 → ヘルスチェック
+```
+
+### 2. デプロイ方式
+
+| 方式 | 説明 | 用途 |
+|------|------|------|
+| Docker イメージ配布 | Registry 経由でイメージをプル | 開発環境 |
+| ローリングデプロイ | 段階的にインスタンスを更新 | ECS ステージング・本番 |
+| Blue/Green | 新旧環境を切り替え | RDS アップグレード |
+
+### 3. 環境別デプロイ
+
+```bash
+# 開発環境: Docker イメージ配布
+# 「開発環境にデプロイして」
+
+# ステージング環境: ECS ローリングデプロイ
+# 「ステージングにデプロイして」
+
+# 本番環境: 承認後デプロイ
+# 「本番にデプロイして」
+```
+
+### 4. ロールバック
+
+問題発生時は前バージョンに切り戻す。
+
+```bash
+# 「開発環境をロールバックして」
+# 「本番を前バージョンに戻して」
+```
+
+### 5. ステータス確認・ログ
+
+```bash
+# 「開発環境の状態を確認して」
+# 「ステージングのログを見せて」
+# 「全環境の状態を確認して」
+```
+
+### 6. 注意事項
+
+- **段階的デプロイ**: Development → Staging → Production の順序を厳守
+- **ステージング検証**: 本番デプロイ前にステージングで十分に検証
+- **ロールバック準備**: デプロイ前にロールバック手順を確認
+- **ヘルスチェック**: デプロイ後に必ず動作確認を実施
+
+### 関連スキル
+
+- `operating-cicd` : CI/CD パイプライン構築
+- `operating-backup` : デプロイ前のバックアップ
+- `developing-release` : リリースワークフロー