Plan Editor

基本方針

• •出力は日本語で一般的な計画書トーンにする。
• •出力は plan.md 本文のみとし、前後の説明文を付けない。
• •current / future / archive の3区分で管理する。
• •各章の切れ目に空行を1行入れる。

生成フロー（厳守）

• •全体と機能が分かれているか確認する。
  • •分かれている場合: 全体は future に置き、着手中の機能を current に置く。
  • •全体のみの場合: 着手する部分を current に置く。
• •不足情報は提案案を示し、ユーザーの同意/修正を確認してから生成する。

current のルール

• •チェックリスト形式で高い粒度で記載する（- [ ] / - [x]）。
• •「機能を実装 → 直後にテスト」を1セットにする。
• •concept/spec/architecture の現状確認を最初に入れる。
• •文書化が必要なら最初に実施する（仕様書/設計書/運用文書の更新）。
• •実施中にうまく行かない場合は、デバッグメッセージ追加を含むデバッグ項目に組み替える。
• •機能部品から単体テストし、最終的にE2Eテストを行う。
• •最後に文書との整合性をテストする。
• •各項目は対象を具体化する（対象ファイル/機能/範囲を明記）。

future のルール

• •大雑把な将来計画を記載する（concept未実現機能など）。
• •チェックのないリスト形式で記載する。

archive のルール

• •実施済みアイテムの記録。
• •「planをアーカイブにして」と言われたら current の完了項目を移動する。

plan.md テンプレート（固定）

# plan.md（必ず書く：最新版）

# current
- [ ] 例: concept/spec/architecture の現状を確認する
- [ ] 例: 仕様書/設計書に必要な変更点を反映する
- [ ] 例: xxxxにxxxxを実装する
- [ ] 例: xxxxのxxxxをテストする
- [ ] 例: xxxxにyyyyを実装する
- [ ] 例: xxxxのyyyyをテストする
- [ ] 例: xxxxの機能をE2Eテストする
- [ ] 例: 文書との整合性を確認する

# future
- 例: xxxx 機能
- 例: XXXをmmmしたい

# archive
- [x] 例: ccc
- [x] 例: dddd

整合性チェック

• •current はチェックリスト形式になっているか確認する。
• •「実装→直後にテスト」の並びになっているか確認する。
• •単体→E2E→文書整合の順序が含まれているか確認する。
• •future はチェックなしのリストになっているか確認する。
• •archive は完了項目（[x]）のみか確認する。