requirements について
成果と観察可能な振る舞いを重視する、プロダクト・エンジニアリングチーム向けの要件作成スキルです。受け入れ例、依存関係、未確定事項、スコープ境界を構造化して記述できます。
主な機能
- 01目標、担当者、入力、結果の抽出
- 02受け入れ例と制約の記述
- 03依存関係と未確定事項の特定
- 04失敗ケースと境界条件の検討
- 05根拠に基づく要件状況の追跡
- 06前提と対象外項目の区別
活用シーン
- 01概要からテスト可能な要件を作成する
- 02認可と書き込みの動作を明確にする
- 03記載された要件に照らして実装を確認する
- 04未確定の契約やスコープを明らかにする
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/requirementsを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
agents/openai.yamlevals/evals.jsontriggers.json詳細
要件
成果と観察可能な動作について要件を記述します。ユーザーが明示した選択を保ち、好みの解決策に置き換えないでください。
作業内容
- 概要または実際に稼働している製品から、ユーザーの目標、開始イベント、許可されたアクター、入力、結果、失敗時の動作を抽出します。
- トレーサビリティが役立つ場合に限り、要件に安定した ID を付けます。法律文書のような冗長な表現は避け、「エディターはプロジェクト名を変更できます。ビューアーは変更できません」のように記述します。
- 各書き込み操作について、サーバー側の認可、検証、永続化、重複送信時の動作、タイムアウト後に結果が不明な場合の対応を特定します。
- 該当する品質上の制約を、条件とともに指定します。対象デバイス、入力方法、コンテンツサイズ、レイテンシの測定方法、サポート対象言語、プライバシー、可用性などです。提案する目標値は提案として明記します。
- 依存関係、未解決の契約に関する質問、対象外の範囲を記載します。API をでっち上げたり、存在するかのように示したりしないでください。
- 実装を再確認する際は、各要件について、満たしているか、変更されたか、不足しているか、未検証かを、証拠とともに報告します。
成果物
要件 → 受け入れ例 → 依存関係／不明点の形式を使用します。正しい動作と、もっともらしい実装とを区別するのに必要な例だけを追加します。
各要件は次の形式で記述します。
FR-01: ［アクター＋動作］。受け入れ条件: ［観察可能な例］。依存関係／不明点: ［...］ NFR-01: ［制約＋条件］。検証: ［対象を限定した確認］
対象外、前提、未解決の質問、次のステップで締めくくります。
重大な動作には、失敗または境界のケースを含めます。「アクセシブル」「高速」「安全」は、対象を限定した検証基準が必要です。分岐順序が未解決の問題には $flow を使用し、再利用可能なインタラクションに契約が必要な場合は $component を使用します。
記入例
FR-01: エディターはプロジェクト名を変更できます。ビューアーは変更できません。受け入れ条件: ビューアーによる名前変更の直接リクエストはサーバーで拒否され、保存済みの名前は変更されません。依存関係: 組織ごとのロールデータ。
FR-02: 名前変更がタイムアウトしても、変更が二重に適用されません。受け入れ条件: タイムアウト後に再送信しても、保存される名前と監査ログのエントリはそれぞれ 1 つです。不明点: API が冪等性キーに対応しているかどうか。
FR-03: プロジェクト一覧のステータスフィルターは URL に保持されます。受け入れ条件: コピーしたリンクを開くと、同じフィルターが適用された一覧が表示されます。依存関係: なし。
NFR-01: キーボードだけで名前変更を完了できます。検証: ポインターを使わずに名前変更を完了し、フォーカスがプロジェクト名に戻ることを確認します。
NFR-02（提案、未合意）: クライアントが現場用スマートフォンを対象として確認した場合、モバイル回線を制限したプロファイルで、プロジェクト一覧に使える内容が 2 秒以内に表示されます。検証: 対象デバイスがクライアントによって確認された後、そのデバイスプロファイルで測定します。
対象外: 一括名前変更、名前変更履歴の表示。
前提: プロジェクト名は組織ごとに一意です。
未解決の質問: エディターが開いているプロジェクトの名前を別のエディターが変更した場合、ビューアーには何が表示されるか。
次のステップ: 2 人のエディターが同時に名前を変更する場合を含め、名前変更の $flow を作成します。
注意点
- 権限チェックでボタンを非表示にするだけでは、誰でも API を呼び出せる実装がビルドを通過してしまいます。直接リクエストを送るケースを含めてください。
- 書き込み操作には 3 つ目の失敗パターンがあります。サーバーが保存した後にリクエストがタイムアウトする場合です。そのため、重大な書き込み操作には再試行に関する要件が必要です。
- コンポーネント名を指定した要件（「ドロップダウンを追加する」など）は、設計前に解決策を固定してしまいます。
- 条件と検証方法がなければ、「高速」「安全」「アクセシブル」はテストで判定できません。
- 要件に記載されたエンドポイント名は、既存の契約として扱われます。文書化されていない API は不明点として列挙してください。
適用範囲
- 対象者や実現したい成果など、アイデアがまだ曖昧な場合は使用せず、代わりに
$intentを使用します。 - 未解決の質問がナビゲーションやページ構成に関する場合は使用せず、代わりに
$sitemapを使用します。 - タスクの手順を順を追って整理する場合は使用せず、代わりに
$flowを使用します。