plan

name	plan
description	Issue起点の実装計画を作成する。Issueの内容とプロジェクトの設計ドキュメントを照合し、影響範囲・実装方針・テスト方針を含む計画を出力する。
when_to_use	「計画して」「plan」「プラン」などの発言時、Issue番号を指定して実装計画を依頼された時
context	fork

Issue起点の実装計画

引数: $ARGUMENTS（Issue番号。例: 123）

重要: このスキルの目的

このスキルは Issue の内容から実装計画を立てる ためのものである。 ブランチ作成、コミット、PR作成は一切行わない。計画の提示のみが目的。 gitの状態確認（git status, git log等）は不要。

手順

1. 最初に必ず gh issue view $ARGUMENTS を実行してIssue内容を取得する。Issue取得前に他の作業をしてはならない

2. 取得したIssue内容を読み、対象範囲・対象機能・期待動作を把握する

3. プロジェクトに設計ドキュメント（例: ルーティング/画面/DB/README 等の設計資料）が存在する場合は照合し、影響範囲を特定する

4. Issueで言及されている関連ファイルが存在する場合、それらの現在の実装を読んで問題点を確認する

5. 横展開スキャン: 今回の修正対象と同種の問題が、他のファイル・画面に潜んでいないかを計画段階で洗い出す。 目的は「ある画面で直した修正が他画面に取りこぼされる」横展開漏れを実装前に検知すること。 ここでは 実装も是非判断もしない。事実として「類似箇所がどこに何件あるか」を把握するだけ。 以下の2つの観点で確認する:

   • 構文的横展開（同じパターンの探索）: 今回の修正対象と同一のクラス名・同一構造の要素・ 同じ役割の処理を grep 等で探し、他画面の同種箇所を洗う。

     • 例: 特定のフォーム要素を直すなら、同じクラス名を grep して他画面の同種要素を洗う

   • 意味的横展開（課題の本質からの探索）: 参照した Issue の「なぜそれをやるのか？」「期待する状態」 などの記載から、そもそも解決したい本質的な課題は何か を捉え直す。そのうえで 「その課題を本質的に解決するには、構文が一致しなくても本来ここも直すべきではないか」を考える。

     • 例: Issue の目的が「画面間で挙動を統一する」なら、今回の対象だけでなく 同じ方針が崩れている他画面も "同じ課題の一部" として浮かび上がる
     • 単なる文字列一致では見つからない「目的を共有する箇所」を、課題理解に基づいて拾う賢さを持つこと

6. 以下を含む実行計画をユーザーに提示する

   • 問題の根本原因（調査結果に基づく）
   • 影響範囲（変更対象のファイル・コンポーネント・テーブル）
   • 実装方針（どのように実装するか、ステップごと）
   • テスト方針（UT・E2Eで何を検証するか）
   • 横展開所見（横展開スキャンの結果。構文的・意味的の両観点を踏まえる）
     • 今回のスコープに含める類似箇所（あれば、理由とともに）
     • 今回のスコープ外として別Issue化を提案する類似箇所（あれば、件数・概要・なぜ別Issueが妥当か）
     • 類似箇所が無ければ「横展開対象なし」と明記する

禁止事項

• Issue取得前にgit操作やブランチ状態の確認を行うこと
• 「何をしますか？」とユーザーに聞き返すこと（Issueに書いてある）
• ブランチ作成・コミット・PR作成などの実装作業

計画出力後の案内

計画を出力したら、以下のメッセージをユーザーに提示して終了する:

計画内容を確認し、問題なければ実装を開始してください。
修正が必要な場合はフィードバックをお願いします。再度 `/plan $ARGUMENTS` で計画を修正します。