なぜカスタムプロンプトは廃止されるのか
旧フォーマットに関するOpenAIのページは、次のような決定的な一言から始まります。「カスタムプロンプトは非推奨です。Codexが明示的または暗黙的に呼び出すことができる再利用可能な指示には、スキルを使用してください。」
同ページでは、この変更が必要となった制限について説明しています。「カスタムプロンプトは明示的な呼び出しが必要であり、ローカルのCodexホームディレクトリ（例：~/.codex）に保存されるため、リポジトリを介して共有されません。プロンプトを共有したい場合（またはCodexに暗黙的に呼び出させたい場合）は、スキルを使用してください。」
この一文がすべてを物語っています。カスタムプロンプトはその構造上、個人用です。~/.codex/promptsに保存され、その名前を入力することで呼び出されますが、同じリポジトリをクローンした同僚には一切共有されません。そこにエンコードされていたプロセス知識が何であれ、実際には一人のものに留まっていました。
スキルはこれとは逆の目的で設計されています。OpenAIはスキルを「指示、リソース、およびオプションのスクリプトをパッケージ化し、どちらの製品でもワークフローを確実に実行できるようにするもの」と説明しており、Codexは複数の場所からこれらを読み込みます。リポジトリの場合、「Codexは、現在の作業ディレクトリからリポジトリのルートまでのすべてのディレクトリにある.agents/skillsをスキャンします。」ユーザー、管理者、システムの場所もありますが、リポジトリの場所こそがスキルを共有可能にするものです。
フォルダ名に注意してください。.codex内のフォルダではなく、.agents/skillsです。ユーザーレベルの場所も同様のパターンに従い、$HOME/.agents/skillsとなります。Codexのホームディレクトリ内でCodexのスキルフォルダを探している人は、探す場所を間違えています。
また、スキルはCodex CLI以外でも機能します。「スタンドアロンのスキルは、ChatGPTデスクトップアプリ、Codex CLI、およびIDE拡張機能で利用可能です。」この適応範囲の広さも、古いフォーマットが維持されるのではなく廃止される理由の一部です。
よくある誤った代替アプローチ
プロンプトをそのままの場所に残す。 当面は機能し続けますが、非推奨であるため新しい機能が適用されることはなく、チームの他のメンバーからは見えないままです。
各プロンプトをそのままSKILL.mdに貼り付ける。 見た目は正しく見えますが、挙動が異なります。プロンプトは名前を入力したときにのみ実行されました。しかし、スキルは自動的に選択される可能性があります。Codexは「暗黙的な呼び出し」を通じて、「タスクがスキルのdescription（説明）と一致したとき」にスキルを有効化できます。以前はあなたの指示を待っていたデプロイルーティンが、自発的に提案されるようになるかもしれません。
プレースホルダーを残したまま、展開されることを期待する。 カスタムプロンプトは、コマンドの後に入力するスペース区切りの引数から展開される1から9までの位置プレースホルダー、さらに$ARGUMENTSや$FILEのような名前付きプレースホルダーをサポートしていました。スキルのドキュメントには、これと同等のプレースホルダー展開についての記載はありません。OpenAIのインポートガイドでは、まさにこのカテゴリをレビュー対象として指摘しています。「引数、シェル補間、またはファイルパスのプレースホルダーに依存するプロンプトテンプレートまたはコマンドスタイルのプロンプト。」
すべてのスキルをリポジトリのルートに配置する。 Codexが階層構造を提供しているのには理由があります。特定のサービスに関連するスキルはそのサービスのディレクトリに配置でき、ルートレベルのスキルはすべてのサブフォルダから表示されます。
インポーターに頼り切る。 OpenAIのインポートフローは、他のエージェントから設定を移行する際に「スラッシュコマンド」を「スキル」にマッピングします。これは他のツールのコマンドをカバーするものですが、あくまで出発点であり、完全な移行レビューの代わりにはなりません。
解決策：各プロンプトを慎重に変換し、呼び出し方法を決定する
ゴールは、プロンプトが実行していた処理を行い、チーム全員が確認できる場所に配置され、必要なときにだけトリガーされるスキルのセットを作成することです。
ステップ 1：プロンプトを整理し、所有者ごとに分類する
~/.codex/prompts を開き、すべてのファイルをリストアップします。それぞれのファイルについて、機能、引数の有無、そして個人用かチームのプロセスか、の3点を確認します。
個人用のプロンプト（好みのコミットメッセージのスタイルや、自分だけの習慣など）は、ユーザーレベルの $HOME/.agents/skills に配置します。OpenAIはこの場所の推奨用途として、「ユーザーが作業するあらゆるリポジトリに適用される、ユーザーに関連するスキルを管理するため」と説明しています。
チームのプロセス（リポジトリのリリース方法、レビューの実行方法など）は、リポジトリ内に配置します。リポジトリ内のどこでも適用される場合はルートを使用します。OpenAIはルートスキルを「リポジトリ内の任意のサブフォルダで利用可能」と説明しています。特定の領域にのみ適用される場合は、より近い場所に配置します。フォルダレベルのスキルは、「マイクロサービスやモジュールにのみ関連するスキル」に適しています。
リストアップする際、目的が重複しているプロンプトがないか確認してください。Codexは重複を調整しません。「2つのスキルが同じ name を共有している場合、Codexはそれらをマージしません。両方がスキルセレクターに表示される可能性があります。」同じ名前を持つほぼ同一の2つのスキルが両方表示されると、あなたやチームメンバーが混乱する原因になります。
ステップ 2：各プロンプトをスキルとして書き直し、プレースホルダーを明示的な入力に置き換える
スキルは SKILL.md ファイルを含むフォルダであり、「SKILL.md ファイルには name と description を含める必要があります。」プロンプトごとに1つのフォルダを作成します。
説明（description）は、Codexがスキルを適用するかどうかを判断する基準となるため、最も重要な行です。OpenAIのガイダンスでは、「明確な範囲と境界を持つ簡潔な説明を記述してください。説明が短縮されてもホストがスキルを一致させることができるよう、主要なユースケースとトリガーワードを先頭に配置します」とされています。クリエイターテンプレートではさらに明確に、「このスキルがいつトリガーされるべきか、またされるべきでないかを正確に説明してください」と記載されています。
引数を取るプロンプトについては、各プレースホルダーを、指示が要求する明示的な入力に変換します。プロンプトがCodexに「まずこれらをステージングする: $FILES」と指示していた箇所を、スキルでは「どのファイルをステージングするか、また指示されなかった場合にそれをどのように特定するか」を記述します。スキルのベストプラクティスでも同様に、「明示的な入力と出力を伴う命令的なステップを記述する」ことが推奨されています。
各スキルは1つのタスクに集中させ（OpenAIはベストプラクティスの筆頭に「各スキルを1つのタスクに集中させる」を挙げています）、決定論的な挙動や外部ツールが必要な場合を除き、スクリプトよりも指示（テキスト）を優先します。
プロンプトを説明するよりも実演する方が簡単な場合、OpenAIは他の2つの方法をドキュメント化しています。1つはCodex内で $skill-creator として呼び出される組み込みのクリエイターで、「スキルが何を行うか、いつトリガーされるべきか、指示のみにするかスクリプトを含めるかを質問」します。もう1つは、デモンストレーションからスキルを起草する「Record & Replay（記録と再生）」です。
ステップ 3：呼び出し方法を決定し、重複を無効化して、トリガーをテストする
変換したすべてのスキルについて、自動で実行させるべきかどうかを判断します。デプロイ、プルリクエストの作成、ブランチの削除など、副作用を伴う処理はすべて、明示的な呼び出しに留める候補となります。
OpenAIは、スキル内のオプションの agents/openai.yaml ファイルでこの切り替えをドキュメント化しています。allow_implicit_invocation はデフォルトで true ですが、「false の場合、Codexはユーザーのプロンプトに基づいて暗黙的にスキルを呼び出しません。明示的な $skill 呼び出しは引き続き機能します。」これにより、必要なスキルに対して従来のプロンプトの挙動を復元できます。
スキルを削除せずに無効化する場合、OpenAIは ~/.codex/config.toml 内の [[skills.config]] エントリに enabled = false を指定し、その後再起動することをドキュメント化しています。
その後、テストを行います。OpenAIの推奨事項は、「プロンプトをスキルの説明に対してテストし、正しいトリガー挙動を確認する」ことです。各スキルをトリガーすべきいくつかのタスクと、トリガーすべきでないいくつかのタスクをCodexに与え、意図通りの結果になるまで説明を調整します。Codexは「スキルの変更を自動的に検出」しますが、更新が反映されない場合は再起動を推奨しています。
最後に、スキルが正常に動作するようになったら、古いプロンプトファイルを削除して、各ルーティンのバージョンを1つに統一します。
MemoryLakeでのセットアップ
変換されたスキルは、タスクの実行方法を記録します。しかし、なぜそのタスクがその方法で行われるのか（リリースチェックリストを作成するきっかけとなった障害や、レビューでマイグレーションを最初に確認する理由など）は記録されません。MemoryLakeは、手順とその根拠が乖離しないように、それらの理由を保管しておく場所です。
エントリーはあなた自身の言葉で記述します。Codex의 ホームフォルダ、リポジトリのスキルディレクトリ、またはベンダーのストアから何かが読み取られたり、書き込まれたり、削除されたりすることはありません。
ステップ 1：APIキーを作成する
サインインし、ダッシュボードからキーを生成します。このキーにより、Codexやチームが使用するその他のツールにおいて、エージェントが作成したエントリーを読み取ることができるようになります。
ステップ 2：最初のメモリをアップロードする
チームの各スキルについて、その背景にある決定事項（なぜそのステップが存在するのか、それがなかったときに何が起きたのか、誰が合意したのか）を追加します。1つのエントリーにつき1つの決定事項と、その理由を紐付けます。
ステップ 3：AIとエージェントを接続する
エージェントの参照先をワークスペースに設定します。これにより、.agents/skillsをまったく読み込まないツールを含め、作業が発生するあらゆる場所でその理由を参照できるようになります。
実務における変化
第1の違いは、プロセス知識がチームの知識になることです。個人のホームフォルダにあるプロンプトは、その人が離れれば失われていました。リポジトリ内のスキルはレビューされ、バージョン管理され、全員が利用可能になります。これは、CodexにAGENTS.mdのルールを一貫して遵守させることを、個人の問題ではなくチームの関心事にするのと同じアプローチです。
第2に、呼び出しが「意思決定」になります。プロンプトは常に明示的でした。スキルはデフォルトで自動使用の対象となります。スキルごとにこの選択を行うというわずかな作業が、大きな予期せぬトラブルを防ぎます。
第3に、ルールと手順の区別が明確になります。常に真であるプロジェクトの事実は指示ファイルに属し、タスクの手順はスキルに属します。これと同様の切り分けは、Cursorにおけるスキルとルールの使い分けでも議論されており、ここでも同様に当てはまります。この2つを混同することが、そもそもCodexがプロジェクトのコンテキストを忘れてしまう理由の1つです。
第4に、ポータビリティ（移植性）です。スキルはオープンスタンダードに従っているため、同じフォルダが複数のツールで機能します。これは、Devinのメモリをスキルに移行する背景にあるパターンや、Zedのスキルカタログのように、スキルが予想外のカタログに登場する背景にあるパターンと同じです。
プロンプトからスキルへの変換におけるベストプラクティス
.codexではなく.agents/skillsを探す。 リポジトリのスキルは.agents/skillsディレクトリに、ユーザーのスキルは$HOME/.agents/skillsに配置されます。
変換する前に個人用とチーム用を分類する。 スキルをどこに配置するかによって、誰がそれを利用できるかが決まります。
説明（description）をトリガー条件として記述する。 いつ適用されるべきか、されるべきでないかを明記し、重要なキーワードを先頭に配置します。
プレースホルダーを明示的な入力に置き換える。 スキルのドキュメントには引数の展開についての記載はなく、OpenAIのインポートガイドではプレースホルダーに依存するプロンプトをレビュー対象として指摘しています。
副作用のある処理については暗黙的な呼び出しをオフにする。 allow_implicit_invocationをfalseに設定し、それらのスキルは明示的な呼び出しに留めます。
各スキルにユニークな名前を付ける。 Codexは同名のスキルをマージせず、並べて表示します。
根拠を永続的な場所に保管する。 スキルは手順であり、メモリ（記憶）ではありません。GrokのスキルがAIメモリにとって何を意味するかでも、別のベンダーにおける同様の区別について説明しています。また、CursorのルールをCodexに移行するでは、常時有効な指示を移行する隣接するタスクについてカバーしています。
結論
OpenAIの非推奨に関する通知はわずか2文ですが、その2文目がすべてを説明しています。カスタムプロンプトは「ローカルのCodexホームディレクトリに保存される」ため、「リポジトリを介して共有されません。」スキルはこれを解決します。スキルは.agents/skillsに保存され、フォルダまたはリポジトリ全体にスコープを設定でき、Codex CLI、IDE拡張機能、およびChatGPTデスクトップアプリで動作します。
変換の際には注意が必要です。スキルは、明示的に指定しない限り自動的にトリガーされる可能性があり、プロンプトが依存していたプレースホルダーは明示的な入力に変換する必要があります。
プロンプトを整理し、所有者ごとに分類し、正確な説明を添えてそれぞれを書き直し、呼び出し方法を慎重に設定して、トリガーをテストします。その後、古いファイルを削除し、各ルーティンの背景にある理由を、次のチームメンバーが読める場所に保管してください。