plan

/plan -- アーキテクチャを考慮した計画策定

概要

実装計画を作成する前に、プロジェクトのアーキテクチャパターンを考慮する、構造化された計画策定モードに入ります。いきなりコードに取りかかるのではなく、このコマンドでは意図的に立ち止まり、次の作業を行います。

• プロジェクトの現在のアーキテクチャを特定する（または推奨する）
• タスクが影響するレイヤー、モジュール、境界を整理する
• 明確な手順を含む、番号付きの実装計画を作成する
• コードを書く前に計画が確かなものになるまで見直す

計画は継続的に更新するドキュメントです。実装中に問題が発生した場合は、無理に進めず、いったん止めて計画を立て直してください。

使用するタイミング

• 3つ以上の実装手順を必要とする、簡単ではないタスク
• アーキテクチャ上の判断を伴うタスク（新しいモジュール、横断的な関心事、新しい境界づけられたコンテキスト）
• 複数のレイヤー（API、アプリケーション、ドメイン、インフラストラクチャ）にまたがる機能
• 複数の利用者に影響する可能性のあるリファクタリング
• ユーザーが「plan」「think through」「design this」「how should I approach」と言った場合

計画を省略する場合： 単一ファイルの変更、単純なバグ修正、誤字の修正、設定の微調整。

方法

ステップ 1：タスクを理解する

このタスクを対象とする承認済み仕様が docs/specs/ にあるか確認します。存在する場合は、それを信頼できる情報源とし、受け入れ基準を計画の手順に対応づけて、ステップ 2 に進みます。機能の規模が大きく、1文で説明できないため仕様書が必要であるにもかかわらず、仕様がない場合は、想定に基づいて計画を立てるのではなく、まず /spec を実行するよう提案します。それ以外の場合は、焦点を絞った質問でユーザーが作りたいものを明確にします。 明示されていない要件を推測してはいけません。

ステップ 2：アーキテクチャを検出する

architecture-advisor スキルを使用して、プロジェクトのアーキテクチャを判断します。

• 既存のアーキテクチャを示す要素（フォルダー構成、プロジェクト参照、パターン）を確認する
• アーキテクチャが確立されていない場合は、アーキテクチャに関する質問を実施する
• 適切なアーキテクチャ固有のスキル（vertical-slice、clean-architecture、ddd）を読み込む

ステップ 3：影響を受ける領域を整理する

タスクが影響するすべてのレイヤー、モジュール、境界を特定します。

• 新規または変更されるファイルがあるプロジェクト／フォルダーはどれですか？
• 横断的な関心事（認証、キャッシュ、検証、ロギング）はありますか？
• 既存のどのコードに影響しますか？影響範囲を把握するため、find_references と find_callers MCP ツールを使用します。
• データベースのマイグレーションは必要ですか？

ステップ 4：計画を作成する

次の構成で番号付きの計画を出力します。

## Plan: [Task Title]

**Architecture:** [Detected architecture]
**Affected layers:** [List]
**Estimated steps:** [Count]

### Steps
1. [Step] -- [Which file/layer] -- [Why this order]
2. ...

### Open Questions
- [Anything that needs user input before proceeding]

### Risks
- [Potential issues and mitigations]

ステップ 5：計画を見直す

計画を提示して、「この計画でよさそうですか？それとも、何か調整しましょうか？」と尋ねます。ユーザーが承認するまで修正します。承認されてから実装に進みます。

例

User: /plan Add a product catalog feature with search and filtering

Claude: Let me analyze your project structure first...

## Plan: Product Catalog Feature

**Architecture:** Vertical Slice Architecture
**Affected layers:** Features/, Infrastructure/Persistence/, Tests/
**Estimated steps:** 6

### Steps
1. Create Product entity + EF config -- Domain layer -- Foundation for everything else
2. Add migration -- Infrastructure -- Schema must exist before features
3. Scaffold GetProducts feature (with filtering) -- Features/Products/ -- Read path first
4. Scaffold CreateProduct feature -- Features/Products/ -- Write path
5. Add integration tests -- Tests/Features/Products/ -- Verify both features
6. Wire up OpenAPI metadata -- Features/Products/ -- Documentation

### Open Questions
- Should search be full-text (PostgreSQL tsvector) or simple LIKE?
- Do products need categories/tags for filtering?

Does this plan look right, or should I adjust anything?

関連項目

• /spec -- 1文で説明できない大きな機能は、まず仕様書を作成します
• /scaffold -- 計画の承認後にファイルを生成します
• /verify -- 計画の実装後に検証を実行します