指定されたPRを6観点(セキュリティ、ドキュメント乖離、可読性、ライブラリ選定、PR説明、既知脆弱性)でレビューし、人間向け・AI向けの2形式でPRにコメントする。初回レビューおよび修正後の再レビューに使用する。Do NOT use for レビューコメントへの修正適用(pr-comment-fixerを使用すること)。
requirements-defining
【非推奨】requirement-management に統合された。新規の要件定義には requirement-management を使用すること。既存の docs/sdd/requirements/ を保守・参照する場合にのみ使用する。
EARS記法によるMarkdownの要件定義書(ユーザーストーリー・受入基準・非機能要件)を作成・編集する。Do NOT use for 新規プロジェクトの要件定義(requirement-management を使用すること)。
含まれるファイル(5)
- SKILL.md6.3 KB
- assets/templates/nfr_template_ja.md2.5 KB
- assets/templates/requirements_index_template_ja.md2.8 KB
- assets/templates/user_story_template_ja.md1.7 KB
- references/ears_notation_ja.md10.6 KB
SKILL.md(原文)
インストールする前に、エージェントに与えられる指示の中身を確認できます。
要件定義スキル(非推奨)
⚠️ このスキルは非推奨です。
要件定義の機能は
requirement-managementに統合されました。要求の矛盾・欠落を機械検証できる同スキルを新規利用では使用してください。
非推奨(本スキル) 移行先 保存形式 Markdown( docs/sdd/requirements/)YAML( docs/requirements/)整合性チェック 人手のレビュー reqctl.py validateによる機械検証理由の記録 任意 必須( rationale.why)検証手段 受入基準の文章 テストIDへの紐付け( verification)移行手順は
sdd/requirement-management/references/migration_from_sdd_ja.mdを参照してください。 既存のdocs/sdd/requirements/を保守・参照する場合にのみ、以下の手順を使用します。
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記法の詳細は references/ears_notation_ja.md を参照。
ワークフロー
新規作成フロー
- 情報収集: プロジェクトの目的、対象ユーザー、主要機能を確認
- ディレクトリ作成:
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(非推奨): 設計は実装時にPR本文へ記載する- 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 | - |
レビュー
まだレビューはありません。使ってみた感想をお寄せください。
同じリポジトリのスキル
概要と使いどころ
キャリア設計のためのデプスインタビューを実施し、本人の価値観・強み・動機を引き出す。5 Whys、ラダリング法を用いてキャリアビジョンの明確化を支援する。転職相談、自己理解、キャリアカウンセリング、1on1面談の深掘りに使用する。Do NOT use for 製品・サービスのユーザーリサーチ(depth-interviewing-productを使用すること)。
サービス開発のためのデプスインタビューを実施し、ユーザーの真のニーズ・課題・動機を引き出す。5 Whys、ラダリング法を用いてプロダクト開発に活かせるインサイトを発見する。ユーザーリサーチ、課題発見、ペルソナ構築、プロダクト仮説検証に使用する。Do NOT use for キャリア相談やキャリアカウンセリング(depth-interviewing-careerを使用すること)。
インフラメトリクスの定期調査を体系的に実施し、サービスの健全性を評価する。2層アプローチで11カテゴリのメトリクスを確認し、構造化レポートを作成する。定期的なサービス監視、障害予兆の検出、パフォーマンス評価に使用する。Do NOT use for 個別インシデントの根本原因分析(incident-rcaを使用すること)。
インシデント調査で根本原因を特定するためのなぜなぜ分析ファシリテーター。推測を避け、ユーザーの発言を記録し、マインドツリーで全体を可視化する。障害発生後の原因究明、ポストモーテム、再発防止策の策定に使用する。Do NOT use for 定期的なサービス健全性チェック(health-checkを使用すること)。
IPA非機能要求グレード2018(可用性・性能拡張性・運用保守性・移行性・セキュリティ・システム環境)の記入済み要件を入力として、運用設計書を生成する。非機能要件定義が完了しているプロジェクトの運用設計フェーズで使用する。Do NOT use for 非機能要件の定義自体(requirement-managementを使用すること)。Do NOT use for 業界調査やヒアリングから始める運用設計(operations-designを使用すること)。