菜单
ユーザー要件を分析し、システム設計ドキュメント(DESIGN.md)を生成します。ユーザー要件が曖昧または不明確な場合、システムアーキテクチャの設計が必要な場合、大規模な機能開発の設計仕様が必要な場合、技術的実現可能性の検証が必要な場合に使用します。不明点はAskUserQuestionツールで確認します。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
承認済みの設計書（DESIGN.md）からTDD準拠のTODO.mdを作成します。analyzing-requirementsスキルで設計が完了・承認された後に使用します。developingスキルで実装できる形式のタスクリストを生成します。
Claude Codeスキルを公式ベストプラクティスに基づいてレビューします。SKILL.mdファイルのレビュー、スキル品質のチェック、スキル構造の検証、改善提案が必要な場合に使用します。「このスキルをレビューして」「スキル品質をチェック」「SKILL.mdを検証」「このスキルを改善」などのリクエストで起動します。
| name | analyzing-requirements |
| description | ユーザー要件を分析し、システム設計ドキュメント(DESIGN.md)を生成します。ユーザー要件が曖昧または不明確な場合、システムアーキテクチャの設計が必要な場合、大規模な機能開発の設計仕様が必要な場合、技術的実現可能性の検証が必要な場合に使用します。不明点はAskUserQuestionツールで確認します。 |
曖昧なユーザーリクエストを具体的で実行可能な設計仕様に変換する。要件を深く理解し、技術的実現可能性を検証し、アーキテクチャを設計し、開発者が従える詳細な設計ドキュメント(DESIGN.md)を生成する。
注: タスク分解とTODO.md生成は planning-tasks スキルで行う
分析を開始する前に、../shared/references/must-rules.mdのすべてのMUSTルールを確認する：
すべてのタスク分解はこれらのルールに準拠する必要がある。
ユーザーリクエストを複数の観点から分析する：
何を構築するか（What）
目的と価値（Why）
使用パターン（How）
タイムライン（When）
対象ユーザー（Who）
必須: 決して仮定を立てない
利用可能なツールを使用して既存の実装を調査する：
# 関連する実装を検索
Grep(pattern="relevant-keyword")
Read(file_path="related-file")
Glob(pattern="**/*.{js,ts,py}")
情報が不足している場合、AskUserQuestionツールを使用してユーザーに確認する：
AskUserQuestion({
questions: [
{
question: "この機能の認証方式はどれを使用しますか？",
header: "認証方式",
options: [
{
label: "JWT",
description: "JSON Web Tokenを使用したステートレス認証"
},
{
label: "Session",
description: "サーバーサイドセッション管理"
},
{
label: "OAuth 2.0",
description: "外部認証プロバイダーとの連携"
}
],
multiSelect: false
}
]
})
不明点が複数ある場合は、一度に複数の質問（最大4つ）を行うことができる 質問がなくなるまで繰り返して確認する
要件を明確に構造化する：
システム全体の構成と技術選定を行う：
システム構成
技術選定
データ設計
非機能要件の設計
エラー戦略
テスト戦略
設計ドキュメント(DESIGN.md)を生成する：
# [プロジェクト名] 設計ドキュメント
生成日: [日付]
ジェネレーター: analyzing-requirements
## システム概要
[システムの目的、解決する問題、ビジネス価値、対象ユーザー]
## 機能要件
### 必須機能（MUST have）
- [機能1の説明]
- [機能2の説明]
### オプション機能（NICE to have）
- [機能3の説明]
## 非機能要件
### パフォーマンス要件
- レスポンスタイム: [具体的な数値]
- スループット: [具体的な数値]
- 同時接続数: [具体的な数値]
### セキュリティ要件
- 認証方式: [JWT、Session、OAuth等]
- 認可方式: [RBAC、ABAC等]
- データ暗号化: [保存時、転送時]
- 脆弱性対策: [XSS、CSRF、SQLインジェクション等]
### 可用性・信頼性
- 稼働率目標: [99.9%等]
- バックアップ戦略: [方式と頻度]
- 障害復旧時間: [RTO、RPO]
## アーキテクチャ設計
### システム構成
[コンポーネント図、レイヤーアーキテクチャの説明]
### 技術スタック
- **フロントエンド**: [React、Vue.js等]
- **バックエンド**: [Node.js、Go、Python等]
- **データベース**: [PostgreSQL、MongoDB等]
- **インフラ**: [AWS、GCP、Azure等]
- **その他**: [Redis、RabbitMQ等]
### モジュール構成
[各モジュールの責務と依存関係]
## データ設計
### エンティティ定義
User
[他のエンティティ...]
### データフロー
[データの流れを図で示す、または文章で説明]
## API設計
### エンドポイント一覧
POST /api/auth/login - ログイン GET /api/users/:id - ユーザー情報取得 PUT /api/users/:id - ユーザー情報更新 [他のエンドポイント...]
### リクエスト/レスポンス例
```json
// POST /api/auth/login
Request:
{
"email": "user@example.com",
"password": "secret"
}
Response:
{
"token": "jwt-token",
"user": { ... }
}
[認証プロセスの詳細]
[開発に必要な環境とセットアップ手順]
[ビルド、テスト、デプロイの自動化]
[監視項目とログ収集方法]
### ステップ6: ファイル出力
設計ドキュメントを書き出す：
```javascript
// docsディレクトリにDESIGN.mdを出力
Write(
file_path="docs/DESIGN.md",
content=designContent
)
生成したDESIGN.mdをセルフレビューし、問題がなくなるまで修正を繰り返す。
1. DESIGN.mdを読み返す
2. 以下のチェックリストで問題を洗い出す
3. 問題があれば修正してファイルを更新
4. 問題がなくなるまで1-3を繰り返す（最大3回）
要件の完全性
設計の明確性
実装への橋渡し
問題を発見した場合：
3回のレビューで解決しない問題がある場合は、AskUserQuestionツールでユーザーに確認する。
設計完了前に確認：