Codex Skillsの使い方｜SKILL.mdの作り方・置き場所・呼び出し方【2026年10月】

Codex Skills（スキル）は、繰り返し使う作業手順を SKILL.md というファイルにまとめ、Codexに必要なときだけ読み込ませる仕組みです。 $ でスキル名を指定して呼び出すほか、依頼内容がスキルの説明文（description）に合えば、Codexが自分で選んで使います。

置き場所はリポジトリ内の .agents/skills、自分のホームの ~/.agents/skills など6区分あり、作成は組み込みの $skill-creator に頼むのがいちばん速い方法です。一方で、説明文の書き方しだいで「呼んでいないのに動く」「呼びたいのに選ばれない」が起きやすく、チームで配るならプラグインという別の仕組みも関わってきます。

本記事では、Codex Skillsの仕組み、作り方、置き場所、呼び出し方、配布の方法、そしてClaude Code Skillsとの違いまでを、OpenAIの公式ドキュメントと照合して整理しました。

本記事の情報について：2026年10月12日に確認したOpenAIの公式ドキュメント（Build skills・Skills & Plugins・Skill controls・Custom Prompts・Package your plugin）と、スキルの共通仕様であるAgent Skills Specificationにもとづいています。Codexのドキュメントは現在 learn.chatgpt.com で公開されています。

状況別の読み分け早見表

Codex Skillsとは — 作業手順をまとめて必要なときだけ読ませる仕組み

Codex Skillsは、指示・参考資料・スクリプトを1つのフォルダにまとめた「再利用できる作業手順」です。OpenAIのBuild skillsは、スキルを「タスクに固有の能力でChatGPTとCodexを拡張するもの」と説明し、手順・資料・必要に応じたスクリプトを1つにまとめることで、決まったワークフローを確実にたどれるようにすると書いています。

毎回チャットに同じ指示を貼り付ける代わりに、手順を一度スキルとして書いておけば、Codexはその作業が来るたびに同じやり方で進めます。公式のSkills & Pluginsでは、日次の要約づくり、ドキュメントの点検、資料作成、チームの文章ルールの適用といった例が挙がっています。「人によってやり方がばらつく作業」「暗黙知になっている作業」ほど、スキルにする価値があります。

スキルの中身はフォルダ1つ

スキルの実体は、SKILL.md を含むディレクトリです。SKILL.md には name と description が必須で、それ以外のフォルダは任意です。

my-skill/
├── SKILL.md          # 必須：メタデータ（name・description）と手順
├── scripts/          # 任意：実行するコード
├── references/       # 任意：必要なときに読む参考資料
├── assets/           # 任意：テンプレートや素材
└── agents/
    └── openai.yaml   # 任意：表示名・呼び出し方針・依存ツール

scripts/ には決まった処理を確実に行うためのコード、references/ には手順の途中で参照する詳しい資料、assets/ には出力のひな形や画像などを置きます。agents/openai.yaml はOpenAI製品向けの追加設定で、表示名や「自動で呼ばれてよいか」を決めるファイルです（後述）。

必要なときだけ読み込む「段階的な読み込み」

スキルの最大の特徴は、最初から全文を読み込まないことです。公式ドキュメントはこれを progressive disclosure（段階的な開示） と呼んでいます。

Codexは起動時に、各スキルの name と description、それにファイルのパスだけを一覧として受け取ります。そして、いまの作業にそのスキルを使うと判断したときに、はじめて SKILL.md の全文を読みます。scripts/ や references/ の中身は、手順の中で必要になった時点で読みます。

この一覧には上限があります。公式ドキュメントによると、最初の一覧はモデルのコンテキストウィンドウの最大2%、ウィンドウの大きさが分からない場合は8,000文字までに収められます。スキルが多いと、Codexはまず説明文を短く切り詰め、それでも収まらなければ一部のスキルを一覧から外して警告を出します。ただし、この上限がかかるのは最初の一覧だけで、選ばれたスキルの SKILL.md は全文が読まれます。

たとえば仮にコンテキストウィンドウが20万トークンなら、一覧に使えるのは4,000トークンほどです。スキルを数十個入れると、1つあたりの説明文に割ける量はかなり小さくなります。説明文の冒頭に、いちばん大事な用途と呼び出しのきっかけになる言葉を置くのは、切り詰められても判別できるようにするためです。

共通仕様「Agent Skills」にもとづいている

Codex Skillsは、Agent Skillsというオープンな共通仕様の上に作られています。仕様書（Agent Skills Specification）が定めている主なルールは次のとおりです。

