@k2works/claude-code-booster 1.13.0 → 2.0.0

package/lib/assets/.claude/skills/analyzing-inception-deck/SKILL.md

@@ -1,137 +1,84 @@
 ---
 name: analyzing-inception-deck
-description: インセプションデッキの作成を支援。プロジェクトの「なぜ」「何を」「どうやって」を 10 の問いで整理し、チーム全体の認識を揃える。プロジェクト立ち上げやインセプションデッキの作成・更新時に使用。
+description: インセプションデッキの作成を支援。プロジェクトの「なぜ」「何を」「どうやって」を 10 の問いで整理し、チーム全体の認識を揃える。「インセプションデッキを作りたい」「プロジェクトの方向性を整理したい」「10 の問いに答えたい」「チームの認識を揃えたい」「プロジェクトを立ち上げる」といった場面で発動する。プロジェクトの方向性を最初に揃えておくことで、後工程での手戻りを大幅に減らせる。
 ---
 
-# インセプションデッキ作成支援
+# インセプションデッキ作成
 
-プロジェクトの方向性・スコープ・リスク・トレードオフをチーム全体で共有するためのインセプションデッキを作成します。ビジネスアーキテクチャ分析書（`analyzing-business`）の成果物をもとに、10 の問いに回答する形式で整理します。
+プロジェクトの方向性・スコープ・リスク・トレードオフをチーム全体で共有するためのインセプションデッキを作成する。ビジネスアーキテクチャ分析書（`analyzing-business` の成果物）をもとに、10 の問いに回答する形式で整理する。
 
-## Instructions
+インセプションデッキは「チーム全員が同じ方向を向く」ための道具であり、完璧な計画書ではない。不明点は仮定を明記し、後続のステークホルダーレビューで検証する方が、分析を止めるより効果的。
 
-### 1. 参照ドキュメント
+## 参照ドキュメントとテンプレート
 
-- @docs/reference/開発ガイド.md - 開発ライフサイクルにおけるインセプションデッキの位置づけ
+| 種類 | パス | 備考 |
+|------|------|------|
+| ガイド | @docs/reference/開発ガイド.md | 開発ライフサイクルにおける位置づけ |
+| テンプレート | @docs/template/インセプションデッキ.md | 編集禁止。コピーして使用する |
+| 入力 | @docs/analysis/business_architecture.md | ビジネスアーキテクチャ分析書 |
+| 成果物 | `docs/analysis/inception-deck.md` | テンプレートを基に作成 |
 
-### 2. テンプレート
+## 10 の問いと情報源
 
-- @docs/template/インセプションデッキ.md - インセプションデッキテンプレート（**編集禁止**）
+ビジネスアーキテクチャ分析書から情報を抽出し、各問いに回答する。ビジネスアーキテクチャ分析書が未作成の場合は、プロジェクトの基本情報をヒアリングして直接回答する。
 
-### 3. 入力
+| # | 問い | 主な情報源 |
+|---|------|-----------|
+| 1 | なぜやるのか？ | ケイパビリティヒートマップの低成熟度領域、バリューストリームのボトルネック |
+| 2 | どんなビジョンなのか？ | ビジネスプリンシプル、ガイディングプリンシプル、価値提案 |
+| 3 | どんな価値をもたらすのか？ | ビジネスモデルキャンバスの価値提案・主要活動 |
+| 4 | スコープの範囲はどこか？ | バリューストリーム、ケイパビリティマップ、ビジネスシナリオ |
+| 5 | 主なステークホルダーは？ | 組織マップ、ビジネスシナリオのアクター一覧 |
+| 6 | 基本的な解決策は？ | ガイディングプリンシプル（アプリケーション・データ・テクノロジー） |
+| 7 | 主なリスクは何か？ | ビジネス環境、組織体制、技術的制約 |
+| 8 | どのくらい作業があり費用はいくらか？ | 組織マップの人員構成、フィーチャの優先度 |
+| 9 | トレードオフにどう向き合うか？ | ビジネスプリンシプル（時間・予算・品質・スコープの優先度） |
+| 10 | 初回リリースはいつか？ | フェーズ分割に基づくマイルストーン |
 
-- @docs/analysis/business_architecture.md - ビジネスアーキテクチャ分析書（`analyzing-business` の成果物）
-- プロジェクトの基本情報（組織体制、技術方針、開発チーム構成）
+## 作成の進め方
 
-### 4. 成果物
+### 新規作成
 
-- @docs/analysis/inception-deck.md - インセプションデッキ
+1. `docs/analysis/business_architecture.md` が存在するか確認する。存在しない場合は `analyzing-business` スキルを先に実行するか、基本情報をヒアリングする
+2. テンプレート（@docs/template/インセプションデッキ.md）を読み込む
+3. 10 の問いに順番に回答する。各問いの回答にはビジネスアーキテクチャ分析書からの根拠を示す
+4. 概念アーキテクチャ図を PlantUML で作成する（問い 6）
+5. マイルストーンの Gantt チャートを PlantUML で作成する（問い 10）
+6. `docs/analysis/inception-deck.md` として出力する
 
-### 5. 作業内容
+### 途中から再開・更新
 
-テンプレートの 10 の問いに対し、ビジネスアーキテクチャ分析書の情報を抽出・整理して回答する。
+既存の `docs/analysis/inception-deck.md` がある場合は、まずその内容を確認する。更新が必要な問いのみを修正する。
 
-#### なぜやるのか？
+**Example:**
 
