plan-issue

課題を読んでから着手するまでの手順です。

判定の正本は既存のルールです。ここには写さない。

判定	正本
課題の記述のうち、どれを直す対象とみなすか	verify_before_asserting.md の「課題票の症状記述も裏を取る」
計画に入れる変更の範囲	scope_changes_to_the_issue.md
どこで止まって尋ねるか	decide_or_ask.md
他のリポジトリへ連絡するか	notify_related_repo_sessions.md
契約を先に決めて内側から積む順序	implement_from_contract_inward_out.md

進め方

読み始める前に、pstack の sharpen に従って、熟練者ならこの課題をどう進めるか、本当に求められているのは何かを1度考える。

1. 課題を全部読む

本文だけで止めない。コメントが件名・期限・担当の変更履歴だけでも読む。期限や優先度が上がった経緯は、そこにしか残っていないことがある。

読むもの	何が分かるか
本文	背景と受入基準
コメント（変更履歴を含む）	期限・優先度の変化、議論の経緯
添付・関連課題・子課題	本文に書かれていない前提
本文のリンク先（公式手順・記事）	作業の実体
起票者	本文を書き換えてよいか（他人の起票なら書き換えない）

リンク先の本文が空なら、ヘッドレスのブラウザで開き直す（ verify_the_check_worked.md ）。それでも読めなければ、読めなかったと記録して次へ進む。記事の要約だけを根拠にしない。

2. 受入基準と状態の説明を分ける

閉じる条件は受入基準です。 背景の節に書かれた症状は、今の状態を説明しているだけのことがある。直す対象に入れるかは、受入基準と突き合わせて決める。

受入基準が無い課題では閉じる条件の案を自分で書き、計画の中で「案」と明記する。決めるのはユーザーか起票者。

3. どこを変えるかを一次情報で確かめる

課題の件名に出てくる場所と、実際に変える場所は一致しないことがあります。「メールのリンク」と書いてあっても、変える先がアプリのコードとは限らない。

関わりうるリポジトリは、見つけた1つで止めずに先に全部数える。同じ機能（メール送信・決済・認証など）を持つリポジトリを同じ語で検索し、0件のリポジトリも「関わっていない」根拠として控える。

変える場所	確かめ方
今いるリポジトリのコード	git grep で該当の処理を探し、path:line で控える
他のリポジトリ（FE・インフラ・スキーマ）	手元のクローンを読む。worktree を共有しているなら HEAD は動かさない
コードの外（外部サービスの管理画面・DNS・アカウント設定）	公式手順を読み（ライブラリや SDK の仕様は /context7-mcp で、Web のページは /ax で引く）、IaC で管理されているかを git grep で確かめる。管理されていなければ手作業になる

何が見つからなかったかも控える。 「この設定はコードに無い」は計画の前提になる。0件を報告する前に、同じ探し方で必ず当たる語を1回引く（ verify_the_check_worked.md ）。

4. 確かめられないことを洗い出す

権限が無くて見られないもの（外部サービスの管理画面・本番の設定値）は、推測で埋めずに「未確認」として計画に残す。誰に見てもらえば埋まるかを添える。

確かめてもらう相手が決まり、聞くことが複数あるなら、/mattpocock-skills:to-questionnaire に従って相手へ渡す質問票の下書きを作る。置き場はスクラッチパッドにする。

5. 計画を組む

ステップごとに次の列を埋める。

列	書くこと
やること	動詞で書く。対象を名指しする
変える場所	リポジトリ名、またはコードの外の場所
誰が	自分 / ユーザー / 権限を持つ人
取り消せるか	取り消せないなら、そのステップの前で尋ねる
確かめ方	受入基準のどれを、何で確かめるか

ステップの並べ方。

• 調べるステップを、変えるステップより前に置く
• 取り消せないステップ（外部の設定変更・本番への反映）は、戻し方を同じ行に書く
• 影響が出る時間帯があるなら、作業の時間帯も書く
• 他のリポジトリを跨ぐなら、マージ順を書く

設計を含む計画は、組む前に pstack の原則を当てる。

• 既存の設計へ要件を足すなら principle-redesign-from-first-principles に従い、継ぎ足しの形と、要件を最初から知っていた場合の形を比べる
• 前例の無い設計判断を1案で決めているなら principle-exhaust-the-design-space に従い、比べる案を2〜3並べる。試作で比べるなら /mattpocock-skills:prototype を使い、どれにするかを尋ねる形は decide_or_ask.md に従う
• 大きな移行や複数の PR に分かれる変更なら、figure-it-out の Phase A（完了の条件を偽にできる形で書く・範囲を量る・厳しさを決める）で枠を決めてから表を組む

不具合の課題は、暫定対応が要るかを先に決める

不具合では、今起きている被害を止めることと原因を取り除くことで、急ぐ度合いと取り消せるかが違う。計画の前に、恒久対応が入るまで被害が続くかを見る。

判断	計画の形
被害が続き、恒久対応より早く止められる手がある	暫定対応と恒久対応の表を分ける
恒久対応がすぐ出せる、または被害が今は出ていない	分けず、暫定対応が要らない理由を1行書く

暫定対応には、何が残るか（止めた機能・手作業で直したデータ）と、いつ外すかを同じ行に書く。フラグやデータの手直しは、恒久対応が入ったあとに戻し忘れやすい。

原因が分かっていない不具合は、/mattpocock-skills:diagnosing-bugs の最初のフェーズに従い、速く安定して合否が出る再現の手段を作るステップを計画の先頭に置く。再現できないまま直し方の表を組まない。

6. 判断が要る点を尋ねる

方針・範囲・取り消せない操作の可否で、答えによって計画が変わるものだけを AskUserQuestion で出す。推奨を先頭に置く。

答えに依らない調査は、尋ねる前に済ませる。

出力の目安

1. 一言目に、何をすれば閉じるかを1〜2行で書く
2. 概要: 背景・受入基準・期限を表で1つ
3. 調べたこと: 確かめた事実を path:line か URL 付きで。見つからなかったものも1行で
4. 計画: 上の5列の表
5. 未確認と判断が要る点

課題へ計画を書き込むかは、ユーザーが決める。書き込むなら [memo] で、投稿前に点検を通す（ no_ai_style_writing.md ）。未確認と判断が要る点は書き込まず、会話で伝える。課題に残すのは、調べて分かったことと計画だけにする。

やってはいけないこと

• 本文だけ読んで計画を立てること。コメント・リンク先・関連課題も読む
• 件名の語から、変える場所をコードと決めつけること。外部サービスの設定だけで閉じる課題もある
• 権限が無くて見られないものを、推測で埋めること
• 受入基準に無い改善を、計画に混ぜること
• 計画を立てた流れで実装まで進むこと。着手はユーザーの指示を受けてから
• 他人が起票した課題の本文を書き換えること

関連

• /create-backlog-issue （課題の起票）: 起票はあちら。本スキルは起票された課題を読んで着手前の計画を立てる
• /mattpocock-skills:grilling （計画の壁打ち）: 計画を立てた後、穴を突いて詰めたいときに使う
• verify_before_asserting.md （断定の前に裏を取る）: 手順2と3の根拠
• scope_changes_to_the_issue.md （課題の範囲へ変更を閉じる）: 計画に入れる範囲の判定
• decide_or_ask.md （自分で決めるか尋ねるか）: 手順6の判定