requirements-designlisted

# 要求と受け入れ条件 実装を始める前に、**何を満たせば完了なのか**を観測可能な形へ確定させる。 ## この Skill の責務 | 問い | 担当 | | --- | --- | | 何を満たすか（受け入れ条件・仕様） | この Skill | | どう分解するか（タスク・順序・対象ファイル） | `implementation-plan` | | どう作るか（失敗するテスト → 実装） | `tdd-cycle` | | 満たしたと言えるか（証跡） | `quality-gates` | 受け入れ条件のない計画は、完了判定ができない。逆に、受け入れ条件だけあって分解がない 状態は問題ない（分解は `implementation-plan` が続けて行う）。 `tdd-cycle` / `quality-gates` は開発ループの後段を担う Skill で、順次追加している。 導入されていない環境では、実装とテストは対象プロジェクトの既存手順に従う。 ## 使う場面 - 新しい振る舞いを追加する、既存の振る舞いを変える - 依頼文に「いい感じに」「使いやすく」「速く」のような評価語が含まれる - バグ修正で、正しい挙動が依頼文から一意に決まらない - 複数の解釈が成り立ち、選んだ解釈によって実装が変わる ## 使わない場面 - 文言・書式・設定値の変更で、振る舞いが変わらない - 受け入れ条件が依頼文にすでに検証可能な形で書かれている - 調査だけを依頼されており、変更を伴わない ## 手順 ### 1. 依頼を要約せずに写す 最初に依頼文を**原文のまま**記録する。要約は��釈を含み、後から「そう言っていない」と 食い違う原因になる。原文と、そこから導いた解釈を別の欄に分けて書く。 ### 2. 曖昧語を検出して具体化する 依頼文から評価語・程度語を洗い出し、観測できる量へ言い換える。言い換えが自分で決められない ものは 3 の前提として扱う。 | 依頼文の語 | 具体化の例 | | --- | --- | | 速くする | 対象操作の応答時間を、現状の実測値を基準にどこまで縮めるか | | 使いやすく | どの操作が何手から何手になるか | | 安全にする | どの入力を拒否し、どの権限で何を許すか | | ちゃんと動く | どの入力に対してどの出力になるか | | 大量データに耐える | 件数・同時実行数の上限をいくつと置くか | | エラーを出さない | 失敗時に何を返し、どこへ記録するか | ### 3. 前提を明示する 決められない点は、放置せず次のどちらかにする。 | 状況 | 対応 | | --- | --- | | 選択を誤ると手戻りが大きい、または安全性・課金・外部公開に関わる | 利用者に質問して止まる | | 誤っても局所的に直せる | **前提として明記**して進める | 前提は「前提: 対象は既存の管理画面利用者のみで、外部公開はしない」のように、後から 成否を判定できる文で書く。「たぶん〜だろう」は前提ではない。 ### 4. 成功条件を観測可能な形へ変換する 受け入れ条件の形式と、満たすべき性質（観測可能・一意・テスト可能）は [references/acceptance-criteria.md](references/acceptance-criteria.md) に置く。 ### 5. 対象範囲と非対象を書く 扱うもの（含む）と扱わないもの（含まない）を対