design-spec

準備

対象のフィーチャー名を確認し、要件定義書の存在を確認する。

• .artifacts/features/<feature>/requirements.md が 存在する 場合: フェーズ 1 へ進む。
• 存在しない 場合: ユーザーへ通知し、先に define-reqs を実行するか、要件をインラインで提供するよう案内する。

フェーズ 1: 現状分析

• .artifacts/features/<feature>/requirements.md を読み込む。
• 既存コードベースがある場合は Grep / Glob でアーキテクチャ・パターン・規約を把握する。
• .artifacts/project_architecture.md が存在する場合は読み込み、既存構造との整合を取る。
• .artifacts/research/*.md が存在する場合は読み込み、調査結果を設計へ反映する。

フェーズ 2: 設計

仕様書で以下の領域を扱う。

• 技術スタック: 言語・フレームワーク・外部サービスの選定と根拠。
• アーキテクチャ: 全体構造・データフロー・提案するディレクトリ構成。
• データモデル / スキーマ: エンティティ・型定義・バリデーションルール。
• インターフェース仕様: API エンドポイント・関数シグネチャ・状態管理方針。
• UI/UX コンポーネント: 主要コンポーネント・画面遷移・インタラクション（該当する場合）。
• テスト戦略: 単体テスト対象・ハッピーパス / エラーパスの定義・テストコマンド例。
• 非機能要件: セキュリティ・パフォーマンス・スケーラビリティ・保守性。
• トレードオフ分析: 重要な設計決定ごとにメリット・デメリット・代替案・決定根拠を記録する。

曖昧な点や不足要件があれば、書き出し前に AskUserQuestion で確認する。

アーキテクチャ原則

• モジュール性と関心の分離: 単一責任・高凝集 / 低結合・明確なインターフェース。
• スケーラビリティ: 水平スケーリング能力・可能な限りステートレス設計。
• 保守性: 明確なコード構成・一貫したパターン・テストのしやすさ。
• セキュリティ: セキュア・バイ・デフォルト・最小権限の原則・監査証跡。
• パフォーマンス: ネットワークリクエストの最小化・適切なキャッシュ・遅延ロード。

検出すべきアンチパターン

設計中に以下を検出した場合はフラグを立てて対処する。

• Big Ball of Mud: 明確な構造がない。
• Golden Hammer: 同じ解決策をあらゆる問題に適用する。
• Premature Optimization: 計測なしに最適化する。
• Tight Coupling: コンポーネント間の過度な依存。
• God Object: 1 つのクラス / モジュールがすべてを担う。
• Analysis Paralysis: 過剰な計画で実装が進まない。

フェーズ 3: 完了の扱い

設計が固まった時点で本スキルの責務は完了とする。成果物ファイルへの書き出し・ユーザーへの報告・ 次フェーズへの案内は本スキルでは行わない。これらは呼び出し元（コマンドまたはエージェント定義）が担う。