仕様書は、SKILL.md 本体を500行以内に収め、詳しい資料は別ファイルに分けることを勧めています。読み込みの目安として、メタデータは約100トークン、SKILL.md 本文は5,000トークン未満が推奨とされています。なお、Codexの公式ドキュメント（Build skills）が必須として挙げているのは name と description の2つで、license などの任意項目をCodexがどう扱うかまでは書かれていません。Codexで確実に効くのは name・description・agents/openai.yaml の設定、と考えておくのが安全です。

スキル・プラグイン・カスタムプロンプト・MCPの違い

Codexには、指示や機能を足す仕組みがいくつかあります。役割が近いので、まず違いを押さえておくと迷いません。

公式の使い分けは明快で、特定の作業の手順を再利用したいならスキル、外部サービスとの接続も含めてインストールできる形で配りたいならプラグインです（Skills & Plugins）。カスタムプロンプトは非推奨になっており、公式はスキルへの移行を案内しています。MCPサーバーの設定そのものはCodex MCP設定ガイドで詳しく扱っています。

Codex Skillsの呼び出し方 — $ メンションと自動起動

スキルの使われ方は「明示的な呼び出し」と「暗黙の呼び出し（自動起動）」の2つです。どちらで使われるかは、スキル側の設定と説明文で決まります。

$ メンションと /skills で明示的に呼ぶ

Codex CLIやIDE拡張では、プロンプトの中で $ を入力するとスキル名を指定できます。/skills を実行して一覧から選ぶこともできます。ChatGPT側では @ でスキルを選びます（Build skills）。

$db-migration-check 今回追加したマイグレーションを点検して

明示的に呼べば、説明文の一致度に関係なくそのスキルが使われます。「この作業は必ずこの手順でやってほしい」ときは、自動起動に頼らずに名前で呼ぶのが確実です。

説明文に合えば自動で使われる

明示しなくても、依頼の内容がスキルの description に合っていれば、Codexがそのスキルを選んで使います。自動起動の判断材料は説明文だけなので、説明文の質がそのままスキルの使われやすさになります。

公式ドキュメントは、説明文を「対象範囲と境界がはっきりした簡潔な文」にし、主な用途ときっかけになる言葉を前に置くよう勧めています。範囲があいまいな説明文だと、関係のない依頼でスキルが動いたり、逆に必要な場面で選ばれなかったりします。

自動起動を止めたいスキルは allow_implicit_invocation

本番環境への反映や、データを書き換える手順のように「勝手に動いてほしくない」スキルもあります。その場合は agents/openai.yaml に次のように書きます。

policy:
  allow_implicit_invocation: false

allow_implicit_invocation の既定値は true です。false にすると依頼内容からの自動起動はされなくなりますが、$スキル名 での明示的な呼び出しは引き続き使えます。「人が呼んだときだけ動く手順書」にしたいスキルは、この設定にしておくと安心です。

スキルの置き場所 — Codexが探す6つの場所

Codexは、リポジトリ・ユーザー・管理者・システムの4種類、合わせて6つの場所からスキルを読み込みます。リポジトリ内では、Codexを起動したディレクトリからリポジトリのルートまで、各階層の .agents/skills を順にたどって探します。

置き場所を決めるときの考え方はシンプルです。そのリポジトリの事情に依存する手順はリポジトリに、自分の作業スタイルに関わる手順はホームに置きます。リポジトリに置いたスキルはファイルとして一緒に管理されるので、チームの全員が同じ手順を使えます。モノレポなら、全体共通のスキルを最上位に、特定パッケージ専用のスキルをそのパッケージの .agents/skills に置けば、作業する場所に応じて必要なスキルだけが加わります。

同じ名前のスキルは「上書き」されない

複数の場所に同じ name のスキルがある場合、Codexはそれらを統合しません。どちらもスキルの選択肢に表示されます（Build skills）。ホームのスキルをリポジトリのスキルで上書きする、といった優先順位の仕組みはありません。

同じ名前が並ぶと、人が選ぶときも自動起動のときも紛らわしくなります。チームのスキルと個人のスキルで名前がぶつかりそうなら、個人側に my- のような接頭辞を付けるなど、名前を分けておくのが無難です。

シンボリックリンクも使える

Codexはシンボリックリンクにしたスキルフォルダに対応しており、スキャン時にはリンク先をたどります。別の場所で管理しているスキルを .agents/skills からリンクする、といった使い方ができます。後述するClaude Codeとの併用でも、この仕組みが役に立ちます。

