basic-design

basic-design: 基本設計書の作成・改訂

feature-spec と対をなす 基本設計書 1 本 を作る単機能スキル。成果物は docs/dev/<対象>/basic-design.md。仕様が「何を満たすか（REQ-#）」を定義するのに対し、 基本設計は 「どう実現するか」 を定義し、各機能を REQ-# へ紐づけて 要求に紐づかない機能 = スコープ外混入 を機械検出可能にする。

このスキルがやらないこと

• 実装しない。コードの作成・修正は範囲外。
• 仕様を書かない・改訂しない。要求の追加・変更が必要になったら /feature-spec <対象> の改訂モードへ回す（設計側で要求を勝手に足さない。それがスコープドリフトの発生源）。
• 詳細設計に踏み込みすぎない。クラス単位の内部実装・アルゴリズムの逐次手順は実装工程の 領分。基本設計は 境界（モジュール・インターフェース・データの流れ） までを確定させる。
• テスト成果物を作らない・直さない。docs/test/<対象>/ は testing スキル群の担当。

このスキルが従う原則

1. 単体動作（graceful degradation）

• 成果物の既定パスは docs/dev/<対象>/basic-design.md。
• プロジェクト側（CLAUDE.md / AGENTS.md 等）に成果物の配置規約があればそちらを優先する。
• 主入力: docs/dev/<対象>/spec.md（REQ-# を参照して機能一覧を導出する）。
• 任意入力（あれば整合を取るが、無くても成立する）:
  • docs/test/<対象>/test-analysis.md（テスト条件 TC-#。観測点・境界の洗い出しに使う）
  • docs/test/<対象>/test-case.md（テストケース CASE-#。設計が想定する入出力と突合する）
  • docs/dev/definition-of-done.md（完成の定義）
  • 任意のレビュードキュメント・ユーザーの直接指示
• spec.md が無くても作れる。ユーザーの直接指示・任意のレビュードキュメントを入力に 設計書を書いてよい。ただしその場合、機能一覧の「対応要求」列が - になり、 セルフ機械検査が「要求に紐づかない機能」として検出する。 先に /feature-spec <対象> を実行して仕様を確定させることを推奨する 旨を利用者へ伝え、 それでも進めるなら検査 NG が出ることを了解のうえで進める。

2. 調査優先 + 決定のみ質問

• 事実はリポジトリ調査で埋める。既存のモジュール構成・レイヤ分け・命名規約・ 依存の向き・公開契約は、利用者に訊く前に自分で調べる。既存構成に馴染む設計を出す。
• 利用者にしか決められない判断だけ を AskUserQuestion（推奨案を先頭）で確認する。 本スキルでは 設計方式の選択・既存構成を変えるか否か・分割の粒度・改訂提案の採否 が これに当たる。トレードオフのある選択は選択肢と代償を添えて訊く。
• 流れは 調査 → ドラフト提示 → 承認 → 規約パスへ書き込み。承認前に確定ファイルを書かない。

3. 記述品質

• 曖昧語（「適宜」「など」「柔軟に」「必要に応じて」）を設計文から排する。
• 略号・コードネームを定義なしで使わない。初出で正式名称・意味を併記する。
• インターフェースは 呼び出し側が実装なしで使える粒度 で書く（名前・入力・出力・ エラー時の振る舞い）。「よしなに返す」で終わらせない。

4. Progressive disclosure

• 本文は簡潔に保ち、雛形は references/ に置く。
• テンプレ: references/template.md（basic-design.md の雛形）。

機能一覧の REQ-# 契約（下流が依存する形式）

• 機能一覧は | 機能 | 対応要求 | 概要 | のテーブル で書く。
• 対応要求列に REQ-# を必ず書く。1 機能が複数要求にまたがるなら REQ-01/03 と併記する。
• 実在しない REQ-# を書かない（spec.md に無い ID は機械検査で検出される）。
• 要求に紐づかない機能を足さない。設計中に「これも要るのでは」と気づいたら、 勝手に足さず /feature-spec の改訂モードで要求として立てる ことを提案する。
• test-case.md があるときは CASE-# との対応が取れるかを確認する（機械検査も突合する）。