design

design — 要件定義・基本設計・詳細設計

このスキルの役割

開発対象の機能について、以下の3フェーズを順番に進め、ドキュメントとして残す。

1. 要件定義 — 「何を作るか」「なぜ作るか」を確定する
2. 基本設計 — システム全体の構造と振る舞いを設計する
3. 詳細設計 — 実装に必要なクラス・関数・スキーマレベルの設計を行う

成果物は docs/design/<feature-slug>/ 配下に保存し、後続の implement / verify Skill が参照する。

nike CLI の活用

テンプレート書き出しは nike CLI に任せて AI トークンを節約する。CLI のパスはプラグイン環境で ${CLAUDE_PLUGIN_ROOT}/scripts/nike.py、ローカル開発では scripts/nike.py。

やりたいこと	コマンド	効果
新機能のテンプレ3点生成	python3 <nike.py> init <slug> --name "<人間向け名>"	requirements/basic-design/detailed-design を一発作成
既存 feature の状況確認	python3 <nike.py> status [<slug>]	全 feature のフェーズ完了状況を JSON で取得
設計ドキュメントの lint	python3 <nike.py> validate <slug>	FR/AC フォーマット崩れ・ID 重複・必須セクション欠落を事前検出

CLI は決定的な処理だけを行う。実際の内容は AI が Edit ツールで埋める。

使い方

ステップ 1: スラグ確定 + 雛形生成

ユーザーから機能名を受け取り、kebab-case のスラグを決定（例: 「ユーザー認証」→ user-auth）。判断に迷う場合のみ確認する。

nike status で既存 feature をチェックし、同名なら既存設計の更新として扱う。新規なら:

python3 <nike.py> init <slug> --name "<人間向け名>"

これで docs/design/<slug>/{requirements,basic-design,detailed-design}.md が生成される。

ステップ 2: 要件定義 (requirements.md)

生成された requirements.md を Edit で埋める。ユーザーに以下をヒアリング（一気に聞かず関連 2-3 個ずつ）。

• 背景・目的: なぜこの機能が必要か。誰のどんな課題を解くか。
• スコープ: やること / やらないこと
• ユーザーストーリー: 「〇〇として、〜したい、なぜなら〜」形式で 3-7 件
• 機能要件: FR-XX 形式。各 FR に受け入れ基準を 「Given <前提>, When <操作>, Then <結果>」 形式で記述（この形式は nike parse-requirements がパースできる正規形）
• 非機能要件: 性能、可用性、セキュリティ、保守性、互換性
• 制約条件: 技術スタック、外部依存、規約、期限など
• 前提条件: 想定する環境やデータ状態

書き終えたらユーザーに見せ、合意を得てから次へ進む。

ステップ 3: 基本設計 (basic-design.md)

requirements.md に沿って以下を埋める。既存コードがあれば必ず読み、整合性を取る。

• アーキテクチャ概要: コンポーネント図 (Mermaid graph TB) と各層の責務
• 主要コンポーネント: それぞれの役割、入出力、依存関係
• データフロー: 主要シナリオごとのシーケンス図 (sequenceDiagram)
• データモデル: ER 図 (erDiagram)
• 外部インターフェース: API、CLI、UI など外から見た振る舞い
• エラー処理方針: どこでどう扱うか
• 設計判断ログ: 採用した方針と却下した代替案、理由

書き終えたらユーザーに合意を取る。

ステップ 4: 詳細設計 (detailed-design.md)

basic-design.md を実装可能な粒度まで落とす。

• モジュール / ファイル構成: 新規追加・変更するファイルのツリー
• クラス・関数仕様: シグネチャ、パラメータ、戻り値、副作用、例外
• API 仕様: エンドポイント、メソッド、リクエスト/レスポンススキーマ、ステータスコード
• DB スキーマ: テーブル定義、インデックス、マイグレーション方針
• 状態遷移: 必要なら stateDiagram-v2
• 疑似コード: 複雑なロジックは擬似コードで示す
• テスト観点: ユニット / 統合 / E2E それぞれで何を検証するか
• 実装ステップ: 実装順序の提案（依存関係を考慮）

受け入れ基準の記述ルール（重要）

nike parse-requirements が後続フェーズで FR/AC を自動抽出する。以下のフォーマットを守ること:

### FR-01: <機能名>
**説明**: <一文>

**受け入れ基準**:
- Given <前提>, When <操作>, Then <結果>
- Given <前提>, When <操作>, Then <結果>

• 見出しレベル ###、ID は FR- + 連番
• 受け入れ基準は - Given ..., When ..., Then ... の一行形式（読点は , ， 、 のいずれも可）
• 改行を挟まず一行で書く（複雑なら複数 AC に分割）

この形式を崩すと verify Skill の自動 AC 表生成が動かない。

仕上げ前の検証

各フェーズ書き終えたら、ユーザー合意を取る前に以下を実行して構造的な問題が無いことを確認する:

python3 <nike.py> validate <slug>

• status: ok → 構造 OK。ユーザー合意のステップへ
• status: warnings → 警告内容を確認、必要なら修正
• status: errors → 必ず修正してから次のフェーズへ進む

進め方の原則

• 一度に全部書こうとしない。フェーズごとにユーザーと合意を取りながら進める。
• 既存コードを必ず確認する。設計が現実のコードベースと矛盾していないかチェックする。
• わからないことは推測せず質問する。ただし質問はまとめて。
• Mermaid を活用する。図はテキストで残し、レビューしやすくする。
• 過度に詳細な記述は避け、実装者が判断すべき部分は意図的に余白を残す。
• テンプレート書き出しは nike init に任せ、AI トークンは内容の充填と判断に使う。
• 各フェーズの仕上げで nike validate を回し、構造崩れを早期検出する。