@k2works/claude-code-booster 4.11.0 → 4.12.0

package/lib/assets/.claude/skills/analyzing-test-strategy/SKILL.md

@@ -1,89 +1,89 @@
----
-name: analyzing-test-strategy
-description: テストピラミッド設計、テスト種別の定義、カバレッジ目標の設定を含むテスト戦略を策定。「テスト戦略を決めたい」「テスト計画を立てたい」「カバレッジ目標を設定したい」「テストピラミッドを設計したい」「TDD/BDD の方針を決めたい」といった場面で発動する。テスト戦略を先に策定することで、開発中の「何をどこまでテストすべきか」の迷いを排除する。
----
-
-# テスト戦略策定
-
-アーキテクチャパターンに適合するテスト形状（ピラミッド型・ダイヤモンド型・逆ピラミッド型）を選択し、テスト戦略を策定する。
-
-テスト戦略はアーキテクチャと表裏一体。レイヤードアーキテクチャならピラミッド型、マイクロサービスならダイヤモンド型が適合しやすい。テスト形状を間違えると、テストの実行時間が爆発するか、品質保証が不十分になる。
-
-## 参照ドキュメントとテンプレート
-
-| 種類 | パス | 備考 |
-|------|------|------|
-| ガイド | @docs/reference/テスト戦略ガイド.md | テスト戦略の進め方詳細 |
-| テンプレート | @docs/template/設計.md | 編集禁止。コピーして使用する |
-| 入力 | @docs/requirements/requirements_definition.md | 要件定義 |
-| 入力 | @docs/requirements/business_usecase.md | ビジネスユースケース |
-| 入力 | @docs/requirements/system_usecase.md | システムユースケース |
-| 入力 | @docs/requirements/user_story.md | ユーザーストーリー |
-| 入力 | @docs/design/architecture_backend.md | バックエンドアーキテクチャ |
-| 入力 | @docs/design/architecture_frontend.md | フロントエンドアーキテクチャ |
-| 成果物 | `docs/design/test_strategy.md` | テスト戦略 |
-
-## テスト形状の選択
-
-アーキテクチャパターンとシステム特性に基づいてテスト形状を選択する。形状の選択理由を明記せよ。
-
-- **ピラミッド型（ユニット重視）**: ビジネスロジックが複雑でドメイン層が厚い場合に適する。ユニットテストを土台に高速なフィードバックを得る
-- **ダイヤモンド型（統合テスト重視）**: マイクロサービスや外部連携が多い場合に適する。サービス間の結合点を重点的にテストする
-- **逆ピラミッド型（E2E 重視）**: UI 中心のアプリケーションやレガシーシステムの保護に適する。ただし実行時間とメンテナンスコストが高いことを認識せよ
-
-## テストレベルの定義
-
-各テストレベルの責務を明確に定義する。テストレベル間で検証内容が重複すると、テストスイート全体の実行時間が不必要に増える。
-
-- **ユニットテスト**: 単一クラス/関数の振る舞いを検証する。外部依存はモックする
-- **統合テスト**: コンポーネント間の連携を検証する。DB やメッセージキューとの結合を含む
-- **E2E テスト**: ユーザーシナリオに基づいてシステム全体を検証する
-- **受け入れテスト**: ユーザーストーリーの受入条件を検証する
-
-## テスト戦略の策定
-
-具体的な数値目標とツール選定を行う。曖昧な「十分にテストする」ではなく、測定可能な基準を設定せよ。
-
-- **カバレッジ目標**: テストレベルごとのカバレッジ目標を設定する（例: ユニット 80%、統合 60%）
-- **テストツールの選定**: 技術スタックに適合するテストツールを選定する
-- **CI/CD との連携**: テスト実行のタイミングと失敗時の振る舞いを定義する
-
-## トレーサビリティの確保
-
-要件からテストケースまでの追跡を可能にする。「この機能はどのテストで保証されているか」を常に回答可能にせよ。
-
-- **要件とテストケースのマッピング**: ユーザーストーリーの受入条件とテストケースを対応づける
-
-## 作成の進め方
-
-1. アーキテクチャドキュメント（バックエンド・フロントエンド）を確認する
-2. @docs/reference/テスト戦略ガイド.md を読み込む
-3. テスト形状→テストレベル→カバレッジ目標→ツール選定の順に策定する
-4. `docs/design/test_strategy.md` として出力する
-
-## 途中から再開する場合
-
-既存の `docs/design/test_strategy.md` がある場合は、まずその内容を確認する。不足しているテストレベルの定義や更新が必要な部分のみを修正する。
-
-**Example:**
-
-```
-ユーザー: 「テスト形状はピラミッド型に決めた。カバレッジ目標を設定したい」
-回答: 既存の test_strategy.md のテスト形状を確認し、
-      ピラミッド型に基づいてテストレベルごとのカバレッジ目標を設定する。
-      ユニット→統合→E2E の順に目標値と測定方法を定義する。
-```
-
-## 注意事項
-
-- アーキテクチャ設計が完了していることが前提。未完了でも進めて構わない
-- テスト戦略はアーキテクチャパターンに適合させる。パターンとの不整合は無駄なテストを生む
-- TDD/BDD の適用を検討し、開発プロセスとテスト戦略を一体化する
-- タスク項目（リスト）の前には空行を入れる（Markdown Lint 準拠）
-
-## 関連スキル
-
-- `orchestrating-analysis` — 分析フェーズ全体のワークフロー案内
-- `analyzing-architecture` — テスト形状選択の基盤となるアーキテクチャ設計
-- `analyzing-tech-stack` — テストツール選定との整合性
-- `analyzing-non-functional` — 性能テストの基準となる非機能要件
+---
+name: analyzing-test-strategy
+description: テストピラミッド設計、テスト種別の定義、カバレッジ目標の設定を含むテスト戦略を策定。「テスト戦略を決めたい」「テスト計画を立てたい」「カバレッジ目標を設定したい」「テストピラミッドを設計したい」「TDD/BDD の方針を決めたい」といった場面で発動する。テスト戦略を先に策定することで、開発中の「何をどこまでテストすべきか」の迷いを排除する。
+---
+
+# テスト戦略策定
+
+アーキテクチャパターンに適合するテスト形状（ピラミッド型・ダイヤモンド型・逆ピラミッド型）を選択し、テスト戦略を策定する。
+
+テスト戦略はアーキテクチャと表裏一体。レイヤードアーキテクチャならピラミッド型、マイクロサービスならダイヤモンド型が適合しやすい。テスト形状を間違えると、テストの実行時間が爆発するか、品質保証が不十分になる。
+
+## 参照ドキュメントとテンプレート
+
+| 種類 | パス | 備考 |
+|------|------|------|
+| ガイド | @docs/reference/テスト戦略ガイド.md | テスト戦略の進め方詳細 |
+| テンプレート | @docs/template/設計.md | 編集禁止。コピーして使用する |
+| 入力 | @docs/requirements/requirements_definition.md | 要件定義 |
+| 入力 | @docs/requirements/business_usecase.md | ビジネスユースケース |
+| 入力 | @docs/requirements/system_usecase.md | システムユースケース |
+| 入力 | @docs/requirements/user_story.md | ユーザーストーリー |
+| 入力 | @docs/design/architecture_backend.md | バックエンドアーキテクチャ |
+| 入力 | @docs/design/architecture_frontend.md | フロントエンドアーキテクチャ |
+| 成果物 | `docs/design/test_strategy.md` | テスト戦略 |
+
+## テスト形状の選択
+
+アーキテクチャパターンとシステム特性に基づいてテスト形状を選択する。形状の選択理由を明記せよ。
+
+- **ピラミッド型（ユニット重視）**: ビジネスロジックが複雑でドメイン層が厚い場合に適する。ユニットテストを土台に高速なフィードバックを得る
+- **ダイヤモンド型（統合テスト重視）**: マイクロサービスや外部連携が多い場合に適する。サービス間の結合点を重点的にテストする
+- **逆ピラミッド型（E2E 重視）**: UI 中心のアプリケーションやレガシーシステムの保護に適する。ただし実行時間とメンテナンスコストが高いことを認識せよ
+
+## テストレベルの定義
+
+各テストレベルの責務を明確に定義する。テストレベル間で検証内容が重複すると、テストスイート全体の実行時間が不必要に増える。
+
+- **ユニットテスト**: 単一クラス/関数の振る舞いを検証する。外部依存はモックする
+- **統合テスト**: コンポーネント間の連携を検証する。DB やメッセージキューとの結合を含む
+- **E2E テスト**: ユーザーシナリオに基づいてシステム全体を検証する
+- **受け入れテスト**: ユーザーストーリーの受入条件を検証する
+
+## テスト戦略の策定
+
+具体的な数値目標とツール選定を行う。曖昧な「十分にテストする」ではなく、測定可能な基準を設定せよ。
+
+- **カバレッジ目標**: テストレベルごとのカバレッジ目標を設定する（例: ユニット 80%、統合 60%）
+- **テストツールの選定**: 技術スタックに適合するテストツールを選定する
+- **CI/CD との連携**: テスト実行のタイミングと失敗時の振る舞いを定義する
+
+## トレーサビリティの確保
+
+要件からテストケースまでの追跡を可能にする。「この機能はどのテストで保証されているか」を常に回答可能にせよ。
+
+- **要件とテストケースのマッピング**: ユーザーストーリーの受入条件とテストケースを対応づける
+
+## 作成の進め方
+
+1. アーキテクチャドキュメント（バックエンド・フロントエンド）を確認する
+2. @docs/reference/テスト戦略ガイド.md を読み込む
+3. テスト形状→テストレベル→カバレッジ目標→ツール選定の順に策定する
+4. `docs/design/test_strategy.md` として出力する
+
+## 途中から再開する場合
+
+既存の `docs/design/test_strategy.md` がある場合は、まずその内容を確認する。不足しているテストレベルの定義や更新が必要な部分のみを修正する。
+
+**Example:**
+
+```
+ユーザー: 「テスト形状はピラミッド型に決めた。カバレッジ目標を設定したい」
+回答: 既存の test_strategy.md のテスト形状を確認し、
+      ピラミッド型に基づいてテストレベルごとのカバレッジ目標を設定する。
+      ユニット→統合→E2E の順に目標値と測定方法を定義する。
+```
+
+## 注意事項
+
+- アーキテクチャ設計が完了していることが前提。未完了でも進めて構わない
+- テスト戦略はアーキテクチャパターンに適合させる。パターンとの不整合は無駄なテストを生む
+- TDD/BDD の適用を検討し、開発プロセスとテスト戦略を一体化する
+- タスク項目（リスト）の前には空行を入れる（Markdown Lint 準拠）
+
+## 関連スキル
+
+- `orchestrating-analysis` — 分析フェーズ全体のワークフロー案内
+- `analyzing-architecture` — テスト形状選択の基盤となるアーキテクチャ設計
+- `analyzing-tech-stack` — テストツール選定との整合性
+- `analyzing-non-functional` — 性能テストの基準となる非機能要件

