@k2works/claude-code-booster 6.4.0 → 6.5.0

package/lib/assets/.claude/skills/orchestrating-operation/SKILL.md

@@ -1,161 +1,161 @@
----
-name: orchestrating-operation
-description: 運用フェーズ全体のワークフローをオーケストレーション。環境構築、プロビジョニング、CI/CD 構築、デプロイ設定、運用スクリプト作成の実行順序を案内。運用フェーズの開始や環境構築・デプロイの全体像の把握時に使用。
----
-
-# 運用フェーズオーケストレーション
-
-運用フェーズ全体の作業を支援します。環境構築からデプロイ設定、運用スクリプト作成までの包括的なワークフローを提供します。
-
-## Instructions
-
-### 1. 運用フェーズの全体像
-
-運用フェーズは「構築」と「配置」の 2 つの活動で構成されます。各環境の構築作業では、環境固有の手順書を作成・参照しながら進めます。
-
-```
-構築 → 配置 → ドキュメント更新
-```
-
-#### 構築
-
-環境の準備とインフラの整備を行います。
-
-1. **環境構築** — 各環境のセットアップ
-2. **プロビジョニング** — IaC によるインフラ管理
-3. **CI/CD 構築** — パイプラインの設計と実装
-4. **運用スクリプト作成** — 各環境のタスクランナー・自動化スクリプト
-
-#### 配置
-
-アプリケーションのビルドとデプロイを行います。
-
-1. **デプロイ設定** — デプロイ戦略の設計と実装
-
-### 2. 環境構築の段階的フロー
-
-環境構築は以下の順序で段階的に進めます。各環境のセットアップ時には対応するテンプレートを参照し、手順書を作成します。
-
-```
-アプリケーション開発環境 → 開発環境 → ステージング環境 → 本番環境
-```
-
-| 段階 | 環境 | 目的 | 手順書テンプレート |
-|------|------|------|------------------|
-| 1 | アプリケーション開発環境 | ローカル開発の効率化 | @docs/template/アプリケーション開発環境セットアップ手順書.md |
-| 2 | 開発環境 | チーム共有の動作確認環境 | @docs/template/開発環境セットアップ手順書.md |
-| 3 | ステージング環境 | 本番相当のテスト環境 | @docs/template/AWSステージング環境セットアップ手順書.md |
-| 4 | 本番環境 | プロダクション環境 | @docs/template/AWSプロダクション環境セットアップ手順書.md |
-
-各環境のセットアップ完了後、運用スクリプトを作成し、ドキュメントを更新します。
-
-### 3. プロビジョニング
-
-IaC（Infrastructure as Code）によるインフラ管理を行います。
-
-**主要な活動**:
-
-- Terraform / CloudFormation 等によるインフラ定義
-- 状態管理（S3 + DynamoDB 等）
-- モジュール化とコードの再利用
-- テスト（LocalStack / Terratest 等）
-
-**プロビジョニングのサイクル**:
-
-```
-インフラコード作成 → plan → apply → テスト → ドキュメント更新
-```
-
-### 4. CI/CD 構築
-
-継続的インテグレーション・デプロイのパイプラインを構築します。
-
-**主要な活動**:
-
-- CI パイプライン設計（ビルド・テスト・品質チェック）
-- CD パイプライン設計（デプロイ自動化）
-- OIDC 認証によるセキュアな CI/CD 連携
-- 環境別のデプロイ戦略
-
-### 5. デプロイ設定
-
-各環境へのデプロイ戦略を設計・実装します。
-
-| デプロイ方式 | 説明 | 用途 |
-|-------------|------|------|
-| ローリングデプロイ | 段階的にインスタンスを更新 | ECS / Kubernetes |
-| Blue/Green | 新旧環境を切り替え | RDS アップグレード等 |
-| Docker イメージ配布 | Registry 経由でイメージをプル | 開発環境サーバー |
-
-### 6. 運用スクリプト作成
-
-各環境の構築・デプロイ・管理を自動化するスクリプトを作成します。
-
-@docs/reference/運用スクリプト作成ガイド.md に従い、ネーミングルール・ディレクトリ構成・実装スタイルを統一します。
-
-**作成タイミング**: 各環境のセットアップ完了時に、その環境の運用スクリプトを作成します。
-
-**スクリプトの種類**:
-
-- 環境構築・セットアップ
-- ビルド・プッシュ
-- デプロイ・ロールバック
-- ステータス確認・ログ取得
-- バックアップ・リストア
-- クリーンアップ
-
-### 7. 実行手順
-
-運用フェーズを開始する際の推奨手順:
-
-1. **現状確認**: 既存の環境・インフラ・ドキュメントを確認
-2. **環境計画**: 必要な環境と構築順序を決定
-3. **手順書作成**: テンプレートを基に環境ごとの手順書を作成。書く前に `apply-docs-structure` で配置先を判断する（プロジェクト別構成なら `docs/operation/<project>/` 配下。Skill: `apply-docs-structure`）
-4. **環境構築**: 手順書に従い段階的に環境を構築（Skill: `managing-operations`）
-5. **CI/CD 構築**: パイプラインの設計と実装
-6. **運用スクリプト**: タスクランナー・自動化スクリプトの作成
-7. **ドキュメント更新**: 手順書・コマンドリファレンスの整備
-8. **OKF 適用**: `docs/` が OKF バンドルなら、作成・更新した手順書に `apply-okf` を実行する（Skill: `apply-okf`）。環境構築手順は時間とともに嘘になるので `--stale-days` を付けて見直し期限を持たせ、旧手順は削除せず `deprecate --replaced-by` で後継に繋ぐ
-
-### 8. コンテキスト管理
-
-長時間の運用セッションでは Context limit reached エラーを回避するため、タスクの区切りごとに `/compact` を実施してコンテキストを圧縮する。
-
-**`/compact` を実施するタイミング**:
-
-- 環境 1 つのセットアップが完了したとき
-- プロビジョニングの plan → apply サイクルが完了したとき
-- CI/CD パイプラインの設計・実装が一段落したとき
-- 運用スクリプト一式の作成が完了したとき
-- コミット完了後、次の環境構築に着手する前
-
-**運用ルール**:
-
-1. `/compact` 実施前に、現在の作業状態と次の工程をメモとして出力する
-2. `/compact` 実施後、次の工程の作業を継続する
-3. 大規模な環境構築（例: AWS ステージング環境）では、リソースグループごとに `/compact` を検討する
-
-### 9. 注意事項
-
-- **前提条件**: 分析フェーズで運用要件が定義済みであること
-- **制限事項**: 本番環境の構築・デプロイは十分な確認と承認のもとで実行
-- **推奨事項**: ステージング環境で十分に検証してから本番環境に適用
-
-### 10. ベストプラクティス
-
-1. **段階的構築**: アプリ開発環境 → 開発環境 → ステージング → 本番の順序を厳守
-2. **IaC 優先**: 手作業を最小限に抑え、インフラをコードで管理
-3. **テンプレート活用**: 手順書テンプレートを基に環境固有の手順書を作成
-4. **自動化徹底**: 環境構築の各段階で運用スクリプトを作成
-5. **ドキュメント同期**: 環境変更時は手順書・コマンドリファレンスを同時更新し、`apply-okf` で `generated`・`stale_after` を追従させる
-
-### 関連スキル
-
-- `operating-setup` : 環境構築の段階的実行
-- `operating-provision` : IaC によるインフラプロビジョニング
-- `operating-cicd` : CI/CD パイプライン構築
-- `operating-deploy` : デプロイ・ロールバック
-- `operating-backup` : バックアップ・リストア
-- `analyzing-operation` : 運用要件の定義
-- `apply-docs-structure` : 手順書の配置先判断（プロジェクト別 `docs/operation/<project>/`）
-- `apply-okf` : 手順書への OKF 規約適用（`stale_after`・`deprecate`）
+---
+name: orchestrating-operation
+description: 運用フェーズ全体のワークフローをオーケストレーション。環境構築、プロビジョニング、CI/CD 構築、デプロイ設定、運用スクリプト作成の実行順序を案内。運用フェーズの開始や環境構築・デプロイの全体像の把握時に使用。
+---
+
+# 運用フェーズオーケストレーション
+
+運用フェーズ全体の作業を支援します。環境構築からデプロイ設定、運用スクリプト作成までの包括的なワークフローを提供します。
+
+## Instructions
+
+### 1. 運用フェーズの全体像
+
+運用フェーズは「構築」と「配置」の 2 つの活動で構成されます。各環境の構築作業では、環境固有の手順書を作成・参照しながら進めます。
+
+```
+構築 → 配置 → ドキュメント更新
+```
+
+#### 構築
+
+環境の準備とインフラの整備を行います。
+
+1. **環境構築** — 各環境のセットアップ
+2. **プロビジョニング** — IaC によるインフラ管理
+3. **CI/CD 構築** — パイプラインの設計と実装
+4. **運用スクリプト作成** — 各環境のタスクランナー・自動化スクリプト
+
+#### 配置
+
+アプリケーションのビルドとデプロイを行います。
+
+1. **デプロイ設定** — デプロイ戦略の設計と実装
+
+### 2. 環境構築の段階的フロー
+
+環境構築は以下の順序で段階的に進めます。各環境のセットアップ時には対応するテンプレートを参照し、手順書を作成します。
+
+```
+アプリケーション開発環境 → 開発環境 → ステージング環境 → 本番環境
+```
+
+| 段階 | 環境 | 目的 | 手順書テンプレート |
+|------|------|------|------------------|
+| 1 | アプリケーション開発環境 | ローカル開発の効率化 | @docs/template/アプリケーション開発環境セットアップ手順書.md |
+| 2 | 開発環境 | チーム共有の動作確認環境 | @docs/template/開発環境セットアップ手順書.md |
+| 3 | ステージング環境 | 本番相当のテスト環境 | @docs/template/AWSステージング環境セットアップ手順書.md |
+| 4 | 本番環境 | プロダクション環境 | @docs/template/AWSプロダクション環境セットアップ手順書.md |
+
+各環境のセットアップ完了後、運用スクリプトを作成し、ドキュメントを更新します。
+
+### 3. プロビジョニング
+
+IaC（Infrastructure as Code）によるインフラ管理を行います。
+
+**主要な活動**:
+
+- Terraform / CloudFormation 等によるインフラ定義
+- 状態管理（S3 + DynamoDB 等）
+- モジュール化とコードの再利用
+- テスト（LocalStack / Terratest 等）
+
+**プロビジョニングのサイクル**:
+
+```
+インフラコード作成 → plan → apply → テスト → ドキュメント更新
+```
+
+### 4. CI/CD 構築
+
+継続的インテグレーション・デプロイのパイプラインを構築します。
+
+**主要な活動**:
+
+- CI パイプライン設計（ビルド・テスト・品質チェック）
+- CD パイプライン設計（デプロイ自動化）
+- OIDC 認証によるセキュアな CI/CD 連携
+- 環境別のデプロイ戦略
+
+### 5. デプロイ設定
+
+各環境へのデプロイ戦略を設計・実装します。
+
+| デプロイ方式 | 説明 | 用途 |
+|-------------|------|------|
+| ローリングデプロイ | 段階的にインスタンスを更新 | ECS / Kubernetes |
+| Blue/Green | 新旧環境を切り替え | RDS アップグレード等 |
+| Docker イメージ配布 | Registry 経由でイメージをプル | 開発環境サーバー |
+
+### 6. 運用スクリプト作成
+
+各環境の構築・デプロイ・管理を自動化するスクリプトを作成します。
+
+@docs/reference/運用スクリプト作成ガイド.md に従い、ネーミングルール・ディレクトリ構成・実装スタイルを統一します。
+
+**作成タイミング**: 各環境のセットアップ完了時に、その環境の運用スクリプトを作成します。
+
+**スクリプトの種類**:
+
+- 環境構築・セットアップ
+- ビルド・プッシュ
+- デプロイ・ロールバック
+- ステータス確認・ログ取得
+- バックアップ・リストア
+- クリーンアップ
+
+### 7. 実行手順
+
+運用フェーズを開始する際の推奨手順:
+
+1. **現状確認**: 既存の環境・インフラ・ドキュメントを確認
+2. **環境計画**: 必要な環境と構築順序を決定
+3. **手順書作成**: テンプレートを基に環境ごとの手順書を作成。書く前に `apply-docs-structure` で配置先を判断する（プロジェクト別構成なら `docs/operation/<project>/` 配下。Skill: `apply-docs-structure`）
+4. **環境構築**: 手順書に従い段階的に環境を構築（Skill: `managing-operations`）
+5. **CI/CD 構築**: パイプラインの設計と実装
+6. **運用スクリプト**: タスクランナー・自動化スクリプトの作成
+7. **ドキュメント更新**: 手順書・コマンドリファレンスの整備
+8. **OKF 適用**: `docs/` が OKF バンドルなら、作成・更新した手順書に `apply-okf` を実行する（Skill: `apply-okf`）。環境構築手順は時間とともに嘘になるので `--stale-days` を付けて見直し期限を持たせ、旧手順は削除せず `deprecate --replaced-by` で後継に繋ぐ
+
+### 8. コンテキスト管理
+
+長時間の運用セッションでは Context limit reached エラーを回避するため、タスクの区切りごとに `/compact` を実施してコンテキストを圧縮する。
+
+**`/compact` を実施するタイミング**:
+
+- 環境 1 つのセットアップが完了したとき
+- プロビジョニングの plan → apply サイクルが完了したとき
+- CI/CD パイプラインの設計・実装が一段落したとき
+- 運用スクリプト一式の作成が完了したとき
+- コミット完了後、次の環境構築に着手する前
+
+**運用ルール**:
+
+1. `/compact` 実施前に、現在の作業状態と次の工程をメモとして出力する
+2. `/compact` 実施後、次の工程の作業を継続する
+3. 大規模な環境構築（例: AWS ステージング環境）では、リソースグループごとに `/compact` を検討する
+
+### 9. 注意事項
+
+- **前提条件**: 分析フェーズで運用要件が定義済みであること
+- **制限事項**: 本番環境の構築・デプロイは十分な確認と承認のもとで実行
+- **推奨事項**: ステージング環境で十分に検証してから本番環境に適用
+
+### 10. ベストプラクティス
+
+1. **段階的構築**: アプリ開発環境 → 開発環境 → ステージング → 本番の順序を厳守
+2. **IaC 優先**: 手作業を最小限に抑え、インフラをコードで管理
+3. **テンプレート活用**: 手順書テンプレートを基に環境固有の手順書を作成
+4. **自動化徹底**: 環境構築の各段階で運用スクリプトを作成
+5. **ドキュメント同期**: 環境変更時は手順書・コマンドリファレンスを同時更新し、`apply-okf` で `generated`・`stale_after` を追従させる
+
+### 関連スキル
+
+- `operating-setup` : 環境構築の段階的実行
+- `operating-provision` : IaC によるインフラプロビジョニング
+- `operating-cicd` : CI/CD パイプライン構築
+- `operating-deploy` : デプロイ・ロールバック
+- `operating-backup` : バックアップ・リストア
+- `analyzing-operation` : 運用要件の定義
+- `apply-docs-structure` : 手順書の配置先判断（プロジェクト別 `docs/operation/<project>/`）
+- `apply-okf` : 手順書への OKF 規約適用（`stale_after`・`deprecate`）

