修正で詰むときの処方箋：

「作り直し」と「デバッグ」を使い分けるプロンプト設計

TL;DR（Too Long; Didn’t Read）

詰む原因はだいたい ①仕様が散らかってる ②変更範囲が曖昧 ③合格条件がない の3つ。
解決は二刀流：
- 作り直し（再設計→再生成）…要件を一枚に収束→最短コード
- デバッグ反復…MRE（最小再現）→原因特定→最小差分パッチ
どちらでも効く共通ルール：I/O契約を書く／AC（受け入れ基準）を3〜5個／修正はdiffだけ。

なぜ詰むのか（短く説明）

要件が分散：会話ログや過去指示がバラバラで、モデルが「何が正か」を持てない。
差分がぼける：直すのか作り替えるのかが不明で、毎回の出力が全貼り替えになる。
合格条件がない：完成の定義がないから、いつまでも不満が残る。

使い分けの判断（30秒で決める）

“要件が揺れてる／根本の設計が怪しい” → 作り直し
“壊れてる箇所は局所／要件は固い” → デバッグ反復
迷ったら デバッグでMRE作成 → 設計レベル問題なら即作り直しへ切替。

作り直し：再設計→再生成プロンプト（コピペ可）

目的：過去の迷いを捨て、要件を一枚に確定→最短の完成コードを出させる。

# 役割
あなたは「シニアフロントエンドエンジニア兼PM」。結論ファースト、冗長禁止、事実のみ。

# ゴール（1文）
[プロダクト名] を [環境] 向けに、[ユーザー行動] を最小手数で実現する。

# 実行環境・制約
- 実行場所: [WordPressカスタムHTML 等]
- 外部ライブラリ: [禁止 / OK(具体名)]
- 1ファイル完結: [はい/いいえ]（最大[行数]行）
- モバイル最適化: [必須]（基準幅[ ]px）
- パフォ下限: 初回描画[ ]ms以内 / 画像合計[ ]MB以下
- アクセシビリティ: [キーボード操作/ARIA ○○]

# I/O契約（重要）
入力: ユーザーが [入力1/型/制約] を与える  
出力: 画面に [出力/型] が表示され、[コピー/保存/DL] 可能  
エラー: [UI挙動（例：赤枠+文言「○○が必須」）]

# 仕様（確定事項）
1. 機能A: [例：UTM生成→QR化→即時プレビュー]
2. 機能B: [ ]
3. 状態保持: [URLパラメータ/localStorage/なし]
4. デザイン: トーン[ミニマル]、カラー[#0f172a/#2563eb]
5. 文言: 日本語。ボタンは2〜4字。

# 受け入れ基準（AC）
- AC1: [特定入力] → [特定出力]（例：utm_medium=social がURLに付与）
- AC2: [操作手順] → [結果]（例：1クリックでQR更新）
- AC3: 幅375px/768px/1024pxで崩れゼロ
- AC4: ページ再読込で前回値を復元
- AC5: Lighthouse Best Practices 80点以上（近似で可）

# 出力形式（厳守）
1. 設計要約（50行以内：依存/構成/UI/データフロー）
2. 完成コード（1ファイル：HTML+CSS+JS、コメント最小）
3. 自己テスト手順（5ケース）→AC検証可能に
4. 将来の拡張ポイント（3つ）→今は実装しない

使い方のコツ

空欄は数値と具体語で埋めてから投入（行数・色・文言・幅）。
ACは最低3つ。UI/機能/レスポンシブをカバー。
「拡張ポイント」を書き、今やらない範囲をロックしてスコープ肥大を防ぐ。

デバッグ反復：最小差分で直すプロンプト（コピペ可）

目的：壊れた現物を“点で”直す。MRE→仮説→パッチ→回帰テストを機械的に回す。

# 役割
あなたは「Principal Engineer」。仮説検証駆動。修正は最小差分パッチ(unified diff)で提示。不明は「不明」と言う。

# 目的
[バグの一文要約] を再現→根本原因特定→動作回復→回帰テスト追加。

# 現状（MRE：最小再現情報）
- 期待する動作: [ ]
- 実際の結果: [ ]
- 再現手順: [1] [2] [3]
- エラー/ログ: [ ]
- 影響範囲: [ファイル/関数/UI]
- 環境: [ブラウザ/OS/画面幅/WP等]

# 変更ガード（壊さないための柵）
- 既存のUI文言/色/クラス名は変更しない（必要時のみ理由明記）
- コードスタイルは現状踏襲（セミコロン/インデント）
- パフォ低下は不可。増える場合は根拠と代替案も。

# 出力形式（厳守）
1) 原因分析（箇条書き最大3点）
2) 代替案の比較（A/B）…長所/短所/影響範囲
3) 採用案と理由（1段落）
4) パッチ（unified diff、変更行のみ）
5) 回帰テスト（手動チェック or 小JSテスト）5ケース
6) リスクとロールバック手順（簡潔）

