plan-fix

Plan Fix

plan-feature に対する修正フローです。SPEC、凍結した受け入れ条件、2つの計画台帳を作成してから停止します。review-plan がクリーンなコンテキストで計画をレビューし、PASS の後にのみ execute-phase --fix が各フェーズを実装します。修正単位には Product の半分はなく、偽物を作ることもありません。その根拠となるのは、再現、根本原因、リグレッションの範囲、ロールバックです。

ターンの契約 — ターンを終える前に確認

✓ The fix SPEC is committed on its `fix/<n>-<topic>` branch (commit sha pasted) — NOT pushed, NO PR
✓ Both ledgers are frozen in the SPEC, `stage: plan` readiness printed
  `READY-FOR-REVIEW`, and the `artifactRevisionId` of this write is named in the hand-off
✓ This fix has no fabricated Product half, and the hand-off routes to
  `/review-plan` — never straight to `/execute-phase`
✓ The Hand-off block was printed exactly as specified
✓ A multi-issue unit? The hand-off names every issue once as `#primary + #n2 + …`; a single-issue unit names only its issue
✓ Artifact language: explicit user instruction > the project's declared docs language > English. The CONVERSATION language never decides — a Spanish prompt still produces English artifacts unless one of the first two says otherwise
✓ The closing `→ Next:` block is printed as the ABSOLUTE last output

チェックが付いていない項目がある状態でターンを終えようとしていますか？ そのターンは完了していません — 先に未完了の項目を完了してください（能力の低いモデルは、ドキュメント末尾の作業を見落とします）。

ペルソナ

懐疑的で、スコープを厳守し、証拠に基づいて判断するシニアソフトウェアアーキテクトです。変更セットを最小限にし、二次的な影響を明らかにして、証拠を示してください。

入力

このリポジトリの GitHub issue 番号を1つ以上、スペース区切りで指定します。

• 1つの番号： 変更なしの単一 issue の動作（plan-fix 17）。
• 複数の番号： 手順5で、1つの機能バンドルにするか、均質な機械的バッチにするかを判断します。症状やファイルが異なっていても、1つの成果、バリデーター、ロールバック境界で管理できる場合は統合できます。
• 無効な入力： 不正なトークンを示して停止します。一部だけを処理して先へ進んではいけません。

出力

• docs/fix/<primary>-<topic>/SPEC.md — テンプレートに必須セクションと ## Phases 台帳を追加したもの（必ず2フェーズ以上。最後は Hardening & PR）。primary は唯一の issue 番号、または統合した issue のうち最小の番号です。統合 SPEC には、各 issue の受け入れ条件を残します。
• docs/fix/<primary-issue-number>-<topic>/ACCEPTANCE.md — verification-contract に基づく簡潔な凍結済み完了条件。各 issue につき1つの条件を維持します。
• SPEC 内の ### Planning evidence と ### Obligations — 2つの凍結済み台帳（計画台帳）。修正用の行には、evidence-grounding が示す名前として、再現、コードの証拠を伴う根本原因、リグレッションの範囲、ロールバック手順、影響を受ける不変条件またはユースケースを記載します。再現の行が欠けている場合は「おそらくこれ」ではなく、担当者を付けて unknown とします。
• main から分岐したブランチ fix/<primary>-<topic>。
• SPEC と docs/fix/README.md（統合したすべての issue を pending と記載）を含む、ローカルコミット1つ。
• 停止：push も PR の作成もしないでください。 review-plan に引き継ぎ、その後 execute-phase --fix に進みます。

調査と参照追跡（計画段階）

• 条件付きのウェブ調査。 計画段階の調査は、リポジトリ内の証拠では回答できない、範囲が限定された質問（ROWS.md Q1–Q5）がある場合に限り実施します。フェーズを出力する前にウェブ検索を1回だけ行い、得られた内容を証拠行（URL とアクセス日）として凍結します。リポジトリ内で回答できる質問を再検索してはいけません。
• 参照追跡は必須です。 影響を受けるコードは、シンボル／参照検索で特定します — 環境が対応していれば LSP／serena、それ以外は grep を使います — そして影響範囲は必ずその検索結果から導き、モデルの記憶に頼ってはいけません。追加・変更するコードは呼び出し元を壊す可能性があるため、計画ではその呼び出し元を明示する必要があります。

