アーキテクチャ優先計画は何をしますか？

この計画は、何よりも次の2つの問いに答えます: 構成要素は何か、それらはどのように接続されるか（図）、およびそれらの間の正確な契約は何か（インターフェース）。タスクリストは二次的なものです。有能な実装者は、優れたインターフェースからタスクを導き出すことができます。

計画はローカルで個人的なものです: ~/plans/<YYYY-MM-DD>-<slug>/。Markdownファイルが信頼できる唯一の情報源です。Artifactはそのビューです。

1. リクエストを理解する

目標を1～2文で言い換え、明示的にスコープ外とするものも示します。
要件が曖昧な場合は質問します（下記の質問を参照）。設計を変える可能性がある質問に限ります。回答が新しい分岐を生む場合は、もう1ラウンド行います。
適切なデフォルトがコードの既存動作に依存する場合、まずステップ2を簡単に実施し、推奨事項が推測ではなくリポジトリに基づくようにします。

質問

このステップ、ディベート後、そして反復中のユーザーへの質問はすべて、AskUserQuestionツールを介して行い、チャット内のリストとしては決して行いません。ユーザーはほとんどの質問に1クリックで回答できる必要があります:

推奨値を事前に入力する。自分が選択するであろうオプションを最初に配置し、ラベルの最後に (推奨)を付けます。コードベースの既存パターン、AGENTS.md、および設計を最もシンプルに保つものに基づいて決定します。
質問ごとに2～4の具体的な選択肢を、それぞれ実際の選択肢として、設計にとって何を意味するかの説明とともに提示します（例：「マイグレーションを追加」、「useCursorFeedを再利用」）。「その他」オプションは追加しません。ツールが自由記述用に1つ追加します。
自己完結型。ユーザーにはダイアログのみが表示される可能性があるため、各質問には機能名と決定対象の事項を明記し、質問の根拠となった調査結果があれば簡潔に記述します。
1回の呼び出しにつき最大4つの質問までとし、それぞれに短いheaderチップ（12文字以内、「Storage」、「Auth」、「Scope」など）を付けます。関連する質問はまとめ、残りは別の呼び出しで行います。
multiSelect は、選択肢が排他的でない場合にのみ使用します（例：「どの画面にこれを適用するか？」）。具体的な成果物（インターフェーススケッチ、スキーマ、ASCIIレイアウト）を比較する場合は**preview** を使用します。
明確な答えがあり、変更が容易に元に戻せる選択肢の場合は、質問せずに決定し、決定表に記録します。

2. コンテキストを収集する

phave-ng（メインチェックアウトまたはスタックのワークツリー）内で:

