designlisted

# 設計 実装を始める前に、**どう作るか**を文書として確定させる。担当する AI が変わっても同じ構成の 成果物になるよう、作る文書と書く内容を規約で決める。 ## この Skill の責務 | 問い | 担当 | | --- | --- | | どの工程が必要か（モード判定） | `development-workflow` | | 何を満たすか（受け入れ条件・仕様） | `requirements-design` | | **どう作るか（データ構造・入出力の契約・処理の流れ・決定の理由）** | この Skill | | どう分解するか（タスク・順序・対象ファイル） | `implementation-plan` | | 完了後に何を残すか | `plan-to-spec` | **モードの判定はしない。** どのモードに当たるかの基準は `development-workflow` が持つ。 この Skill は判定結果を受け取る側に徹する。 この文書で「タスク」と書くのは、`implementation-plan` が並べる作業の単位を指す。課題管理の issue のことではない。 ## 受け取るもの | 入力 | 出所 | 無いときの扱い | | --- | --- | --- | | モード | `development-workflow` の判定結果 | 判定を先に通す | | 受け入れ条件 | `requirements-design` が書いた仕様 | 仕様を先に書く（`legacy-refactor` を除く） | | 触る領域 | 受け入れ条件と対象範囲から読む | 設計の時点では実装の差分がないため、差分からは判断しない | **`legacy-refactor` は仕様を入力に取らない。** 工程表でも要求と受け入れ条件を通らないためである。 このモードでは、直す対象の現状の構造から触る領域を読む。 ## モードごとの成果物 **何を書くかはモードと領域の 2 つで決まる。** モードが水準を決め、領域が該当を決める。 成果物の要否、水準、設計の書き先、設計 Pull Request の要否、省いた理由の書き先は [references/deliverables.md](references/deliverables.md) を唯一の定義として読む。 ## 手順 ### 1. 触る領域を決める 受け入れ条件と対象範囲を読み、触る領域を決める。**「すべての変更」の行が指す参照に加えて、 当たった領域の参照だけ**を読む。 | 触る領域 | 読む参照 | | --- | --- | | すべての変更 | [references/design-template.md](references/design-template.md) / [references/deliverables.md](references/deliverables.md) / [references/decisions.md](references/decisions.md) | | 構成要素を追加・変更する、または配置・依存・反映先を変える | [references/system-architecture.md](references/system-architecture.md) | | 型・クラスを追加または変更する、または型を変えずに状態遷移か処理の順序を変える | [references/structure-