sdd-build

SDD Build

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

実際の実装を行います。Buildを単独のドキュメント生成として扱わないでください。

概要フロー

1. Brainstorm、Define、Designを受け取ります。
2. プロジェクト／コードへの書き込みアクセスを確認します。
3. 要件、Verify Gate、LLM Prompts、File Manifestを抽出します。
4. 3つの成果物とプロジェクトの実際の状態との整合性を検証します。
5. 依存関係の順序に沿ってタスク計画を作成します。
6. 実行モードを提案し、最初の変更を加える前にユーザーの判断を求めます。
7. 該当するケースで、かつ対応できる場合は、ビルド前の外部レビューについて尋ねます。
8. 各タスクを慎重に実行し、段階ごとに検証します。
9. 必要に応じて、ドリフト検出とLLMプロンプトゲートを適用します。
10. 失敗時にはretry ladderを使用します。
11. File Manifestにmigrationがある場合に限り、Verify Gateの前に、プロジェクトの確認（名前とref）および読み取りによる証明を行ってから、データベースにmigrationを適用します。
12. DEFINEのVerify Gateをブロッキングゲートとして実行します。
13. プロジェクトで設定されている補完的な検証を実行します。
14. 該当するケースで、かつ対応できる場合は、ビルド後の外部レビューについて尋ねます。
15. assets/BUILD_REPORT_TEMPLATE.mdを使ってBUILD_REPORTを作成します。
16. python scripts/validate_build_report.py <BUILD_REPORT.md>でレポートを検証します。
17. 完全なビルドは、Execute o **SDD Handoff by RDD**.を実行する場合にのみ完了とします。

実行開始時にreferences/build-protocol.mdを読みます。 モードを選択する際にreferences/execution-modes.mdを読みます。 ユーザーがRalphを選択した場合はassets/PROGRESS_TEMPLATE.mdを使用します。 ユーザーがBriefsを選択した場合はassets/WORKER_BRIEF_TEMPLATE.mdを使用します。 File Manifestにmigrationがある場合は、適用する前にreferences/aplicar-migration.mdを読みます。 最終ゲートの前にreferences/verify-gate.mdを読みます。 LLMのランタイム／プロンプトに関する兆候がある場合にのみ、references/llm-prompt-gate.mdを読みます。 失敗が繰り返された場合、または正式な外部レビューを行う場合は、references/retry-and-advisor.mdを読みます。

学習者への話し方

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

段階	学習者向けの名前	このスキルでの手順
1	計画	1〜3
2	モード	4、5
3	タスク N/M	6〜11（Status のカウンター。各タスクの前に一文を添える）
4	Verify Gate	12〜14
5	レポート	15〜17

すべての応答は、次の順序にしてください（内容がない項目は省略します）：Status（Build: ✅ 1 … · ▶️ 3 Tarefas 2/5 · ⬜ 4 …； ✅ 完了（単に確認しただけではありません）；⏸️ 停止；➖ スキップ；段階に戻る場合、その理由は「今の状況」に記載します） · 行ったこと（コマンド出力は含めず、短い文で、学習者が選んだ内容を記録します） · 今の状況：段階 N — 名前（2〜4文。時間のかかる作業の前には、何を実行するか、返信は不要であることを伝えます） · あなたの判断（許可を求める場合：質問を太字にし、各選択肢の効果を添えます；自由回答の場合：質問を太字にし、「わかりません」という回答方法も示します；項目をまとめる場合は番号を付けます） · 次の手順（1行）。

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

必須入力

次のものを必須とします：

• BRAINSTORM_{FEATURE}.md；
• DEFINE_{FEATURE}.md；
• DESIGN_{FEATURE}.md；
• 該当機能に対応する、書き込み可能なプロジェクト／コード。

コードを編集する前に、3つのドキュメントをすべて最後まで読んでください。

プロジェクトにアクセスできない場合は、ユーザーに提供または接続を依頼してください。仕様ファイルだけをもとに、Build が完了したかのように装わないでください。

任意の入力：

