plan-it

計画を立てる

理由から外へ向かって計画します。変更がユーザーにとってなぜ重要なのか、現在のシステムにどのように適合するのか、検証可能な単位で何を提供するのかを考えます。正確なコード、ファイル名、編集順序、命名は、契約の一部でない限り実装時に決めます。

境界

• 計画上の判断に必要な指示、コード、テスト、設定だけを確認します。形式的に読み直すのではなく、現在のコンテキストを活用します。
• 計画を立てるだけでは、製品の編集や永続的な成果物の作成は許可されません。別の場所が承認されていない限り、計画は会話内にとどめます。
• 役立つ場合や必須の場合は、ハーネスの計画支援を利用します。小規模で明確、リスクの低い変更なら、会話内で簡潔に計画するだけで十分です。
• 実現可能性だけを尋ねられた場合は、アプローチ、影響、リスク、実施可否を報告して、そこで終了します。

1. 理由を明確にする

何よりも先に、変更の対象ユーザー、解決する問題、ユーザー側から見た成功の定義を述べます。理由は受け入れ基準の根拠であり、スコープを決める基準です。

依頼には、望ましい機能、受け入れ基準、ユーザー価値の3つが必要です。不足している内容だけを尋ね、ユーザーがすでに述べたことは聞き直しません。ユーザーが「列を追加する」「Xに切り替える」といった方法だけを示した場合は、その目的を尋ねます。

2. 方法を決める

リポジトリに検証スキルがある場合は、その機能マップから依頼に記載された機能を探します。コードの出発点は Where it lives セクション、受け入れ基準の出発点は Driving it セクションです。現在のシステムに即して、既存のどのモジュール、インターフェース、パターンを拡張するか、何を変更せずに残すか、どのトレードオフが重要かを決めます。選択が重要な場合に限り、代替案を比較します。抽象的な説明にとどめ、コード、擬似コード、編集手順は示しません。

アプローチが、まだ確認されていない事柄（外部エンドポイント、GPU の経路、サードパーティの権限、デプロイ先など）に依存する場合は、計画を確定する前に実際に確認します。動作することを示す呼び出しまたは実行を1回行います。ここで依存関係がブロックされれば必要なのは質問ですが、構築後に判明すれば構築のやり直しが必要になります。

3. 作業をスライスに分ける

作業を順序付きのスライスとして提供します。各スライスには、次の内容を含めます。

• 成果 — ユーザーまたは呼び出し元が確認できる結果。
• 受け入れ — 実際のシステムでその成果を実証する方法。コマンド、リクエスト、ユーザーフロー、および合格とみなす観測可能な結果を示します。テスト、型チェック、リントなどは受け入れを支援しますが、受け入れそのものの代わりにはなりません。
• 境界 — 変更するモジュールまたは契約と、意図的に変更しないもの。
• 貢献先 — 「理由」のどの部分を前進させるか。

「理由」のどの部分にも貢献しないスライスは、同じブランチに先送りするのではなく除外します。各スライスは、それぞれ単独でコミット、レビュー、取り消しができる規模にします。無関係な複数の境界にまたがる場合は、分割します。検証済みの基盤を順に積み重ねられるように並べます。

4. 検証と権限を確定する

• テストファースト。 ユーザーの選択またはプロジェクトのポリシーに従います。それ以外の場合は、選択した方針を明示します。TDD を選択した場合、振る舞いを変更するスライスでは /implement-plan が /tdd に従います。新しいテストによってカバレッジが増えるかどうかの判断には、テストの判断基準を使用します。
• プロジェクトの検証。 プロジェクトに検証スキルがあれば、その名前を示します。ない場合は、この種のアプリで受け入れをどのように実施するかを述べ、ユーザーに /create-verification-skill の実行を提案します。
• コミット。 各スライスが合格した後に自動でコミットするのか、依頼があった場合のみコミットするのかを記録します。
• 承認。 承認が必要な新しい設計上の決定、破壊的な操作、共有環境または本番環境への影響を明らかにします。妥当な計画を立てるうえで障害となる質問だけを尋ねます。

出力

詳細さはリスクに応じて調整します。小規模な変更なら、「理由」「方法」、1つのスライスを数行でまとめます。規模の大きな変更の場合：

## Why

## How

## What

## Validation and Authority

## Risks and Open Decisions

完了条件

計画には、Why、How、およびそれぞれに観察可能な成果、実際のシステムでの受け入れ確認、境界、Why へのリンクがある、順序付けられたスライスが記載されています。未確認の依存関係の実現可能性が確認されているか、リスクとして記載されており、テストファーストの選択、検証方法、コミット方針が記録されています。計画のみを許可する権限のもとでは、実装は行われていません。

承認されたら、/implement-plan を実行して続行してください。ユーザーがすでに明確で低リスクな実装を許可している場合、簡潔な計画を提示するために、改めて承認を求める必要はありません。ただし、新たな設計上の決定には引き続き承認が必要です。