古い解説にある ~/.codex/skills について

検索すると、スキルの置き場所を ~/.codex/skills と説明している記事も見つかります。2026年10月12日時点の公式ドキュメントが挙げる置き場所は上の6つで、ユーザー単位の場所は $HOME/.agents/skills です。古い記事を参考にしてスキルが出てこない場合は、まず置き場所が .agents/skills になっているかを確かめてください。

Codex Skillsの作り方

スキルを作る方法は3つあります。対話で作る $skill-creator、実演から作るRecord & Replay、そしてフォルダを手で作る方法です。

$skill-creator に作ってもらう

いちばん手軽なのは、Codexに同梱されている skill-creator を使う方法です。Codexで次のように呼び出します。

$skill-creator

skill-creator は、スキルが何をするのか、いつ呼び出されるべきか、手順書だけにするかスクリプトも含めるかを質問してきます。既定は手順書だけ（instruction-only）の構成です。答えていくとスキルの下書きができるので、中身を確認して手直しします。

公式のSkills & Pluginsが示す作り方の流れは、次の4段階です。

1. 作業を1つに絞る。 普段その作業を何から始めるか（ファイル、リンク、メモ）と、完成形がどうなっていればよいかを書き出す
2. 流れを説明する。 $skill-creator に、目的・手順・出力の形式・必ず含めること・避けることを伝える。テンプレートやよい例があれば添える
3. 下書きを確かめて試す。 手順を読み直し、実際に近い依頼で試して、抜けた手順や形式のずれを直す
4. 有効にして使い回す。 有効になったスキルは関連する依頼で使われ、明示的に呼ぶこともできる

なお、公式ドキュメントでは、作業を実演して記録し、その手順からスキルの下書きを作るRecord & Replayという方法も紹介されています。「説明するより見せたほうが早い」作業に向いています。

手書きで作る最小のスキル

フォルダと SKILL.md を自分で作っても構いません。公式ドキュメントの最小形は次のとおりです。

---
name: skill-name
description: Explain exactly when this skill should and should not trigger.
---

Skill instructions for ChatGPT or Codex to follow.

もう少し実務に近い例として、データベースのマイグレーションファイルを点検するスキルを書いてみます。リポジトリの最上位に .agents/skills/db-migration-check/SKILL.md として置く想定です。

---
name: db-migration-check
description: データベースのマイグレーションファイルを追加・変更したときに、本番適用前の危険な操作を点検する。マイグレーションの点検、スキーマ変更のレビューを頼まれたときに使う。アプリのコードだけの変更には使わない。
---

# マイグレーション点検

## 入力
- 今回追加・変更されたマイグレーションファイル

## 手順
1. 対象のマイグレーションファイルを列挙する
2. 各ファイルについて、次の操作が含まれるかを確認する
   - 列やテーブルの削除
   - NOT NULL 制約の追加（既存行に値がない場合）
   - 大きなテーブルへのインデックス追加
3. 該当があれば、影響と安全な代替手順を references/safe-patterns.md から引いて提案する

## 出力
- ファイルごとに「問題なし／要確認」と、その理由を1〜2行で書く

フォルダ名と name を一致させること、name は英小文字とハイフンだけにすることが、共通仕様のルールです。Codexはスキルの変更を自動で検出しますが、更新が反映されないときはCodexを再起動します。

選ばれやすい説明文の書き方

自動起動の判断材料は description だけです。上の例の説明文は、次の3つを意識して書いています。

• 何をするかを最初に書く：「マイグレーションファイルを点検する」を冒頭に置き、切り詰められても用途が分かるようにする
• 呼び出しのきっかけになる言葉を入れる：「マイグレーションの点検」「スキーマ変更のレビュー」のように、依頼に出てきそうな言い回しを含める
• 使わない場面を書く：「アプリのコードだけの変更には使わない」と境界を示し、関係のない依頼で動かないようにする

逆に「データベース関連の作業を手伝う」のような広すぎる説明文は、ほとんどの依頼に当てはまってしまいます。公式のベストプラクティスにある「1つのスキルには1つの仕事」は、説明文を絞り込むためにも効いてきます。

説明文を書いたら、動くべき依頼と動くべきでない依頼を並べて試すと、境界が狙いどおりかを確かめられます。上の db-migration-check なら、たとえば次のような組み合わせです。