• UX_REVIEW_{FEATURE}.md；
• プロジェクトのガイダンス（README、guidance、conventions、config）；
• sdd.config.yaml；
• 実際の lint/test/typecheck/build コマンド；
• エージェント／サブエージェントのツール；
• 外部レビュー用ツール；
• manual-ux の人による確認記録。

優先順位

動作と受け入れ条件について：

1. ユーザーの最新の明示的な回答；
2. DEFINE；
3. DESIGN；
4. Brainstorm。

技術的な実装について：

1. DESIGN；
2. プロジェクトの実際のコードと規約；
3. DEFINE；
4. Brainstorm。

意図のずれを防ぎ、YAGNI によって除外された項目が再び持ち込まれないよう、Brainstorm を活用してください。

要件、アーキテクチャ、契約を、通過させるために黙って変更してはいけません。実装に仕様変更が必要な場合は、該当タスクを停止し、ユーザーに確認してください。

1. コンテキストを読み込み、突き合わせる

Brainstorm から抽出する項目：

• 当初の意図；
• 選択したアプローチ；
• 却下した選択肢；
• YAGNI；
• 制約と依存関係。

DEFINE から抽出する項目：

• MUST／SHOULD／COULD；
• Success Criteria；
• Acceptance Tests；
• Out of Scope；
• Constraints；
• Verify Gate；
• LLM Prompts: true|false。

DESIGN から抽出する項目：

• アーキテクチャ；
• コンポーネント；
• Key Decisions；
• File Manifest；
• Code Patterns；
• 該当する場合は LLM Prompt Inventory；
• Data Flow；
• Integration Points；
• Testing Strategy；
• Error Handling；
• Configuration；
• Security；
• Observability；
• Requirements Traceability。

DEFINE が LLM Prompts: true で、DESIGN に ## LLM Prompts がない場合は停止し、Design の修正を依頼してください。 DEFINE が LLM Prompts: false で、DESIGN にプロンプトの一覧がある場合は停止し、不一致を解消してください。 File Manifest がない、または不完全な場合は停止し、実装に入る前に Design を修正してください。

2. プロジェクトを調査する

書き込みを行う前に：

• プロジェクトのルートを特定します；
• 関連するガイダンス／規約を読みます；
• 利用可能な場合は、バージョン管理の状態を確認します；
• Git がある場合は、現在のブランチを特定します；
• 変更するファイルを読みます；
• マニフェストに記載された直接依存関係を特定します；
• 実際に存在する検証コマンドを特定します；
• DESIGN のパスが引き続きプロジェクトに対応していることを確認します。

Git が利用可能な場合：

• フィーチャーブランチのポリシーがある場合は、デプロイ用／デフォルトのブランチで直接作業しないでください；
• 編集前に、適切なブランチを作成するか使用します；
• コミットや SHA を捏造しないでください。

Git が利用できない場合：

• プロジェクトを安全に編集できる場合に限り、続行します；
• ブランチ／コミットの帰属情報を利用できなかったことをレポートに記録します。

3. Build の計画を作成する

File Manifest をタスクに変換します。

各タスクについて、内部的に以下を記録します：

• manifest id；
• path；
• action；
• purpose；
• dependencies；
• 関連する acceptance criteria；
• 増分検証コマンド；
• security surface?；
• LLM prompt item?；
• owner/executor。

依存関係に従って順序付けます。 依存関係が未完了のタスクには着手しないでください。

タスク間でパスが重複する場合は、順番に実行します。

4. ユーザーとモードを選択する

references/execution-modes.md を読みます。

最初の変更を行う前に：

1. ケースの兆候を評価します；
2. モードを推奨します；
3. 具体的な兆候を根拠として、最初に推奨を提示します；
4. ユーザーに選択を求めます。

モード：

• default：現在のコンテキストで順次実行するループ；
• ralph：環境が再実行／サブエージェントに対応している場合、タスクごとにクリーンなコンテキストを使用；
• briefs：環境が並列処理に対応している場合、wave ごとにステートレスなワーカーを使用する実験的モード。

現在のプラットフォームで実行できないモードを提示しないでください。 ralph／briefs が利用できない場合は、その旨を質問時に説明し、default を推奨します。

