plan

za:plan — 実装プラン作成

実装に着手する前に、要件・プロジェクトの文脈・既存コードを突き合わせて、抜け漏れのない 実装プランを 1 ファイルにまとめる。狙いは「いきなり実装して手戻りする」のを防ぎ、 着手前に不明点を潰しておくこと。

下の手順を順番に実行する。各ステップの「なぜ」を理解した上で、機械的になぞるのでは なく状況に合わせて判断すること。

手順

1. プロジェクトのコンテキストを読む

docs/CONTEXT.md を読む。これはプロジェクトのドメイン・用語・構成・前提が書かれた 土台で、プランはここに書かれた語彙と方針に沿わせる。

• 無い場合: 「docs/CONTEXT.md が見つからないため、コードから文脈を推測して進めます」と 一言伝えてから、リポジトリ構成（README、主要ディレクトリ、設定ファイル）をざっと見て 文脈を補う。CONTEXT.md の新規作成を勧めてもよいが、プラン作成自体は止めない。

2. 要件を確定する

要件はこのスキルに渡された引数から読み取る（例: /za:plan ログイン機能を追加 の 「ログイン機能を追加」）。

• 引数が空の場合: 「どんな要件のプランを作りますか？」とユーザーに尋ね、回答を要件とする。
• 引数が一言・曖昧な場合でも、ここでは深掘りしない。曖昧さは次の「不明点」で扱う。

3. 不明点を洗い出す

コンテキストと要件を突き合わせ、プランを書くために確定が必要な不明点を列挙する。 typ的には次のような観点:

• 要件の範囲（何を含み、何を含まないか）／成功条件
• 既存のどのモジュール・データ・APIに影響するか、再利用できるか
• 技術選定・データ構造・インターフェースの選択肢
• エラー時/境界条件の扱い、後方互換性
• 非機能要件（性能・セキュリティ・運用）

4. 不明点を解消する — まず調査、残りを質問

不明点ごとに、まずコードや既存ドキュメントを調べて自力で解消できないか試す。 これはユーザーの手間を最小化するため。コードを読めば分かることをいちいち質問しない。

• 既存実装・依存・命名規約・テスト・設定を調べて答えが出るものは、自分で確定させ、 「調査で解消した点」として後でプランに根拠を残す。
• 調べても判断がユーザーに委ねられるもの（仕様の意図、優先順位、好みの選択）だけを ユーザーに質問する。質問は番号付きの一覧でまとめて提示し、各項目に 自分の推奨案を添える（ユーザーが「全部おまかせ」で即答できるように）。

回答を得たら、それも踏まえて不明点が十分潰れたか確認する。新たな不明点が出たら繰り返す。

5. プラン作成のルールを読む

docs/PLAN.md を読む。これはこのプロジェクトでのプランの書式・粒度・記載事項の ルールを定めたもの。プランは必ずこのルールに従う（プロジェクトが書式の所有者であり、 こちらが勝手な形式を押し付けない）。

• 無い場合: 「docs/PLAN.md が無いため標準の書式で作成します」と伝え、末尾の **「デフォルトのプラン書式」**を使う。

6. 実装プランを書き出す

ここまでの「コンテキスト・要件・調査で解消した点・ユーザーへの質問と回答」を統合し、 実装プランを作成して次のパスに書き込む:

docs/plans/{yyyymmdd}-{title}.md

• {yyyymmdd}: 実行時の日付。date +%Y%m%d を実行して取得する（推測しない）。
• {title}: 要件を端的に表す短い kebab-case のスラッグ（例: add-login, menu-bar-settings）。日本語よりも英字スラッグを基本とする。
• docs/plans/ が無ければ作成する。
• 既存の同名ファイルがあれば、上書き前にユーザーに確認する。

プランには最低限、要件の確定内容・前提（コンテキスト）・調査で分かったこと・ ユーザー回答で確定した事項・具体的な実装ステップ・影響範囲やリスクを含める （docs/PLAN.md がある場合はそのルールを優先）。

7. 必要ならコンテキストを更新する

今回の要件確認・調査・意思決定の過程で、プロジェクトの土台として残すべき新しい事実や 決定（用語の追加、構成の変更方針、確定したアーキテクチャ判断など）が出たら、 docs/CONTEXT.md に追記・修正する。

• これは「今回のプラン固有の話」ではなく「今後も効く前提」だけを書く。CONTEXT を プラン内容で膨らませないこと。
• 更新したら、何をどう変えたかを最後にユーザーへ一言報告する。

完了時の報告

最後に、作成したプランのパス、ユーザーに確認した主な論点とその結論、CONTEXT.md を 更新した場合はその要点を、簡潔にまとめて伝える。

---

デフォルトのプラン書式

docs/PLAN.md が存在しない場合に使う標準テンプレート。先頭の見出しは要件名にする。

# {要件名}

- 作成日: {YYYY-MM-DD}
- ステータス: ドラフト

## 概要
{何を実現するか・なぜやるかを 2〜4 行で}

## 背景・前提（コンテキスト）
{docs/CONTEXT.md と調査から得た、このプランが依拠する前提}

## 要件
- {確定した要件を箇条書きで}
- スコープ外: {含めないこと}

## 確定した論点
{調査やユーザーへの質問で決まった事項と、その理由・根拠}

## 実装方針
{採用するアプローチと、その選定理由}

## 実装ステップ
1. {着手順に、検証可能な単位で}
2. ...

## 影響範囲・リスク
- 影響を受けるモジュール/データ: {}
- リスクと対策: {}

## 未確定事項（あれば）
- {残った前提や、後続で判断する点}