2行目のように言い回しが違う依頼で選ばれない場合は、説明文に「スキーマ変更」「テーブルの列追加」のような言葉を足します。4行目で意図せず選ばれる場合は、「既存データの読み取りだけの作業には使わない」のように境界を書き足します。

手順書とスクリプトの分け方

公式ドキュメントは、決まった結果が必要な場合や外部ツールが必要な場合を除き、スクリプトより手順書（指示）を優先するよう勧めています。判断を伴う作業は手順書に、毎回同じ結果でなければ困る処理（集計、フォーマット変換、決まったコマンドの実行など）はスクリプトに、と分けると扱いやすくなります。

手順は「命令形で、入力と出力をはっきり書く」のが公式の推奨です。上の例で「入力」「手順」「出力」を分けているのはそのためです。長い参考資料は references/ に分け、SKILL.md からは「必要なときにこのファイルを読む」と書いておけば、段階的な読み込みの仕組みを活かせます。

何をどのファイルに書くか

共通仕様は SKILL.md を500行以内、本文を5,000トークン未満に収めるよう勧めています。スキルを使うたびに SKILL.md の全文が読まれるので、毎回必要な情報だけを本文に残し、それ以外は付属フォルダに逃がすのが基本です。

迷ったら「この情報がないと、毎回の作業が始められないか」で判断します。始められないなら本文、特定の条件のときだけ必要なら references/ です。本文に長い規約を丸ごと貼ると、スキルを使うたびにコンテキストを大きく消費し、肝心の作業に使える余地が減ってしまいます。

agents/openai.yaml で表示名・呼び出し方針・依存ツールを決める

agents/openai.yaml は任意のファイルで、ChatGPTデスクトップアプリでの表示、呼び出しの方針、スキルが使うツールの依存関係を設定します。公式ドキュメントに載っている設定例は次のとおりです。

interface:
  display_name: "Optional user-facing name"
  short_description: "Optional user-facing description"
  icon_small: "./assets/small-logo.svg"
  icon_large: "./assets/large-logo.png"
  brand_color: "#3B82F6"
  default_prompt: "Optional surrounding prompt to use the skill with"

policy:
  allow_implicit_invocation: false

dependencies:
  tools:
    - type: "mcp"
      value: "openaiDeveloperDocs"
      description: "OpenAI Docs MCP server"
      transport: "streamable_http"
      url: "https://developers.openai.com/mcp"

チームで使うスキルなら、少なくとも display_name と short_description を付けておくと、一覧で何のスキルか分かりやすくなります。MCPサーバーに頼るスキルは dependencies に書いておくと、スキルを使うときの準備がスムーズになります。

有効化・無効化と公式スキルの追加

消さずに無効にする [[skills.config]]

使わなくなったスキルを、削除せずに止めておくこともできます。~/.codex/config.toml に次のように書きます。

[[skills.config]]
path = "/path/to/skill/SKILL.md"
enabled = false

path には SKILL.md のパスを指定します。config.toml を変えたあとはCodexの再起動が必要です。リポジトリにチーム共通のスキルが入っていて、自分の作業では邪魔になる、といった場面で使えます。

$skill-installer で公式・外部のスキルを入れる

同梱以外の厳選スキル（curated skills）を自分の環境に追加するには、$skill-installer を使います。たとえばLinear連携のスキルを入れる場合は次のとおりです。

$skill-installer linear

インストーラーには、ほかのリポジトリからスキルを取ってくるよう頼むこともできます。追加したスキルは自動で検出されますが、出てこない場合はCodexを再起動します。公式のスキル集はopenai/skillsで公開されており、GitHubのチェックの失敗を直す gh-fix-ci やPDFを扱う pdf などの例を読めます。なお、このリポジトリは現在非推奨とされており、最新のスキルとプラグインの例はopenai/pluginsにあります。

外部から取り込んだスキルには、scripts/ に実行されるコードが含まれていることがあります。中身を読まずに入れるのではなく、何を実行するスキルなのかを確かめてから使うのが安全です。公式ドキュメントも、$skill-installer は自分の環境での利用や試行向けであり、自作スキルを配布するならプラグインを使うよう案内しています。

チームで共有・配布する3つの方法

スキルを自分以外に届ける方法は、大きく3つあります。管理者向けのSkill controlsは、これらを別々の経路として整理しています。

この3つは互いに独立しています。公式ドキュメントによれば、スキルをある経路から別の経路へ移しても、ワークスペースでの所有者・共有設定・ロール、プラグインのインストール状態、コネクタの認可は引き継がれません。プラグインを入れただけでは、同梱されたコネクタやMCPサーバーへのアクセス権は与えられない点にも注意が必要です。