package/lib/assets/.claude/skills/analyzing-ui-design/SKILL.md

@@ -1,80 +1,80 @@
----
-name: analyzing-ui-design
-description: PlantUML を使用した画面遷移図・画面イメージ（salt 図）の作成と UI 設計を支援。「画面設計をしたい」「画面遷移図を作りたい」「UI を設計したい」「ワイヤーフレームを作りたい」「画面一覧を整理したい」といった場面で発動する。UI を先に設計することで、フロントエンド実装時の「画面が決まっていない」手戻りを防ぐ。
----
-
-# UI 設計
-
-PlantUML のステートチャート図（画面遷移）と salt 図（画面イメージ）を使用して UI を設計する。
-
-UI 設計はユーザーとシステムの接点を定義する活動。ユースケースが「何ができるか」を定義するのに対し、UI 設計は「どのように操作するか」を定義する。画面遷移と画面レイアウトを先に決めることで、フロントエンド実装の方向性が確定する。
-
-## 参照ドキュメントとテンプレート
-
-| 種類 | パス | 備考 |
-|------|------|------|
-| ガイド | @docs/reference/UI設計ガイド.md | UI 設計の進め方詳細 |
-| テンプレート | @docs/template/設計.md | 編集禁止。コピーして使用する |
-| 入力 | @docs/requirements/requirements_definition.md | 要件定義 |
-| 入力 | @docs/requirements/business_usecase.md | ビジネスユースケース |
-| 入力 | @docs/requirements/system_usecase.md | システムユースケース |
-| 入力 | @docs/requirements/user_story.md | ユーザーストーリー |
-| 入力 | @docs/design/architecture_backend.md | バックエンドアーキテクチャ |
-| 入力 | @docs/design/architecture_frontend.md | フロントエンドアーキテクチャ |
-| 成果物 | `docs/design/ui_design.md` | UI 設計 |
-
-## 画面一覧作成
-
-ユースケースから必要な画面を網羅的に識別する。画面の漏れはフロントエンド実装の後半で発覚しやすいため、この段階で徹底的に洗い出せ。
-
-- **ユースケースからの画面識別**: 各ユースケースのアクターが操作する画面を列挙する
-- **画面の目的と機能の定義**: 各画面で「何を見る」「何を操作する」を明確にする
-
-## 画面遷移図作成
-
-PlantUML のステートチャート図を使用して画面間の遷移を定義する。遷移条件（ボタンクリック、バリデーション成功等）を必ず明記せよ。
-
-## 画面イメージ作成
-
-PlantUML の salt 図を使用して画面レイアウトを定義する。入力項目・ボタン・表示項目の配置を決定する。ピクセル単位の精度は不要だが、情報の優先順位とグルーピングを正確に表現せよ。
-
-## インタラクション設計
-
-ユーザー操作フローとシステムのフィードバックを定義する。エラー時のユーザー体験は正常時以上に重要。
-
-- **ユーザー操作フローの定義**: 主要な操作シナリオをステップバイステップで記述する
-- **エラー処理・フィードバックの設計**: バリデーションエラー、通信エラー、タイムアウト時の表示と回復方法を定義する
-
-## 作成の進め方
-
-1. 入力ドキュメント（ユーザーストーリー、フロントエンドアーキテクチャ）を確認する
-2. @docs/reference/UI設計ガイド.md を読み込む
-3. 画面一覧→画面遷移図→画面イメージ→インタラクション設計の順に作成する
-4. `docs/design/ui_design.md` として出力する
-
-## 途中から再開する場合
-
-既存の `docs/design/ui_design.md` がある場合は、まずその内容を確認する。不足している画面や更新が必要な遷移のみを修正する。
-
-**Example:**
-
-```
-ユーザー: 「画面一覧は作った。画面遷移図を作りたい」
-回答: 既存の ui_design.md の画面一覧を確認し、
-      各画面間の遷移を PlantUML ステートチャート図で定義する。
-      遷移条件（ボタン操作・バリデーション結果）を明記する。
-```
-
-## 注意事項
-
-- 要件定義とユースケースが完了していることが前提。未完了でも進めて構わない
-- 画面遷移には PlantUML のステートチャート図、画面イメージには PlantUML の salt 図を使用する
-- ユーザビリティを考慮し、一貫性のある UI を設計する。操作パターンの統一が使いやすさの基本
-- タスク項目（リスト）の前には空行を入れる（Markdown Lint 準拠）
-
-## 関連スキル
-
-- `orchestrating-analysis` — 分析フェーズ全体のワークフロー案内
-- `analyzing-usecases` — 入力となるユースケース・ユーザーストーリー
-- `analyzing-architecture` — フロントエンドアーキテクチャとの整合性
-- `developing-frontend` — 後続のフロントエンド TDD 実装
+---
+name: analyzing-ui-design
+description: PlantUML を使用した画面遷移図・画面イメージ（salt 図）の作成と UI 設計を支援。「画面設計をしたい」「画面遷移図を作りたい」「UI を設計したい」「ワイヤーフレームを作りたい」「画面一覧を整理したい」といった場面で発動する。UI を先に設計することで、フロントエンド実装時の「画面が決まっていない」手戻りを防ぐ。
+---
+
+# UI 設計
+
+PlantUML のステートチャート図（画面遷移）と salt 図（画面イメージ）を使用して UI を設計する。
+
+UI 設計はユーザーとシステムの接点を定義する活動。ユースケースが「何ができるか」を定義するのに対し、UI 設計は「どのように操作するか」を定義する。画面遷移と画面レイアウトを先に決めることで、フロントエンド実装の方向性が確定する。
+
+## 参照ドキュメントとテンプレート
+
+| 種類 | パス | 備考 |
+|------|------|------|
+| ガイド | @docs/reference/UI設計ガイド.md | UI 設計の進め方詳細 |
+| テンプレート | @docs/template/設計.md | 編集禁止。コピーして使用する |
+| 入力 | @docs/requirements/requirements_definition.md | 要件定義 |
+| 入力 | @docs/requirements/business_usecase.md | ビジネスユースケース |
+| 入力 | @docs/requirements/system_usecase.md | システムユースケース |
+| 入力 | @docs/requirements/user_story.md | ユーザーストーリー |
+| 入力 | @docs/design/architecture_backend.md | バックエンドアーキテクチャ |
+| 入力 | @docs/design/architecture_frontend.md | フロントエンドアーキテクチャ |
+| 成果物 | `docs/design/ui_design.md` | UI 設計 |
+
+## 画面一覧作成
+
+ユースケースから必要な画面を網羅的に識別する。画面の漏れはフロントエンド実装の後半で発覚しやすいため、この段階で徹底的に洗い出せ。
+
+- **ユースケースからの画面識別**: 各ユースケースのアクターが操作する画面を列挙する
+- **画面の目的と機能の定義**: 各画面で「何を見る」「何を操作する」を明確にする
+
+## 画面遷移図作成
+
+PlantUML のステートチャート図を使用して画面間の遷移を定義する。遷移条件（ボタンクリック、バリデーション成功等）を必ず明記せよ。
+
+## 画面イメージ作成
+
+PlantUML の salt 図を使用して画面レイアウトを定義する。入力項目・ボタン・表示項目の配置を決定する。ピクセル単位の精度は不要だが、情報の優先順位とグルーピングを正確に表現せよ。
+
+## インタラクション設計
+
+ユーザー操作フローとシステムのフィードバックを定義する。エラー時のユーザー体験は正常時以上に重要。
+
+- **ユーザー操作フローの定義**: 主要な操作シナリオをステップバイステップで記述する
+- **エラー処理・フィードバックの設計**: バリデーションエラー、通信エラー、タイムアウト時の表示と回復方法を定義する
+
+## 作成の進め方
+
+1. 入力ドキュメント（ユーザーストーリー、フロントエンドアーキテクチャ）を確認する
+2. @docs/reference/UI設計ガイド.md を読み込む
+3. 画面一覧→画面遷移図→画面イメージ→インタラクション設計の順に作成する
+4. `docs/design/ui_design.md` として出力する
+
+## 途中から再開する場合
+
+既存の `docs/design/ui_design.md` がある場合は、まずその内容を確認する。不足している画面や更新が必要な遷移のみを修正する。
+
+**Example:**
+
+```
+ユーザー: 「画面一覧は作った。画面遷移図を作りたい」
+回答: 既存の ui_design.md の画面一覧を確認し、
+      各画面間の遷移を PlantUML ステートチャート図で定義する。
+      遷移条件（ボタン操作・バリデーション結果）を明記する。
+```
+
+## 注意事項
+
+- 要件定義とユースケースが完了していることが前提。未完了でも進めて構わない
+- 画面遷移には PlantUML のステートチャート図、画面イメージには PlantUML の salt 図を使用する
+- ユーザビリティを考慮し、一貫性のある UI を設計する。操作パターンの統一が使いやすさの基本
+- タスク項目（リスト）の前には空行を入れる（Markdown Lint 準拠）
+
+## 関連スキル
+
+- `orchestrating-analysis` — 分析フェーズ全体のワークフロー案内
+- `analyzing-usecases` — 入力となるユースケース・ユーザーストーリー
+- `analyzing-architecture` — フロントエンドアーキテクチャとの整合性
+- `developing-frontend` — 後続のフロントエンド TDD 実装

