---
name: plan-code
description: ソフトウェアの改修や移行で、実装前に根拠付きの変更計画を作る。やること/やらないことの明確化、関連資産の調査、既存パターンの確認、Before/Afterの変更案、リスク、PR分割案、承認前プラン提示が必要なときに使う。
---

# Plan Code

コード変更の実装前に、根拠付きで計画を作る。
計画段階では実装しない。まず認識合わせと調査を行う。

## When To Use

- アプリケーション資産の新規改修や移行タスクを始めるとき
- どのプログラム、設定、I/O、DBを触るべきか整理したいとき
- 実装前に変更方針とリスクをレビューしたいとき

## Workflow

1. タスク解釈を確認する
2. 先にスコープ前提を固定する
3. やること、やらないことを分ける
4. 関連資産を調査する
5. 既存パターンと根拠を集める
6. Before/Afterで変更案を作る
7. リスク、確認事項、PR分割案を出す
8. 人間の承認待ちで止まる

## Scope Fixing

- 調査前に、次の前提が依頼文で確定しているかを確認する
  - データ表現: 文字列か数値か、フォーマットや型制約は何か
  - 互換性の意味: 表示互換、データ互換、キー互換、ソート互換のどれを優先するか
  - 横断範囲: 本体のみか、隣接システムや下流ジョブも含むか
- 確定していない前提は、最初に `要確認事項` へ置く
- 未確定のままでも計画は作ってよいが、その場合は変更案に `仮説` を付ける

## Investigation Order

- まず対象データや機能を定義しているモデル、スキーマ、設定、DDL を探す
- 次にその定義を参照するアプリケーションコード、バッチ、ジョブ定義、UI、API を辿る
- 最後に隣接システムや下流資産を確認する
- 資産を計画に含めるときは、「そのファイルに対象項目がある」または「そのファイルが対象項目のレコード長、キー長、入出力仕様に従属する」のどちらかを根拠にする
- 実ファイルで依存を確認できない隣接資産は、変更対象として断定せず `要確認事項` または `仮説` に留める

## Evidence Rules

- 各変更案に少なくとも1つの根拠を付ける
- 根拠は既存コード、実行結果、テスト結果、ジョブ定義、運用上の観測事実のいずれかに限定する
- 根拠が弱い案は `仮説` と明記する
- 関連資産には、含めた理由を短く添える
- 実在しない定義や、実ファイル確認で否定された変更は計画から外す

## Guardrails

- 計画中に実装へ進まない
- ついでの改善や全面リファクタリングを混ぜない
- 曖昧な要件は質問事項として残す
- 根拠がない変更案は採用しない
- 下流影響を推測だけで確定しない
- `必要なら` と書かれた周辺資産は、調査で依存を確認してから含める

## Output Format

- 依頼理解
- スコープ前提
- やること
- やらないこと
- 関連資産
- 既存パターン/根拠
- 変更案 Before/After
- リスク
- 要確認事項
- PR分割案
- 次のアクション