write-plan

計画の作成

出力言語： 回答と成果物は、ユーザー自身の言語で記述してください（リポジトリの履歴ではなく、ユーザーのメッセージに合わせます）。

概要

承認済みの設計を、忘れっぽいエージェントでもスコープを勝手に作り出さずに実行できる実装計画に変換します。

基本原則：各タスクは個別にテスト可能であること。各ステップは2～5分で完了すること。TDDを標準のマイクロサイクルとします。

必須の前提工程：write-spec（またはgrillによる承認済みの文書・口頭での設計）。複雑な境界にはsolidを使います。プロダクトに関する判断事項が未解決のまま計画を立ててはいけません。

告知：「write-plan を使って……します」

使用するタイミング

• write-spec（または免除された口頭での設計）の承認後、コーディング前
• 複数ファイルまたは複数ステップにわたる機能
• ユーザーが実装計画やタスクの分解を求めたとき

使用しない場合：プロダクトの方針が未確定 → まずgrill／write-specを使います。明白な1つのテストサイクルで済む1行の修正（そのままtddへ進みます）。純粋な調査。

鉄則

NO CODING FROM A VAGUE PLAN.
Every task lists exact files, a failing-test step, a verify-red step, minimal impl, verify-green, and a commit step (or explicit why commit is deferred).

ワークフロー

1. スコープの確認 — 独立したサブシステムが複数ありますか？それぞれを個別の計画に分けます（1つの計画につき、単独でリリース可能なスライスを1つ）。
2. ファイルマップ — パスを確定する前に、構造の指針を確認します。境界（ポート／アダプター／依存関係の矢印）にはsolidを使います。スライスに新しい境界を追加しない場合は、その旨を伝えて次へ進みます。ファイルマップには確認結果を記録します。
3. タスクの分解 — 小さく分け、足場作りはそれを必要とするタスクに含めます。各タスクのREDステップを書く前に、検証の指針を確認します。テストケース一覧にはtest-designを使います。各ケースはユーザー／プロダクトの言葉（目標／条件／パラメーター）で記述し、作成者以外でも「何が」「なぜ」証明されるのかがわかるようにします。これらのケースがタスクのREDテストとなります。
4. 計画ファイルを作成 — デフォルトはdocs/creed/plans/YYYY-MM-DD-<feature>.mdです（ユーザーがパスを指定した場合はそちらを優先します）。
5. セルフレビュー — 未確定事項が残っておらず、各タスクにインターフェースと検証コマンドがあり、YAGNIに従っていることを確認します。
6. ユーザー確認 — 実行前に計画に目を通してもらいます。
7. 引き継ぎ — tdd＋test-designを使って実行します（任意でSuperpowersのsubagent-driven-development／executing-plansを使用します）。

この2つの指針は、必須のゲートではなく、工程に組み込むための提案です。新しい境界がなければsolidは省略でき、ケースの定義にはtest-designを使います。ここで明記することで、黙って省略されたり、過剰に適用されたりするのを防ぎます。

計画ヘッダー（必須）

# <Feature> Implementation Plan

> **For agents:** Use Creed **tdd** + **test-design** per task. Optional: Superpowers subagent-driven-development / executing-plans.

**Goal:** <one sentence>

**Architecture:** <2–3 sentences — the boundaries settled with **solid**; if no new boundary, say "no new boundary">

**Tech Stack:** <key libs>

**Cases (from test-design):** <the "when …, it should …" list, each with goal / conditions / parameters in reader-facing words>

## Global Constraints

- <verbatim constraints from spec: versions, naming, platforms, …>

---

タスクのテンプレート

### Task N: <Name>

**Files:**
- Create: `path/to/file.ts`
- Modify: `path/to/existing.ts`
- Test: `path/to/file.test.ts`

**Interfaces:**
- Consumes: <signatures from earlier tasks>
- Produces: <names/types later tasks rely on>

- [ ] **Step 1: Write the failing test** (apply **test-design**)
- [ ] **Step 2: Run it — expect FAIL for the right reason**
- [ ] **Step 3: Minimal implementation** (**tdd** GREEN; **solid** boundaries)
- [ ] **Step 4: Run tests — expect PASS**
- [ ] **Step 5: Commit** (or defer with reason; ship later via **commit-and-push**)

APIを明確にするうえで重要なテスト／実装のスニペットは、必要に応じて本文に含めます。長大なコードを貼り付けないでください。

粒度

良いタスク	悪いタスク
1つの振る舞いとそのテストサイクル	「認証を実装する」
正確なパス	「サーバー周りを更新する」
独立してレビューできる	タスク2の結果を判断するには、タスク5を完了する必要がある

言い訳と実情

言い訳	実情
「コーディング中にパスを決めます」	それがスコープの拡大につながります。計画でファイルを確定してください。
「大きなタスク1つで問題ありません」	レビュアーはその半分だけを却下できません。分割してください。
「テスト手順は省略します。後でTDDをします」	「後で」は「決してやらない」と同じです。ステップにはRED／GREENを含めてください。
「計画は設計ドキュメントです」	仕様（write-spec）は何を／なぜ行うか、計画は誰がいつどのファイルを変更するかを記述します。
「計画の中でプロダクトのスコープを決めます」	プロダクトに関する判断事項が未解決なら、grillに戻り、その後write-specを使います。
「Solidは形式的な手順なので省略します」	その場合は「新しい境界はありません」と明言して次に進みます。問題なのは省略そのものではなく、黙って省略することです。
「test-designはtddで後から使うものです」	ケースによってタスクのREDステップが形作られます。計画時に決めることで、各タスクを個別にテスト可能にできます。

チェックリスト

• 仕様（write-spec）が承認済み、または口頭での設計と免除がある
• 構造の指針（solid）を確認済み — または「新しい境界はありません」と明言した
• 検証の指針（test-design）を確認済み — ユーザー／プロダクトの言葉（目標／条件／パラメーター）でケースを記述した
• ヘッダーとタスクを含む計画ファイルを作成した
• 各タスクにファイル、インターフェース、RED→GREEN→コミットがある
• 計画によってプロダクトに関する判断事項を再び未確定にしていない
• ユーザーが計画をレビューした（または明示的に免除した）
• tddで実行する準備ができている

引き継ぎ

移行ゲート — プランを実行または次の段階に引き渡す前に、ユーザーに確認してください（AskUserQuestion を 1 回。自動で次に進まないでください）：

A) Recommended: Proceed → tdd (+ test-design)
B) Review first — run **review** on this plan (`references/plan.md`; upstream = the spec it narrows), then return to this gate
C) Adjust — revise the plan, then return to this gate
D) Something else (I will type it)

• プロダクトの内容がまだ曖昧 → grill / write-spec
• 実行する → tdd + test-design
• 構造に行き詰まっている → solid
• リリース完了 → まず review、次に commit-and-push