aep-design

設計

統合ブランチ（$BASE — /aep-git-ref の「$BASE の解決」に従って解決します）で、インタラクティブに機能を設計します。問題を調査し、解決策を提案し、設計をレビューして、成果物をコミットします。これらすべてをユーザーとの会話の中で行います。

この工程の位置づけ：

/aep-onboard → /aep-scaffold → [ /aep-design → /aep-launch → /aep-build → /aep-wrap ]
                          ▲ you are here

セッション： メインセッションでユーザーと対話します 入力： 機能のアイデアまたはユーザーのリクエスト（必要に応じて製品コンテキストを参考にします） 出力： 統合ブランチにコミットされた OpenSpec の変更（提案、設計、仕様、タスク）

---

動作モード

起動時に自動検出します。

ls product-context.yaml 2>/dev/null

• スタンドアロン（product-context.yaml がない）— 機能のライフサイクルを独立して実行し、「前提条件」に進みます。
• 製品サイクル（product-context.yaml がある）— 機能は /aep-envision → /aep-map → /aep-dispatch → /aep-design のストーリーです。ディスパッチされたストーリーのコンテキスト（受け入れ基準、インターフェースの義務、既存の変更）が各フェーズの前にどのように読み込まれるかについては、references/modes.md を参照してください。

---

前提条件

1 行で行う確認が 2 つあります。/aep-onboard は不足しているツールをインストールし、/aep-scaffold は不足している OpenSpec スキルをインストールします。

which git openspec >/dev/null 2>&1 && { which gh >/dev/null 2>&1 || which glab >/dev/null 2>&1; } || echo "MISSING cli tool → run /aep-onboard"
ls .claude/skills/openspec-{explore,propose,apply-change,archive-change}/SKILL.md >/dev/null 2>&1 || echo "MISSING openspec skill → run /aep-scaffold"

---

ワークフローモードの選択

設計の前に、フルまたはライトのワークフローモードを選択します。この選択は以下のフェーズ 3 を規定し、/aep-launch と /aep-build にも引き継がれます。2 つのモード、選択基準、選択内容の記録方法、そして launch と build でその選択を反映する方法については、references/workflow-modes.md を参照してください。

---

フェーズ 1：OpenSpec の調査

/opsx:explore

ユーザーと要件およびスコープを明確にし、関連するパターンをコードベースで調査して、リスクと不明点を特定します。必要に応じて、docs/ にアーキテクチャに関するメモを作成します。

事後条件： 要件、スコープ、リスクが変更ディレクトリ（openspec/changes/<change-name>/）に記録されています。

---

フェーズ 2：OpenSpec の提案

/opsx:propose

OpenSpec の変更一式を生成します。proposal.md（内容と理由）、design.md（方法、主な決定事項、リスク）、specs/**/*.md（要件とシナリオ）、tasks.md（実装チェックリスト）が含まれます。ストーリーがディスパッチ済みの場合、変更はすでに存在するため、/opsx:propose で内容を改良します。

事後条件： openspec/changes/<change-name>/proposal.md が存在します（design.md、specs/、tasks.md とともに）。

---

フェーズ 3：設計レビュー

スコープ（アーキテクチャ、インターフェース、タスクの分割）を、非機能面からレビューします。

1. セキュリティ — 認証の欠落、インジェクションの可能性、データ漏えいはありませんか？
2. パフォーマンス — N+1 クエリ、大きなペイロード、ブロッキング処理はありませんか？
3. 既存のパターン — コードベースの規約に従っていますか？
4. エッジケース — 並行処理、競合状態、障害モードを考慮していますか？

調整が必要な場合は、OpenSpec の変更ファイルを直接更新します。

ライトモード： フェーズ 3 を完全にスキップします。

事後条件： ユーザーが設計を承認し、その承認が proposal.md（承認メモまたはチェック済みのボックス）に記録されています。

---

統合ブランチへのコミット

変更ディレクトリとアーキテクチャに関するドキュメントがあれば、それも $BASE にコントロールプレーンコミットとしてコミットします。/aep-git-ref の「コントロールプレーンコミット」に従い、$BASE は /aep-git-ref の「$BASE の解決」に従って解決してください。git add openspec/changes/<change-name>/ docs/ で明示的にステージし、コミットメッセージには feat: add <change-name> architecture doc and OpenSpec change を指定します。これにより、$BASE からワークスペースを作成したときに、すべての成果物が揃います。

事後条件： 変更ディレクトリが $BASE にコミットされ、プッシュされています。

---

次のステップ

設計が完了しました。続いて /aep-launch に進み、機能を実装するための自律型ワークスペースセッションを起動します。