package/lib/assets/.claude/skills/orchestrating-project/SKILL.md

@@ -1,149 +1,149 @@
----
-name: orchestrating-project
-description: 計画・進捗管理フェーズ全体のワークフローをオーケストレーション。リリース計画→GitHub Project 同期→進捗追跡の実行順序を案内し、イテレーションのライフサイクルを管理する。「プロジェクト管理を始めたい」「イテレーションの進め方を知りたい」「計画と GitHub を同期したい」「プロジェクトの全体像を把握したい」といった場面で発動する。計画・実行・振り返りのサイクルを標準化することで、プロジェクトの予測可能性を高める。
----
-
-# 計画・進捗管理オーケストレーション
-
-計画・進捗管理フェーズ全体のワークフローを案内する。リリース計画の策定から GitHub Project への同期、進捗追跡まで包括的なプロジェクト管理サイクルを提供する。
-
-## オプション
-
-| オプション | 説明 |
-|-----------|------|
-| なし | 計画・進捗管理フェーズ全体のワークフローを表示 |
-| `--init` | プロジェクト管理の初期セットアップ（リリース計画→GitHub 同期） |
-| `--iteration <番号>` | 特定イテレーションのライフサイクル管理（計画→実行→振り返り→報告） |
-| `--sync` | 計画ドキュメントと GitHub Project の同期 + ドキュメントインデックス更新 |
-| `--status` | プロジェクト全体の状態サマリーを表示 |
-
-## フェーズの全体像
-
-1. **リリース計画の策定** (Skill: `planning-releases`) — スコープ・スケジュール・リソースの定義、ベロシティ管理
-2. **GitHub Project 同期** (Skill: `syncing-github-project`) — Issue 作成、カスタムフィールド設定、Milestone 管理
-3. **進捗追跡** (Skill: `tracking-progress`) — 達成度分析、品質メトリクス、ドキュメント更新
-
-## プロジェクト管理ワークフロー
-
-```mermaid
-graph TD
-    A[要件定義/ユーザーストーリー] --> B[リリース計画作成]
-    B --> C[GitHub Project 同期]
-    C --> D[イテレーション計画作成]
-    D --> E[開発実行]
-    E --> F[進捗追跡]
-    F --> G[ふりかえり]
-    G --> H[完了報告書作成]
-    H --> I[GitHub 同期更新]
-    I --> J{次のイテレーション?}
-    J -->|あり| D
-    J -->|なし| K{次のリリース?}
-    K -->|あり| B
-    K -->|なし| L[プロジェクト完了]
-```
-
-## 初期セットアップフロー（--init）
-
-プロジェクト管理の初期セットアップを段階的に実行する。
-
-1. **リリース計画作成**: `planning-releases --release` でマクロ計画を策定する
-2. **GitHub Project 同期**: `syncing-github-project` で GitHub に反映する
-3. **イテレーション 1 計画**: `planning-releases --iteration 1` で初回イテレーション計画を作成する
-4. **状態確認**: `tracking-progress --brief` で初期状態を確認する
-
-## イテレーションライフサイクル（--iteration）
-
-各イテレーションのライフサイクルを 3 フェーズで管理する。
-
-### 開始時
-
-1. `planning-releases --iteration <N>` でイテレーション計画を作成する
-2. `syncing-github-project --sync` で GitHub に反映する
-3. `tracking-progress --iteration <N>` で初期状態を確認する
-
-### 実行中
-
-1. `tracking-progress --brief` で進捗を定期確認する
-2. `syncing-github-project --status` で GitHub の状態を確認する
-
-### 終了時
-
-1. `tracking-progress --update` で進捗ドキュメントを更新する
-2. `planning-releases --retrospective` でふりかえりを実施する
-3. `planning-releases --report` で完了報告書を作成する
-4. `syncing-github-project --sync` で GitHub に最終同期する
-5. `operating-docs --update` で `docs/index.md` と `mkdocs.yml` を同期する
-6. `apply-docs-structure` の check で、作成した計画・報告書がプロジェクト別カテゴリ（`docs/development/<project>/` など）に正しく配置されているか検証する
-7. `apply-okf` で、このイテレーションで作成・更新した計画・報告書・設計ドキュメントに OKF 規約を適用する（`apply docs --changed --by <agent>`）。イテレーション計画は完了したら `verify` ではなく実績を記した報告書が後継になるので、計画側は `stable` のまま残し、報告書を新規登録する
-
-## GitHub 同期フロー（--sync）
-
-`--sync` は GitHub Project の同期に加え、ドキュメントインデックスも更新する。
-
-1. `syncing-github-project` で GitHub Issue / Milestone / Label を同期する
-2. `operating-docs --update` で `docs/index.md`、`mkdocs.yml`、各ディレクトリの `index.md` を現在のドキュメント構成に同期する
-3. `docs/` が OKF バンドルなら `apply-okf` で変更分に規約を適用し、`apply-docs-structure` の check と `gulp okf:check` で ERROR 0 を確認する
-4. 変更があればコミットする
-
-## 途中から再開
-
-プロジェクト管理の途中から再開する場合は、まず現在の状態を確認する。
-
-**Example:**
-
-```
-ユーザー: 「イテレーション 2 の開発が終わった。振り返りをしたい」
-回答: docs/development/iteration_plan-2.md の完了状況を確認し、
-      tracking-progress --update で進捗を更新してから
-      planning-releases --retrospective でふりかえりを実施する。
-```
-
-## 出力例
-
-```
-プロジェクト管理状態
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-リリース計画
-├─ リリース 1.0 MVP: 8 週間（4 イテレーション）
-├─ 総ストーリー: 34 件（155SP）
-└─ 進捗: 25%（イテレーション 1/4 完了）
-
-GitHub Project
-├─ 同期状態: 最新
-├─ Open Issues: 26 件
-├─ Closed Issues: 8 件
-└─ 最終同期: 2026-02-17
-
-現在のイテレーション（IT-2）
-├─ 期間: 2026-02-17 〜 2026-02-28
-├─ 計画 SP: 12SP
-├─ 完了 SP: 4SP
-├─ 達成率: 33%
-└─ ベロシティ（前回）: 10SP
-```
-
-## コンテキスト管理
-
-タスクの区切りごとに `/compact` を実施して Context limit reached エラーを回避する。
-
-- リリース計画・イテレーション計画の作成完了時、GitHub 同期完了時、ふりかえり・報告書作成完了時に実施する
-- `/compact` 前に現在の作業状態と次のタスクをメモとして出力する
-
-## 注意事項
-
-- 要件定義書またはユーザーストーリーが存在すること、`gh` CLI がインストールされ認証済みであること（前提条件）
-- 初回ベロシティは推測値のため、3 イテレーション後に再調整を推奨する
-- `docs/development/release_plan.md` を Single Source of Truth として管理し、GitHub への同期を定期的に実施する
-- データドリブンにベロシティ実績に基づいて計画を継続的に調整する
-
-## 関連スキル
-
-- `planning-releases` — リリース・イテレーション計画の作成と管理
-- `syncing-github-project` — GitHub Project への同期と一元管理
-- `tracking-progress` — 進捗分析・レポート生成
-- `operating-docs` — ドキュメントインデックス更新・Lint（`--sync` 時に自動実行）
-- `apply-docs-structure` — 計画・報告書の配置先判断と構成検証（イテレーション終了時・`--sync` 時）
-- `apply-okf` — 計画・報告書への OKF 規約適用（イテレーション終了時・`--sync` 時）
-- `orchestrating-analysis` — 分析フェーズのオーケストレーション
-- `orchestrating-development` — 開発フェーズのオーケストレーション
+---
+name: orchestrating-project
+description: 計画・進捗管理フェーズ全体のワークフローをオーケストレーション。リリース計画→GitHub Project 同期→進捗追跡の実行順序を案内し、イテレーションのライフサイクルを管理する。「プロジェクト管理を始めたい」「イテレーションの進め方を知りたい」「計画と GitHub を同期したい」「プロジェクトの全体像を把握したい」といった場面で発動する。計画・実行・振り返りのサイクルを標準化することで、プロジェクトの予測可能性を高める。
+---
+
+# 計画・進捗管理オーケストレーション
+
+計画・進捗管理フェーズ全体のワークフローを案内する。リリース計画の策定から GitHub Project への同期、進捗追跡まで包括的なプロジェクト管理サイクルを提供する。
+
+## オプション
+
+| オプション | 説明 |
+|-----------|------|
+| なし | 計画・進捗管理フェーズ全体のワークフローを表示 |
+| `--init` | プロジェクト管理の初期セットアップ（リリース計画→GitHub 同期） |
+| `--iteration <番号>` | 特定イテレーションのライフサイクル管理（計画→実行→振り返り→報告） |
+| `--sync` | 計画ドキュメントと GitHub Project の同期 + ドキュメントインデックス更新 |
+| `--status` | プロジェクト全体の状態サマリーを表示 |
+
+## フェーズの全体像
+
+1. **リリース計画の策定** (Skill: `planning-releases`) — スコープ・スケジュール・リソースの定義、ベロシティ管理
+2. **GitHub Project 同期** (Skill: `syncing-github-project`) — Issue 作成、カスタムフィールド設定、Milestone 管理
+3. **進捗追跡** (Skill: `tracking-progress`) — 達成度分析、品質メトリクス、ドキュメント更新
+
+## プロジェクト管理ワークフロー
+
+```mermaid
+graph TD
+    A[要件定義/ユーザーストーリー] --> B[リリース計画作成]
+    B --> C[GitHub Project 同期]
+    C --> D[イテレーション計画作成]
+    D --> E[開発実行]
+    E --> F[進捗追跡]
+    F --> G[ふりかえり]
+    G --> H[完了報告書作成]
+    H --> I[GitHub 同期更新]
+    I --> J{次のイテレーション?}
+    J -->|あり| D
+    J -->|なし| K{次のリリース?}
+    K -->|あり| B
+    K -->|なし| L[プロジェクト完了]
+```
+
+## 初期セットアップフロー（--init）
+
+プロジェクト管理の初期セットアップを段階的に実行する。
+
+1. **リリース計画作成**: `planning-releases --release` でマクロ計画を策定する
+2. **GitHub Project 同期**: `syncing-github-project` で GitHub に反映する
+3. **イテレーション 1 計画**: `planning-releases --iteration 1` で初回イテレーション計画を作成する
+4. **状態確認**: `tracking-progress --brief` で初期状態を確認する
+
+## イテレーションライフサイクル（--iteration）
+
+各イテレーションのライフサイクルを 3 フェーズで管理する。
+
+### 開始時
+
+1. `planning-releases --iteration <N>` でイテレーション計画を作成する
+2. `syncing-github-project --sync` で GitHub に反映する
+3. `tracking-progress --iteration <N>` で初期状態を確認する
+
+### 実行中
+
+1. `tracking-progress --brief` で進捗を定期確認する
+2. `syncing-github-project --status` で GitHub の状態を確認する
+
+### 終了時
+
+1. `tracking-progress --update` で進捗ドキュメントを更新する
+2. `planning-releases --retrospective` でふりかえりを実施する
+3. `planning-releases --report` で完了報告書を作成する
+4. `syncing-github-project --sync` で GitHub に最終同期する
+5. `operating-docs --update` で `docs/index.md` と `mkdocs.yml` を同期する
+6. `apply-docs-structure` の check で、作成した計画・報告書がプロジェクト別カテゴリ（`docs/development/<project>/` など）に正しく配置されているか検証する
+7. `apply-okf` で、このイテレーションで作成・更新した計画・報告書・設計ドキュメントに OKF 規約を適用する（`apply docs --changed --by <agent>`）。イテレーション計画は完了したら `verify` ではなく実績を記した報告書が後継になるので、計画側は `stable` のまま残し、報告書を新規登録する
+
+## GitHub 同期フロー（--sync）
+
+`--sync` は GitHub Project の同期に加え、ドキュメントインデックスも更新する。
+
+1. `syncing-github-project` で GitHub Issue / Milestone / Label を同期する
+2. `operating-docs --update` で `docs/index.md`、`mkdocs.yml`、各ディレクトリの `index.md` を現在のドキュメント構成に同期する
+3. `docs/` が OKF バンドルなら `apply-okf` で変更分に規約を適用し、`apply-docs-structure` の check と `gulp okf:check` で ERROR 0 を確認する
+4. 変更があればコミットする
+
+## 途中から再開
+
+プロジェクト管理の途中から再開する場合は、まず現在の状態を確認する。
+
+**Example:**
+
+```
+ユーザー: 「イテレーション 2 の開発が終わった。振り返りをしたい」
+回答: docs/development/iteration_plan-2.md の完了状況を確認し、
+      tracking-progress --update で進捗を更新してから
+      planning-releases --retrospective でふりかえりを実施する。
+```
+
+## 出力例
+
+```
+プロジェクト管理状態
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+リリース計画
+├─ リリース 1.0 MVP: 8 週間（4 イテレーション）
+├─ 総ストーリー: 34 件（155SP）
+└─ 進捗: 25%（イテレーション 1/4 完了）
+
+GitHub Project
+├─ 同期状態: 最新
+├─ Open Issues: 26 件
+├─ Closed Issues: 8 件
+└─ 最終同期: 2026-02-17
+
+現在のイテレーション（IT-2）
+├─ 期間: 2026-02-17 〜 2026-02-28
+├─ 計画 SP: 12SP
+├─ 完了 SP: 4SP
+├─ 達成率: 33%
+└─ ベロシティ（前回）: 10SP
+```
+
+## コンテキスト管理
+
+タスクの区切りごとに `/compact` を実施して Context limit reached エラーを回避する。
+
+- リリース計画・イテレーション計画の作成完了時、GitHub 同期完了時、ふりかえり・報告書作成完了時に実施する
+- `/compact` 前に現在の作業状態と次のタスクをメモとして出力する
+
+## 注意事項
+
+- 要件定義書またはユーザーストーリーが存在すること、`gh` CLI がインストールされ認証済みであること（前提条件）
+- 初回ベロシティは推測値のため、3 イテレーション後に再調整を推奨する
+- `docs/development/release_plan.md` を Single Source of Truth として管理し、GitHub への同期を定期的に実施する
+- データドリブンにベロシティ実績に基づいて計画を継続的に調整する
+
+## 関連スキル
+
+- `planning-releases` — リリース・イテレーション計画の作成と管理
+- `syncing-github-project` — GitHub Project への同期と一元管理
+- `tracking-progress` — 進捗分析・レポート生成
+- `operating-docs` — ドキュメントインデックス更新・Lint（`--sync` 時に自動実行）
+- `apply-docs-structure` — 計画・報告書の配置先判断と構成検証（イテレーション終了時・`--sync` 時）
+- `apply-okf` — 計画・報告書への OKF 規約適用（イテレーション終了時・`--sync` 時）
+- `orchestrating-analysis` — 分析フェーズのオーケストレーション
+- `orchestrating-development` — 開発フェーズのオーケストレーション