implementation-planlisted

# 実装プランガイド ## 基本方針 実装の開始時およびPR作成時に、`issues/` 配下に実装プランファイルが存在するか確認し、なければ作成する。プランを残すことで後任エンジニアや将来の自分が変更意図を追跡できる。 ## 実装プランが必要なケース 以下のいずれかに該当する場合は作成する: - 複数ファイルにまたがる変更 - 新規機能の追加 - 既存ロジックの大幅な変更 - DBマイグレーションを伴う変更 - 複数のタスクに分解できる作業 ## 実装プランが不要なケース 以下のような軽微な変更では不要: - typo修正、文言変更 - 設定値の変更のみ - 1ファイルで完結する軽微な修正 - フォーマッター適用のみ - ドキュメントのみの更新 判断に迷う場合はユーザーに確認する。 ## ファイル配置・命名 - パス: `issues/` - ファイル名に日本語は含めないこと（Git/CI/検索ツール互換性のため） - タスクIDがある場合: `issues/TASK-1234_concise-description.md` - タスクIDがない場合: `issues/{feature-name}.md` ## PR作成時のプランファイル生成 PR作成時に `issues/` にプランファイルが存在しない場合、以下の情報源からプランファイルを生成する: 1. **会話履歴** - それまでのやりとりから要件・背景・方針を抽出 2. **git log** - コミット履歴からタスクの流れと変更概要を把握 3. **git diff** - 実際の変更内容から修正対象ファイルと変更内容を特定 これらを組み合わせて、下記フォーマットに沿ったプランファイルを作成してからPRを作成する。 ## 前段の Skill との関係 | 問い | 担当 | | --- | --- | | どの工程が必要か（モード判定） | `development-workflow` | | 何を満たすか（受け入れ条件・仕様） | `requirements-design` | | **どう分解するか（このプラン）** | この Skill | | どう作るか（失敗するテスト → 実装） | `tdd-cycle` | | 満たしたと言えるか（証跡） | `quality-gates` | 受け入れ条件が未確定のままタスクを並べない。分解の単位は受け入れ条件に紐づく。 これらの Skill が導入されていない環境では、プラン内に受け入れ条件と検証手段を直接書く。 ## プランのフォーマット 不要な節は削る。空の見出しを残さない。 ```markdown # {タスクID}: {機能名/修正内容} ## 関連リンク （Issue/チケット/設計ドキュメントがあれば記載） ## モード （development-workflow の判定結果と根拠。1 行。判定基準の表は写さない） ## 目的と非目的 達成したい状態: - （何のための変更か） やらないこと: - （今回の範囲外と決めたもの。「あとで」ではなく「今回はやらない」） ## 前提 - 前提 1: （決められない点を、後から成否を判定できる文で書く） ## 受け入れ条件 - [ ] （観測可能・一意・テスト可能な条件。検証手段を添える） - [ ] （起きてはいけないこと・退行しないこと） ## 代替案と採否 | 案 | 内容 | 採否 | 理由 | | ---