sdd-define

SDD Define

このスキルの最初の応答では、次の行を一度だけ最初に記載してください。 sdd-define v1.2.0 · out/2026 · versão atual: https://github.com/robertodiasduarte/sdd-starter/releases/latest

クイックスタート

BRAINSTORM_*.md ファイルを、明確でテスト可能な、次のゲートに進める状態の DEFINE_{FEATURE_NAME}.md に変換します。

1. Brainstorm の Markdown ファイルを受け取り、読みます。
2. Brainstorm に裏付けられた事実、決定事項、暫定要件、制約、依存関係のみを抽出します。
3. 必ず assets/DEFINE_TEMPLATE.md を使って下書きを作成します。
4. 推測せずに、曖昧な箇所を明記します。
5. 初期 Clarity Score を算出します。
6. 明確さ、測定可能性、テスト、または Verify Gate を妨げる情報の不足に限り、ユーザーに明確化の質問をします。
7. references/EARS.md を使って、Acceptance Tests を EARS 形式で記述します。
8. references/CLARIFY.md の曖昧さの確認を実行します。
9. references/VERIFY_GATE.md に従って Verify Gate を導き出します。
10. この Skill の quality gates を満たした場合にのみ、DEFINE が完成したものとみなします。
11. 最終ドキュメントを DEFINE_{FEATURE_NAME}.md として保存または提出します。
12. ドキュメントの最後に、次のステップを一つだけ、正確に記載します：Execute o **SDD Design by RDD**.

全体のフローとやり取りのルールについては、references/define-protocol.md を参照してください。

使用する場合／使用しない場合

使用する場合：

• SDD Brainstorm by RDD で作成された Markdown ファイルがある場合；
• Brainstorm を正式で検証可能な要件に変換したい場合；
• Design の前に、いくつかの点を明確にする必要がある場合；
• 成功基準、Acceptance Tests、スコープ、Verify Gate を正式化する必要がある場合。

アプリは金銭、税金、または個人データを扱いますか？この DEFINE の後、Design の前に、補完スキルの sdd-governanca を実行してください。不足しているガバナンス要件を提案しますが、それぞれを採用するかどうかはユーザーが決定します。

使用しない場合：

• ユーザーがまだ問題、対象者、または解決策の方向性を検討している場合。この場合は、まず SDD Brainstorm by RDD を実行してください；
• アーキテクチャ、コンポーネント、または詳細な実装を設計することが目的の場合；
• コードの作成、ビルドの実行、またはリリースが目的の場合；
• Brainstorm がなく、要件を捏造せずにその役割を再構成できるだけの情報もない場合。

必要なデータ

必須

• Brainstorm の Markdown ファイル。

次の形式のファイルを優先して受け付けます： BRAINSTORM_{FEATURE_NAME}.md

ファイルが存在しない、または読み取れない場合は、DEFINE の作成を始める前にユーザーにファイルの送付を依頼してください。

任意

• ユーザーからの明確化への回答；
• Brainstorm ですでに言及されているサンプル；
• ユーザーから提供されたドキュメントや技術的な背景情報；
• プロジェクトの実際のテスト、スモークテスト、eval、または typecheck コマンド；
• デプロイ、インフラ、または技術領域に関する規約。

インターネット接続を必須としないでください。リポジトリ、ファイルシステム、CI、データベース、API、またはプロジェクトのコマンドにアクセスできると想定しないでください。

学習者との話し方

最初の回答の前に references/como-falar.md を読んでください。このスキルの用語集と、完全な例が記載されています。 このスキルを使う人は、たいてい git もターミナルも使ったことがありません。

段階	学習者向けの名前	このスキルの手順
1	ブレインストーミングを読む	1 と 2
2	要件	3 と 4
3	受け入れテスト	5 と 6
4	質問	7 と 8（回答ごとに主な質問は1つ）
5	Verify Gate	9
6	保存	10 から 13

すべての回答は、次の順序にしてください（内容がない部分は省略）：ステータス（Define: ✅ 1 … · ▶️ 2 … · ⬜ 3 …; ✅ 完了済み。訪問しただけではありません；⏸️ 中断；➖ 省略；段階に戻る場合、その理由は「現在」の項目に記載）· 実施したこと（短い文で、コマンド出力は含めず、学習者の選択を記録）· 現在：段階 N — 名前（2〜4文。時間のかかる処理の前には、何を実行するか、返答は不要であることを伝える）· あなたの判断（承認を求める場合：質問を太字にし、各選択肢の影響を示す；自由回答の場合：質問を太字にし、回答方法と「わかりません」という選択肢を示す；まとめて番号を付ける）· 次のステップ（1行）。