最初にCLAUDE.md、AGENTS.md、および.claude/rules/*を読みます。これらには、あなたが反してはならない決定がエンコードされています。
既存のものを探します: 機能が触れる、または再利用できる可能性のある型、サービス、ルート、テーブル、ジョブ、コンポーネント。広範囲に渡る場合は、エリアごとに並列でExploreエージェントを実行し、その結論のみを保持します。
拡張する既存のインターフェースをすべてメモし、そのpath:lineを記録します。

3. 規模を見積もる

	小規模	大規模
兆候	コードベースの1エリア、おおよそ1PR（約400行未満）、マイグレーションなしまたは些細なもの	複数エリア、スキーマ変更、新しいバックグラウンドジョブ、複数のPR、または複数の担当者やセッション
出力	`plan.md` のみ	`plan.md` に加えて `slices/01-<name>.md`、`slices/02-<name>.md`、...

小規模な作業は分割しません。 1PRの変更に対する儀式は無駄です。

大規模な作業の場合は、垂直スライスに分割します: 各スライスはそれ自体でマージ可能であり、mainを機能させたままにし、テスト可能なものを提供します。スキーマのみの「スライス」や「フロントエンドスライス」はスライスではありません。スライスを依存関係順に並べ、それぞれがおおよそ1PRになるようにします。

4. 計画を書く

~/plans/<date>-<slug>/plan.md:

# <タイトル>

**ステータス:** ドラフト | 承認済み | 進行中 | 完了
**規模:** 小規模 | 大規模 (Nスライス)
**リポジトリ / ベース:** phave-ng @ <コミット>

## 目標
<2～3文> · **スコープ外:** <箇条書き>

## アーキテクチャ
### コンポーネント
<Mermaidフローチャート: 既存のピースはプレインスタイル、新しいピースはハイライト、変更されたピースはマーク>
### キーフロー
<重要なフローごとにMermaidシーケンス図。主要なエラーパスを含む>
### データモデル
<テーブルまたはカラムが変更される場合はMermaid ER図; ライフサイクルがあるものは状態図>

## インターフェース
<機能が追加または変更するすべての契約を、リポジトリの言語で実際のコードとして記述。
 それぞれを NEW または CHANGED とマークし、対象ファイルパスを記載します。>
- 型 / ドメインモデル
- 関数とサービス: 完全なシグネチャ、およびスローする内容
- HTTP / サーバーアクション: メソッド、パス、リクエストとレスポンスの型、認証、エラーコード
- データベース: テーブル、カラム、インデックス、RLSポリシー、マイグレーション名
- ジョブ / イベント: 名前、ペイロード型、冪等性、リトライ
- UIコンポーネント: props、およびそれをレンダリングするページ

## 主要な設計決定
| 決定 | 検討したオプション | 選択したもの | 理由 |

## 未解決の質問
- [ ] <質問> — 誰が回答できるか、および回答によって何が変わるか

## スライス        (大規模のみ)
| # | スライス | 提供するもの | 依存先 | ステータス |

## 計画 (小規模のみ)
<順序付けられた手順; 各手順について: 実装するインターフェース、ファイル、テスト方法>

## テスト戦略
<何がユニットテストされ、何がスタックに対してテストされるか (`ai-test` / `manual-test` を参照)>

## リスク

各 slices/0N-<name>.md には以下が含まれます: 目標、plan.md から実装するインターフェース（リンク、コピーはしない）、ファイル、順序付けられた手順、受け入れ基準、テスト、および 実装メモ（空欄、implement-plan によって埋められる）。

ルール:

図はMermaidで、1つの図につき1つのアイデア。1つの図に約12ノード以上必要な場合は分割します。
インターフェースはコードであり、散文ではありません。実際のファイルに名前を付けます。可能な場合は既存の型を再利用し、その旨を明記します。
合理的なエンジニアが異なる決定を下す可能性のあるすべての決定は、決定表に記載します。
不明な点は未解決の質問に記載し、それぞれにあなたが推奨する回答を付けます。黙って推測しないでください。

5. 批判者 / 擁護者ディベート

Agentツールを使用して並行して2つのエージェントを起動します。各エージェントには、計画のパスと主要なリポジトリファイルを読み込ませますが、あなたの結論は与えません:

批判者: 「何が間違っているかを見つけてください。設計は目標を満たしていますか？インターフェースが欠落している、漏れがある、またはコードベースのパターンと矛盾していますか？スライスは本当に垂直ではありませんか？過剰設計または仕様不足の部分、見逃した再利用、障害モード、マイグレーションリスク、権限のギャップはありますか？各問題を具体的な修正案とともに報告してください。」
擁護者: 「計画の選択、特に明白な代替案が却下された箇所について、最も強力な主張をしてください。批判者が攻撃しそうな点と、現在の設計がなぜ有効かを挙げてください。」

次に反論ラウンドを実施します: 各エージェントに相手の出力（SendMessage）を送信し、各論点について譲歩するか主張するか、その理由を示すよう求めます。

あなたが審判です。各論点について:

合意された変更: plan.md / スライスファイルに適用します。
未解決でユーザーが必要な場合: 未解決の質問に移し、あなたが推奨するオプションを付けます。
却下: 決定を維持し、その理由を決定表に記録します。

## ディベート概要 を plan.md に追加します: 論点 → 批判者 → 擁護者 → 解決。

6. Artifactとして提示する

artifact-design と、図については artifact-diagramming を読み込みます。レビュー用に1ページを公開します。順序は以下の通りです:

タイトル、ステータス、規模、および1段落の概要
主要な設計決定（表）
未解決の質問: ユーザーから必要な情報、優先度高く見つけやすい場所に
アーキテクチャ図: 生のMermaidテキストではなくレンダリングされたもの
インターフェース: ハイライトされたコードとして、レイヤー別にグループ化し、NEW / CHANGED バッジを付けて
スライス（大規模）または手順（小規模）
ディベートのハイライト: 計画を変更した点、またはまだ未解決の点のみ
plan.md のローカルパス

チャットでリンクを共有します。次に、AskUserQuestion（質問を参照）を使用して未解決の質問をし、各質問に対して批判者と擁護者の立場をオプションとして、あなたの推奨を最初に提示します。

7. 承認されるまで反復する

ユーザーの回答とコメントは最初に plan.md に反映します: 回答された質問は未解決の質問から決定表に移動します。反復中に生じた新しい質問も同様に、AskUserQuestionと推奨オプションを使用して質問します。その後、同じArtifact（同じファイルパス、URLは変わらない）を再公開します。ユーザーが承認したら、ステータス: 承認済み に設定し、implement-plan を参照するよう促します。

このスキルではプロダクトコードを作成しません。

アーキテクチャ優先計画