BUILD_REPORT に以下を記録します：

• 兆候；
• 推奨；
• ユーザーの決定；
• 該当する場合は、プラットフォームで利用できない機能。

5. ビルド前レビューを判断する

正式な外部レビューは任意で、利用可能なツール／機能によって異なります。

以下の場合は実施を推奨します：

• 3 ファイル以上にまたがる新しいアーキテクチャ；
• セキュリティサーフェス；
• 公開ルート／キャッシュ対象ルート；
• 重要な契約の変更。

契約の変更を伴わない 1～2 ファイルの軽微な調整では、実施を推奨しません。

決定するのはユーザーです。

外部の機能が利用できない場合は、レビューを実施したかのように装わず、Not available と記録します。

正式なレビューを実施する場合は、references/retry-and-advisor.md に従い、すべての指摘を APPLIED または REBUTTED として記録します。

6. 各タスクを実行する

以下の 5 つの原則に従います：

1. 仮定を質問に変える：重要な曖昧さがあれば、質問します。
2. シンプルさ：マニフェストが求める内容を超えることはしません。
3. 的を絞った変更：必要がない限り、隣接するコードをリファクタリングしません。
4. コードより先に基準を定める：書き始める前に、検証方法を把握します。
5. エビデンス：検証を実行せずに成功を宣言しません。

各項目について：

1. 必要最小限のコンテキストを読み直します；
2. ドリフト検出を実行します；
3. 該当する場合はプロンプトゲートを実行します；
4. 予定されたパスのみを作成／変更／削除します；
5. 既存のスタイルと抽象化を維持します；
6. 増分検証を実行します；
7. コマンド、終了コード、関連する出力を記録します；
8. エビデンスがある場合に限り、タスクを完了としてマークします。

各タスクの前に、学習者に向けて、そのタスク（N／M）、実行する内容、返信は不要であることを一文で伝えます。カウンターは Status に表示します。

TODO／FIXME を要件の代わりに残さないでください。

7. ドリフト検出

各項目の前に実行します。

確認事項：

• パスまたは内容に、未記載のランタイムプロンプト／LLMが含まれていませんか？
• 実装に、想定されていないファイルが必要ではありませんか？
• 必要なコードによって、アーキテクチャ上の判断が変わりませんか？
• スコープ外の要件がありませんか？
• YAGNIによって削除された項目が再導入されていませんか？
• プロジェクトの実際の契約がDESIGNと矛盾していませんか？

ドリフトがある場合：

• 影響を受けるタスクを停止します。
• 相違点を説明します。
• ユーザーに選択肢を提示します。
• 変更が重要な場合は、まず仕様を更新します。
• BUILD_REPORTにイベントを記録します。

コード内でドリフトを黙って「吸収」してはいけません。

8. LLMプロンプトのゲート

次の場合はreferences/llm-prompt-gate.mdを読みます。

• LLM Prompts: trueの場合、または
• ドリフト検出でランタイムプロンプト／LLMが見つかった場合。

Designで確定しているはずのプロバイダー、モデル、最終プロンプト、出力スキーマを独自に作らないでください。

DESIGNでプロンプトエンジニアリングまたはループ仕様策定のスキルが求められているにもかかわらず、利用できない場合：

• プロンプトを即興で作成しません。
• 依存関係について確認し、記録します。
• 影響を受けるLLM関連の項目のみをブロックします。

9. リトライ手順

タスクの検証に失敗した場合は、references/retry-and-advisor.mdを使用します。

• 1回目の失敗：ローカルまたは単純なエラーであれば、同じコンテキストで修正します。
• 2回目の失敗：前の仮説を引き継がず、失敗した基準、エラー、必要な入力のみを使用して、新規タスクとして再実行します。
• 3回目の失敗：停止してブロッカーを記録します。基準を回避してはいけません。

プラットフォームが新規コンテキストでの再実行に対応していない場合：

• 最小限のコンテキストでFIX briefをシミュレートします。
• 制約を明示します。
• 新しいコンテキストが作成されたかのように装ってはいけません。

