@k2works/claude-code-booster 3.4.1 → 3.6.0

package/lib/assets/.claude/skills/analyzing-non-functional/SKILL.md

@@ -1,95 +1,95 @@
----
-name: analyzing-non-functional
-description: 性能、セキュリティ、可用性、保守性、拡張性の非機能要件を測定可能な形で定義。「非機能要件を定義したい」「SLA を決めたい」「セキュリティ要件を整理したい」「性能目標を設定したい」「可用性の目標を決めたい」といった場面で発動する。非機能要件を事前に定義することで、リリース後の「遅い」「落ちる」「危ない」を防ぐ。
----
-
-# 非機能要件定義
-
-性能、セキュリティ、可用性、保守性、拡張性の非機能要件を測定可能な形で定義する。
-
-非機能要件は「システムがどう振る舞うべきか」を定義する。機能要件だけでシステムを作ると、性能劣化・セキュリティ脆弱性・障害時の長時間停止といった問題が本番で初めて発覚する。数値目標を先に定めることで、アーキテクチャ選定とテスト戦略に明確な基準を与える。
-
-## 参照ドキュメントとテンプレート
-
-| 種類 | パス | 備考 |
-|------|------|------|
-| ガイド | @docs/reference/非機能要件定義ガイド.md | 非機能要件定義の進め方詳細 |
-| テンプレート | @docs/template/設計.md | 編集禁止。コピーして使用する |
-| 入力 | @docs/requirements/requirements_definition.md | 要件定義 |
-| 入力 | @docs/design/architecture_backend.md | バックエンドアーキテクチャ |
-| 入力 | @docs/design/architecture_frontend.md | フロントエンドアーキテクチャ |
-| 入力 | @docs/design/architecture_infrastructure.md | インフラストラクチャアーキテクチャ |
-| 成果物 | `docs/design/non_functional.md` | 非機能要件定義 |
-
-## 性能要件
-
-ユーザー体験に直結する指標を定義する。曖昧な「速い」ではなく、具体的な数値で定義せよ。
-
-- **レスポンスタイム**: 画面操作ごとの応答時間目標（p50/p95/p99）を設定する
-- **スループット**: 単位時間あたりの処理件数を定義する
-- **同時接続数**: ピーク時の同時接続ユーザー数を見積もる
-
-## セキュリティ要件
-
-守るべき資産とリスクに応じたセキュリティ対策を定義する。過剰防衛はコストの無駄、過小防衛はインシデントの元。
-
-- **認証・認可**: 認証方式（OAuth2、SAML 等）と認可モデル（RBAC、ABAC 等）を決定する
-- **データ暗号化**: 通信経路と保存データの暗号化方式を定義する
-- **監査ログ**: 誰が・いつ・何をしたかを追跡可能にする
-
-## 可用性要件
-
-ビジネスインパクトに応じた稼働目標を設定する。99.9% と 99.99% ではコストが桁違いになることを意識せよ。
-
-- **稼働率目標**: SLA として定義する稼働率を設定する
-- **障害復旧時間（RTO）**: 障害発生からサービス復旧までの目標時間を設定する
-- **データ復旧時点（RPO）**: データ損失の許容範囲を設定する
-
-## 保守性要件
-
-運用チームが日常的に必要とする機能を定義する。
-
-- **ログ出力**: ログレベル・出力先・保持期間を定義する
-- **監視項目**: メトリクス収集の対象と閾値を設定する
-- **アラート設定**: 通知先と重要度レベルを定義する
-
-## 拡張性要件
-
-将来のスケールに備えた設計指針を定義する。
-
-- **スケーラビリティ**: 水平/垂直スケーリングの方針を定める
-- **将来の拡張性**: 想定される拡張シナリオと対応方針を記載する
-
-## 作成の進め方
-
-1. 入力ドキュメント（要件定義、アーキテクチャ設計）を確認する
-2. @docs/reference/非機能要件定義ガイド.md を読み込む
-3. 各カテゴリの非機能要件を測定可能な数値で定義する
-4. `docs/design/non_functional.md` として出力する
-
-## 途中から再開する場合
-
-既存の `docs/design/non_functional.md` がある場合は、まずその内容を確認する。不足しているカテゴリや数値の見直しが必要な部分のみを修正する。
-
-**Example:**
-
-```
-ユーザー: 「性能要件は定義した。セキュリティ要件を整理したい」
-回答: 既存の non_functional.md の性能要件を確認し、
-      セキュリティ要件の定義に進む。認証・認可方式、
-      暗号化方式、監査ログの要件を具体的な数値・方式で定義する。
-```
-
-## 注意事項
-
-- 機能要件とアーキテクチャ設計が完了していることが前提。未完了でも進めて構わない
-- 非機能要件は必ず測定可能な形で定義する。「高速であること」ではなく「p95 で 200ms 以内」のように書け
-- SLA/SLO を明確に定義し、ビジネス側との合意を取る前提で記載する
-- タスク項目（リスト）の前には空行を入れる（Markdown Lint 準拠）
-
-## 関連スキル
-
-- `orchestrating-analysis` — 分析フェーズ全体のワークフロー案内
-- `analyzing-architecture` — 前段のアーキテクチャ設計
-- `analyzing-operation` — 後続の運用要件定義（非機能要件が入力になる）
-- `analyzing-test-strategy` — 後続のテスト戦略（性能テストの基準になる）
+---
+name: analyzing-non-functional
+description: 性能、セキュリティ、可用性、保守性、拡張性の非機能要件を測定可能な形で定義。「非機能要件を定義したい」「SLA を決めたい」「セキュリティ要件を整理したい」「性能目標を設定したい」「可用性の目標を決めたい」といった場面で発動する。非機能要件を事前に定義することで、リリース後の「遅い」「落ちる」「危ない」を防ぐ。
+---
+
+# 非機能要件定義
+
+性能、セキュリティ、可用性、保守性、拡張性の非機能要件を測定可能な形で定義する。
+
+非機能要件は「システムがどう振る舞うべきか」を定義する。機能要件だけでシステムを作ると、性能劣化・セキュリティ脆弱性・障害時の長時間停止といった問題が本番で初めて発覚する。数値目標を先に定めることで、アーキテクチャ選定とテスト戦略に明確な基準を与える。
+
+## 参照ドキュメントとテンプレート
+
+| 種類 | パス | 備考 |
+|------|------|------|
+| ガイド | @docs/reference/非機能要件定義ガイド.md | 非機能要件定義の進め方詳細 |
+| テンプレート | @docs/template/設計.md | 編集禁止。コピーして使用する |
+| 入力 | @docs/requirements/requirements_definition.md | 要件定義 |
+| 入力 | @docs/design/architecture_backend.md | バックエンドアーキテクチャ |
+| 入力 | @docs/design/architecture_frontend.md | フロントエンドアーキテクチャ |
+| 入力 | @docs/design/architecture_infrastructure.md | インフラストラクチャアーキテクチャ |
+| 成果物 | `docs/design/non_functional.md` | 非機能要件定義 |
+
+## 性能要件
+
+ユーザー体験に直結する指標を定義する。曖昧な「速い」ではなく、具体的な数値で定義せよ。
+
+- **レスポンスタイム**: 画面操作ごとの応答時間目標（p50/p95/p99）を設定する
+- **スループット**: 単位時間あたりの処理件数を定義する
+- **同時接続数**: ピーク時の同時接続ユーザー数を見積もる
+
+## セキュリティ要件
+
+守るべき資産とリスクに応じたセキュリティ対策を定義する。過剰防衛はコストの無駄、過小防衛はインシデントの元。
+
+- **認証・認可**: 認証方式（OAuth2、SAML 等）と認可モデル（RBAC、ABAC 等）を決定する
+- **データ暗号化**: 通信経路と保存データの暗号化方式を定義する
+- **監査ログ**: 誰が・いつ・何をしたかを追跡可能にする
+
+## 可用性要件
+
+ビジネスインパクトに応じた稼働目標を設定する。99.9% と 99.99% ではコストが桁違いになることを意識せよ。
+
+- **稼働率目標**: SLA として定義する稼働率を設定する
+- **障害復旧時間（RTO）**: 障害発生からサービス復旧までの目標時間を設定する
+- **データ復旧時点（RPO）**: データ損失の許容範囲を設定する
+
+## 保守性要件
+
+運用チームが日常的に必要とする機能を定義する。
+
+- **ログ出力**: ログレベル・出力先・保持期間を定義する
+- **監視項目**: メトリクス収集の対象と閾値を設定する
+- **アラート設定**: 通知先と重要度レベルを定義する
+
+## 拡張性要件
+
+将来のスケールに備えた設計指針を定義する。
+
+- **スケーラビリティ**: 水平/垂直スケーリングの方針を定める
+- **将来の拡張性**: 想定される拡張シナリオと対応方針を記載する
+
+## 作成の進め方
+
+1. 入力ドキュメント（要件定義、アーキテクチャ設計）を確認する
+2. @docs/reference/非機能要件定義ガイド.md を読み込む
+3. 各カテゴリの非機能要件を測定可能な数値で定義する
+4. `docs/design/non_functional.md` として出力する
+
+## 途中から再開する場合
+
+既存の `docs/design/non_functional.md` がある場合は、まずその内容を確認する。不足しているカテゴリや数値の見直しが必要な部分のみを修正する。
+
+**Example:**
+
+```
+ユーザー: 「性能要件は定義した。セキュリティ要件を整理したい」
+回答: 既存の non_functional.md の性能要件を確認し、
+      セキュリティ要件の定義に進む。認証・認可方式、
+      暗号化方式、監査ログの要件を具体的な数値・方式で定義する。
+```
+
+## 注意事項
+
+- 機能要件とアーキテクチャ設計が完了していることが前提。未完了でも進めて構わない
+- 非機能要件は必ず測定可能な形で定義する。「高速であること」ではなく「p95 で 200ms 以内」のように書け
+- SLA/SLO を明確に定義し、ビジネス側との合意を取る前提で記載する
+- タスク項目（リスト）の前には空行を入れる（Markdown Lint 準拠）
+
+## 関連スキル
+
+- `orchestrating-analysis` — 分析フェーズ全体のワークフロー案内
+- `analyzing-architecture` — 前段のアーキテクチャ設計
+- `analyzing-operation` — 後続の運用要件定義（非機能要件が入力になる）
+- `analyzing-test-strategy` — 後続のテスト戦略（性能テストの基準になる）

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