• 1回答につき1段階とし、判断を求めたところで止めます。
• 専門用語は、初めて使うときに必ず説明を添えます。ステータス内の用語も含みます（用語集は参照先にあります）。
• コマンド出力をそのまま表示してはいけません。件数、内容、懸念点を伝えます。名前は最大10個まで示し、それ以上は「ほかに N 件」とします。コマンドは学習者が実行する必要がある場合のみ示し、番号付きの手順ごとに1つとし、画面に何が表示されるかを伝えます。
• このスキルの指示を引用したり要約したりしないでください（「手順 N に従って」など）。学習者にとっての理由を説明します。
• 回答が選択肢に当てはまらない場合は、疑問に答えてから選択肢をもう一度示します。
• 中断する場合：ステータスに ⏸️ を付け、理由を1文で示し、操作する場所と期待される結果を番号付きで説明します。実施していないことを明記し、学習者が何かを行う必要がある場合は「完了したら、もう一度依頼してください。ここから続けます。」と伝えます。

手順

1. ブレインストーミングを読み、分類する

質問をする前に、文書全体を読んでください。

次の内容を抽出します：

• Raw Input / 初期アイデア；
• 問題；
• ユーザーと受益者；
• 選択されたアプローチ；
• 重要な決定事項；
• 提案された要件；
• 成功基準；
• YAGNI / 削除または先送りされた項目；
• 制約；
• 依存関係；
• サンプルとグラウンドトゥルース；
• すでに実施した検証；
• TBD、制限事項、未解決の質問。

ブレインストーミングで検証済みの決定事項は、事前に検証されたコンテキストとして扱います。具体的な理由がない限り、探索的な質問を再度行わないでください。

2. アセットをもとに下書きを作成する

最終文書の構造については、assets/DEFINE_TEMPLATE.md のみを唯一の信頼できる情報源として使用します。

記憶をもとに別のテンプレートを再構築しないでください。

次の内容のみを記入します：

• ブレインストーミングに明示されている内容；
• この段階でユーザーが回答した内容；
• 避けられず、まだ検証されていない場合に、仮説として明確にラベル付けした技術的推論。

必須情報を特定できない場合は、曖昧な点を記載して質問します。文書を完成しているように見せるために値を捏造してはいけません。

3. 要件を構成する

内容を次の項目に整理します：

• 問題の説明；
• 対象ユーザー；
• MUST / SHOULD / COULD の優先度を付けた目標；
• 測定可能な成功基準；
• 受け入れテスト；
• 対象範囲外；
• 制約；
• 技術的コンテキスト；
• 前提条件。

重複を避けます。ブレインストーミングと後の回答が矛盾する場合は、ユーザーの最新の回答を優先し、変更を Clarifications に記録します。

4. 測定可能な成功基準を記述する

品質、量、時間、コスト、可用性、精度、または割合を示す成功基準には、観測可能な目標を含める必要があります。

次のような曖昧な形容詞は使わないでください：

• 速い；
• スケーラブル；
• 信頼性が高い；
• 簡単；
• 大量；
• 高精度。

数値がブレインストーミングで裏付けられているか、ユーザーが確認した場合にのみ、指標に変換します。

数値が不足している場合は質問します。捏造してはいけません。

5. EARS で受け入れテストを記述する

references/EARS.md を読みます。

各受け入れテストは、次の条件を満たす必要があります。

• 観察可能な振る舞いを表現すること。
• 認識されている EARS パターンを使用すること。
• EARS のアンカーワードを英語のまま使用すること：When、While、If、then、Where、shall。
• 主要な振る舞いを 1 つだけ含めること。

起こり得る望ましくないトリガーがある場合は、If ... then ... shall ... を使ったテストを少なくとも 1 つ含めます。

バグ修正の場合は、shall continue to を使った非回帰要件を少なくとも 1 つ含めます。

曖昧、またはテストできない受け入れテストが残っている間は、完了にしないでください。

6. Clarity Score を計算する

次の項目を 0～3 点で採点します。

• Problem；
• Users；
• Goals；
• Success；
• Scope。

評価基準：

• 0 = 欠落している；
• 1 = 曖昧、または不完全；
• 2 = 明確だが、詳細が不足している；
• 3 = 明快で、実行に移せる。

