codex-guidelisted

# Codex Guide Codex の使い方や仕様を案内するときのガイド。 ## この skill を使う場面 - ユーザーが Codex CLI / app / IDE extension の使い方を聞いたとき - `rules`, `execpolicy`, approvals, hooks, `AGENTS.md`, skills, subagents, MCP, config を説明するとき - Codex のモデル、設定、コマンド、slash command、運用方法を案内するとき - Codex について「本当にそういう仕様か」を確認したいとき ## 基本方針 - **記憶で断定しない。** まず OpenAI の公式 Codex docs を確認する。 - **仕様説明は一次情報優先。** 非公式ブログや推測をベースにしない。 - **rules / approvals は docs だけで終わらせない。** `codex execpolicy check` で実際の判定を確認する。 - **コマンド挙動は再現確認する。** 可能なら軽い実コマンドで `allow` / `prompt` / `forbidden` を確かめる。 - **変わりやすい情報は公式 docs hub から辿る。** 直リンクが変わっていそうなら Codex docs トップから探し直す。 ## 標準ワークフロー ### 1. まず公式 docs を探す 用途ごとに `references/official-sources.md` の該当ページを開く。 - Codex 全体像: docs hub / CLI / Academy - 設定: Config basics / advanced / reference / sample - approvals / rules: Rules - カスタマイズ: Skills / Subagents / AGENTS.md / Hooks / MCP - 実践例: Academy / Use cases / `openai/codex` ### 2. rules / execpolicy の相談なら必ず検証する 変更提案前に、少なくとも以下を実行する。 ```bash codex execpolicy check --pretty --rules <rules-file> -- <command...> ``` 最低 2 パターン確認すること。 - 許可したいコマンド - 止めたい、または prompt にしたいコマンド 部分許可を設計するときは、重なる rule も確認する。 ### 3. 実運用に近いコマンドで再確認する `execpolicy check` だけでなく、可能なら軽い実コマンドでも確認する。 例: - `allow` 想定の軽いコマンドを 1 本 - `prompt` 想定の軽いコマンドを 1 本 ## 特に注意すること - `prefix_rule` は複数一致する。最終判定は **より厳しい decision が勝つ**。 - 部分 `allow` を書いても、より広い `prompt` が同時一致すると最終的に `prompt` になる。 - 迷ったら「広く `allow`、危ないサブコマンドだけ `prompt`」か、「全部明示列挙」のどちらかで設計する。 - `match` / `not_match` を書ける場面では書く。意図ミスの早期発見