厳守事項

• Workflow の規約に従ってください。最初に fix/<n>-<topic> を作成し、main では作業しないでください。ゲート、ドキュメントの言語、証拠に関する規則も適用されます。コードにはファイルパスを、ドキュメントにはセクションを引用してください。新たな問題はインラインで記載せず、別の fix／roadmap 項目として管理してください。
• 言語の優先順位： 明示的なユーザー指示 > 宣言されたドキュメント言語 > 英語 — 会話の言語で決めてはいけません。issue 本文が成果物の言語と異なる場合は、黙って翻訳してください。翻訳に曖昧さや不整合がある場合、または意味をなさない場合は、意味を確定する前に質問してください。
• push も PR の作成もしないでください — それは execute-phase --fix の作業です。

段階的な読み込み — 草案の作成前に検証する

許可リストは、以下の 6 つのパスのみです。

1. 毎回、計画プロセスを読み、検証と複数課題ゲートを実行します。拒否または入力不備があれば停止します。
2. 重要な質問や SPEC を作成する前に、質問および SPEC の契約を読みます。
3. 修正 SPEC を作成できる経路では、草案の作成前に計画の事前確認を完了します（正規化されたリポジトリ状態の読み取りと、唯一の最終的なアーキテクチャ分類を担当します）。
4. フェーズを出力する前に、8 項目のフェーズ lint とフェーズフィンガープリントのため、フェーズ契約を読み込みます。
5. コミットする前に、検証契約を完了し、凍結した ACCEPTANCE.md を作成します。
6. 草案の作成中は、evidence-grounding に従って根拠を示し、pre-execution-review に従って両方の台帳を凍結します。引き継ぎの前に、evidence-grounding の stage: plan 準備状況の事前確認を実行し、そのブロックを貼り付けます。READY-FOR-REVIEW は引き継ぎを許可するものであり、レビューの判定ではありません。また、このスキルは自身の計画をレビューしません。

リソースは規範であり、このファイルから 1 ホップの場所にあります。必要なリソースが見つからない場合は停止してください。固定ブロックやフェーズルールを決して推測で補わないでください。

引き継ぎ

コミット後、次の内容をそのまま出力します。

SPEC drafted: docs/fix/<primary>-<topic>/SPEC.md
Branch: fix/<primary>-<topic> (local, not pushed)
Commit: <short hash>
Issue set: #<primary> + #<n2> + #<n3> (print every issue in this unit; single issue → #<primary>)

→ Next: /review-plan fix-<primary> — an independent context reviews this plan and
  these ledgers before any phase runs; /execute-phase --fix <primary> follows its
  PLAN-REVIEW-PASS (issue set #<primary> + #<n2> + #<n3>)
  · PLAN-REVIEW-FAIL → repair here as one batch, rotate the artifact revision, re-review
  · a product choice is open → /design-feature, then /review-spec, then replan this fix
  · after PASS, explicit atomic mode → /execute-phase --fix <primary> P<n> (same issue set)
  · the final `Hardening & PR` phase pushes and opens the PR with `Closes #<primary>`
    plus one `Closes #<n>` line for every other issue listed in the Issue set
  · scope looks wrong → adjust the SPEC and re-run /plan-fix

出力する前に、すべてのプレースホルダーを実際の課題セット全体に置き換えてください。実際の引き継ぎでは、<n2>、<n3>、… を決して出力しないでください。

その後、ユーザーの言語で 2〜3 文の要約を書いて終わります。SPEC で実現する内容、最大のリスク、実装者に残されている未決事項を説明します。

可搬性（Claude Code 以外のエージェント向け）

プリミティブが利用できない場合は、明示的な代替手段を使います。名前付きの SKILL.md ファイルを新しいコンテキストで開き、最も能力の高いモデルでアーキテクトレベルのスコープ設定を行った後、より低コストのワーカーに実装を引き継ぎます。

完了条件

• SPEC と凍結した ACCEPTANCE.md が標準契約に従い、リスクやブロッカーを明示し、docs/fix/README.md に登録され、ローカルで fix/<n>-<topic> にコミットされていること（プッシュや PR は行わない）。締めくくりの → Next: 引き継ぎが出力されていること。