# 方針
まず再現→最小ログ埋め込み→仮説→1か所ずつ差替→再テスト。ライブラリ追加や大改修は最後。

“差分だけ出させる”ための追記（推奨）

以降の回答は「差分パッチ（unified diff）」のみ。説明は最後に1段落だけ。非変更箇所は出さない。

どちらでも効く短いアドオンプロンプト（場面別）

ログ最小挿入 再現に必要な最小ログを追加。console.logは `tag:phase:key` 形式で統一。出力例も示して。
I/O契約の再宣言 この機能のI/O契約を3行で。入力（型/制約）、出力（型/副作用）、エラー時UI。
パフォ劣化NG DOM更新回数や計算量を増やさない修正を優先。増やす場合は根拠と代替案を併記。
回帰テストを先に この不具合が再発しないことを保証する手動チェックリスト（5項目）を先に書いて。次にパッチを。

実戦チェックリスト（送る前に5項目だけ確認）

I/O契約を書いたか
AC（3〜5個）が具体か
MRE（入力/操作/期待/実結果）が揃ってるか
スコープ外（やらないこと）を明記したか
diff要求（全貼り替え禁止）を入れたか

ありがちな失敗 → こう直す

「直して」だけで依頼 → I/O＋ACを短く足す 目的：URL生成UIの不具合修正。 I/O：入力=source/medium/campaign（必須）、出力=プレビューURL、エラー=未入力は赤枠+文言。 AC：①3入力→即時URL更新 ②QRは1クリック更新 ③375/768/1024pxで崩れなし。
動くけど遅い → 時間予算を入れる パフォ下限：初期描画400ms以内、再描画200ms以内。増える場合は根拠と代替案をセットで。
勝手に全改修された → ガード＆diff必須 既存のUI文言/クラスは維持。変更が必要なら理由を明記。出力はunified diffのみ。

例：UTM+QRツールを再生成する場合（サンプルAC）

AC1: utm_source/utm_medium/utm_campaign 入力で即時プレビューURL更新  
AC2: 「QR生成」押下でキャンバスにQR描画→PNG保存可  
AC3: 未入力時はボタン無効＋理由表示  
AC4: 再読込で前回値を復元（localStorage）  
AC5: 375/768/1024pxで崩れなし

よくある質問（短かく回答）

Q. どっちを先に試す？
A. デバッグ→MREから。設計レベルの破綻が見えたら即「作り直し」へ。

Q. ACは何個？
A. 3〜5個。多すぎるとブレる。UI/機能/レスポンシブ/パフォから抽出。

Q. diffを嫌がられる
A. 出力形式にunified diff限定を明記。説明は1段落だけ許す。

メタ情報（そのまま使える）

タイトル案：修正で詰む人へ：作り直しとデバッグのプロンプト設計（テンプレ配布）
スラッグ：prompt-templates-regenerate-vs-debug
メタディスクリプション：修正で詰む原因は「仕様分散・差分不明・合格条件なし」。作り直し／デバッグの二刀流テンプレと、I/O契約・AC・diffで詰みを防ぐ実戦手順をまとめました。
見出し構成：TL;DR → 判断 → テンプレ（再生成/デバッグ） → アドオン → チェックリスト → 失敗例 → FAQ