@@ -1,95 +1,95 @@
----
-name: analyzing-operation
-description: 運用フロー、監視設計、バックアップ、障害対応、変更管理の運用要件を定義。「運用要件を定義したい」「監視設計をしたい」「障害対応手順を作りたい」「バックアップ方針を決めたい」「運用フローを整理したい」といった場面で発動する。運用要件を事前に設計することで、本番稼働後の「運用できない」問題を防ぐ。
----
-
-# 運用要件定義
-
-運用フロー、監視、バックアップ、障害対応、変更管理の運用要件を定義する。
-
-運用はシステムのライフサイクルの中で最も長い期間を占める。開発時に運用を考慮しないと、リリース後に「監視がない」「復旧手順がない」「変更のたびにダウンタイムが発生する」といった問題が噴出する。運用設計は「作った後どう維持するか」を先に決める活動。
-
-## 参照ドキュメントとテンプレート
-
-| 種類 | パス | 備考 |
-|------|------|------|
-| ガイド | @docs/reference/運用要件定義ガイド.md | 運用要件定義の進め方詳細 |
-| テンプレート | @docs/template/設計.md | 編集禁止。コピーして使用する |
-| 入力 | @docs/requirements/requirements_definition.md | 要件定義 |
-| 入力 | @docs/design/architecture_infrastructure.md | インフラストラクチャアーキテクチャ |
-| 入力 | @docs/design/non_functional.md | 非機能要件定義 |
-| 成果物 | `docs/design/operation.md` | 運用要件定義 |
-
-## 運用フロー設計
-
-定常運用を自動化前提で設計する。手動運用が多いほど人的ミスのリスクが上がる。
-
-- **日次運用**: ログローテーション、バッチ処理、ヘルスチェックなど
-- **月次運用**: セキュリティパッチ適用、容量管理、レポート生成など
-- **年次運用**: ライセンス更新、DR テスト、監査対応など
-
-## 監視設計
-
-SLA/SLO を満たすために必要な監視を設計する。アラート疲れを防ぐため、本当に対応が必要なアラートのみを設定せよ。
-
-- **監視項目の定義**: CPU、メモリ、ディスク、レスポンスタイム、エラー率など
-- **アラート閾値の設定**: Warning/Critical の閾値を非機能要件の数値に基づいて設定する
-- **エスカレーションフロー**: アラート重要度に応じた通知先と対応フローを定義する
-
-## バックアップ設計
-
-RPO（データ復旧時点）を満たすバックアップ方式を設計する。リストア手順のテストまでがバックアップ設計。
-
-- **バックアップ方式**: フルバックアップ/差分バックアップ/増分バックアップの組み合わせを決定する
-- **バックアップスケジュール**: RPO に基づいた頻度を設定する
-- **リストア手順**: 復旧手順を文書化し、定期的にテストする
-
-## 障害対応設計
-
-RTO（障害復旧時間）を満たす復旧手順を設計する。障害時にゼロから考えるのは最悪のパターン。
-
-- **障害検知方法**: 自動検知の仕組みとその精度を定義する
-- **復旧手順**: 障害パターンごとの復旧手順を事前に文書化する
-- **連絡体制**: オンコール体制とエスカレーションパスを定義する
-
-## 変更管理設計
-
-本番環境への変更を安全に行うための手順を設計する。ロールバック手順がないリリースは許可するな。
-
-- **リリース手順**: デプロイの自動化手順を定義する
-- **ロールバック手順**: 問題発生時の切り戻し手順を事前に準備する
-- **変更承認フロー**: 変更の影響範囲に応じた承認プロセスを定義する
-
-## 作成の進め方
-
-1. 入力ドキュメント（非機能要件、インフラアーキテクチャ）を確認する
-2. @docs/reference/運用要件定義ガイド.md を読み込む
-3. 運用フロー→監視→バックアップ→障害対応→変更管理の順に設計する
-4. `docs/design/operation.md` として出力する
-
-## 途中から再開する場合
-
-既存の `docs/design/operation.md` がある場合は、まずその内容を確認する。不足している運用領域や更新が必要な手順のみを修正する。
-
-**Example:**
-
-```
-ユーザー: 「監視設計はできた。障害対応手順を作りたい」
-回答: 既存の operation.md の監視設計を確認し、
-      監視で検知されるアラートに対応する障害対応手順を設計する。
-      障害パターンの分類→復旧手順→連絡体制の順で作成する。
-```
-
-## 注意事項
-
-- 非機能要件とインフラアーキテクチャが完了していることが前提。未完了でも進めて構わない
-- 運用手順は自動化を前提に設計する。IaC（Infrastructure as Code）を活用し、手動手順を最小化せよ
-- リストア手順とロールバック手順は必ずテスト可能な形で文書化する
-- タスク項目（リスト）の前には空行を入れる（Markdown Lint 準拠）
-
-## 関連スキル
-
-- `orchestrating-analysis` — 分析フェーズ全体のワークフロー案内
-- `analyzing-non-functional` — 前段の非機能要件定義（SLA/SLO が入力）
-- `analyzing-architecture` — インフラアーキテクチャが運用設計の基盤
-- `managing-operations` — 開発フェーズでの実際の環境構築・デプロイ
+---
+name: analyzing-operation
+description: 運用フロー、監視設計、バックアップ、障害対応、変更管理の運用要件を定義。「運用要件を定義したい」「監視設計をしたい」「障害対応手順を作りたい」「バックアップ方針を決めたい」「運用フローを整理したい」といった場面で発動する。運用要件を事前に設計することで、本番稼働後の「運用できない」問題を防ぐ。
+---
+
+# 運用要件定義
+
+運用フロー、監視、バックアップ、障害対応、変更管理の運用要件を定義する。
+
+運用はシステムのライフサイクルの中で最も長い期間を占める。開発時に運用を考慮しないと、リリース後に「監視がない」「復旧手順がない」「変更のたびにダウンタイムが発生する」といった問題が噴出する。運用設計は「作った後どう維持するか」を先に決める活動。
+
+## 参照ドキュメントとテンプレート
+
+| 種類 | パス | 備考 |
+|------|------|------|
+| ガイド | @docs/reference/運用要件定義ガイド.md | 運用要件定義の進め方詳細 |
+| テンプレート | @docs/template/設計.md | 編集禁止。コピーして使用する |
+| 入力 | @docs/requirements/requirements_definition.md | 要件定義 |
+| 入力 | @docs/design/architecture_infrastructure.md | インフラストラクチャアーキテクチャ |
+| 入力 | @docs/design/non_functional.md | 非機能要件定義 |
+| 成果物 | `docs/design/operation.md` | 運用要件定義 |
+
+## 運用フロー設計
+
+定常運用を自動化前提で設計する。手動運用が多いほど人的ミスのリスクが上がる。
+
+- **日次運用**: ログローテーション、バッチ処理、ヘルスチェックなど
+- **月次運用**: セキュリティパッチ適用、容量管理、レポート生成など
+- **年次運用**: ライセンス更新、DR テスト、監査対応など
+
+## 監視設計
+
+SLA/SLO を満たすために必要な監視を設計する。アラート疲れを防ぐため、本当に対応が必要なアラートのみを設定せよ。
+
+- **監視項目の定義**: CPU、メモリ、ディスク、レスポンスタイム、エラー率など
+- **アラート閾値の設定**: Warning/Critical の閾値を非機能要件の数値に基づいて設定する
+- **エスカレーションフロー**: アラート重要度に応じた通知先と対応フローを定義する
+
+## バックアップ設計
+
+RPO（データ復旧時点）を満たすバックアップ方式を設計する。リストア手順のテストまでがバックアップ設計。
+
+- **バックアップ方式**: フルバックアップ/差分バックアップ/増分バックアップの組み合わせを決定する
+- **バックアップスケジュール**: RPO に基づいた頻度を設定する
+- **リストア手順**: 復旧手順を文書化し、定期的にテストする
+
+## 障害対応設計
+
+RTO（障害復旧時間）を満たす復旧手順を設計する。障害時にゼロから考えるのは最悪のパターン。
+
+- **障害検知方法**: 自動検知の仕組みとその精度を定義する
+- **復旧手順**: 障害パターンごとの復旧手順を事前に文書化する
+- **連絡体制**: オンコール体制とエスカレーションパスを定義する
+
+## 変更管理設計
+
+本番環境への変更を安全に行うための手順を設計する。ロールバック手順がないリリースは許可するな。
+
+- **リリース手順**: デプロイの自動化手順を定義する
+- **ロールバック手順**: 問題発生時の切り戻し手順を事前に準備する
+- **変更承認フロー**: 変更の影響範囲に応じた承認プロセスを定義する
+
+## 作成の進め方
+
+1. 入力ドキュメント（非機能要件、インフラアーキテクチャ）を確認する
+2. @docs/reference/運用要件定義ガイド.md を読み込む
+3. 運用フロー→監視→バックアップ→障害対応→変更管理の順に設計する
+4. `docs/design/operation.md` として出力する
+
+## 途中から再開する場合
+
+既存の `docs/design/operation.md` がある場合は、まずその内容を確認する。不足している運用領域や更新が必要な手順のみを修正する。
+
+**Example:**
+
+```
+ユーザー: 「監視設計はできた。障害対応手順を作りたい」
+回答: 既存の operation.md の監視設計を確認し、
+      監視で検知されるアラートに対応する障害対応手順を設計する。
+      障害パターンの分類→復旧手順→連絡体制の順で作成する。
+```
+
+## 注意事項
+
+- 非機能要件とインフラアーキテクチャが完了していることが前提。未完了でも進めて構わない
+- 運用手順は自動化を前提に設計する。IaC（Infrastructure as Code）を活用し、手動手順を最小化せよ
+- リストア手順とロールバック手順は必ずテスト可能な形で文書化する
+- タスク項目（リスト）の前には空行を入れる（Markdown Lint 準拠）
+
+## 関連スキル
+
+- `orchestrating-analysis` — 分析フェーズ全体のワークフロー案内
+- `analyzing-non-functional` — 前段の非機能要件定義（SLA/SLO が入力）
+- `analyzing-architecture` — インフラアーキテクチャが運用設計の基盤
+- `managing-operations` — 開発フェーズでの実際の環境構築・デプロイ

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