-- ビジネスアーキテクチャのケイパビリティヒートマップから成熟度が低い領域を特定
-- バリューストリームのボトルネックや非効率を課題として抽出
-- 現状の問題を簡潔かつ明確に記述
-
-#### どんなビジョンなのか？
-
-- ビジネスプリンシプルとガイディングプリンシプルからビジョンを導出
-- ビジネスモデルキャンバスの価値提案をシステムのビジョンに変換
-
-#### どんな価値をもたらすのか？
-
-- ビジネスモデルキャンバスの価値提案・主要活動から具体的なビジネス目標を一覧化
-- 各目標に対して期待される効果を定義
-
-#### スコープの範囲はどこか？
-
-- バリューストリームとケイパビリティマップから優先度付きのフィーチャを抽出
-- スコープ内（必須・高・中）、スコープ外、未決定の 3 カテゴリで整理
-- ビジネスシナリオのユースケースを機能要求の根拠とする
-
-#### 主なステークホルダーは？
-
-- 組織マップとビジネスシナリオのアクター一覧からステークホルダーを特定
-- 各ステークホルダーの役割と主な関心事を整理
-
-#### 基本的な解決策はどのようなものになるか？
-
-- ガイディングプリンシプル（アプリケーション・データ・テクノロジー）から技術方針を導出
-- PlantUML で概念アーキテクチャ図を作成
-- 外部連携（API、配送業者、FBA 等）との接点を明示
-
-#### 主なリスクは何か？
-
-- ビジネス環境、組織体制、技術的制約からリスクを特定
-- 各リスクの影響度と対策を一覧化
-
-#### どのくらい作業があり、費用はいくらか？
-
-- 組織マップの人員構成をもとにチーム構成を想定
-- フィーチャの優先度に基づきフェーズを分割
-- 各フェーズの概算期間を見積もり
-
-#### トレードオフにどう向き合うか？
-
-- 「時間」「予算」「品質」「スコープ」の 4 要素について方針を決定
-- ビジネスプリンシプルに基づき、固定する要素と柔軟にする要素を明確化
-- 品質特性の優先順位を定義
-
-#### 初回リリースが可能になるのはいつか？
-
-- フェーズ分割に基づくマイルストーンを PlantUML の Gantt チャートで作成
-- MVP（最小実行可能製品）のリリースポイントを明示
-- 段階的リリース戦略を定義
-
-### 6. 注意事項
-
-- **前提条件**: @docs/analysis/business_architecture.md が作成済みであること（`analyzing-business` を先に実行）
-- **制限事項**: テンプレート @docs/template/インセプションデッキ.md は絶対に編集しないこと
-- **推奨事項**: 10 の問いすべてに回答し、不明点は仮定を明記した上で後続のステークホルダーレビューで検証する
-
-### 7. 記述ルール
-
-タスク項目などは一行開けて記述する。
-
-OK:
-
-```markdown
-**受入条件**:
-
-- [ ] 10 の問いすべてに回答されている
-- [ ] ビジネスアーキテクチャ分析書との整合性が確認されている
+```
+ユーザー: 「スコープが変わったのでインセプションデッキを更新したい」
+回答: 既存のインセプションデッキを読み込み、問い 4（スコープ）と
+      問い 8（作業量・費用）、問い 10（マイルストーン）を更新する。
 ```
 
-NG:
+## PlantUML の活用
 
-```markdown
-**受入条件**:
-- [ ] 10 の問いすべてに回答されている
-- [ ] ビジネスアーキテクチャ分析書との整合性が確認されている
-```
+問い 6 と問い 10 では PlantUML を使って視覚的に表現する。図があることでチーム間の認識合わせが格段にスムーズになる。
 
-## Examples
+- **概念アーキテクチャ図**（問い 6）: コンポーネント図で主要なシステム要素と外部連携を示す
+- **マイルストーン Gantt チャート**（問い 10）: フェーズ分割と MVP リリースポイントを示す
 
-### 新規プロジェクトでインセプションデッキを作成
+## スライド生成
 
-1. @docs/analysis/business_architecture.md を読み込む
-2. テンプレートの 10 の問いに沿って情報を整理
-3. 概念アーキテクチャ図とマイルストーンの Gantt チャートを PlantUML で作成
-4. @docs/analysis/inception-deck.md として出力
+インセプションデッキの Markdown ドキュメントが完成したら、`generating-slides` スキルで PowerPoint スライドを生成できる。チームへのプレゼンテーション用に活用する。
 
-### 既存インセプションデッキの更新
+## 注意事項
 
-1. 既存の @docs/analysis/inception-deck.md を読み込む
-2. ビジネスアーキテクチャ分析書の更新内容を反映
-3. リスク・スコープ・マイルストーンを見直し
+- ビジネスアーキテクチャ分析書が前提だが、未作成でもプロジェクト情報から直接作成可能。完璧な入力を待つより、仮定を置いて進める方が効果的
+- テンプレートは編集禁止。コピーして成果物を作成する
+- タスク項目（リスト）の前には空行を入れる（Markdown Lint 準拠）
 
-### 関連スキル
+## 関連スキル
 
-- `analyzing-business` : 前提となるビジネスアーキテクチャ分析（本スキルの入力を生成）
-- `analyzing-requirements` : 後続の要件定義（インセプションデッキのスコープを詳細化）
-- `analyzing-usecases` : 後続のユースケース作成（スコープ内フィーチャの具体化）
-- `planning-releases` : 後続のリリース計画（マイルストーンを詳細化）
-- `generating-slides` : インセプションデッキの PowerPoint スライド生成
+- `analyzing-business` — 前提となるビジネスアーキテクチャ分析（本スキルの入力を生成）
+- `analyzing-requirements` — 後続の要件定義（スコープを詳細化）
+- `generating-slides` — インセプションデッキの PowerPoint スライド生成
+- `planning-releases` — 後続のリリース計画（マイルストーンを詳細化）
+- `orchestrating-analysis` — 分析フェーズ全体のワークフロー案内

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

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

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

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