Propose Feature Requirements Skill（機能要件提案スキル）
目的（Purpose）
EARS記法を使用して、機能の正式な要件定義書を作成します。これにより、コンセプトをテスト可能で具体的な要件に変換します。
使用タイミング（When to Use）
- 機能コンセプトが存在し、承認されている場合
- システムが正確に何をすべきかを明確に定義する必要がある場合
- 機能要件と非機能要件を定義する準備ができている場合
前提条件（Prerequisites）
- 機能コンセプト文書が
docs/features/NNNN-feature-name/concept.mdに存在すること - コンセプトがレビューされ、承認されていること
- ユーザーが機能の範囲を理解していること
手順（Procedure）
1. コンセプトの存在確認（Verify Concept Exists）
# コンセプトが存在することを確認
ls ./docs/features/NNNN-feature-name/concept.md
存在しない場合は、先に propose-feature-concept スキルを使用します。
2. アイデア洗練ドキュメントの確認（Check for Idea Honing Document）
ls ./planning/NNNN-feature-name/idea-honing.md 2>/dev/null
存在する場合は、要件に役立つ洞察を確認します。Q&Aからエッジケースや制約が明らかになる場合があります。
3. 要件テンプレートのコピー（Copy Requirements Template）
cp ./docs/features/0000-templates/requirements.md ./docs/features/NNNN-feature-name/
4. 要件プレフィックスの決定（Determine Requirements Prefix）
要件ID用の短いプレフィックス（2〜5文字）を選びます。
- 機能を説明するものにすること
- 例：
SEM（セマンティック検索）、REG（レジストリ管理） SEM-1、SEM-2のように使用します
5. 概要の記入（Fill in Overview）
この仕様書がカバーする内容を簡潔に記述します。コンセプト文書を参照します。
6. 機能要件の定義（Define Functional Requirements）
各要件にはEARS形式を使用します：
**WHILE** [状態または条件]
**WHEN** [トリガーまたはイベント]
**THEN** システムは **SHALL** [要求される振る舞い]
本当に小さな例（1〜3行）の場合のみ、インラインで追加します：
key = "value"
大きな例は、付録に記載することを推奨します。
7. 非機能要件の定義（Define Non-Functional Requirements）
パフォーマンス、ユーザビリティ、セキュリティ、その他の品質要件を追加します：
**WHILE** [動作条件]
**THEN** システムは **SHALL** [パフォーマンス要件]
スケーラビリティに関する質問（主要な操作ごとに問いかける）：
- アイテム数が1000倍、ファイル数が100万、行数が1000万になったらどうなるか？
- メモリ使用量はデータサイズに比例して増えるべきか、一定に保つべきか？
- 許容されるレイテンシは？スケールに応じて劣化するか？
これらの質問は、設計フェーズで重要な制約となる表面化させます。 操作がO(1)メモリやO(log n)時間でなければならない場合は、ここに明記します。
8. エラー処理の定義（Define Error Handling）
エラーの処理方法を指定します：
**WHILE** [進行中の操作]
**WHERE** [エラー条件が発生]
**THEN** システムは **SHALL** [エラー処理の振る舞い]
9. 付録の追加（Add Appendices）
要件が煩雑になるのを避けるため、大きな例は付録に：
- APIレスポンススキーマ
- 設定ファイル形式
- データ構造
- プロトコル仕様
各付録には明確なラベルを付けます：
## Appendix A: API応答スキーマ
## Appendix B: 設定ファイル形式
10. 完全性の確認（Review for Completeness）
以下を確認：
- すべての要件がEARSキーワードを使用していること
- 要件がテスト可能で具体的であること
- インライン例が本当に小さいこと
- 大きな例は付録にあること
- 要件に選択したプレフィックスを使用した一意のIDがあること
検証（Validation）
要件文書を検証します：
# ファイルの存在確認
ls ./docs/features/NNNN-feature-name/requirements.md
# 内容を確認
head -50 ./docs/features/NNNN-feature-name/requirements.md
# EARSキーワードの確認
grep -E "WHILE|WHEN|WHERE|THEN|SHALL" ./docs/features/NNNN-feature-name/requirements.md
よくある問題（Common Issues）
EARSキーワードの欠落: すべての要件でWHILE/WHEN/WHERE/THEN/SHALLを使用すること。
曖昧すぎる: 要件はテスト可能な程度に具体的であること。
インライン例が大きすぎる: 3行を超えるものは付録に移動すること。
プレフィックスが不統一: すべての要件IDで同じプレフィックスを使用すること。
次のステップ（Next Steps）
要件作成後：
- 完全性とテスト可能性についてレビュー
- 実装者からフィードバックを得る
- 要件が固まったら、
propose-feature-designスキルを使用して設計に進む