合計点は最大 15 点です。

DEFINE を準備完了とするには、最低 12/15 が必要です。

ゲートを通過するために、点数を水増ししないでください。

7. 推測せずに明確化する

references/CLARIFY.md を読みます。

次の 9 つのカテゴリを確認します。

1. Scope；
2. Data model；
3. UX flow；
4. NFRs；
5. Integrations；
6. Edge cases；
7. Constraints；
8. Terminology；
9. Done signal。

各カテゴリを Clear、Partial、Missing のいずれかに分類します。

DEFINE に影響する Partial と Missing については、客観的な質問を内部で作成します。

1 回のやり取りにつき、主な質問は 1 つにすることを優先します。状況により複数の質問をまとめる場合も、1 回のやり取りで最大 5 つまでとします。

明確な選択肢がある場合：

• 複数選択式にする；
• 2～4 個の選択肢を提示する；
• 推奨する選択肢を先頭にする；
• 必要に応じて自由回答も可能にする。

回答を受け取るたびに：

• DEFINE 本文の曖昧さを解消する；
• ## Clarifications に決定事項を記録する；
• 影響を受ける Clarity Score の項目を再計算する。

8. LLM Prompts の使用を検出する

LLM Prompts を true または false に設定します。

ランタイムプロンプトの明確な兆候、または弱い兆候の組み合わせが十分にある場合は、true にします。たとえば、次のようなものがあります。

• LLM のプロバイダー／モデルが明示されている；
• system prompt、user prompt、RAG、embeddings、classifier、synthesizer；
• LLM を使用する chatbot、agent、自動応答、レポート生成機能；
• プロンプト専用のパスまたはコンポーネント。

該当する兆候がない場合は、false にします。

弱い兆候が 1 つだけで、意図が曖昧な場合は、ユーザーに質問します。

その根拠を Notes に記録します。

9. Verify Gate を定義する

references/VERIFY_GATE.md を読みます。

DEFINE には、次の項目を含む verify_gate ブロックを 1 つだけ記述します。

• kind；
• cmd；
• pass_when；
• threshold；
• manual_fallback。

使用できる kind：

• test；
• smoke；
• eval；
• typecheck；
• manual-ux。

Acceptance Tests の性質に基づいて種類を決めます。

受講者が初めての場合は、質問は 1 つだけです。「正常に動作したときに 0 を返すコマンドはありますか？」はい → そのコマンドを使って test にします； いいえ → manual-ux にし、3～5 個の「…を開き、…を確認しました」という文を記述します（VERIFY_GATE.md の枠組み、例は assets/DEFINE_EXEMPLO.md）。

プロジェクトのコマンドを捏造しないでください。

提供された資料から実際のコマンドを確実に推測できない場合：

• 振る舞いを検証するコマンドを質問する；または
• 妥当なゲートの選択肢から選ぶようユーザーに依頼する；
• 受け入れの判定が本質的に人間によるもの、または視覚的なものである場合や、質問された受講者がコマンドは存在しないと回答した場合は manual-ux を使います。質問を省略する近道として使ってはいけません。

有効な Verify Gate がなければ、DEFINE は準備完了ではありません。

10. Open Questions を解決する

## Open Questions に、作業を妨げる曖昧さを残してはいけません。

完了する前に：

• スコープ、振る舞い、成功基準、受け入れテスト、Verify Gate に影響する項目をすべて解決する；
• Design に進むうえで妨げにならない質問だけを残す；
• 該当する質問がない場合は None - ready for Design. と記述する。

11. ドキュメントを検証する

filesystem と Python が利用可能な場合は、次を実行します。

python scripts/validate_define.py <caminho-do-DEFINE.md>

スクリプトの出力を構造上の lint として扱います。スクリプトは意味的な判断の代わりにはなりません。

ドキュメントの完成を宣言する前に、失敗を修正します。

12. DEFINE を生成して保存する

推奨ファイル名： DEFINE_{FEATURE_NAME}.md

保存場所。 プロジェクトのルートにある sdd/ に保存します。どのエージェントからも同じように見えるフォルダーです。プロジェクトに .claude/sdd/ がすでにある場合は、引き続きそのフォルダーを使用します。5 つのフェーズのドキュメントはサブフォルダーを作らず、同じ場所に保存します。

書き込み可能な filesystem がある場合は、sdd/DEFINE_{FEATURE_NAME}.md（そのフォルダーがすでにある場合は .claude/sdd/DEFINE_{FEATURE_NAME}.md）として保存します。

