【非推奨】requirement-management に統合された。新規の要件定義には requirement-management を使用すること。既存の docs/sdd/requirements/ を保守・参照する場合にのみ使用する。
EARS記法によるMarkdownの要件定義書（ユーザーストーリー・受入基準・非機能要件）を作成・編集する。Do NOT use for 新規プロジェクトの要件定義（requirement-management を使用すること）。
The English summary is being prepared. Showing the original description.
See how to installReview the instructions the agent will receive before you install.
⚠️ このスキルは非推奨です。
要件定義の機能は
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 # 目次・概要・要件サマリ
├── stories/
│ ├── US-001.md # ユーザーストーリー詳細
│ ├── US-002.md
│ └── ...
└── nfr/
├── performance.md # 性能要件
├── security.md # セキュリティ要件
└── usability.md # ユーザビリティ要件
EARS記法の詳細は references/ears_notation_ja.md を参照。
docs/sdd/requirements/stories/ と docs/sdd/requirements/nfr/ を作成stories/US-XXX.md として作成nfr/*.md を作成stories/US-XXX.md を作成ユーザーの指示を受け取ったら、まず以下を分類：
明示された情報:
不明な情報:
要件定義の前に、以下の点を確認させてください：
【明示された情報】
- [ユーザーから明示的に指定された内容]
【不明/要確認の情報】
1. [項目1]: [選択肢A] / [選択肢B] / その他
2. [項目2]: [具体的な質問]
上記の不明点について教えていただけますか？
docs/sdd/requirements/の作成完了後：
後続スキルで整合性の確認が行われます。
assets/templates/requirements_index_template_ja.mdassets/templates/user_story_template_ja.mdassets/templates/nfr_template_ja.mdreferences/ears_notation_ja.md| ファイル種別 | 命名規則 | 例 |
|---|---|---|
| ユーザーストーリー | US-XXX.md | US-001.md, US-002.md |
| 性能要件 | performance.md | - |
| セキュリティ要件 | security.md | - |
| ユーザビリティ要件 | usability.md | - |
| 可用性要件 | availability.md | - |
| 保守性要件 | maintainability.md | - |
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
指定されたPRを6観点（セキュリティ、ドキュメント乖離、可読性、ライブラリ選定、PR説明、既知脆弱性）でレビューし、人間向け・AI向けの2形式でPRにコメントする。初回レビューおよび修正後の再レビューに使用する。Do NOT use for レビューコメントへの修正適用（pr-comment-fixerを使用すること）。
The English summary is being prepared. Showing the original description.
キャリア設計のためのデプスインタビューを実施し、本人の価値観・強み・動機を引き出す。5 Whys、ラダリング法を用いてキャリアビジョンの明確化を支援する。転職相談、自己理解、キャリアカウンセリング、1on1面談の深掘りに使用する。Do NOT use for 製品・サービスのユーザーリサーチ（depth-interviewing-productを使用すること）。
The English summary is being prepared. Showing the original description.
サービス開発のためのデプスインタビューを実施し、ユーザーの真のニーズ・課題・動機を引き出す。5 Whys、ラダリング法を用いてプロダクト開発に活かせるインサイトを発見する。ユーザーリサーチ、課題発見、ペルソナ構築、プロダクト仮説検証に使用する。Do NOT use for キャリア相談やキャリアカウンセリング（depth-interviewing-careerを使用すること）。
The English summary is being prepared. Showing the original description.
インフラメトリクスの定期調査を体系的に実施し、サービスの健全性を評価する。2層アプローチで11カテゴリのメトリクスを確認し、構造化レポートを作成する。定期的なサービス監視、障害予兆の検出、パフォーマンス評価に使用する。Do NOT use for 個別インシデントの根本原因分析（incident-rcaを使用すること）。
The English summary is being prepared. Showing the original description.
インシデント調査で根本原因を特定するためのなぜなぜ分析ファシリテーター。推測を避け、ユーザーの発言を記録し、マインドツリーで全体を可視化する。障害発生後の原因究明、ポストモーテム、再発防止策の策定に使用する。Do NOT use for 定期的なサービス健全性チェック（health-checkを使用すること）。
The English summary is being prepared. Showing the original description.
IPA非機能要求グレード2018（可用性・性能拡張性・運用保守性・移行性・セキュリティ・システム環境）の記入済み要件を入力として、運用設計書を生成する。非機能要件定義が完了しているプロジェクトの運用設計フェーズで使用する。Do NOT use for 非機能要件の定義自体（requirement-managementを使用すること）。Do NOT use for 業界調査やヒアリングから始める運用設計（operations-designを使用すること）。
The English summary is being prepared. Showing the original description.