Fable5でリファクタリング指示書を自動生成するプロンプト

Claude fable5 にリファクタリングさせた 結構いい 使ったプロンプト↓ あなたは、このコードベースを深く分析し、実装担当モデルがリファクタリングを完遂するための指示書を作る役割です。 あなた自身は、まだ実装しないでください。 あなたの仕事は、プロジェクト全体を読み、何を作っているのか、守るべき仕様は何か、どこに技術的負債があるのか、どこを触ると危険なのかを整理し、実装担当モデルに渡すためのMarkdown形式の指示書を作ることです。 最終的に、人間がCodexやOpusなどの実装担当モデルに次の形で渡せる refactor-instructions.md を作ってください。 「/goal refactor-instructions.md に書かれたことを完遂しろ」 まず、プロジェクトフォルダ内を読み込んでください。 存在する場合は、少なくとも以下を確認してください。 AGENTS.md CLAUDE.md README プロジェクト固有の指示ファイル packageや依存関係の設定 build、lint、test、typecheck、CI設定 docs、spec、設計メモ エントリーポイント 主要モジュール テスト DB schema、migration 認証、課金、通知、外部API、ジョブ、キュー、ストレージ関連 既存スクリプトや運用手順 まず、証拠にもとづいてこのプロジェクトを理解してください。 推測だけで判断しないでください。 次の内容を整理してください。 このプロジェクトは何をするものか 主要なユーザー体験やワークフローは何か 主要なエントリーポイントはどこか 主要モジュールと責務は何か データはどう流れるか 外部依存は何か 現在の検証コマンドは何か 絶対に壊してはいけない既存挙動は何か 次に、技術的負債を整理してください。 観点は以下です。 重複 死コード 責務の混在 所有範囲の曖昧さ 過剰または不足している抽象化 依存方向の乱れ 型、schema、契約の曖昧さ テスト不足や壊れやすいテスト エラーハンドリングやログの不統一 設定や環境差分の複雑さ 非同期処理や並行処理の危険箇所 パフォーマンス上のリスク セキュリティ上慎重に扱うべき境界 命名やファイル配置の分かりにくさ 各負債について、以下を書いてください。 根拠となるファイルや箇所 なぜ負債と言えるのか 影響範囲 変更リスク 改善案 検証方法 実装担当モデルが今実装してよいか、提案だけに留めるべきか 機能的に何が正しいかわからない場合は、勝手に決めないでください。 その場合は、実装用の指示書を確定する前に「実装前に確認すべき質問」としてまとめてください。 特に以下に該当する場合は、必ず質問にしてください。 正しい仕様がコードから判断できない テストと実装が矛盾している 削除候補のコードが本当に不要かわからない 公開API、DB schema、保存済みデータに影響する可能性がある 認証、課金、通知、外部連携に影響する可能性がある 互換性を壊す可能性がある 複数の設計案があり、プロダクト判断が必要 そのうえで、実装担当モデルに渡すためのMarkdown指示書を作ってください。 指示書には、必ず以下を含めてください。 Objective Project Understanding Behaviors To Preserve Non-Negotiables Stop And Ask Conditions Baseline Commands Debt Map Implementation Phases Verification Requirements Reporting Format Out-of-scope Items 実装フェーズは、小さく安全な順番にしてください。 推奨順序は以下です。 1. 現在状態と検証コマンドを確認する 2. 重要挙動にテストや再現手順がなければ先に安全網を作る 3. 明らかに安全な整理から始める 4. 小さな責務分離を行う 5. 境界やインターフェースを明確にする 6. テストしやすい構造にする 7. 大きな設計変更は、承認なしに実装せず提案に留める 実装用の指示書には、以下の制約も入れてください。 最初にgit statusを確認する 既存の未コミット変更と自分の変更を混ぜない 編集前にbaselineの検証結果を記録する 変更は小さく戻しやすい単位にする 無関係な整形やついでのリファクタリングをしない 既存挙動を勝手に変えない 正しさが不明な場合は実装を止めて質問する 各フェーズごとに検証する 最後に実行したコマンドと結果を報告する 最終出力では、次の2つを出してください。 1. 実装前に確認すべき質問 必要な場合のみ。コードから判断できるものは質問しないでください。 2. refactor-instructions.md本文 人間がそのまま保存して、CodexやOpusなどの実装担当モデルに /goal で渡せる内容にしてください。 重要: 曖昧な「全部リファクタして」という計画にしないでください。 見た目の綺麗さを目的にしないでください。 古いコードをすべて悪と決めつけないでください。 実装担当モデルが証拠なく大きな削除や全面書き換えをしないようにしてください。 目的は、既存仕様を壊さず、負債を減らし、今後変更しやすい状態にすることです。