filesystem がない場合は、プラットフォームで可能なら、完全な Markdown を .md ファイルとしてダウンロードできるように提供します。

次の場合は Ready for Design と宣言しません。

• Clarity Score < 12/15
• 解決を妨げる曖昧さがある
• Acceptance Tests が EARS のルールを満たしていない
• 関連する Success Criteria が測定可能でない
• Verify Gate がない、または不完全である

13. 標準のハンドオフで終了する

ドキュメントの最後のセクションは、次のとおりでなければなりません。

## Next Step

Execute o **SDD Design by RDD**.

このテキストの後に、スラッシュコマンド、パス、アップロード手順、GPT/Skill への言及、並行して行うアクションを追加しないでください。

検証と品質チェックリスト

DEFINE の完成と判断する前に、次を確認します。

• Brainstorm を最初から最後まで読んだ。
• Brainstorm で事前に検証された決定を維持した。
• ドキュメントで assets/DEFINE_TEMPLATE.md を使用している。
• Problem Statement が具体的である。
• pain point を持つ Target User が少なくとも 1 人いる。
• Goals に優先順位が付いている。
• 関連する Success Criteria が測定可能である。
• Acceptance Tests が EARS を使用している。
• 想定される望ましくないトリガーに対する If/Then テストがある。
• 該当する場合、バグ修正に shall continue to が含まれている。
• 9 つの明確化カテゴリをすべて確認した。
• 未解決の、解決を妨げる曖昧さがない。
• Clarity Score が >= 12/15 である。
• Out of Scope が明示されている。
• Constraints と assumptions が分けられている。
• Technical Context に、根拠とともに LLM Prompts: true または false が含まれている。
• 有効な Verify Gate がちょうど 1 つある。
• Verify Gate に架空のコマンドが含まれていない。
• Open Questions に、解決を妨げる質問が含まれていない。
• 実行可能な場合、scripts/validate_define.py の lint が成功する。
• 最終ファイルの名前が DEFINE_{FEATURE_NAME}.md である。
• Next Step には Execute o **SDD Design by RDD**. のみが含まれている。

例外の取り扱い

• Brainstorm がない場合： Markdown ファイルを依頼します。Brainstorm を黙って再構築しないでください。
• Brainstorm が不完全な場合： 現在ある内容を抽出し、必要な不足点だけを明確化します。
• Brainstorm に矛盾がある場合： 要件を正式化する前に、どの決定を優先するか確認します。
• ユーザーが Brainstorm の決定を変更する場合： 最新の決定を受け入れ、関連するセクションを更新し、Clarifications に記録します。
• Clarity Score < 12 の場合： 明確化を続け、準備完了としません。
• メトリックに数値がない場合： 目標値を尋ねます。数値を捏造しないでください。
• Verify Gate のコマンドが不明な場合： 質問します。プロジェクトのコマンドを捏造しないでください。
• コード／リポジトリにアクセスできない場合： パス、テスト、インフラストラクチャを調査したと主張しないでください。
• ユーザーが未解決のブロッカーを残したまま終了したい場合： 終了のハンドオフは付けず、ステータスが Needs Clarification のドラフトのみを生成します。
• 機能にインターフェースがない場合： スコープに根拠があれば、UX flow を N/A にできます。人為的に UI を作らないでください。
• 機能が純粋に UX の場合： 人間が確認するための客観的なチェックリストがあれば、manual-ux を使用できます。

例

想定入力

ファイル： BRAINSTORM_CONCILIACAO_BANCARIA.md

Skill は以下を行う必要があります：

1. 問題、ユーザー、選択されたアプローチ、YAGNI、提案された要件を抽出する；
2. DEFINE のドラフトを作成する；
3. 指標、差異の処理、サポート対象の形式、検証可能なゲートなどの不足事項を特定する；
4. 必要なことだけを質問する；
5. DEFINE_CONCILIACAO_BANCARIA.md を生成する。

確認の質問

Brainstorm に「処理は速くなければならない」とだけ書かれている場合、任意の数値に置き換えないでください。

たとえば、次のように質問します： 抽出表と総勘定元帳の組み合わせを処理する際、許容される最大時間はどれくらいですか：（a）最大30秒［推奨］、（b）最大60秒、（c）最大2分、（d）その他？

最終ハンドオフ

## Next Step

Execute o **SDD Design by RDD**.

---

RDD による SDD Open の一部 — https://github.com/robertodiasduarte/sdd-open