リポジトリに置くのがいちばん簡単

同じリポジトリで作業するチームなら、$REPO_ROOT/.agents/skills にスキルを置いて一緒に管理するのがいちばん手軽です。変更の履歴が残り、手順の改善もコードと同じようにレビューできます。

ほかのリポジトリにも配るならプラグイン

複数のリポジトリやチームに同じスキルを配りたい場合、2つ以上のスキルをまとめたい場合、コネクタと一緒に配りたい場合は、プラグインにします（Build skills）。プラグインは、ChatGPTとCodexで共通のプラグインディレクトリから入れられる配布用のパッケージです。

Package your pluginによると、現在の作成ツール（@plugin-creator）が作るのは .codex-plugin/plugin.json を必ず含む互換レイアウトで、スキルは skills/ フォルダに入れます。持ち運べる形式としてプラグインのルートに plugin.json を置く方式もあり、既存の .codex-plugin/plugin.json も引き続き使えると説明されています。

my-plugin/
├── .codex-plugin/
│   └── plugin.json
├── .mcp.json
├── .app.json
├── skills/
├── hooks/
├── scripts/
└── assets/

使える場所にも違いがあります。単体のスキルはChatGPTデスクトップアプリ・Codex CLI・IDE拡張で使えます。プラグインに同梱したスキルは、Web・デスクトップ・モバイルのChatGPTのChatとWorkでも使えますが、Skill controlsによるとプラグインはIDE拡張では使えません。VS Codeなどの拡張だけで作業するメンバーがいるなら、リポジトリに置いたスキルのほうが確実に届きます。

カスタムプロンプトからスキルへ移行する

~/.codex/prompts にMarkdownを置いて /prompts:名前 で呼ぶカスタムプロンプトは、公式に非推奨（deprecated）になっています。Custom Promptsのページは、再利用する指示にはスキルを使うよう案内しています。

両者の違いは次のとおりです。

移行の手順は単純で、プロンプトの中身を SKILL.md の本文に移し、フロントマターの description を「いつ使うか」が分かる説明文に書き直します。カスタムプロンプトの description は一覧に表示する短い説明でしたが、スキルでは自動起動の判断材料になるため、用途と境界をはっきり書く必要があります。

注意したいのは引数です。カスタムプロンプトでは $FILES のような置き換えで値を受け取れましたが、Build skillsのページにはこれにあたる仕組みが書かれていません。スキルでは、$スキル名 のあとに続けて対象や条件を普通の文章で書き、SKILL.md 側には「依頼文から対象のファイルを読み取る」と手順として書いておくのが自然です。勝手に動いてほしくない手順（コミットや公開など）だったなら、allow_implicit_invocation: false にして、これまでどおり明示的に呼んだときだけ動くようにしておきます。

Claude Code Skillsとの違い

Claude CodeにもSkillsという同じ名前の仕組みがあり、SKILL.md を中心とした構成もよく似ています。ただし、置き場所や同名時の扱いなど、細かいところは違います。Claude Code側の詳しい使い方はClaude Code Skillsの使い方で解説しています。

Claude Code側の内容は、Anthropicの公式ドキュメント（Extend Claude with skills）で2026年10月12日に確認したものです。

両方で同じスキルを使う

CodexとClaude Codeを併用しているなら、同じ手順を2か所に書き分けるのは避けたいところです。Codexの公式ドキュメントはシンボリックリンクのスキルフォルダに対応していると明記しており、Claude Codeの公式ドキュメントも、スキルのフォルダをほかの場所へのシンボリックリンクにできると書いています。たとえば正本を .agents/skills/db-migration-check/ に置き、.claude/skills/db-migration-check をそこへのリンクにすれば、1つのファイルを両方から読めます。

このとき、フロントマターは両方に共通する name と description を中心にしておきます。disable-model-invocation のようなClaude Code固有の項目は、Codexの公式ドキュメントに記載がないため、Codexでも効く前提にはしないでください。Codexで自動起動を止めたい場合は、agents/openai.yaml の設定を別に用意します。2つのツールの役割分担そのものは、Claude CodeとCodexを併用するワークフローで詳しく扱っています。

スキルが出てこない・選ばれないときの確認

スキルを作ったのに一覧に出てこない、あるいは期待した場面で使われないときは、次の順に確認すると原因を絞り込めます。