package/lib/assets/.claude/skills/analyzing-usecases/SKILL.md

@@ -1,72 +1,72 @@
----
-name: analyzing-usecases
-description: 要件定義からユースケースとユーザーストーリーを体系的に作成。ビジネスユースケース→システムユースケース→ユーザーストーリーの順に導出し、トレーサビリティを維持する。「ユースケースを作成したい」「ユーザーストーリーを書きたい」「要件定義からストーリーを導出したい」「受け入れ基準を定義したい」といった場面で発動する。ユースケースとストーリーを構造的に紐づけることで、開発フェーズでの「なぜこの機能を作るのか」が常に追跡可能になる。
----
-
-# ユースケース・ユーザーストーリー作成
-
-要件定義からユースケースを抽出し、ユーザーストーリーまで一貫したトレーサビリティを維持しながら作成する。
-
-ビジネスユースケース→システムユースケース→ユーザーストーリーの 3 段階で具体化することで、「ビジネス要求」と「実装タスク」の間の論理的なつながりを保証する。
-
-## 参照ドキュメントとテンプレート
-
-| 種類 | パス | 備考 |
-|------|------|------|
-| ガイド | @docs/reference/ユースケース作成ガイド.md | ユースケース作成の進め方詳細 |
-| テンプレート | @docs/template/完全形式のユースケース.md | 編集禁止。参照のみ |
-| 入力 | @docs/requirements/requirements_definition.md | 要件定義 |
-| 成果物 | `docs/requirements/business_usecase.md` | ビジネスユースケース |
-| 成果物 | `docs/requirements/system_usecase.md` | システムユースケース |
-| 成果物 | `docs/requirements/user_story.md` | ユーザーストーリー |
-
-## 作成の 3 ステップ
-
-### ステップ 1: ビジネスユースケース作成
-
-要件定義からビジネスレベルのユースケースを抽出する。システムの詳細には踏み込まず、業務目標とアクターの関係を定義する。
-
-- 要件定義のシステム外部環境（層 2）を起点にアクターとユースケースを識別する
-- アクターとユースケースの関係を PlantUML で図示する
-
-### ステップ 2: システムユースケース作成
-
-ビジネスユースケースをシステム境界の視点で詳細化する。「システムが何を提供するか」を明確にする。
-
-- ビジネスユースケースの各項目をシステムレベルに分解する
-- システム境界を明確にし、テンプレートの完全形式で記述する
-
-### ステップ 3: ユーザーストーリー作成
-
-システムユースケースから開発可能な粒度のユーザーストーリーを導出する。
-
-- 「〜として、〜したい。なぜなら〜だからだ」の形式で記述する
-- 各ストーリーに受け入れ基準を定義する
-- ユースケースとの対応関係を明記してトレーサビリティを確保する
-
-## 途中から再開・更新
-
-既存の成果物がある場合は、まず現在の状態を確認する。不足しているステップや更新が必要な部分のみを修正する。
-
-**Example:**
-
-```
-ユーザー: 「ビジネスユースケースは作った。ユーザーストーリーを書きたい」
-回答: ステップ 2（システムユースケース）の存在を確認する。
-      未作成ならステップ 2 から開始。作成済みならステップ 3 に進む。
-      既存のビジネスユースケースのアクターとユースケースを起点に、
-      システムユースケースを詳細化してからユーザーストーリーを導出する。
-```
-
-## 注意事項
-
-- 入力の `requirements_definition.md` が存在しない場合は `analyzing-requirements` を先に実行する
-- テンプレートは編集禁止。参照のみとし、成果物は別ファイルに作成する
-- `user_story.md` にはユーザーストーリーのみ記述する。リリース計画・イテレーション計画は `planning-releases` で別途作成する
-- タスク項目（リスト）の前には空行を入れる（Markdown Lint 準拠）
-
-## 関連スキル
-
-- `analyzing-requirements` — 前段の要件定義（RDRA 2.0）
-- `planning-releases` — 後続のリリース・イテレーション計画
-- `orchestrating-analysis` — 分析フェーズ全体のワークフロー案内
+---
+name: analyzing-usecases
+description: 要件定義からユースケースとユーザーストーリーを体系的に作成。ビジネスユースケース→システムユースケース→ユーザーストーリーの順に導出し、トレーサビリティを維持する。「ユースケースを作成したい」「ユーザーストーリーを書きたい」「要件定義からストーリーを導出したい」「受け入れ基準を定義したい」といった場面で発動する。ユースケースとストーリーを構造的に紐づけることで、開発フェーズでの「なぜこの機能を作るのか」が常に追跡可能になる。
+---
+
+# ユースケース・ユーザーストーリー作成
+
+要件定義からユースケースを抽出し、ユーザーストーリーまで一貫したトレーサビリティを維持しながら作成する。
+
+ビジネスユースケース→システムユースケース→ユーザーストーリーの 3 段階で具体化することで、「ビジネス要求」と「実装タスク」の間の論理的なつながりを保証する。
+
+## 参照ドキュメントとテンプレート
+
+| 種類 | パス | 備考 |
+|------|------|------|
+| ガイド | @docs/reference/ユースケース作成ガイド.md | ユースケース作成の進め方詳細 |
+| テンプレート | @docs/template/完全形式のユースケース.md | 編集禁止。参照のみ |
+| 入力 | @docs/requirements/requirements_definition.md | 要件定義 |
+| 成果物 | `docs/requirements/business_usecase.md` | ビジネスユースケース |
+| 成果物 | `docs/requirements/system_usecase.md` | システムユースケース |
+| 成果物 | `docs/requirements/user_story.md` | ユーザーストーリー |
+
+## 作成の 3 ステップ
+
+### ステップ 1: ビジネスユースケース作成
+
+要件定義からビジネスレベルのユースケースを抽出する。システムの詳細には踏み込まず、業務目標とアクターの関係を定義する。
+
+- 要件定義のシステム外部環境（層 2）を起点にアクターとユースケースを識別する
+- アクターとユースケースの関係を PlantUML で図示する
+
+### ステップ 2: システムユースケース作成
+
+ビジネスユースケースをシステム境界の視点で詳細化する。「システムが何を提供するか」を明確にする。
+
+- ビジネスユースケースの各項目をシステムレベルに分解する
+- システム境界を明確にし、テンプレートの完全形式で記述する
+
+### ステップ 3: ユーザーストーリー作成
+
+システムユースケースから開発可能な粒度のユーザーストーリーを導出する。
+
+- 「〜として、〜したい。なぜなら〜だからだ」の形式で記述する
+- 各ストーリーに受け入れ基準を定義する
+- ユースケースとの対応関係を明記してトレーサビリティを確保する
+
+## 途中から再開・更新
+
+既存の成果物がある場合は、まず現在の状態を確認する。不足しているステップや更新が必要な部分のみを修正する。
+
+**Example:**
+
+```
+ユーザー: 「ビジネスユースケースは作った。ユーザーストーリーを書きたい」
+回答: ステップ 2（システムユースケース）の存在を確認する。
+      未作成ならステップ 2 から開始。作成済みならステップ 3 に進む。
+      既存のビジネスユースケースのアクターとユースケースを起点に、
+      システムユースケースを詳細化してからユーザーストーリーを導出する。
+```
+
+## 注意事項
+
+- 入力の `requirements_definition.md` が存在しない場合は `analyzing-requirements` を先に実行する
+- テンプレートは編集禁止。参照のみとし、成果物は別ファイルに作成する
+- `user_story.md` にはユーザーストーリーのみ記述する。リリース計画・イテレーション計画は `planning-releases` で別途作成する
+- タスク項目（リスト）の前には空行を入れる（Markdown Lint 準拠）
+
+## 関連スキル
+
+- `analyzing-requirements` — 前段の要件定義（RDRA 2.0）
+- `planning-releases` — 後続のリリース・イテレーション計画
+- `orchestrating-analysis` — 分析フェーズ全体のワークフロー案内

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

@@ -0,0 +1,129 @@
+---
+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）が含まれる。ローカル緑だけでは不十分で、CI が緑であって初めて品質ゲートを通過とみなす。
+
+### ステップ 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`）
+- カバレッジを計測し目標との差分を把握する（`operating-qt` の SonarQube 品質ゲート、または `cargo llvm-cov`）
+- ゲートを通らない場合はクローズを止め、修正してから再度ここに戻る
+- **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 が緑に戻ることを確認してからクローズを確定する
+
+### ステップ 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 と同じ `+stable` ツールチェーンで確認）・カバレッジ把握
+- [ ] **CI が緑**（`gh run list` で対象ブランチの最新実行が success・赤なら修正して再確認）
+- [ ] `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（`@stable`）より古いと、新しい clippy lint がローカルをすり抜けて CI だけ赤になる。クローズ確定前に `gh run` で CI の実結果を必ず確認し、赤なら緑に戻す
+- **正直さを優先する**: 未達・スコープ調整・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` — 各ステップ成果のコミット