PLAN
計画してから実行
〔やりたいこと〕を実装したい。まずは関係するファイルを読んで現状を理解し、変更が必要なファイルと手順の計画を出して。私がOKしてから実装に入って。実装後はテストを実行して、結果を見せて。
使いどころ複数ファイルにまたがる変更や、不慣れなコードを触るときの基本形。対話中に /plan でプランモードにしてから頼むと、いきなり書き換えずに段取りから始められます。
Codex プロンプト事例集
「何を頼めばいいか」を目的別に19レシピにまとめました。計画・実装・修正・レビュー・運用・調査の6カテゴリから、いまの状況に近い型を選んでコピーして、Codexにそのまま貼るだけです。
モコのひとことぜんぶ覚えなくて大丈夫です。困ったときにこのページへ戻ってきて、近いレシピを探してみてくださいね。
HOW TO USE
使い方は3ステップ。置き換え箇所は〔〕です
プロンプトの中の 〔〕 が、あなたの状況に置き換える箇所です。たとえば 〔やりたいこと〕 は「ログイン画面にエラーメッセージを表示」のように書き換えます。〔〕以外はそのままで使えます。
STEP 1コピーボタンを押す各レシピの右上の「コピー」ボタンです。
STEP 2〔〕を置き換える自分のファイル名や症状に書き換えます。
STEP 3Codexに貼り付けそのまま送れば型どおりに進みます。
0 件
PLAN
計画
書き始める前に方向を合わせるレシピです。手戻りをいちばん減らせます。
SPEC
質問で仕様を固める
〔作りたいもの〕を作りたい。いきなり実装せず、まず私に1問ずつ質問して、仕様を一緒に詰めて。十分に固まったら「対象ファイル・やること・やらないこと・完成の確認手順」を短くまとめて。実装はその後、私の合図があってから始めて。
使いどころ要件が自分の中でもふわっとしているとき、書く前に対話で固める型。決まった約束ごとは AGENTS.md（＝Codexへの指示ファイル）に残しておくと、次回から毎回伝えずに済みます。
COMPARE
複数案を比べて選ぶ
〔課題〕の進め方を、コードを書く前に3案出して。それぞれ「変更範囲・メリット・デメリット・リスク」を表で比べて、おすすめとその理由も教えて。まだコードは書かないで。私が案を選んでから実装に進んで。
使いどころやり方に迷いがあるとき、先に選択肢を並べて方向ちがいの事故を防ぐ型。まだ手を動かしてほしくないので、サンドボックス（＝AIが触れる範囲を絞る安全な箱）を read-only にしておくとより安心です。
BUILD
実装
作りながら暴走させない頼み方です。小さく進めて、証拠で確かめます。
MATCH
手本とAGENTS.mdに沿って実装
〔対象ファイル〕に〔何〕を追加して。〔手本になるファイル〕が良いお手本なので、そのパターンに倣って。新しいライブラリは増やさず、AGENTS.md や既存の作りに合わせて。できたら〔確認コマンド：例 npm test〕で動作を確かめて報告して。
使いどころ既存コードの流儀から外れた実装をされたくないときの定番。約束ごとを AGENTS.md（＝Codexへの指示ファイル）に書いておくと、毎回伝えなくても沿ってくれます。
TDD
失敗するテストから作る
これはTDD（＝先にテストを書く進め方）でお願い。まず〔機能〕の仕様を満たす「失敗するテスト」を書いて、実際に落ちることを見せて。次に、そのテストが通る最小限の実装を書いて、緑になるまで直して。テストを消したり骨抜きにして通すのはやめて。落ちたら実装側を直して。
使いどころ仕様をテストで表せる機能なら、これがいちばん確実な進め方。承認を on-request（＝必要なときだけ確認）にしておくと、テスト実行のたびに止まらず進みます。
PROOF
証拠つきで完了報告
実装したら「できました」で終わらせないで。〔検証コマンド：例 npm test〕を実行して、その出力をそのまま貼り、通っていることを証拠で示して。もし失敗していたら、報告の前に根本原因を直して。ビルドや型チェックがあれば、それも同じように確かめて。
使いどころ「できたはず」を防ぐ一文。どんな実装依頼のうしろにも足せます。仕上げに /review や codex review を重ねると、見落としをもう一段すくえます。
FIX
修正
バグやエラーを、握りつぶさず根本から直すための型です。
DEBUG
再現テストから直す
〔症状〕という不具合がある。〔怪しい場所〕あたりが怪しい。まず問題を再現する失敗テストを書いて、原因を特定し、根本から直して。エラーを握りつぶさず、原因に対処して。最後にテストが通ることを、実行結果で示して。
使いどころ「再現→特定→修正→証明」の順番を崩さないための基本の型。原因が思ったより深いときは、一度に直そうとせず一段ずつ確かめてもらうと迷子になりにくいです。
HYPO
原因を仮説→検証で追う
〔症状〕で行き詰まっているので、状況を全部渡します。エラー全文：〔ログを貼り付け〕。関係ファイルは〔対象〕、すでに試したのは〔試したこと〕。まず原因の仮説を3つ、それぞれの確かめ方つきで挙げて。確認が取れたものから根本原因を直して、再発しないことを実行結果で示して。
使いどころ原因不明のエラーは、材料を全部渡して仮説から順に潰してもらうのがコツ。最新の仕様変更が絡んでいそうなら、--search（＝Web検索）を足して調べてもらう手もあります。
REFACTOR
安全網つきリファクタ
〔対象〕をリファクタ（＝振る舞いを変えずに中身を整理）したい。外から見た動きは一切変えないで。まず今のテストが通ることを確認し、足りなければ先に今の挙動を固定するテストを足して。そのうえで小さな単位で整理し、各ステップでテストを実行して緑を保って。1つの論理変更ごとにコミットして、何を変えたか説明して。
使いどころ動いているコードを崩さず整理したいときの安全網セット。心配なら、まず /diff で「今なにが変わったか」を確かめてからコミットに進むと落ち着いて見直せます。
REVIEW
レビュー
出す前に品質を確かめる頼み方です。観点を固定すると毎回同じ質になります。
REVIEW
codex review で見直す
この変更をコードレビューして。見た目のスタイルよりも、バグ、仕様の抜け、既存の動きを壊していないか、テスト不足を優先して見て。問題があれば、ファイル名と該当箇所、なぜ危ないか、どう直すとよいかを具体的に教えて。問題がなければ「指摘なし」とはっきり言って。
使いどころコミット前のセルフチェックを毎回同じ観点で回す定番。対話中なら /review、ターミナルからひと息で頼むなら codex review でも、同じように見てもらえます。
SECURITY
公開前のセキュリティ点検
〔対象範囲〕を、公開する前提でセキュリティ点検して。特に、秘密情報の直書き、入力チェックの抜け、認証・権限まわり、インジェクション、依存ライブラリの既知の弱点を重点的に見て。見つかった問題は深刻度つきで一覧にして、直し方も添えて。修正はまだせず、私が優先度を決めてから直して。
使いどころ公開やデプロイの前に一度は通しておきたい観点別チェック。まず見てもらうだけにしたいので、サンドボックスを read-only（＝読み取り専用）にしておくと、点検中に書き換えられず安心です。
FRESH
先入観なしの別視点で見る
今の変更を、これまでの経緯は伝えず「差分だけ」を見てレビューして。バグ・抜けたエラー処理・境界ケース（＝端っこの入力）・既存パターンとの食い違い・セキュリティの観点で、批判的に点検して。好みの問題ではなく、正しさに関わる指摘だけをまとめて報告して。
使いどころ経緯を渡さないことで、自分のコードに甘くなるのを防げます。codex fork（＝会話を枝分かれ）や新しいセッションで、まっさらな目線から見てもらうのがおすすめです。
OPS
運用
コミット、自動化、設定、引き継ぎ。開発を続けるための段取りです。
COMMIT
変更の要約とコミット文
今の変更を確認して、複数の意味が混ざっていたら、意味のある単位に分けてそれぞれコミットして。各コミットは「何を・なぜ」が分かる日本語メッセージにして。コミット前に、消し忘れのデバッグ表示や直書きの値が残っていないか点検して。最後にコミット一覧を見せて。
使いどころ作業後の散らかった差分を、あとから読める履歴に整えたいとき。先に /diff で「今なにが変わったか」を一緒に確認しておくと精度が上がります。
EXEC
CI・スクリプト用のワンショット
〔やってほしい作業：例 テストを実行して、失敗があれば原因の要約だけ出す〕をお願い。追加の質問はせず、最後に結果を短くまとめて。ファイルの書き換えはしないで、レポートだけ返して。
使いどころこの文はそのまま非対話モードの codex exec に渡せます（例：codex exec -s read-only "〔上の文〕"）。CI（＝自動でテストなどを回す仕組み）や定期実行に向いた形です。確認を挟まない -a never を使うなら、サンドボックス（触れる範囲）を必ず絞ってから。結果をプログラムで受け取りたいときは --json を足すと1行ずつのJSONで返ります。
AGENTS
AGENTS.md のたたき台を作る
このプロジェクト用の AGENTS.md（＝Codexへの決まりごとを書くファイル）のたたき台を作りたい。「使っている言語やフレームワーク／ビルドとテストのコマンド／コーディングの約束ごと／触ってほしくない場所」を、私に一つずつ確認しながら短くまとめて。長くなりすぎないよう、要点だけで。
使いどころまず対話中に /init を実行すると AGENTS.md の雛形ができるので、そこへ具体を足していくイメージです。最初に用意しておくと、毎回同じ説明をしなくて済みます。Claude Codeから来た人は /import で CLAUDE.md を引き継ぐ手もあります。
HANDOFF
別デバイス引き継ぎメモ
そろそろ会話が長いので、引き継ぎメモを作って。「目的／今どこまで進んだか／効いたこと／効かなかったこと／次の一手」を、1つのファイルに簡潔にまとめて。次に別の場所で始めるとき、このメモだけ読めば続きに入れる粒度で。書けたら、要点を3行で報告して。
使いどころ別のパソコンで続けるときや、日をまたぐときの保険に。同じ端末なら codex resume（＝過去の会話を再開）で戻れますが、環境が変わる引き継ぎはメモが確実です。会話が重くなってきたら /compact（＝要約して軽くする）も合わせてどうぞ。
RESEARCH
調査
直す前にまず理解するための頼み方です。「読むだけ」と釘を刺すのがコツです。
EXPLORE
調べるだけ（書き換え禁止）
〔調べたいこと〕を調査して。今回はコードの変更は一切しないで、読むだけ。結論と根拠（ファイルの場所と該当箇所）を箇条書きで報告して。分からなかったことは、正直に「分からない」と書いて。直し方の案があれば提案だけ添えて、実行は私の指示を待って。
使いどころ「ついでに直しちゃう」を防いで、まず状況把握だけさせたいとき。サンドボックスを read-only（＝読み取り専用の安全な箱）にしておくと、仕組みの上でも書き換えを止められます。
TRACE
処理の流れを地図にする
〔機能：例 ログイン〕の流れを追って説明して。入口から順に、どのファイルでどう処理され、どこへつながるかを並べて。登場するファイルの場所と、各ステップ1〜2行の要約で、全体像が一目で分かる地図にして。最後に、初めて触る人がつまずきそうな箇所も教えて。
使いどころ新しいコードに入った初日に、まず頼みたい一件。手元に画面のスクショや資料があれば、/mention（＝ファイルを会話に添える）や -i（＝画像を渡す）で見せると話が早いです。
MCP
MCP追加を相談する
〔やりたいこと：例 チケット管理ツールと連携〕のために、MCP（＝外部ツールとつなぐ仕組み）を足すか相談したい。どんな選択肢があるか、それぞれの「つなぐ相手・必要な権限・気をつける点」をセットで整理して。おすすめと理由も。設定はまだせず、私が決めてから進めて。
使いどころ便利な反面、外部とつながる入口が増えるので、接続先と権限はセットで確かめてから。決めたら codex mcp add で登録できます（細かく決めたいときは設定ファイルの [mcp_servers.*] に直接書く方法も）。
該当するプロンプトがありません。キーワードを短くするか、フィルタを「すべて」に戻してみてください。
モコのひとこと：レシピは重ねられますたとえば COMPARE で方針を決めて、TDD で作って、最後に PROOF を足す。頼みごとの前後にレシピを重ねると、「できたはず」で終わらない進め方になります。迷ったら、まず /plan と read-only の組み合わせから試してみてくださいね。