@k2works/claude-code-booster 4.12.0 → 4.14.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` — 分析フェーズ全体のワークフロー案内