| name | design-and-plan |
| description | 要求や仕様から、実装に渡せる構造判断、vertical slices、HITL/AFK 区分、behavior list、plan artifact を作る入口。 interview-with-docs 後に設計判断と実装計画を作りたいとき、既存 repo の変更を TDD 可能な slice に分けたいとき、multi-repo や境界設計が必要か判断したいとき。
|
design-and-plan — 設計を実装契約に変える
要求や仕様を、implement がそのまま TDD で進められる契約に落とします。
この skill は router です。標準設計で足りる場合は軽く進め、multi-repo や境界リスクがある場合だけ Balanced Coupling へ切り替えます。
こんなときに使う
- interview-with-docs 後の要求を実装可能な構造判断へ落としたいとき
- 既存 repo の変更を TDD 可能な vertical slice に分けたいとき
- HITL / AFK の切り分けを実装前に決めたいとき
- multi-repo や所有境界の設計が必要か判断したいとき
implement へ渡す handoff を作りたいとき
Core Loop
grill result / spec
-> goal and success criteria
-> route selection
-> structure decisions
-> behavior list
-> vertical slices
-> implementation handoff
判断表
| 状況 | ルート | 判断 |
|---|
| 単一 repo、既存 stack、通常の機能追加 | sub_skills/standard/ | 既定ルート |
| 新規 product / stack 未確定 / 大きな採用判断 | sub_skills/standard/ + 技術選定 checkpoint | MVP 技術選定を明示する |
| 複数 repo、shared library、SDK、microservice、別チーム所有 | sub_skills/balanced-coupling-design/ | provide / require と統合距離を見る |
| 境界が崩れている、分散モノリス化、過剰共有が疑われる | sub_skills/balanced-coupling-design/ | 結合の 3 次元で評価する |
迷ったら standard から始めます。境界設計が実際に問題になった時点で Balanced Coupling へ切り替えます。
共通の設計 lens
どのルートでも、次を短く確認します。
- Goal: 何が成立したら終わりか
- Success criteria: 観測可能な完了条件
- Structure: どこに責務を置き、どこを触らないか
- Interface as test surface: どの public interface で確認するか
- Vertical slices: 1 ユーザー行動または 1 acceptance condition ごとに切る
- HITL / AFK: 人間判断が必要な slice と自走できる slice を分ける
- Deletion pressure: 追加する抽象化が、消す・置き換える・狭める余地を残しているか
- Security boundary: 外部入力、認証/認可、機密情報、コマンド実行、ファイル I/O の境界
出力
最終的に implement へ渡せる implementation handoff を作ります。
handoff に含めるもの:
- ゴール
- 成功条件
- 対象外
- 構造判断
- public interface と behavior list
- vertical slices（HITL / AFK を明示）
- 各 slice の最初の test 観点
artifacts: フィールド（artifacts: conversation-only または保存した path の列挙）- 実行 command
- 未決定事項と戻り先
設計書が必要な場合、またはユーザーが設計書の保存を明示した場合は docs/design/NNN_TECHNICAL_DESIGN.md に保存します。
実装進行用の checklist が必要な場合、またはユーザーが計画書の保存を明示した場合は docs/plan/NNN_PLAN.md を作ります。
成果物の path、命名、番号共有は references/WORK_ARTIFACTS.md に従います。
注意点
- router に詳細プロセスを書き込まない。詳細は sub-skill に置く。
- MVP 技術選定を毎回通さない。既存 stack で自然に進められるなら省略する。
- Balanced Coupling を毎回通さない。multi-repo、所有境界、統合リスクがあるときだけ使う。
- 実装をここで始めない。handoff を作ったら
implement へ渡す。
- 仕様の穴を設計で埋めない。blocking unknown があれば
interview-with-docs に戻す。
共通リソース
_foundation/DDD_GLOSSARY.md — DDD と Balanced Coupling モデルの用語集_foundation/IMPLEMENTATION_HEURISTICS.md — サブドメイン分類から実装パターンを導く判断ツリー_foundation/TECH_SELECTION_HARNESS.md — 技術選定が必要な場合だけ読むreferences/WORK_ARTIFACTS.md — 成果物規約assets/NNN_PLAN_TEMPLATE.md — PLAN テンプレートsub_skills/standard/ — 既定ルートsub_skills/balanced-coupling-design/ — multi-repo / 境界設計ルート