10. 段階的に検証する

タスクに最も適した実際のコマンドを使用します。例：

• 対応する単体テスト
• モジュールの型チェック
• ファイルのリント
• インポート／コンパイルチェック
• ローカルでのスモークテスト

コマンドを独自に作らないでください。 コマンドが存在しない場合は、プロジェクト／Designによって裏付けられる場合に限り、観測可能な方法を導き出します。それ以外の場合は確認してください。

タスクごとに結果を記録します。

11. データベースにマイグレーションを適用する

File Manifestにマイグレーション（*.sql、migrations/フォルダー、またはマイグレーションとして記載されたアクション）がある場合に限ります。 マイグレーションがない場合は、データベースについて触れずにスキップします。

references/aplicar-migration.mdを読みます。プロトコル全体はそこに記載されています。ルールの概要：

1. 質問せずに調査する： ツール（PATH上のSupabase CLI · セッション内のSupabase MCP · いずれもない場合はSQL Editorを使う手動手順）、接続先プロジェクト（supabase/.temp/project-ref、.env、プロジェクト一覧 — config.tomlのproject_idはローカル名であり、refではありません）、ローカルデータベースかリモートデータベースかを確認します。
2. プロジェクトが異なる場合は、何よりも先に停止する： ファイルが示すプロジェクトとCLI／MCPの接続先が異なる場合は、両方の名前とrefを提示し、ユーザーが選択するまで何も適用しません。
3. 確認は1回のみ： プロジェクト名とref、保留中のすべてのマイグレーションのSQL全文を提示し、破壊的なDDLが含まれる場合、または接続先が唯一のデータベース（本番環境）の場合は、目立つ形で警告します。
4. Verify Gateの前に適用する — 一度に1ステップずつ実行します。適用し、結果を読み取り、証明してからゲートに進みます。
5. 読み取りによって証明する（information_schema、pg_proc、pg_policies、migration list）。コマンドの終了コード0は証明になりません。適用済みのマイグレーションは再適用せず、「<日付>に適用済み」として記録します。
6. 記録する： sdd/ambiente.mdに- banco:キーを記載し、BUILD_REPORTの## Migrations aplicadasセクションに記録します（Files Changedに.sql／migrations/がある場合、バリデーターはこの記録を必須とします）。

サーバーの確認（declined）を回避するためにマイグレーションを書き換えてはいけません。ユーザーが確認していないSQLを適用してはいけません。

12. 実行を必須とする Verify Gate

references/verify-gate.mdを読みます。

DEFINE の Verify Gate が権威ある基準です。実行する前に、何を実行するか、回答は不要であることを一文でユーザーに伝えます。

cmd が実在し、安全で、利用可能なコマンドの場合に限り実行し、pass_whenを評価します。

• exit 0（通常のケース）：0は green → 続行します。それ以外のコード（pytest の 4や5も含む）は red → Build を完了できません。コードを修正して再実行します。
• exit Nまたはcontains: TEXT：指定されたコード、または出力内の指定されたテキストがある場合に限り green です。それ以外は red です。
• ツールが実行されなかったことを示す出力（コマンドが見つからない、依存関係が不足している）：判定不能 → ツール／インフラを解決します。green と判定してはいけません。
• kind: manual-ux（cmd: "N/A (manual-ux)"）：チェックリストを提示し、人間による確認結果の報告を待ちます。

red または判定不能の場合、成功を宣言してはいけません。 manual-ux の場合、報告書に確認者、日付、結果を必ず記載します。 独自の exit code 契約を持つ自動 runner は SpecGate/sdd-open のものです。references/verify-gate.mdを参照してください。生のcmdの exit code は、その表には従いません。 manifest に migration がある場合、red または判定不能になったときは、他の原因を調べる前にまず migration が未適用、または別のプロジェクトに適用された可能性を確認します。コードを変更する前に、セクション 11 の読み取りによる検証をもう一度行います。

13. 補足検証

gate の後、設定されている場合は次を実行します。

• lint
• typecheck
• 関連する test suite
• build／compile
• gate でカバーされていない smoke test

