仕様駆動開発（SDD）— ガイド付きモード
ユーザーはSDDフローを知る必要はありません。あなたが推進します：毎ターン、プロジェクトの状態を把握し、自分でできることはすべて行い、推測できないことだけを質問し、最後にユーザーに次に何が起こるかを正確に伝えます。
すべての機能は spec.md → design.md → tasks.md → 実装 → review.md の順に進みます。テンプレートは ${CLAUDE_PLUGIN_ROOT}/skills/slate-sdd/templates/ にあります。テンプレートをコピーするシェルコマンドはすべて T="${CLAUDE_PLUGIN_ROOT}/skills/slate-sdd/templates"; で始めます（以下のスニペットでは $T を使用）。
ループ（スキルが使用されるたびに実行）
- 状態を検出（状態検出を参照）。これは静かに実行 — ファイルを読み取り、ユーザーに現在地を尋ねない。
- 入力を吸収。ユーザーから送られたもの —
task.mdのパス、ペーストされた文書、1文、「continue」、「ok」 — を現在のステップにマッピング（入力の処理を参照）。 - ステップの作業を自分で行う。あなたが知っている情報から文書をドラフト：入力、
docs/PRODUCT.md、docs/PRINCIPLES.md、docs/ARCHITECTURE.md、docs/GLOSSARY.md、およびコード自体。コードが答えるようなこと（スタック、コマンド、ファイルパス、既存のパターン）はコードベースを調べて、質問しない。各文書は書き方スタイルに従って書き、提示する前にセルフチェックを実行する。 - ギャップのみを質問（質問の仕方を参照）。合理的な確信を持ってすでにドラフトしたことを質問しない — それを表示し、ユーザーに修正させる。
- ガイドブロックで締めくくる（ガイドブロックを参照）。すべての返信は例外なくこれで終わる。
ユーザーが書いている言語でユーザーに話しかける。文書はプロジェクトの既存ドキュメントが使用している言語で書く（まだない場合は英語、ユーザーが別の指定をしない限り）。
状態検出
次の順序でチェックし、最初の一致で停止：
| # | 条件 | 現在のステップ |
|---|---|---|
| 1 | docs/PRODUCT.md または docs/PRINCIPLES.md が存在しない | セットアップ — プロジェクト文書 |
| 2 | PRODUCT.md/PRINCIPLES.md にまだ [placeholder] テキストが含まれている | セットアップ — 入力を完了 |
| 3 | ユーザーが新しい作業（ファイル、テキスト、アイデア）を送信し、それがアクティブな機能ではない | トリアージ 新しい作業 |
| 4 | アクティブな機能に status: draft の spec.md がある | 仕様 |
| 5 | spec.md 承認済み、design.md がないか status: draft | 設計 |
| 6 | design.md 承認済み、tasks.md にテンプレートのプレースホルダーがまだある | タスク（計画） |
| 7 | tasks.md に done でない T がある | 実装 — 次の T |
| 8 | すべての T が done、review.md が status: pending | レビュー |
| 9 | review.md が承認済み / 注釈付きで承認 | クローズ — メモリ + 状態、次に次の機能を提案 |
アクティブな機能 = docs/MEMORY.md → Current State → In progress に名前があるもの。空の場合は、review.md が承認されていない最も番号の大きい docs/specs/NNN-*/。複数が開いていてユーザーが名前を指定しなかった場合は、どれかを尋ねる（1つの質問、リスト表示）。
状態を素早く読み取る方法：
ls docs/ docs/specs/ 2>/dev/null
grep -H '^status:' docs/specs/*/*.md 2>/dev/null
grep -H -- '- \*\*Status:\*\*' docs/specs/*/tasks.md 2>/dev/null
入力の処理
task.md（または任意の .md/.txt）へのパス — 全文読む。完成したtasks.mdとしてではなく、生の要件として扱う：問題、振る舞い、例、エッジケース、制約、ファイルのヒントを収集。その後トリアージ。- ペーストされたテキストまたは1行のアイデア — 同上。
- "continue" / "próximo" / "ok" / "aprovado" / "pode seguir" — 現在の文書が承認待ちの場合、これは承認：その
statusを設定し、同じ返信内で次のステップに進む。そうでなければ、現在のステップを実行するだけ。 - 修正または回答 — 現在の文書に適用し、解決した
Qを更新し、ギャップを再チェックして続行。 - フローに関する質問 — 簡潔に回答し、ガイドブロックで再開。
トリアージ（新しい作業）
サイズを判断し、1行で下した判断を伝える：
- 小規模 — 明白、元に戻せる、約1～3ファイル、設計の選択肢なし（タイポ、小さなバグ、設定変更）。
tasks.md（docs/specs/NNN-name/内）のみを作成し、内容を記入し、直接実装に進む。ユーザーが希望しない限り、仕様/設計/レビューをスキップ。 - 機能 — 定義すべき振る舞いや設計上の選択があるもの。完全なフローを実行。
- 調査が必要 — 主要な選択肢が本当に不明（ライブラリ、アプローチ、ベンダー）。設計前に
research.mdを含む完全なフロー。
小規模と機能の間で迷った場合は、機能を選択し、ユーザーにショートカットを提案できると伝える。
次にフォルダを作成：
- 次の番号 =
docs/specs/内の最大NNN-+ 1（001から開始）。名前 = 入力からの短いケバブケース；尋ねない。 - テンプレートをコピー：
D=docs/specs/NNN-feature-name; mkdir -p "$D"
cp $T/specs/spec.md $T/specs/design.md $T/specs/tasks.md $T/specs/review.md "$D"/
# 調査が必要な場合のみ：
cp $T/specs/research.md "$D"/
- 入力から収集したすべてをすぐに適切な文書に配置：問題/AC/制約/範囲外 →
spec.md；実装のヒントとファイルパス →design.md/tasks.mdのメモとして保持（失わない；該当セクションに到達したら追加）。 docs/MEMORY.md→ Current State → In progress を機能IDとステップで更新。- 同じ返信で直接仕様ステップに続行。
ステップ
セットアップ
mkdir -p docs/decisions docs/specs
for f in PRODUCT PRINCIPLES ARCHITECTURE GLOSSARY MEMORY; do [ -f docs/$f.md ] || cp $T/$f.md docs/$f.md; done
[ -f docs/decisions/0000-template.md ] || cp $T/decisions/0000-template.md docs/decisions/
[ -f CLAUDE.md ] || cp $T/CLAUDE.md CLAUDE.md
既存のファイルを上書きしない。次に、質問する前にリポジトリから事前入力：package.json / pyproject.toml / go.mod / Cargo.toml / Makefile / CIファイル / README を読んで、スタック、コマンド、ディレクトリマップ、コンポーネントを入力。コードが教えられないことだけをユーザーに尋ねる：製品は何か、誰のためか、目標、非目標、ビジネスルール、チームルール。ユーザーが機能を持ってきた場合、セットアップは短く（PRODUCT + PRINCIPLES の基本）済ませ、機能に進む；ARCHITECTURE と GLOSSARY は後で段階的に入力可能。
仕様
入力から spec.md を入力。すべてのACは Given/When/Then 形式で、それ単体でテスト可能であること — 曖昧な要件を自分でACに書き換え、表示する。設計を妨げる各不明点は Q [blocking] に；軽微な不明点は Q [non-blocking] に、あなたの提案する回答を添えて。短い要約（問題、AC、範囲外、未解決のQ）を提示し、承認を求める。ゲート： blocking のQが未解決でなく、ユーザーが承認した（または質問なしで進めるよう指示した）場合のみ設計を開始 → status: approved に設定。
設計
docs/PRINCIPLES.md と docs/ARCHITECTURE.md を読み、関連するコードパスを調査。design.md を自分で完全にドラフト；すべてのACをカバー（どの部分がどのACをカバーするか明記）。ローカルの決定は理由とともに D エントリとして自分で行い、元に戻すのにコストがかかるか好みの問題である決定だけを、それぞれにあなたの推奨を添えてユーザーに提示。プロジェクト全体に影響する決定 → docs/decisions/ にADRを提案。短い要約を表示し、承認を求める。ゲート： 仕様と同じ。
タスク
仕様＋設計から tasks.md を入力：依存関係順の小さな T、それぞれに Covers、Files、および PRINCIPLES.md → コマンドからの実際のVerifyコマンド。すべてのACは少なくとも1つの T でカバー；すべてのエッジケース E にはテストがある。ユーザーが要求しない限り承認ゲートなし — タスクリストを表示し、実装に進む。
実装
一度に1つの T：in-progress に設定、実装、そのVerifyを実行、done（または理由とともに blocked）に設定。各 T の後、2～3行で報告し、何かが失敗した場合、T が PRINCIPLES.md と競合する場合、または完了に範囲外の何かが必要な場合を除き、次のものに続行 — その場合は停止して質問。docs/MEMORY.md → In progress を現在の T に向けたままにする。
レビュー
review.md を入力：実装レポート、結果とエビデンス付きのすべてのAC、完全なテスト/lint/ビルドコマンドの実行、PRINCIPLESレビューチェックリストの適用、所見のリスト。書き方スタイルに対して機能文書をチェック。各違反を minor 所見として記録。評決を提示。ユーザーが同意した場合は blocker/major 所見を修正し、再レビュー。
クローズ
永続的な教訓を docs/MEMORY.md に移動、Current State を更新（Done += この機能、In progress クリア）、PRODUCT.md → Capabilities に機能を追加、フォローアップからADRを作成。次に次の項目を提案（Next から、レビューのフォローアップから、または「次のタスクを送ってください」）。
質問の仕方
- 1ターンあたり最大 3～5 の質問、重要度順。番号付き、短く。
- すべての質問にはあなたの提案する回答を含める。ユーザーが「ok」/「1 ok, 2 não」などと返信できるように：
1. 期限切れのリンクにはエラーページを表示すべきですか？ → 提案：はい、「再送信」ボタン付きで。 AskUserQuestionツールが利用可能で、回答がいくつかの選択肢の中から選ぶものである場合、それを使用し、推奨オプションを最初に。- コード、ドキュメント、または入力がすでに答えていることを尋ねない。ユーザーに次にどのSDDステップを実行するかを尋ねない — それはあなたの仕事。
- ユーザーが「あなたが決めて」/「tanto faz」/「pode seguir」と言った場合、あなたの提案を取り、記録し（
Q → answerまたはDとして）、続行。
ガイドブロック
すべての返信をこのブロック（ユーザーの言語で）で終わらせ、ユーザーが何をすべきか考えなくて済むようにする：
---
📍 機能: NNN-feature-name · ステップ: 仕様 (2/6) [セットアップ · 仕様 · 設計 · タスク · 実装 · レビュー]
✅ 今回完了: <1行>
❓ あなたから必要なもの: <番号付き質問、または「なし」>
➡️ 次: <ユーザーが返信した後に正確に何が起こるか — 例：「'ok' と返信すると仕様を承認し、設計を書きます」>
ユーザーから何も必要ない場合は、その旨を伝え、「continue」で次に何を行うかを伝える。
ガイドブロックとチャットメッセージは、完全な書き方スタイルのセルフチェックを必要としない。短く直接的であること。
文書ルール
- すべての
[placeholder]、NNN、YYYY-MM-DDを置き換える。空のセクションはNone.になる — 見出しは決して削除しない。 - テキストをコピーする代わりに、ID（
AC、Q、D、T、E、F）を使用して文書間で相互参照する。 design.mdの前およびタスクの実装前にdocs/PRINCIPLES.mdを読む。- 要件が不明瞭な場合は、推測するのではなく
Qを追加して質問する。タスクがPRINCIPLES.mdと競合する場合は停止して質問する。 - 各事実は1つの文書に存在し、他の文書はそれを参照する。
書き方スタイル（すべての文書）
次のモデルがこれらの文書を読み、それに基づいて行動する。各文が1つの意味のみを持つように書く。これらのルールはすべての言語に適用される。
明瞭性と正確性（ASD-STE100 に触発）
- 1文につき1つのアイデア。 指示は最大20語。説明は最大25語。
- 1文につき1つの指示。 動作には命令形を使用。「
404を返す。」と書き、「システムはおそらく404を返すべきでしょう。」とは書かない。 - 能動態、現在形。 動作主を明示：ユーザー、システム、またはコンポーネント名。
- 1つの用語 = 1つの意味。
docs/GLOSSARY.mdの正確な用語を使用。同じ概念に同義語を使用しない。新しいドメイン用語を使用するときは、その用語をGLOSSARY.mdに追加する。 - 要件キーワード: must / must not / may（deve / não deve / pode）のみを使用。「should」、「ideally」、「try to」、「if possible」（「deveria」、「idealmente」、「tentar」、「se possível」）は使用しない。
- 定量化する。 曖昧な単語を数値、単位、または観察可能な結果に置き換える。数値なしでこれらの単語を使用しない：fast, slow, many, few, large, small, robust, easy, simple, properly, user-friendly, some, "etc.", "and so on"（rápido, lento, muitos, poucos, grande, robusto, fácil, adequado, alguns, "etc."）。
- 誤：「ページの読み込みが速い。」正：「ページは 2 秒未満 (p95) で読み込まれる。」
- 慣用句、比喩、ジョーク、つなぎ言葉、マーケティング調は禁止。
- 不明瞭な代名詞は禁止。 「それ」、「これ」、「あれ」が2つの名詞を指す可能性がある場合、名詞を繰り返す。
- 散文より構造。 リストとテーブルを優先。段落は最大3文。
- コード内の正確な名前。 識別子、パス、コマンド、フィールド、値をバッククォートで囲む。言い換えない。
第一原理
- 事実から始める。 習慣や類推は理由にならない。「他のプロジェクトがXをしている」は理由にならない。
- 重要な主張にはラベルを付ける：
- 事実 — 検証済み。ソースを明示：ファイルパス、コマンド出力、データ、または文書。
- 仮定 — 未検証。検証方法を書く。
- 決定 — 選択。事実または制約から導き出された理由を示す。
- 各決定を問題、
AC、または制約にトレースする。決定にトレースがない場合は削除する。 - 解決策の前にニーズ。 この順序で書く：問題 → 制約 → それらを満たす最も単純な解決策。
- 最も単純なオプションを最初に。 すべてのACを満たす最も単純なオプションを選択する。追加された各コンポーネント、依存関係、またはステップには、明示された理由が必要。
セルフチェック（文書を表示する前に実行）
-
[placeholder]、NNN、YYYY-MM-DDが残っていない。 - ルール5および6の禁止単語が残っていない。
- 各文がルール1の語数制限内である。
- 各ドメイン用語が
docs/GLOSSARY.mdにある。 - 各
Dおよび各決定に理由がある。 - 未検証の主張はそれぞれ仮定とラベル付けされ、検証方法がある。
参考
$T = ${CLAUDE_PLUGIN_ROOT}/skills/slate-sdd/templates/ 内のテンプレート：
PRODUCT.md、PRINCIPLES.md、ARCHITECTURE.md、GLOSSARY.md、MEMORY.md、CLAUDE.md— プロジェクトレベル、1回作成。decisions/0000-template.md— プロジェクト全体の決定ごとに1つのADR。specs/spec.md、design.md、tasks.md、review.md、research.md— 機能ごとに1セット。