@@ -1,91 +1,91 @@
----
-name: analyzing-requirements
-description: RDRA 2.0 に基づく体系的な要件定義を支援。システム価値→外部環境→境界→内部構造の 4 層で要件を整理。「要件定義を始めたい」「システムの要求を整理したい」「RDRA で分析したい」「業務フローを整理したい」「システムコンテキストを作りたい」といった場面で発動する。要件を体系的に整理することで、開発フェーズでの「何を作ればいいかわからない」問題を防ぐ。
----
-
-# 要件定義
-
-RDRA 2.0（リレーションシップ駆動要件分析）に基づき、システム価値→外部環境→境界→内部構造の 4 層で要件を体系的に整理する。
-
-RDRA の価値は、要件を「何となくの要望リスト」ではなく「なぜそれが必要か」の根拠付きで構造化できること。各層の出力が次の層の入力になるため、トレーサビリティが自然に確保される。
-
-## 参照ドキュメントとテンプレート
-
-| 種類 | パス | 備考 |
-|------|------|------|
-| ガイド | @docs/reference/要件定義ガイド.md | RDRA 2.0 の進め方詳細 |
-| テンプレート | @docs/template/要件定義.md | 編集禁止。コピーして使用する |
-| 入力 | @docs/strategy/business_architecture.md | ビジネスアーキテクチャ分析書 |
-| 入力 | @docs/strategy/inception-deck.md | インセプションデッキ |
-| 成果物 | `docs/requirements/requirements_definition.md` | テンプレートを基に作成 |
-
-## RDRA の 4 層構造
-
-各層は上から下に向かって具体化されていく。上位層が曖昧だと下位層の定義がブレるため、この順序で進めることが重要。
-
-### 層 1: システム価値
-
-「なぜこのシステムが必要か」を明確にする。インセプションデッキの「なぜやるのか」をシステムの文脈で具体化する。
-
-- **システムコンテキスト図**: システムとアクター（人・外部システム）の関係を PlantUML で図示
-- **要求モデル**: ステークホルダーの要求を構造化して一覧化
-
-### 層 2: システム外部環境
-
-「どのような業務の中でシステムが使われるか」を整理する。ビジネスアーキテクチャ分析書のバリューストリームや組織マップが入力になる。
-
-- **ビジネスコンテキスト**: 業務の全体像とシステムの位置づけ
-- **ビジネスユースケース**: 業務レベルのユースケース識別
-- **業務フロー**: 業務プロセスの可視化（PlantUML アクティビティ図）
-- **利用シーン**: ユーザーがシステムを使う具体的な場面
-
-### 層 3: システム境界
-
-「システムの内と外の接点は何か」を定義する。外部環境の分析結果から、システムが担う範囲を確定する。
-
-- **ユースケース複合図**: システムユースケースとアクターの関係
-- **画面・帳票モデル**: ユーザーインターフェースの概要定義
-- **イベントモデル**: システムが受け取る・発信するイベント
-
-### 層 4: システム内部構造
-
-「システム内部でどのような情報をどう扱うか」を設計する。後続のデータモデル設計・ドメインモデル設計の基礎になる。
-
-- **情報モデル**: システムが扱う主要なエンティティとリレーション
-- **状態モデル**: 主要エンティティの状態遷移
-
-## 作成の進め方
-
-### 新規作成
-
-1. 入力ドキュメント（ビジネスアーキテクチャ分析書、インセプションデッキ）の有無を確認する。なければ基本情報をヒアリングする
-2. テンプレート（@docs/template/要件定義.md）を読み込む
-3. 層 1 から順に 4 層を作成する。各層で PlantUML を活用して視覚化する
-4. `docs/requirements/requirements_definition.md` として出力する
-
-### 途中から再開・更新
-
-既存の `docs/requirements/requirements_definition.md` がある場合は、まずその内容を確認する。不足している層や更新が必要な部分のみを修正する。
-
-**Example:**
-
-```
-ユーザー: 「システムコンテキストは作った。業務フローを整理したい」
-回答: 層 2（システム外部環境）の業務フロー作成に進む。
-      既存のシステムコンテキスト図のアクターを起点に、
-      各アクターの業務プロセスを PlantUML アクティビティ図で可視化する。
-```
-
-## 注意事項
-
-- 入力ドキュメントが未作成でも、プロジェクト情報から直接作成可能。完璧な入力を待つより進める方が効果的
-- テンプレートは編集禁止。コピーして成果物を作成する
-- 各層の成果物には PlantUML を活用し、テキストだけでなく図で表現する
-- タスク項目（リスト）の前には空行を入れる（Markdown Lint 準拠）
-
-## 関連スキル
-
-- `analyzing-business` — 前段のビジネスアーキテクチャ分析
-- `analyzing-inception-deck` — 前段のインセプションデッキ
-- `analyzing-usecases` — 後続のユースケース・ユーザーストーリー詳細化
-- `orchestrating-analysis` — 分析フェーズ全体のワークフロー案内
+---
+name: analyzing-requirements
+description: RDRA 2.0 に基づく体系的な要件定義を支援。システム価値→外部環境→境界→内部構造の 4 層で要件を整理。「要件定義を始めたい」「システムの要求を整理したい」「RDRA で分析したい」「業務フローを整理したい」「システムコンテキストを作りたい」といった場面で発動する。要件を体系的に整理することで、開発フェーズでの「何を作ればいいかわからない」問題を防ぐ。
+---
+
+# 要件定義
+
+RDRA 2.0（リレーションシップ駆動要件分析）に基づき、システム価値→外部環境→境界→内部構造の 4 層で要件を体系的に整理する。
+
+RDRA の価値は、要件を「何となくの要望リスト」ではなく「なぜそれが必要か」の根拠付きで構造化できること。各層の出力が次の層の入力になるため、トレーサビリティが自然に確保される。
+
+## 参照ドキュメントとテンプレート
+
+| 種類 | パス | 備考 |
+|------|------|------|
+| ガイド | @docs/reference/要件定義ガイド.md | RDRA 2.0 の進め方詳細 |
+| テンプレート | @docs/template/要件定義.md | 編集禁止。コピーして使用する |
+| 入力 | @docs/strategy/business_architecture.md | ビジネスアーキテクチャ分析書 |
+| 入力 | @docs/strategy/inception-deck.md | インセプションデッキ |
+| 成果物 | `docs/requirements/requirements_definition.md` | テンプレートを基に作成 |
+
+## RDRA の 4 層構造
+
+各層は上から下に向かって具体化されていく。上位層が曖昧だと下位層の定義がブレるため、この順序で進めることが重要。
+
+### 層 1: システム価値
+
+「なぜこのシステムが必要か」を明確にする。インセプションデッキの「なぜやるのか」をシステムの文脈で具体化する。
+
+- **システムコンテキスト図**: システムとアクター（人・外部システム）の関係を PlantUML で図示
+- **要求モデル**: ステークホルダーの要求を構造化して一覧化
+
+### 層 2: システム外部環境
+
+「どのような業務の中でシステムが使われるか」を整理する。ビジネスアーキテクチャ分析書のバリューストリームや組織マップが入力になる。
+
+- **ビジネスコンテキスト**: 業務の全体像とシステムの位置づけ
+- **ビジネスユースケース**: 業務レベルのユースケース識別
+- **業務フロー**: 業務プロセスの可視化（PlantUML アクティビティ図）
+- **利用シーン**: ユーザーがシステムを使う具体的な場面
+
+### 層 3: システム境界
+
+「システムの内と外の接点は何か」を定義する。外部環境の分析結果から、システムが担う範囲を確定する。
+
+- **ユースケース複合図**: システムユースケースとアクターの関係
+- **画面・帳票モデル**: ユーザーインターフェースの概要定義
+- **イベントモデル**: システムが受け取る・発信するイベント
+
+### 層 4: システム内部構造
+
+「システム内部でどのような情報をどう扱うか」を設計する。後続のデータモデル設計・ドメインモデル設計の基礎になる。
+
+- **情報モデル**: システムが扱う主要なエンティティとリレーション
+- **状態モデル**: 主要エンティティの状態遷移
+
+## 作成の進め方
+
+### 新規作成
+
+1. 入力ドキュメント（ビジネスアーキテクチャ分析書、インセプションデッキ）の有無を確認する。なければ基本情報をヒアリングする
+2. テンプレート（@docs/template/要件定義.md）を読み込む
+3. 層 1 から順に 4 層を作成する。各層で PlantUML を活用して視覚化する
+4. `docs/requirements/requirements_definition.md` として出力する
+
+### 途中から再開・更新
+
+既存の `docs/requirements/requirements_definition.md` がある場合は、まずその内容を確認する。不足している層や更新が必要な部分のみを修正する。
+
+**Example:**
+
+```
+ユーザー: 「システムコンテキストは作った。業務フローを整理したい」
+回答: 層 2（システム外部環境）の業務フロー作成に進む。
+      既存のシステムコンテキスト図のアクターを起点に、
+      各アクターの業務プロセスを PlantUML アクティビティ図で可視化する。
+```
+
+## 注意事項
+
+- 入力ドキュメントが未作成でも、プロジェクト情報から直接作成可能。完璧な入力を待つより進める方が効果的
+- テンプレートは編集禁止。コピーして成果物を作成する
+- 各層の成果物には PlantUML を活用し、テキストだけでなく図で表現する
+- タスク項目（リスト）の前には空行を入れる（Markdown Lint 準拠）
+
+## 関連スキル
+
+- `analyzing-business` — 前段のビジネスアーキテクチャ分析
+- `analyzing-inception-deck` — 前段のインセプションデッキ
+- `analyzing-usecases` — 後続のユースケース・ユーザーストーリー詳細化
+- `orchestrating-analysis` — 分析フェーズ全体のワークフロー案内