これらのチェックは Verify Gate を補完するものであり、代替にはなりません。

補足検証に失敗した場合、解決するか、明示的な blocker とするまで Build は未完了です。

14. Build 後のレビュー

外部ツールを利用できる場合、次のいずれかに該当するときは Build 後のレビューを推奨します。

• セキュリティを変更した
• 公開ルート／キャッシュ対象ルートを変更した
• 複数ファイルにまたがるロジックが複雑である
• ralph／briefs モードを使用した

軽微な修正の場合は推奨しません。

finding がある場合：

• 受け入れる前に、コード上で HIGH／MED を確認する
• 各指摘を APPLIED／REBUTTED として記録する
• HIGH を適用した後、Verify Gate を再実行する

15. BUILD_REPORT の生成

レポートの構造は、唯一の情報源であるassets/BUILD_REPORT_TEMPLATE.mdを使用します。

レポートは実行した検証の証拠に基づいて作成し、推定値を事実として提示してはいけません。

次を含めます。

• metadata と sources
• Mode Selection
• summary
• task execution
• 作成／変更／削除したファイル
• manifest に migration がある場合は、適用した migrations（ファイル、プロジェクト名と ref、日時、読み取りによる検証）
• 該当する場合は、生成／リファクタリングした prompts
• drift
• Verification Results
• Verify Gate receipt
• Acceptance Test Verification
• レビューを実施した場合は Advisor Ledger
• issues／deviations／blockers
• Final Status

Build がブロックされている場合：

• Status: Blockedを使用します
• Release への handoff を完了済みのように記載しません
• ブロックを解除するために必要な対応を示します

完了している場合：

• Status: Completeを使用します
• Final Status はCOMPLETEとします
• 標準の最終セクションを挿入します

16. BUILD_REPORT の検証

次を実行します。

python scripts/validate_build_report.py <caminho-do-BUILD_REPORT.md>

このスクリプトは、レポートの構造と基本的な整合性を検証します。

提出前にエラーを修正します。

17. 出力の保存

コード：

• File Manifest に記載されたパスに保存します。

レポート：

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

• sdd/BUILD_REPORT_{FEATURE}.mdとして保存します
• プロジェクトですでに.claude/sdd/（reports/を含む）を使用している場合は、既存の構成に従います

ユーザーに知らせずに、過去の成果物を上書きしてはいけません。

完了判定の品質ゲート

Build の完了を宣言する前に：

• Brainstorm を読んだ。
• DEFINE を読んだ。
• DESIGN を読んだ。
• 実際のプロジェクトにアクセスし、変更を加えた。
• ユーザーが選択したモードを記録した。
• File Manifest のすべての項目に対応した。
• 明示的な決定なしに、manifest の範囲外を変更していない。
• Drift を記録した。
• 証拠を添えて増分検証を実行した。
• Retry ladder を順守した。
• LLM Prompts=true の各 inventory 項目に receipt がある。
• セキュリティ項目を低コストの worker に委任していない。
• migration を含む manifest：学生がプロジェクト（名前と ref）を確認し、migration を適用した、または適用済みとして記録した。
• migration を含む manifest：読み取りによる証明と、レポート内の ## Migrations aplicadas セクションがある。
• migration を含む manifest：- banco: キーを sdd/ambiente.md に記録した。
• Verify Gate が green（0）、または manual-ux に人間の receipt がある。
• 適用可能な補完チェックに合格した。
• Acceptance Tests に証拠がある。
• Advisor findings がある場合、APPLIED/REBUTTED が付いている。
• 実装の未完了を示す TODO/FIXME がない。
• BUILD_REPORT が asset によって生成された。
• validate_build_report.py に合格した。
• Next Step の全文が Execute o **SDD Handoff by RDD**. のみで構成されている。

完了した Build の引き継ぎ

完了した BUILD_REPORT の最後のセクションは、正確に次のとおりでなければなりません：

## Next Step

Execute o **SDD Handoff by RDD**.

このテキストの後に、slash command、パス、アップロード手順、GPT/Skill への言及、または並行タスクを追加しないでください。

---

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