自動起動が狙いどおりに働くかは、公式ドキュメントのベストプラクティスにあるとおり、実際に近い依頼文で試して確かめるのが確実です。「このスキルが動くべき依頼」と「動くべきでない依頼」をいくつか用意して試すと、説明文の過不足が見えてきます。

受託開発の現場でスキルをどう使い分けるか

最後に、システム開発の現場でCodex Skillsをどう位置づけるかを整理します。スキルは「Codexへの頼み方を上手にする道具」というより、チームの作業手順を、人にもAIにも読める形で残す仕組みとして考えると使いどころが見えてきます。

スキルにする価値が高い作業

スキルにして効果が出やすいのは、次のような作業です。

• 毎回同じ観点で点検する作業：マイグレーションの点検、依存パッケージの更新時の確認、リリース前の確認項目など
• 出力の形式が決まっている作業：変更内容の説明文、障害報告のひな形、議事録の整理など
• 人によってやり方がばらつく作業：テストの書き方の流儀、ログの見方、命名のルールなど

反対に、1回きりの作業や、毎回状況がまったく違う作業はスキルにしても使い回せません。公式の勧める「1つのスキルには1つの仕事」に沿って、小さく作って育てるのが現実的です。

小さく始めて、置き場所を育てる

最初の1本は $skill-creator で作り、自分の ~/.agents/skills で試すのが手軽です。何度か使って手順が固まったら、チームで使うものをリポジトリの .agents/skills に移し、ほかのリポジトリにも配りたくなった段階でプラグインにまとめる、という順に広げると無理がありません。

スキルの手順は、チームの開発ルールそのものでもあります。リポジトリに置いたスキルは、新しく参加したメンバーが作業の進め方を知る資料としても読めます。

スキルを増やしすぎない

スキルは入れれば入れるほど便利になるわけではありません。前述のとおり、最初の一覧はコンテキストウィンドウの2%（不明なら8,000文字）までで、超えると説明文が短く切り詰められ、さらに一部のスキルが一覧から外れます。似た用途のスキルが並ぶと、自動起動のときにどれを選ぶべきかもあいまいになります。

定期的に一覧を見直し、使われていないスキルは [[skills.config]] で無効にするか削除する、似たスキルは1つにまとめる、といった手入れをしておくと、必要なスキルが確実に選ばれる状態を保てます。

チームでスキルを見直すときの観点

リポジトリに置いたスキルは、コードと同じように変更を見直す対象になります。見直しのときは、次の点を確かめると品質がそろいます。

• 説明文：何をするかが冒頭にあり、使わない場面が書かれているか
• 手順：命令形で書かれ、入力と出力がはっきりしているか
• スクリプト：何を実行するかが読めば分かり、外部への送信や削除などの操作が含まれていないか
• 自動起動の可否：データの書き換えや公開を伴う手順なら、allow_implicit_invocation: false になっているか
• 名前：ほかの場所のスキルと名前がぶつかっていないか

Codexそのものの全体像はCodexとは何かを解説した記事、CLIの基本操作はCodex CLIの使い方ガイド、デスクトップアプリでのスキルの扱いはCodexアプリの使い方で解説しています。

よくある質問

まとめ

• Codex Skillsは、作業手順を SKILL.md を中心としたフォルダにまとめ、必要なときだけ読み込ませる仕組み。最初は名前・説明文・パスだけを読み、一覧はコンテキストウィンドウの2%（不明なら8,000文字）まで
• 呼び出しは $ メンションと /skills、または説明文に合ったときの自動起動。自動起動を止めるなら agents/openai.yaml の allow_implicit_invocation: false
• 置き場所は、リポジトリの .agents/skills（3階層）、~/.agents/skills、/etc/codex/skills、同梱のシステム区分の6つ。同じ名前は統合されず、両方が出る
• 作るなら $skill-creator が手軽。説明文は「何をするか」を冒頭に置き、「使わない場面」も書く
• チームの外へ配るならプラグイン。カスタムプロンプトは非推奨なので、スキルへ移しておく
• Claude Codeと併用するなら、正本を1か所に置いてシンボリックリンクで共有できる

参考にした公式情報

• https://learn.chatgpt.com/docs/build-skills
• https://learn.chatgpt.com/docs/skills-and-plugins
• https://learn.chatgpt.com/docs/enterprise/skills
• https://learn.chatgpt.com/docs/custom-prompts
• https://developers.openai.com/plugins/build/plugins
• https://agentskills.io/specification
• https://github.com/openai/skills
• https://github.com/openai/plugins
• https://code.claude.com/docs/en/skills