miyahiro/sdd

既存の仕様・コードに対する改善・修正の影響、互換性、移行、回帰テスト、承認し直す工程を調べたいときに使う。読み取りだけで行う。

新規開発・改善・修正を始めたいときの受付。変更 ID、目的、範囲、規模（標準・軽量）、承認者を決め、状態ファイルを作り、確認してからブランチを作る。

決められない前提や疑問を質問にまとめるとき、人の回答を状態ファイルと成果物へ反映するときに使う。今必要な質問と後の工程で決める質問を分ける。

承認済みの要件・外部設計から、DDD の責務・境界・不変条件、構成と依存、データ、処理、運用、テスト方針、設計判断記録（ADR）を設計するときに使う。

承認済みの要件から、UI・帳票・公開 API・CLI・外部連携など、利用者や外部システムに見える動きと例外を設計するときに使う。

要件・設計・要点・計画について、AI に1問ずつ問い詰めてもらい、判断の抜けや思い込みを承認の前に洗い出したいときに使う。「grill-me して」「深掘りして」「問い詰めて」。前の工程の承認は不要。

新しい仕組みを考えたい、アイデアの壁打ち、課題・価値・制約と候補を比較したいときに使う。前の工程の承認なしで検討できる。

工程の成果物がそろったとき、「承認します」と言われたとき、次の工程へ進みたいときに使う。対象を示して承認を求め、承認を状態ファイルとローカルのコミットに残す。

要件定義（機能別の要件・業務ルール・非機能要件・受入条件）を作るとき、軽量の案件で要件と設計の要点をまとめるときに使う。

要件・設計・タスク・コード・テストの整合性や、実装と受入条件の一致を、読み取りだけでレビューしたいときに使う。承認前の成果物にも使える。

仕様（docs/spec/current）と案件（docs/spec/changes）の形式を検査したいとき、案件の状況の要約（工程・状態・期限の来た質問・再承認・タスク）がほしいときに使う。承認・状況確認・タスク分解・レビューの手順からも使う。

承認済みの設計（軽量では要点）から、依存順のタスク、確認方法、完了の条件をタスク一覧（tasks.md）にまとめるときに使う。

タスク一覧のタスクを、テスト先行（Red・Green・Refactor）で実装し、確認の結果をタスク一覧に残すときに使う。

状況を教えて、記録を見せて、続きから再開して、と頼まれたときに使う。状態ファイルと検査スクリプトの要約だけで答え、成果物を個別に読まない。