writing-plans

計画の作成

計画の依頼によって許可されるのは、計画の成果物の作成または改訂であり、実装ではありません。 ユーザーが実行を依頼した場合、または進行中のワークフローで作業がすでに許可されている場合にのみ、計画を実行してください。

計画の根拠を確認する

質問する前に、関連するリポジトリ内の情報を確認してください。 危険な推測をしなければ進められない場合に限り、質問は最大1つまでにしてください。それ以外の場合は、実行や検証に影響する前提と不明点のみを述べてください。

ユーザーがチャットのみでの出力を求めていない限り、作成した計画をリポジトリに保存してください。 デフォルトでは、簡潔な小文字のケバブケースのトピックを使って docs/plans/YYYY-MM-DD_<topic>-plan.md に保存し、実行中は既存の計画をその場で更新してください。

計画の構成

必ず Goal、Plan、Completion Checklist を含めてください。 次のリストから、有用な任意のセクションのみを追加してください。

## Context
## Architecture
## Tech Stack
## Non-Goals
## Assumptions
## Unknowns
## Risks
## Rollback / Recovery

システムの境界、所有権、データフロー、API、状態、権限、ストレージ、またはデプロイについては Architecture を使用してください。 ツール、ランタイム、パッケージの選択については Tech Stack を使用してください。 本番データ、マイグレーション、インフラストラクチャ、リリース、または公開 API を扱う場合は Rollback / Recovery を含めてください。

実行可能なタスクを記述する

各タスクでは、Markdown のチェックボックスを使用し、1つのアクション、その対象、期待される結果、および受け入れを確認する証拠を明記してください。

- [ ] Update `src/auth.ts` to reject expired tokens; verify with `npm test -- auth`.

タスクは依存関係の順に並べ、重要な不明点は早期の調査タスクにしてください。 「品質を改善する」「エッジケースに対応する」「永続的に監視する」など、曖昧なタスク、複数の作業をまとめたタスク、または終わりのないタスクは避けてください。 ファイル、コマンド、テスト、レビューやデプロイの状態、または明示的なユーザー承認に結び付いた、有限の完了確認で締めくくってください。

実行と進捗の記録

• 受け入れ確認の方法に合格した場合にのみ、タスクにチェックを付けてください。
• 完了がリポジトリの状態から明らかでない場合は、簡潔な証拠を追加してください。
• 失敗した確認や利用できない確認は未完了のままにし、該当しないタスクには - [x] Not applicable: <reason> と記載してください。
• 後続の作業によって証拠が無効になった場合は、タスクを再び未完了にしてください。
• 追跡するのは現在保存されている計画のみとし、無関係な計画を調査したり変更したりしないでください。
• 計画がチャットのみの場合は、更新したチェックボックスと証拠をチャットに表示してください。

すべてのタスクと完了確認にチェックが付き、重要な不明点が解決または承認され、リスクへの対応が明確で、必要な引き継ぎやリリース作業が完了した場合にのみ、完了を宣言してください。 実装したというだけで完了と判断しないでください。

完了した計画を削除する

完全に実行済みの保存済み計画を削除し、削除したパスを報告してください。 チャットのみの計画や、完了の証拠が不足している計画は削除しないでください。