plan

計画

新しいエージェントが、製品や技術に関する判断をせずに完了できるタスクを作成します。すべてのタスクとマイルストーンは垂直スライスにします。つまり、必要なレイヤーを通じて動作する、利用可能な成果と受け入れ確認を備えたものにします。ファイル、レイヤー、チームの境界ではなく、作業の成果ごとに分割します。

プロセス

1. ソース、リポジトリの指示、関連するコードを読みます。
2. 未解決の選択によって動作、インターフェース、データ、セキュリティ、規模、パフォーマンス、互換性、運用、コスト、または検証方法が変わる場合は、作業を中断して /spec に戻ります。
3. それぞれが動作する振る舞いを提供し、1 回のエージェント実行で完了でき、焦点を絞った 1 つのプルリクエストにつながるタスクに分割します。
4. 共有契約は 1 つのタスクにまとめます。同じ問いに独立して答えるタスクを 2 つ作らないでください。
5. リファクタリングによって振る舞いの変更が分かりにくくなる場合は、別にします。
6. タスクを依存関係に基づいて並べます。役立つ場合は、タスクをマイルストーンにまとめます。各マイルストーンでは、受け入れ確認と依存関係を備えた、利用可能なエンドツーエンドの成果を提供します。「データベース」「バックエンド」「フロントエンド」のようなマイルストーンは使わないでください。
7. 計画はチャットで返します。ユーザーから依頼された場合に限り、トラッカーチケットを作成します。計画書は作成しないでください。
8. 計画を作成したら終了します。実装はしないでください。

たとえば、「タスクを追加し、再起動後にも表示されるようにする」には、CLI 入力、検証、保存、出力、テストをすべて 1 つのタスクに含めます。後続のマイルストーンでは、追加、一覧表示、完了の各スライスを通じて「未完了のタスクを管理する」成果を提供できます。マイルストーンには、確認可能な成果と、成果全体が動作することを証明する方法を記載します。

2 人の読み手に向けて書く

各タスクは、人間が読み、エージェントが実行します。

最初のセクションを読めば、人間が 1 分以内にタスクを理解できるようにします。具体的な問題、成果、日常的な観点から見た重要性を明記します。ここでは、要件 ID、実装の詳細、定義されていないプロジェクト用語、対象読者になじみのない略語を使わないでください。

タスク固有の判断、インターフェース、失敗時のルール、セキュリティ制約は、エージェント向けメモに記載します。共有アーキテクチャや要件の全定義には、仕様または決定済みのソースへのリンクを付けます。公開済みのチケットから開けるリポジトリのパスまたは URL を使い、後の編集で契約が変わる可能性がある場合は、決定済みのバージョンを固定します。長期的に参照できるソースがない場合は、必要な共有判断をエージェント向けメモに含めます。ソース全体を各チケットに転載しないでください。

タスク単体で目的、範囲、依存関係、必須の判断、検証方法が明確であれば、単独で成立します。リンク先のソースにすでに記載されている背景を繰り返す必要はありません。

タスクの形式

この簡潔な形式を使います。情報が増えない任意のセクションは省略します。

## <Plain action and result>

### What are we building?
In one to three short sentences, say what is wrong or missing and what will work after this task.

### Why?
In one or two short sentences, explain the practical value to a user, operator, or developer.

### Done when
- Three to seven observable results.

### How to check
Exact commands and required manual checks.

### Agent notes
- Depends on: <task titles, or None>
- Source: <durable spec, brief, issue, or request path/URL, pinned when needed>
- Only the definitions, decisions, constraints, and failure behavior specific to this task.

### Out of scope
- Related work this task is likely to absorb by mistake.

書き方のルール

• 動作と成果を示す短いタイトルにします。
• なじみのある言葉と具体的な動詞を使います。
• 必要な技術用語は、最初に登場する箇所で定義します。それ以外は、確認可能な振る舞いに置き換えます。
• 冪等性を証明するではなく、同じイベントを 2 回送信しても、返信は 1 つだけ作成されると書きます。
• グラウンディングを証明するではなく、回答が引用された文書によって裏付けられていると書きます。
• 既定ではユーザーストーリーを追加しません。最初の 2 つのセクションだけでは製品の振る舞いが明確にならない場合に限り、追加します。
• 最初の 2 つのセクションには実装の仕組みを記載しません。
• タスク固有の実装上の判断はエージェント向けメモに記載します。交換可能なローカルの仕組みは、実装を行うエージェントに任せます。
• 適用される AC-n、REQ-n、INV-n の参照は、「完了条件」またはエージェント向けメモに残します。ただし、タスクを理解するために読み手がそれらの解読を求められる書き方はしません。
• チケットあたり 250〜500 語を目安にします。追加の記述が安全でない実装や互換性のない実装を防ぐために必要な場合を除き、700 語を超えないようにします。それ以外の場合は、タスクを分割するか、共有ソースへのリンクを付けます。
• 同じ事実を複数のセクションで繰り返しません。
• スローガン、比喩、冗長な表現、堅牢な、シームレスな、包括的な、将来にわたって通用するなどの曖昧な主張は使いません。

境界

• 1つの動作する振る舞いを、複数のファイルや技術レイヤーに分けたタスクにしないでください。
• 確認可能な成果のない足場づくりやクリーンアップのタスクを作成しないでください。
• 未解決の判断を実装チケットに隠さないでください。
• 各タスクは、1回のエージェント実行と焦点を絞った1回のレビューで完了できる大きさにしてください。
• 「完了条件」には、観察可能な振る舞いと、満たす必要のある内部ルールを記載してください。
• 「確認方法」には、正確なコマンドと、自動化で振る舞いを網羅できない場合の手動での確認方法を記載してください。
• 原文で要件 ID が使われている場合は、各 ID を同じルールに対応付けたままにしてください。番号を振り直したり、再利用したりしないでください。

計画を返す前に、各タスクを2回読み直してください。

1. 人間による確認：タイトルと最初の2つのセクションだけを読んだ人が、何が、なぜ変わるのか説明できますか？
2. エージェントによる確認：新たに参加したエージェントが、プロダクトやアーキテクチャに関する質問をせずに、対象のソースを見つけ、依存関係と確定済みの判断を把握し、タスクを実装して、その成果を証明できますか？

両方の確認に合格したら、重複する背景説明を削除してください。

返却内容

順序付けたタスク、有用な場合は合格基準を含むマイルストーン、それらの依存関係、および実装を妨げている未決の判断を返してください。タスクを繰り返すだけの独立した要約は追加しないでください。