Agent skill
requirements-defining
EARS記法を用いた要件定義書を作成・編集する。ユーザーストーリーの作成、受入基準の定義、非機能要件の整理が必要な場合に使用する。要件定義フェーズのみを単独で実行する際に使用する。Do NOT use for SDDワークフロー全体の管理（sdd-documentationを使用すること）。
Install this agent skill to your Project
npx add-skill https://github.com/windschord/claude_skils/tree/main/requirements-defining
Metadata
Additional technical details for this skill
- version
- 1.0.0
SKILL.md
要件定義スキル
EARS記法（Easy Approach to Requirements Syntax）を用いて、明確でテスト可能な要件定義書を作成します。
概要
このスキルは、以下の成果物を作成・管理します：
- docs/sdd/requirements/index.md: 要件一覧（目次）
- docs/sdd/requirements/stories/US-XXX.md: ユーザーストーリー詳細
- docs/sdd/requirements/nfr/*.md: 非機能要件（カテゴリ別）
ドキュメント構成
docs/sdd/requirements/
├── index.md # 目次・概要・要件サマリ
├── stories/
│ ├── US-001.md # ユーザーストーリー詳細
│ ├── US-002.md
│ └── ...
└── nfr/
├── performance.md # 性能要件
├── security.md # セキュリティ要件
└── usability.md # ユーザビリティ要件
このスキルを使用する場面
新規作成時
- 新規プロジェクトで要件定義書が必要な場合
- ユーザーストーリーを明確に定義したい場合
- テスト可能な受入基準を作成したい場合
- 非機能要件（性能、セキュリティ等）を整理したい場合
既存ドキュメントの修正時
- docs/sdd/requirements/に新しい要件を追加する場合
- 既存の要件をEARS記法に変換・修正する場合
- 要件のレビュー・改善が必要な場合
EARS記法ガイド
基本パターン
| パターン | 形式 | 使用場面 |
|---|---|---|
| 基本 | システムは〜しなければならない |
常時適用される要件 |
| イベント | 〜の時、システムは〜しなければならない |
イベント駆動要件 |
| 条件 | もし〜ならば、システムは〜しなければならない |
状態依存要件 |
| 継続 | 〜の間、システムは〜しなければならない |
継続的要件 |
| 場所 | 〜において、システムは〜しなければならない |
コンテキスト固有要件 |
要件の例
- REQ-001: ユーザーが「カートに追加」をクリックした時、システムは500ms以内に商品を追加しなければならない
- REQ-002: カートが空の場合、システムは「カートは空です」と表示しなければならない
- REQ-003: 決済処理中、システムは進捗インジケーターを表示しなければならない
- NFR-001: システムは性能劣化なしに1000人の同時ユーザーを処理できなければならない
避けるべき表現
| 避けるべき | 推奨 |
|---|---|
| 「〜すべきである」 | 「〜しなければならない」 |
| 「〜することが望ましい」 | 「〜しなければならない」 |
| 「高速に」「使いやすく」 | 具体的な数値（「2秒以内」「3クリック以内」） |
| 複数の「しなければならない」 | 要件を分割 |
実行効率に関する注意
- テンプレートは使用直前に読み込む: 全テンプレートを事前に読み込まない。index.md作成時にindex用テンプレートのみ、ストーリー作成時にストーリー用テンプレートのみ読み込む
- リファレンス（EARS記法ガイド等）は必要時のみ参照: EARS記法に不慣れな場合や判断に迷う場合のみ読み込む
- 作業完了後は速やかに結果を報告: 長時間無応答にならないよう、作成したドキュメントの概要をユーザーに提示する
- 進捗をステップごとに出力する: 各処理ステップの開始時に進捗メッセージを出力する
進捗出力の例
[requirements-defining] ステップ 1/5: 入力要件を読み込み中...
[requirements-defining] ステップ 2/5: 情報を分類中（明示/不明）...
[requirements-defining] ステップ 3/5: EARS記法で要件を生成中...
[requirements-defining] ステップ 4/5: ユーザーストーリーを作成中...
[requirements-defining] ステップ 5/5: index.mdを作成中...
[requirements-defining] 完了: 5ファイル作成
情報分類の段階的処理
長文の要件説明を受け取った場合、一括分類を避け段階的に処理する:
- Phase 1: 必須情報のみ確認（プロジェクト名、目的、対象ユーザー）→ 不明点があればここで質問
- Phase 2: 機能要件の整理 → ユーザーストーリー作成
- Phase 3: 非機能要件の整理 → NFRドキュメント作成
ワークフロー
新規作成フロー
- 情報収集: プロジェクトの目的、対象ユーザー、主要機能を確認
- ディレクトリ作成:
docs/sdd/requirements/stories/とdocs/sdd/requirements/nfr/を作成 - index.md作成: 目次テンプレートを使用して概要を記述
- ユーザーストーリー作成: 各ストーリーを
stories/US-XXX.mdとして作成 - 非機能要件作成: カテゴリ別に
nfr/*.mdを作成 - index.md更新: 作成した各ドキュメントへのリンクを追加
- レビュー: チェックリストで品質確認
- ユーザー確認: 承認を得て完了
ストーリー追加フロー
- 新規ファイル作成:
stories/US-XXX.mdを作成 - EARS記法で要件定義: ユーザーストーリーテンプレートに従う
- index.md更新: ストーリー一覧テーブルにリンクを追加
- 関連ドキュメント更新: 関連する既存ストーリーに相互リンクを追加
検証チェックリスト
- ユーザーストーリーが明確に定義されている
- すべての要件がEARS記法に従っている
- 要件IDが一意である（REQ-XXX、NFR-XXX）
- 各要件がテスト可能である
- 非機能要件が含まれている
- 曖昧な表現が排除されている
ユーザーとの対話ガイドライン
情報分類プロセス
ユーザーの指示を受け取ったら、まず以下を分類：
明示された情報:
- ユーザーが明確に述べた要件、仕様、制約
不明な情報:
- ユーザーが言及していないが、要件定義に必要な情報
- 「おそらく〜だろう」と推測が必要な項目
確認が必要な場面
- プロジェクトの種類や目的
- 対象ユーザー
- 主要な機能
- 非機能要件の具体的な値（性能、セキュリティなど）
- ユーザーストーリーの優先順位
確認の形式
要件定義の前に、以下の点を確認させてください：
【明示された情報】
- [ユーザーから明示的に指定された内容]
【不明/要確認の情報】
1. [項目1]: [選択肢A] / [選択肢B] / その他
2. [項目2]: [具体的な質問]
上記の不明点について教えていただけますか？
後続スキルとの連携
docs/sdd/requirements/の作成完了後：
- software-designing: docs/sdd/requirements/を基に技術設計を行う
- task-planning: 要件に基づきタスクを分解
後続スキルで整合性の確認が行われます。
リソース
テンプレート
- 目次テンプレート:
assets/templates/requirements_index_template_ja.md - ユーザーストーリーテンプレート:
assets/templates/user_story_template_ja.md - 非機能要件テンプレート:
assets/templates/nfr_template_ja.md
リファレンス
- EARS記法リファレンス:
references/ears_notation_ja.md
命名規則
| ファイル種別 | 命名規則 | 例 |
|---|---|---|
| ユーザーストーリー | US-XXX.md |
US-001.md, US-002.md |
| 性能要件 | performance.md |
- |
| セキュリティ要件 | security.md |
- |
| ユーザビリティ要件 | usability.md |
- |
| 可用性要件 | availability.md |
- |
| 保守性要件 | maintainability.md |
- |
リンク形式
index.mdから個別ファイルへのリンクは、マークダウン形式と@形式の両方を記載：
| US-001 | タイトル | 高 | 承認済 | [詳細](stories/US-001.md) @stories/US-001.md |
- マークダウン形式:
[詳細](stories/US-001.md)- GitHub等での閲覧用 - @形式:
@stories/US-001.md- Claude Codeがファイルを参照する際に使用
Recommended Agent Skills
Expand your agent's capabilities with these related and highly-rated skills.
windschord/claude_skils
orchestrating-agents
Orchestrates multi-step tasks autonomously using a 3-tier agent hierarchy (Director/Manager/Worker). Use when user says "run this end-to-end", "handle everything", "execute all tasks", or needs parallel task execution with queuing, course correction, and session resume. Provides FIFO task queue, escalation policy, git worktree isolation, and context persistence across agent sessions.
windschord/claude_skils
sdd-documentation
SDDワークフロー全体を統括するオーケストレーター。要件定義・設計・タスク計画・実装・逆順レビューの一連のフローを管理する。新規プロジェクトのSDD一括作成、複数フェーズにまたがるワークフロー管理、エラー・バグの体系的な分析と修正に使用する。Do NOT use for 個別フェーズのみの作業（requirements-defining、software-designing、task-planningを直接使用すること）。
windschord/claude_skils
sdd-troubleshooting
エラー・バグ・問題を体系的に分析し修正方針を策定する。テスト失敗、ビルドエラー、実行時エラー、動作不良、バグ報告に対応し、根本原因を分析してから修正を行う。Do NOT use for 根本原因分析が不要な軽微な修正（typo、設定値変更、フォーマット修正など）。
windschord/claude_skils
self-review
ローカルの変更差分（git diff）を3つのサブエージェントで並列レビューし、結果を統合して修正を適用する。PR作成前やタスク完了前のローカル品質チェックに使用する。ai-code-reviewと同一の6観点・重大度基準を適用する。
windschord/claude_skils
depth-interviewing-career
キャリア設計のためのデプスインタビューを実施し、本人の価値観・強み・動機を引き出す。5 Whys、ラダリング法を用いてキャリアビジョンの明確化を支援する。転職相談、自己理解、キャリアカウンセリング、1on1面談の深掘りに使用する。Do NOT use for 製品・サービスのユーザーリサーチ（depth-interviewing-productを使用すること）。
windschord/claude_skils
saas-spec-document
SaaSサービス向けのサービス仕様書を作成します。運用設計書や要件定義書をインプットとして活用し、経済産業省「SaaS向けSLAガイドライン」に準拠したサービス仕様書を生成します。ガイドライン準拠の7カテゴリ（可用性、信頼性、データ管理、セキュリティ、サポート、拡張性、コンプライアンス）に加え、サービス概要・料金・責任分界を含む全10セクションを網羅します。
Didn't find tool you were looking for?