{"owner":"openai","repo":"codex-plugin-cc","hasSkills":true,"totalSkillsCount":8,"totalTokensCount":4185,"categories":["marketplace","plugin-manifest","anthropic-skill"],"hasMcp":false,"mcpConfig":null,"found":[".claude-plugin/marketplace.json","plugins/codex/.claude-plugin/plugin.json","plugins/codex/skills/codex-cli-runtime/SKILL.md","plugins/codex/skills/codex-result-handling/SKILL.md","plugins/codex/skills/gpt-5-4-prompting/SKILL.md","plugins/codex/skills/gpt-5-4-prompting/references/codex-prompt-antipatterns.md","plugins/codex/skills/gpt-5-4-prompting/references/codex-prompt-recipes.md","plugins/codex/skills/gpt-5-4-prompting/references/prompt-blocks.md"],"skills":{".claude-plugin/marketplace.json":"{\n \"name\": \"openai-codex\",\n \"owner\": {\n \"name\": \"OpenAI\"\n },\n \"metadata\": {\n \"description\": \"Codex plugins to use in Claude Code for delegation and code review.\",\n \"version\": \"1.0.6\"\n },\n \"plugins\": [\n {\n \"name\": \"codex\",\n \"description\": \"Use Codex from Claude Code to review code or delegate tasks.\",\n \"version\": \"1.0.6\",\n \"author\": {\n \"name\": \"OpenAI\"\n },\n \"source\": \"./plugins/codex\"\n }\n ]\n}\n","plugins/codex/.claude-plugin/plugin.json":"{\n \"name\": \"codex\",\n \"version\": \"1.0.6\",\n \"description\": \"Use Codex from Claude Code to review code or delegate tasks.\",\n \"author\": {\n \"name\": \"OpenAI\"\n }\n}\n","plugins/codex/skills/codex-cli-runtime/SKILL.md":"---\nname: codex-cli-runtime\ndescription: Internal helper contract for calling the codex-companion runtime from Claude Code\nuser-invocable: false\n---\n\n# Codex Runtime\n\nUse this skill only inside the `codex:codex-rescue` subagent.\n\nPrimary helper:\n- `node \"${CLAUDE_PLUGIN_ROOT}/scripts/codex-companion.mjs\" task \"\"`\n\nExecution rules:\n- The rescue subagent is a forwarder, not an orchestrator. Its only job is to invoke `task` once and return that stdout unchanged.\n- Prefer the helper over hand-rolled `git`, direct Codex CLI strings, or any other Bash activity.\n- Do not call `setup`, `review`, `adversarial-review`, `status`, `result`, or `cancel` from `codex:codex-rescue`.\n- Use `task` for every rescue request, including diagnosis, planning, research, and explicit fix requests.\n- You may use the `gpt-5-4-prompting` skill to rewrite the user's request into a tighter Codex prompt before the single `task` call.\n- That prompt drafting is the only Claude-side work allowed. Do not inspect the repo, solve the task yourself, or add independent analysis outside the forwarded prompt text.\n- Leave `--effort` unset unless the user explicitly requests a specific effort.\n- Leave model unset by default. Add `--model` only when the user explicitly asks for one.\n- Map `spark` to `--model gpt-5.3-codex-spark`.\n- Default to a write-capable Codex run by adding `--write` unless the user explicitly asks for read-only behavior or only wants review, diagnosis, or research without edits.\n\nCommand selection:\n- Use exactly one `task` invocation per rescue handoff.\n- If the forwarded request includes `--background` or `--wait`, treat that as Claude-side execution control only. Strip it before calling `task`, and do not treat it as part of the natural-language task text.\n- If the forwarded request includes `--model`, normalize `spark` to `gpt-5.3-codex-spark` and pass it through to `task`.\n- If the forwarded request includes `--effort`, pass it through to `task`.\n- If the forwarded request includes `--resume`, strip that token from the task text and add `--resume-last`.\n- If the forwarded request includes `--fresh`, strip that token from the task text and do not add `--resume-last`.\n- `--resume`: always use `task --resume-last`, even if the request text is ambiguous.\n- `--fresh`: always use a fresh `task` run, even if the request sounds like a follow-up.\n- `--effort`: accepted values are `none`, `minimal`, `low`, `medium`, `high`, `xhigh`.\n- `task --resume-last`: internal helper for \"keep going\", \"resume\", \"apply the top fix\", or \"dig deeper\" after a previous rescue run.\n\nSafety rules:\n- Default to write-capable Codex work in `codex:codex-rescue` unless the user explicitly asks for read-only behavior.\n- Preserve the user's task text as-is apart from stripping routing flags.\n- Do not inspect the repository, read files, grep, monitor progress, poll status, fetch results, cancel jobs, summarize output, or do any follow-up work of your own.\n- Return the stdout of the `task` command exactly as-is.\n- If the Bash call fails or Codex cannot be invoked, return nothing.\n","plugins/codex/skills/codex-result-handling/SKILL.md":"---\nname: codex-result-handling\ndescription: Internal guidance for presenting Codex helper output back to the user\nuser-invocable: false\n---\n\n# Codex Result Handling\n\nWhen the helper returns Codex output:\n- Preserve the helper's verdict, summary, findings, and next steps structure.\n- For review output, present findings first and keep them ordered by severity.\n- Use the file paths and line numbers exactly as the helper reports them.\n- Preserve evidence boundaries. If Codex marked something as an inference, uncertainty, or follow-up question, keep that distinction.\n- Preserve output sections when the prompt asked for them, such as observed facts, inferences, open questions, touched files, or next steps.\n- If there are no findings, say that explicitly and keep the residual-risk note brief.\n- If Codex made edits, say so explicitly and list the touched files when the helper provides them.\n- For `codex:codex-rescue`, do not turn a failed or incomplete Codex run into a Claude-side implementation attempt. Report the failure and stop.\n- For `codex:codex-rescue`, if Codex was never successfully invoked, do not generate a substitute answer at all.\n- CRITICAL: After presenting review findings, STOP. Do not make any code changes. Do not fix any issues. You MUST explicitly ask the user which issues, if any, they want fixed before touching a single file. Auto-applying fixes from a review is strictly forbidden, even if the fix is obvious.\n- If the helper reports malformed output or a failed Codex run, include the most actionable stderr lines and stop there instead of guessing.\n- If the helper reports that setup or authentication is required, direct the user to `/codex:setup` and do not improvise alternate auth flows.\n","plugins/codex/skills/gpt-5-4-prompting/SKILL.md":"---\nname: gpt-5-4-prompting\ndescription: Internal guidance for composing Codex and GPT-5.4 prompts for coding, review, diagnosis, and research tasks inside the Codex Claude Code plugin\nuser-invocable: false\n---\n\n# GPT-5.4 Prompting\n\nUse this skill when `codex:codex-rescue` needs to ask Codex or another GPT-5.4-based workflow for help.\n\nPrompt Codex like an operator, not a collaborator. Keep prompts compact and block-structured with XML tags. State the task, the output contract, the follow-through defaults, and the small set of extra constraints that matter.\n\nCore rules:\n- Prefer one clear task per Codex run. Split unrelated asks into separate runs.\n- Tell Codex what done looks like. Do not assume it will infer the desired end state.\n- Add explicit grounding and verification rules for any task where unsupported guesses would hurt quality.\n- Prefer better prompt contracts over raising reasoning or adding long natural-language explanations.\n- Use XML tags consistently so the prompt has stable internal structure.\n\nDefault prompt recipe:\n- ``: the concrete job and the relevant repository or failure context.\n- `` or ``: exact shape, ordering, and brevity requirements.\n- ``: what Codex should do by default instead of asking routine questions.\n- `` or ``: required for debugging, implementation, or risky fixes.\n- `` or ``: required for review, research, or anything that could drift into unsupported claims.\n\nWhen to add blocks:\n- Coding or debugging: add `completeness_contract`, `verification_loop`, and `missing_context_gating`.\n- Review or adversarial review: add `grounding_rules`, `structured_output_contract`, and `dig_deeper_nudge`.\n- Research or recommendation tasks: add `research_mode` and `citation_rules`.\n- Write-capable tasks: add `action_safety` so Codex stays narrow and avoids unrelated refactors.\n\nHow to choose prompt shape:\n- Use built-in `review` or `adversarial-review` commands when the job is reviewing local git changes. Those prompts already carry the review contract.\n- Use `task` when the task is diagnosis, planning, research, or implementation and you need to control the prompt more directly.\n- Use `task --resume-last` for follow-up instructions on the same Codex thread. Send only the delta instruction instead of restating the whole prompt unless the direction changed materially.\n\nWorking rules:\n- Prefer explicit prompt contracts over vague nudges.\n- Use stable XML tag names that match the block names from the reference file.\n- Do not raise reasoning or complexity first. Tighten the prompt and verification rules before escalating.\n- Ask Codex for brief, outcome-based progress updates only when the task is long-running or tool-heavy.\n- Keep claims anchored to observed evidence. If something is a hypothesis, say so.\n\nPrompt assembly checklist:\n1. Define the exact task and scope in ``.\n2. Choose the smallest output contract that still makes the answer easy to use.\n3. Decide whether Codex should keep going by default or stop for missing high-risk details.\n4. Add verification, grounding, and safety tags only where the task needs them.\n5. Remove redundant instructions before sending the prompt.\n\nReusable blocks live in [references/prompt-blocks.md](references/prompt-blocks.md).\nConcrete end-to-end templates live in [references/codex-prompt-recipes.md](references/codex-prompt-recipes.md).\nCommon failure modes to avoid live in [references/codex-prompt-antipatterns.md](references/codex-prompt-antipatterns.md).\n","plugins/codex/skills/gpt-5-4-prompting/references/codex-prompt-antipatterns.md":"# Codex Prompt Anti-Patterns\n\nAvoid these when prompting Codex or GPT-5.4.\n\n## Vague task framing\n\nBad:\n\n```text\nTake a look at this and let me know what you think.\n```\n\nBetter:\n\n```xml\n\nReview this change for material correctness and regression risks.\n\n```\n\n## Missing output contract\n\nBad:\n\n```text\nInvestigate and report back.\n```\n\nBetter:\n\n```xml\n\nReturn:\n1. root cause\n2. evidence\n3. smallest safe next step\n\n```\n\n## No follow-through default\n\nBad:\n\n```text\nDebug this failure.\n```\n\nBetter:\n\n```xml\n\nKeep going until you have enough evidence to identify the root cause confidently.\n\n```\n\n## Asking for more reasoning instead of a better contract\n\nBad:\n\n```text\nThink harder and be very smart.\n```\n\nBetter:\n\n```xml\n\nBefore finalizing, verify that the answer matches the observed evidence and task requirements.\n\n```\n\n## Mixing unrelated jobs into one run\n\nBad:\n\n```text\nReview this diff, fix the bug you find, update the docs, and suggest a roadmap.\n```\n\nBetter:\n- Run review first.\n- Run a separate fix prompt if needed.\n- Use a third run for docs or roadmap work.\n\n## Unsupported certainty\n\nBad:\n\n```text\nTell me exactly why production failed.\n```\n\nBetter:\n\n```xml\n\nGround every claim in the provided context or tool outputs.\nIf a point is an inference, label it clearly.\n\n```\n","plugins/codex/skills/gpt-5-4-prompting/references/codex-prompt-recipes.md":"# Codex Prompt Recipes\n\nUse these as starting templates for Codex task prompts or other Codex/GPT-5.4 prompt construction.\nCopy the smallest recipe that fits the task, then trim anything you do not need.\nIn `codex:codex-rescue`, run diagnosis and fix-oriented recipes in write mode by default unless the user explicitly asked for read-only behavior.\n\n## Diagnosis\n\n```xml\n\nDiagnose why the failing test or command is breaking in this repository.\nUse the available repository context and tools to identify the most likely root cause.\n\n\n\nReturn a compact diagnosis with:\n1. most likely root cause\n2. evidence\n3. smallest safe next step\n\n\n\nKeep going until you have enough evidence to identify the root cause confidently.\nOnly stop to ask questions when a missing detail changes correctness materially.\n\n\n\nBefore finalizing, verify that the proposed root cause matches the observed evidence.\n\n\n\nDo not guess missing repository facts.\nIf required context is absent, state exactly what remains unknown.\n\n```\n\n## Narrow Fix\n\n```xml\n\nImplement the smallest safe fix for the identified issue in this repository.\nPreserve existing behavior outside the failing path.\n\n\n\nReturn:\n1. summary of the fix\n2. touched files\n3. verification performed\n4. residual risks or follow-ups\n\n\n\nDefault to the most reasonable low-risk interpretation and keep going.\n\n\n\nResolve the task fully before stopping.\nDo not stop after identifying the issue without applying the fix.\n\n\n\nBefore finalizing, verify that the fix matches the task requirements and that the changed code is coherent.\n\n\n\nKeep changes tightly scoped to the stated task.\nAvoid unrelated refactors or cleanup.\n\n```\n\n## Root-Cause Review\n\n```xml\n\nAnalyze this change for the most likely correctness or regression issues.\nFocus on the provided repository context only.\n\n\n\nReturn:\n1. findings ordered by severity\n2. supporting evidence for each finding\n3. brief next steps\n\n\n\nGround every claim in the repository context or tool outputs.\nIf a point is an inference, label it clearly.\n\n\n\nCheck for second-order failures, empty-state handling, retries, stale state, and rollback paths before finalizing.\n\n\n\nBefore finalizing, verify that each finding is material and actionable.\n\n```\n\n## Research Or Recommendation\n\n```xml\n\nResearch the available options and recommend the best path for this task.\n\n\n\nReturn:\n1. observed facts\n2. reasoned recommendation\n3. tradeoffs\n4. open questions\n\n\n\nSeparate observed facts, reasoned inferences, and open questions.\nPrefer breadth first, then go deeper only where the evidence changes the recommendation.\n\n\n\nBack important claims with explicit references to the sources you inspected.\nPrefer primary sources.\n\n```\n\n## Prompt-Patching\n\n```xml\n\nDiagnose why this existing prompt is underperforming and propose the smallest high-leverage changes to improve it for Codex or GPT-5.4.\n\n\n\nReturn:\n1. failure modes\n2. root causes in the current prompt\n3. a revised prompt\n4. why the revision should work better\n\n\n\nBase your diagnosis on the prompt text and the failure examples provided.\nDo not invent failure modes that are not supported by the examples.\n\n\n\nBefore finalizing, make sure the revised prompt resolves the cited failure modes without adding contradictory instructions.\n\n```\n","plugins/codex/skills/gpt-5-4-prompting/references/prompt-blocks.md":"# Prompt Blocks\n\nUse these blocks selectively when composing Codex or GPT-5.4 prompts.\nWrap each block in the XML tag shown in its heading.\n\n## Core Wrapper\n\n### `task`\n\nUse in nearly every prompt.\n\n```xml\n\nDescribe the concrete job, the relevant repository or failure context, and the expected end state.\n\n```\n\n## Output and Format\n\n### `structured_output_contract`\n\nUse when the response shape matters.\n\n```xml\n\nReturn exactly the requested output shape and nothing else.\nKeep the answer compact.\nPut the highest-value findings or decisions first.\n\n```\n\n### `compact_output_contract`\n\nUse when you want concise prose instead of a schema.\n\n```xml\n\nKeep the final answer compact and structured.\nDo not include long scene-setting or repeated recap.\n\n```\n\n## Follow-through and Completion\n\n### `default_follow_through_policy`\n\nUse when Codex should act without asking routine questions.\n\n```xml\n\nDefault to the most reasonable low-risk interpretation and keep going.\nOnly stop to ask questions when a missing detail changes correctness, safety, or an irreversible action.\n\n```\n\n### `completeness_contract`\n\nUse for debugging, implementation, or any multi-step task that should not stop early.\n\n```xml\n\nResolve the task fully before stopping.\nDo not stop at the first plausible answer.\nCheck whether there are follow-on fixes, edge cases, or cleanup needed for a correct result.\n\n```\n\n### `verification_loop`\n\nUse when correctness matters.\n\n```xml\n\nBefore finalizing, verify the result against the task requirements and the changed files or tool outputs.\nIf a check fails, revise the answer instead of reporting the first draft.\n\n```\n\n## Grounding and Missing Context\n\n### `missing_context_gating`\n\nUse when Codex might otherwise guess.\n\n```xml\n\nDo not guess missing repository facts.\nIf required context is absent, retrieve it with tools or state exactly what remains unknown.\n\n```\n\n### `grounding_rules`\n\nUse for review, research, or root-cause analysis.\n\n```xml\n\nGround every claim in the provided context or your tool outputs.\nDo not present inferences as facts.\nIf a point is a hypothesis, label it clearly.\n\n```\n\n### `citation_rules`\n\nUse when external research or quotes matter.\n\n```xml\n\nBack important claims with citations or explicit references to the source material you inspected.\nPrefer primary sources.\n\n```\n\n## Safety and Scope\n\n### `action_safety`\n\nUse for write-capable or potentially broad tasks.\n\n```xml\n\nKeep changes tightly scoped to the stated task.\nAvoid unrelated refactors, renames, or cleanup unless they are required for correctness.\nCall out any risky or irreversible action before taking it.\n\n```\n\n### `tool_persistence_rules`\n\nUse for long-running tool-heavy tasks.\n\n```xml\n\nKeep using tools until you have enough evidence to finish the task confidently.\nDo not abandon the workflow after a partial read when another targeted check would change the answer.\n\n```\n\n## Task-Specific Blocks\n\n### `research_mode`\n\nUse for exploration, comparisons, or recommendations.\n\n```xml\n\nSeparate observed facts, reasoned inferences, and open questions.\nPrefer breadth first, then go deeper only where the evidence changes the recommendation.\n\n```\n\n### `dig_deeper_nudge`\n\nUse for review and adversarial inspection.\n\n```xml\n\nAfter you find the first plausible issue, check for second-order failures, empty-state behavior, retries, stale state, and rollback paths before you finalize.\n\n```\n\n### `progress_updates`\n\nUse when the run may take a while.\n\n```xml\n\nIf you provide progress updates, keep them brief and outcome-based.\nMention only major phase changes or blockers.\n\n```\n"},"files":{".claude-plugin/marketplace.json":"{\n \"name\": \"openai-codex\",\n \"owner\": {\n \"name\": \"OpenAI\"\n },\n \"metadata\": {\n \"description\": \"Codex plugins to use in Claude Code for delegation and code review.\",\n \"version\": \"1.0.6\"\n },\n \"plugins\": [\n {\n \"name\": \"codex\",\n \"description\": \"Use Codex from Claude Code to review code or delegate tasks.\",\n \"version\": \"1.0.6\",\n \"author\": {\n \"name\": \"OpenAI\"\n },\n \"source\": \"./plugins/codex\"\n }\n ]\n}\n","plugins/codex/.claude-plugin/plugin.json":"{\n \"name\": \"codex\",\n \"version\": \"1.0.6\",\n \"description\": \"Use Codex from Claude Code to review code or delegate tasks.\",\n \"author\": {\n \"name\": \"OpenAI\"\n }\n}\n","plugins/codex/skills/codex-cli-runtime/SKILL.md":"---\nname: codex-cli-runtime\ndescription: Internal helper contract for calling the codex-companion runtime from Claude Code\nuser-invocable: false\n---\n\n# Codex Runtime\n\nUse this skill only inside the `codex:codex-rescue` subagent.\n\nPrimary helper:\n- `node \"${CLAUDE_PLUGIN_ROOT}/scripts/codex-companion.mjs\" task \"\"`\n\nExecution rules:\n- The rescue subagent is a forwarder, not an orchestrator. Its only job is to invoke `task` once and return that stdout unchanged.\n- Prefer the helper over hand-rolled `git`, direct Codex CLI strings, or any other Bash activity.\n- Do not call `setup`, `review`, `adversarial-review`, `status`, `result`, or `cancel` from `codex:codex-rescue`.\n- Use `task` for every rescue request, including diagnosis, planning, research, and explicit fix requests.\n- You may use the `gpt-5-4-prompting` skill to rewrite the user's request into a tighter Codex prompt before the single `task` call.\n- That prompt drafting is the only Claude-side work allowed. Do not inspect the repo, solve the task yourself, or add independent analysis outside the forwarded prompt text.\n- Leave `--effort` unset unless the user explicitly requests a specific effort.\n- Leave model unset by default. Add `--model` only when the user explicitly asks for one.\n- Map `spark` to `--model gpt-5.3-codex-spark`.\n- Default to a write-capable Codex run by adding `--write` unless the user explicitly asks for read-only behavior or only wants review, diagnosis, or research without edits.\n\nCommand selection:\n- Use exactly one `task` invocation per rescue handoff.\n- If the forwarded request includes `--background` or `--wait`, treat that as Claude-side execution control only. Strip it before calling `task`, and do not treat it as part of the natural-language task text.\n- If the forwarded request includes `--model`, normalize `spark` to `gpt-5.3-codex-spark` and pass it through to `task`.\n- If the forwarded request includes `--effort`, pass it through to `task`.\n- If the forwarded request includes `--resume`, strip that token from the task text and add `--resume-last`.\n- If the forwarded request includes `--fresh`, strip that token from the task text and do not add `--resume-last`.\n- `--resume`: always use `task --resume-last`, even if the request text is ambiguous.\n- `--fresh`: always use a fresh `task` run, even if the request sounds like a follow-up.\n- `--effort`: accepted values are `none`, `minimal`, `low`, `medium`, `high`, `xhigh`.\n- `task --resume-last`: internal helper for \"keep going\", \"resume\", \"apply the top fix\", or \"dig deeper\" after a previous rescue run.\n\nSafety rules:\n- Default to write-capable Codex work in `codex:codex-rescue` unless the user explicitly asks for read-only behavior.\n- Preserve the user's task text as-is apart from stripping routing flags.\n- Do not inspect the repository, read files, grep, monitor progress, poll status, fetch results, cancel jobs, summarize output, or do any follow-up work of your own.\n- Return the stdout of the `task` command exactly as-is.\n- If the Bash call fails or Codex cannot be invoked, return nothing.\n","plugins/codex/skills/codex-result-handling/SKILL.md":"---\nname: codex-result-handling\ndescription: Internal guidance for presenting Codex helper output back to the user\nuser-invocable: false\n---\n\n# Codex Result Handling\n\nWhen the helper returns Codex output:\n- Preserve the helper's verdict, summary, findings, and next steps structure.\n- For review output, present findings first and keep them ordered by severity.\n- Use the file paths and line numbers exactly as the helper reports them.\n- Preserve evidence boundaries. If Codex marked something as an inference, uncertainty, or follow-up question, keep that distinction.\n- Preserve output sections when the prompt asked for them, such as observed facts, inferences, open questions, touched files, or next steps.\n- If there are no findings, say that explicitly and keep the residual-risk note brief.\n- If Codex made edits, say so explicitly and list the touched files when the helper provides them.\n- For `codex:codex-rescue`, do not turn a failed or incomplete Codex run into a Claude-side implementation attempt. Report the failure and stop.\n- For `codex:codex-rescue`, if Codex was never successfully invoked, do not generate a substitute answer at all.\n- CRITICAL: After presenting review findings, STOP. Do not make any code changes. Do not fix any issues. You MUST explicitly ask the user which issues, if any, they want fixed before touching a single file. Auto-applying fixes from a review is strictly forbidden, even if the fix is obvious.\n- If the helper reports malformed output or a failed Codex run, include the most actionable stderr lines and stop there instead of guessing.\n- If the helper reports that setup or authentication is required, direct the user to `/codex:setup` and do not improvise alternate auth flows.\n","plugins/codex/skills/gpt-5-4-prompting/SKILL.md":"---\nname: gpt-5-4-prompting\ndescription: Internal guidance for composing Codex and GPT-5.4 prompts for coding, review, diagnosis, and research tasks inside the Codex Claude Code plugin\nuser-invocable: false\n---\n\n# GPT-5.4 Prompting\n\nUse this skill when `codex:codex-rescue` needs to ask Codex or another GPT-5.4-based workflow for help.\n\nPrompt Codex like an operator, not a collaborator. Keep prompts compact and block-structured with XML tags. State the task, the output contract, the follow-through defaults, and the small set of extra constraints that matter.\n\nCore rules:\n- Prefer one clear task per Codex run. Split unrelated asks into separate runs.\n- Tell Codex what done looks like. Do not assume it will infer the desired end state.\n- Add explicit grounding and verification rules for any task where unsupported guesses would hurt quality.\n- Prefer better prompt contracts over raising reasoning or adding long natural-language explanations.\n- Use XML tags consistently so the prompt has stable internal structure.\n\nDefault prompt recipe:\n- ``: the concrete job and the relevant repository or failure context.\n- `` or ``: exact shape, ordering, and brevity requirements.\n- ``: what Codex should do by default instead of asking routine questions.\n- `` or ``: required for debugging, implementation, or risky fixes.\n- `` or ``: required for review, research, or anything that could drift into unsupported claims.\n\nWhen to add blocks:\n- Coding or debugging: add `completeness_contract`, `verification_loop`, and `missing_context_gating`.\n- Review or adversarial review: add `grounding_rules`, `structured_output_contract`, and `dig_deeper_nudge`.\n- Research or recommendation tasks: add `research_mode` and `citation_rules`.\n- Write-capable tasks: add `action_safety` so Codex stays narrow and avoids unrelated refactors.\n\nHow to choose prompt shape:\n- Use built-in `review` or `adversarial-review` commands when the job is reviewing local git changes. Those prompts already carry the review contract.\n- Use `task` when the task is diagnosis, planning, research, or implementation and you need to control the prompt more directly.\n- Use `task --resume-last` for follow-up instructions on the same Codex thread. Send only the delta instruction instead of restating the whole prompt unless the direction changed materially.\n\nWorking rules:\n- Prefer explicit prompt contracts over vague nudges.\n- Use stable XML tag names that match the block names from the reference file.\n- Do not raise reasoning or complexity first. Tighten the prompt and verification rules before escalating.\n- Ask Codex for brief, outcome-based progress updates only when the task is long-running or tool-heavy.\n- Keep claims anchored to observed evidence. If something is a hypothesis, say so.\n\nPrompt assembly checklist:\n1. Define the exact task and scope in ``.\n2. Choose the smallest output contract that still makes the answer easy to use.\n3. Decide whether Codex should keep going by default or stop for missing high-risk details.\n4. Add verification, grounding, and safety tags only where the task needs them.\n5. Remove redundant instructions before sending the prompt.\n\nReusable blocks live in [references/prompt-blocks.md](references/prompt-blocks.md).\nConcrete end-to-end templates live in [references/codex-prompt-recipes.md](references/codex-prompt-recipes.md).\nCommon failure modes to avoid live in [references/codex-prompt-antipatterns.md](references/codex-prompt-antipatterns.md).\n","plugins/codex/skills/gpt-5-4-prompting/references/codex-prompt-antipatterns.md":"# Codex Prompt Anti-Patterns\n\nAvoid these when prompting Codex or GPT-5.4.\n\n## Vague task framing\n\nBad:\n\n```text\nTake a look at this and let me know what you think.\n```\n\nBetter:\n\n```xml\n\nReview this change for material correctness and regression risks.\n\n```\n\n## Missing output contract\n\nBad:\n\n```text\nInvestigate and report back.\n```\n\nBetter:\n\n```xml\n\nReturn:\n1. root cause\n2. evidence\n3. smallest safe next step\n\n```\n\n## No follow-through default\n\nBad:\n\n```text\nDebug this failure.\n```\n\nBetter:\n\n```xml\n\nKeep going until you have enough evidence to identify the root cause confidently.\n\n```\n\n## Asking for more reasoning instead of a better contract\n\nBad:\n\n```text\nThink harder and be very smart.\n```\n\nBetter:\n\n```xml\n\nBefore finalizing, verify that the answer matches the observed evidence and task requirements.\n\n```\n\n## Mixing unrelated jobs into one run\n\nBad:\n\n```text\nReview this diff, fix the bug you find, update the docs, and suggest a roadmap.\n```\n\nBetter:\n- Run review first.\n- Run a separate fix prompt if needed.\n- Use a third run for docs or roadmap work.\n\n## Unsupported certainty\n\nBad:\n\n```text\nTell me exactly why production failed.\n```\n\nBetter:\n\n```xml\n\nGround every claim in the provided context or tool outputs.\nIf a point is an inference, label it clearly.\n\n```\n","plugins/codex/skills/gpt-5-4-prompting/references/codex-prompt-recipes.md":"# Codex Prompt Recipes\n\nUse these as starting templates for Codex task prompts or other Codex/GPT-5.4 prompt construction.\nCopy the smallest recipe that fits the task, then trim anything you do not need.\nIn `codex:codex-rescue`, run diagnosis and fix-oriented recipes in write mode by default unless the user explicitly asked for read-only behavior.\n\n## Diagnosis\n\n```xml\n\nDiagnose why the failing test or command is breaking in this repository.\nUse the available repository context and tools to identify the most likely root cause.\n\n\n\nReturn a compact diagnosis with:\n1. most likely root cause\n2. evidence\n3. smallest safe next step\n\n\n\nKeep going until you have enough evidence to identify the root cause confidently.\nOnly stop to ask questions when a missing detail changes correctness materially.\n\n\n\nBefore finalizing, verify that the proposed root cause matches the observed evidence.\n\n\n\nDo not guess missing repository facts.\nIf required context is absent, state exactly what remains unknown.\n\n```\n\n## Narrow Fix\n\n```xml\n\nImplement the smallest safe fix for the identified issue in this repository.\nPreserve existing behavior outside the failing path.\n\n\n\nReturn:\n1. summary of the fix\n2. touched files\n3. verification performed\n4. residual risks or follow-ups\n\n\n\nDefault to the most reasonable low-risk interpretation and keep going.\n\n\n\nResolve the task fully before stopping.\nDo not stop after identifying the issue without applying the fix.\n\n\n\nBefore finalizing, verify that the fix matches the task requirements and that the changed code is coherent.\n\n\n\nKeep changes tightly scoped to the stated task.\nAvoid unrelated refactors or cleanup.\n\n```\n\n## Root-Cause Review\n\n```xml\n\nAnalyze this change for the most likely correctness or regression issues.\nFocus on the provided repository context only.\n\n\n\nReturn:\n1. findings ordered by severity\n2. supporting evidence for each finding\n3. brief next steps\n\n\n\nGround every claim in the repository context or tool outputs.\nIf a point is an inference, label it clearly.\n\n\n\nCheck for second-order failures, empty-state handling, retries, stale state, and rollback paths before finalizing.\n\n\n\nBefore finalizing, verify that each finding is material and actionable.\n\n```\n\n## Research Or Recommendation\n\n```xml\n\nResearch the available options and recommend the best path for this task.\n\n\n\nReturn:\n1. observed facts\n2. reasoned recommendation\n3. tradeoffs\n4. open questions\n\n\n\nSeparate observed facts, reasoned inferences, and open questions.\nPrefer breadth first, then go deeper only where the evidence changes the recommendation.\n\n\n\nBack important claims with explicit references to the sources you inspected.\nPrefer primary sources.\n\n```\n\n## Prompt-Patching\n\n```xml\n\nDiagnose why this existing prompt is underperforming and propose the smallest high-leverage changes to improve it for Codex or GPT-5.4.\n\n\n\nReturn:\n1. failure modes\n2. root causes in the current prompt\n3. a revised prompt\n4. why the revision should work better\n\n\n\nBase your diagnosis on the prompt text and the failure examples provided.\nDo not invent failure modes that are not supported by the examples.\n\n\n\nBefore finalizing, make sure the revised prompt resolves the cited failure modes without adding contradictory instructions.\n\n```\n","plugins/codex/skills/gpt-5-4-prompting/references/prompt-blocks.md":"# Prompt Blocks\n\nUse these blocks selectively when composing Codex or GPT-5.4 prompts.\nWrap each block in the XML tag shown in its heading.\n\n## Core Wrapper\n\n### `task`\n\nUse in nearly every prompt.\n\n```xml\n\nDescribe the concrete job, the relevant repository or failure context, and the expected end state.\n\n```\n\n## Output and Format\n\n### `structured_output_contract`\n\nUse when the response shape matters.\n\n```xml\n\nReturn exactly the requested output shape and nothing else.\nKeep the answer compact.\nPut the highest-value findings or decisions first.\n\n```\n\n### `compact_output_contract`\n\nUse when you want concise prose instead of a schema.\n\n```xml\n\nKeep the final answer compact and structured.\nDo not include long scene-setting or repeated recap.\n\n```\n\n## Follow-through and Completion\n\n### `default_follow_through_policy`\n\nUse when Codex should act without asking routine questions.\n\n```xml\n\nDefault to the most reasonable low-risk interpretation and keep going.\nOnly stop to ask questions when a missing detail changes correctness, safety, or an irreversible action.\n\n```\n\n### `completeness_contract`\n\nUse for debugging, implementation, or any multi-step task that should not stop early.\n\n```xml\n\nResolve the task fully before stopping.\nDo not stop at the first plausible answer.\nCheck whether there are follow-on fixes, edge cases, or cleanup needed for a correct result.\n\n```\n\n### `verification_loop`\n\nUse when correctness matters.\n\n```xml\n\nBefore finalizing, verify the result against the task requirements and the changed files or tool outputs.\nIf a check fails, revise the answer instead of reporting the first draft.\n\n```\n\n## Grounding and Missing Context\n\n### `missing_context_gating`\n\nUse when Codex might otherwise guess.\n\n```xml\n\nDo not guess missing repository facts.\nIf required context is absent, retrieve it with tools or state exactly what remains unknown.\n\n```\n\n### `grounding_rules`\n\nUse for review, research, or root-cause analysis.\n\n```xml\n\nGround every claim in the provided context or your tool outputs.\nDo not present inferences as facts.\nIf a point is a hypothesis, label it clearly.\n\n```\n\n### `citation_rules`\n\nUse when external research or quotes matter.\n\n```xml\n\nBack important claims with citations or explicit references to the source material you inspected.\nPrefer primary sources.\n\n```\n\n## Safety and Scope\n\n### `action_safety`\n\nUse for write-capable or potentially broad tasks.\n\n```xml\n\nKeep changes tightly scoped to the stated task.\nAvoid unrelated refactors, renames, or cleanup unless they are required for correctness.\nCall out any risky or irreversible action before taking it.\n\n```\n\n### `tool_persistence_rules`\n\nUse for long-running tool-heavy tasks.\n\n```xml\n\nKeep using tools until you have enough evidence to finish the task confidently.\nDo not abandon the workflow after a partial read when another targeted check would change the answer.\n\n```\n\n## Task-Specific Blocks\n\n### `research_mode`\n\nUse for exploration, comparisons, or recommendations.\n\n```xml\n\nSeparate observed facts, reasoned inferences, and open questions.\nPrefer breadth first, then go deeper only where the evidence changes the recommendation.\n\n```\n\n### `dig_deeper_nudge`\n\nUse for review and adversarial inspection.\n\n```xml\n\nAfter you find the first plausible issue, check for second-order failures, empty-state behavior, retries, stale state, and rollback paths before you finalize.\n\n```\n\n### `progress_updates`\n\nUse when the run may take a while.\n\n```xml\n\nIf you provide progress updates, keep them brief and outcome-based.\nMention only major phase changes or blockers.\n\n```\n"},"items":[{"name":"SKILL.md","path":"plugins/codex/skills/codex-cli-runtime/SKILL.md","rawUrl":"https://raw.githubusercontent.com/openai/codex-plugin-cc/HEAD/plugins/codex/skills/codex-cli-runtime/SKILL.md","title":"codex-cli-runtime","category":"anthropic-skill","format":"markdown","content":"---\nname: codex-cli-runtime\ndescription: Internal helper contract for calling the codex-companion runtime from Claude Code\nuser-invocable: false\n---\n\n# Codex Runtime\n\nUse this skill only inside the `codex:codex-rescue` subagent.\n\nPrimary helper:\n- `node \"${CLAUDE_PLUGIN_ROOT}/scripts/codex-companion.mjs\" task \"\"`\n\nExecution rules:\n- The rescue subagent is a forwarder, not an orchestrator. Its only job is to invoke `task` once and return that stdout unchanged.\n- Prefer the helper over hand-rolled `git`, direct Codex CLI strings, or any other Bash activity.\n- Do not call `setup`, `review`, `adversarial-review`, `status`, `result`, or `cancel` from `codex:codex-rescue`.\n- Use `task` for every rescue request, including diagnosis, planning, research, and explicit fix requests.\n- You may use the `gpt-5-4-prompting` skill to rewrite the user's request into a tighter Codex prompt before the single `task` call.\n- That prompt drafting is the only Claude-side work allowed. Do not inspect the repo, solve the task yourself, or add independent analysis outside the forwarded prompt text.\n- Leave `--effort` unset unless the user explicitly requests a specific effort.\n- Leave model unset by default. Add `--model` only when the user explicitly asks for one.\n- Map `spark` to `--model gpt-5.3-codex-spark`.\n- Default to a write-capable Codex run by adding `--write` unless the user explicitly asks for read-only behavior or only wants review, diagnosis, or research without edits.\n\nCommand selection:\n- Use exactly one `task` invocation per rescue handoff.\n- If the forwarded request includes `--background` or `--wait`, treat that as Claude-side execution control only. Strip it before calling `task`, and do not treat it as part of the natural-language task text.\n- If the forwarded request includes `--model`, normalize `spark` to `gpt-5.3-codex-spark` and pass it through to `task`.\n- If the forwarded request includes `--effort`, pass it through to `task`.\n- If the forwarded request includes `--resume`, strip that token from the task text and add `--resume-last`.\n- If the forwarded request includes `--fresh`, strip that token from the task text and do not add `--resume-last`.\n- `--resume`: always use `task --resume-last`, even if the request text is ambiguous.\n- `--fresh`: always use a fresh `task` run, even if the request sounds like a follow-up.\n- `--effort`: accepted values are `none`, `minimal`, `low`, `medium`, `high`, `xhigh`.\n- `task --resume-last`: internal helper for \"keep going\", \"resume\", \"apply the top fix\", or \"dig deeper\" after a previous rescue run.\n\nSafety rules:\n- Default to write-capable Codex work in `codex:codex-rescue` unless the user explicitly asks for read-only behavior.\n- Preserve the user's task text as-is apart from stripping routing flags.\n- Do not inspect the repository, read files, grep, monitor progress, poll status, fetch results, cancel jobs, summarize output, or do any follow-up work of your own.\n- Return the stdout of the `task` command exactly as-is.\n- If the Bash call fails or Codex cannot be invoked, return nothing.\n","frontmatter":{"name":"codex-cli-runtime","description":"Internal helper contract for calling the codex-companion runtime from Claude Code","user-invocable":false},"isInternal":false,"tokens":751,"sizeBytes":3097},{"name":"SKILL.md","path":"plugins/codex/skills/codex-result-handling/SKILL.md","rawUrl":"https://raw.githubusercontent.com/openai/codex-plugin-cc/HEAD/plugins/codex/skills/codex-result-handling/SKILL.md","title":"codex-result-handling","category":"anthropic-skill","format":"markdown","content":"---\nname: codex-result-handling\ndescription: Internal guidance for presenting Codex helper output back to the user\nuser-invocable: false\n---\n\n# Codex Result Handling\n\nWhen the helper returns Codex output:\n- Preserve the helper's verdict, summary, findings, and next steps structure.\n- For review output, present findings first and keep them ordered by severity.\n- Use the file paths and line numbers exactly as the helper reports them.\n- Preserve evidence boundaries. If Codex marked something as an inference, uncertainty, or follow-up question, keep that distinction.\n- Preserve output sections when the prompt asked for them, such as observed facts, inferences, open questions, touched files, or next steps.\n- If there are no findings, say that explicitly and keep the residual-risk note brief.\n- If Codex made edits, say so explicitly and list the touched files when the helper provides them.\n- For `codex:codex-rescue`, do not turn a failed or incomplete Codex run into a Claude-side implementation attempt. Report the failure and stop.\n- For `codex:codex-rescue`, if Codex was never successfully invoked, do not generate a substitute answer at all.\n- CRITICAL: After presenting review findings, STOP. Do not make any code changes. Do not fix any issues. You MUST explicitly ask the user which issues, if any, they want fixed before touching a single file. Auto-applying fixes from a review is strictly forbidden, even if the fix is obvious.\n- If the helper reports malformed output or a failed Codex run, include the most actionable stderr lines and stop there instead of guessing.\n- If the helper reports that setup or authentication is required, direct the user to `/codex:setup` and do not improvise alternate auth flows.\n","frontmatter":{"name":"codex-result-handling","description":"Internal guidance for presenting Codex helper output back to the user","user-invocable":false},"isInternal":false,"tokens":368,"sizeBytes":1731},{"name":"codex-prompt-antipatterns.md","path":"plugins/codex/skills/gpt-5-4-prompting/references/codex-prompt-antipatterns.md","rawUrl":"https://raw.githubusercontent.com/openai/codex-plugin-cc/HEAD/plugins/codex/skills/gpt-5-4-prompting/references/codex-prompt-antipatterns.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# Codex Prompt Anti-Patterns\n\nAvoid these when prompting Codex or GPT-5.4.\n\n## Vague task framing\n\nBad:\n\n```text\nTake a look at this and let me know what you think.\n```\n\nBetter:\n\n```xml\n\nReview this change for material correctness and regression risks.\n\n```\n\n## Missing output contract\n\nBad:\n\n```text\nInvestigate and report back.\n```\n\nBetter:\n\n```xml\n\nReturn:\n1. root cause\n2. evidence\n3. smallest safe next step\n\n```\n\n## No follow-through default\n\nBad:\n\n```text\nDebug this failure.\n```\n\nBetter:\n\n```xml\n\nKeep going until you have enough evidence to identify the root cause confidently.\n\n```\n\n## Asking for more reasoning instead of a better contract\n\nBad:\n\n```text\nThink harder and be very smart.\n```\n\nBetter:\n\n```xml\n\nBefore finalizing, verify that the answer matches the observed evidence and task requirements.\n\n```\n\n## Mixing unrelated jobs into one run\n\nBad:\n\n```text\nReview this diff, fix the bug you find, update the docs, and suggest a roadmap.\n```\n\nBetter:\n- Run review first.\n- Run a separate fix prompt if needed.\n- Use a third run for docs or roadmap work.\n\n## Unsupported certainty\n\nBad:\n\n```text\nTell me exactly why production failed.\n```\n\nBetter:\n\n```xml\n\nGround every claim in the provided context or tool outputs.\nIf a point is an inference, label it clearly.\n\n```\n","isInternal":false,"tokens":349,"sizeBytes":1490},{"name":"codex-prompt-recipes.md","path":"plugins/codex/skills/gpt-5-4-prompting/references/codex-prompt-recipes.md","rawUrl":"https://raw.githubusercontent.com/openai/codex-plugin-cc/HEAD/plugins/codex/skills/gpt-5-4-prompting/references/codex-prompt-recipes.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# Codex Prompt Recipes\n\nUse these as starting templates for Codex task prompts or other Codex/GPT-5.4 prompt construction.\nCopy the smallest recipe that fits the task, then trim anything you do not need.\nIn `codex:codex-rescue`, run diagnosis and fix-oriented recipes in write mode by default unless the user explicitly asked for read-only behavior.\n\n## Diagnosis\n\n```xml\n\nDiagnose why the failing test or command is breaking in this repository.\nUse the available repository context and tools to identify the most likely root cause.\n\n\n\nReturn a compact diagnosis with:\n1. most likely root cause\n2. evidence\n3. smallest safe next step\n\n\n\nKeep going until you have enough evidence to identify the root cause confidently.\nOnly stop to ask questions when a missing detail changes correctness materially.\n\n\n\nBefore finalizing, verify that the proposed root cause matches the observed evidence.\n\n\n\nDo not guess missing repository facts.\nIf required context is absent, state exactly what remains unknown.\n\n```\n\n## Narrow Fix\n\n```xml\n\nImplement the smallest safe fix for the identified issue in this repository.\nPreserve existing behavior outside the failing path.\n\n\n\nReturn:\n1. summary of the fix\n2. touched files\n3. verification performed\n4. residual risks or follow-ups\n\n\n\nDefault to the most reasonable low-risk interpretation and keep going.\n\n\n\nResolve the task fully before stopping.\nDo not stop after identifying the issue without applying the fix.\n\n\n\nBefore finalizing, verify that the fix matches the task requirements and that the changed code is coherent.\n\n\n\nKeep changes tightly scoped to the stated task.\nAvoid unrelated refactors or cleanup.\n\n```\n\n## Root-Cause Review\n\n```xml\n\nAnalyze this change for the most likely correctness or regression issues.\nFocus on the provided repository context only.\n\n\n\nReturn:\n1. findings ordered by severity\n2. supporting evidence for each finding\n3. brief next steps\n\n\n\nGround every claim in the repository context or tool outputs.\nIf a point is an inference, label it clearly.\n\n\n\nCheck for second-order failures, empty-state handling, retries, stale state, and rollback paths before finalizing.\n\n\n\nBefore finalizing, verify that each finding is material and actionable.\n\n```\n\n## Research Or Recommendation\n\n```xml\n\nResearch the available options and recommend the best path for this task.\n\n\n\nReturn:\n1. observed facts\n2. reasoned recommendation\n3. tradeoffs\n4. open questions\n\n\n\nSeparate observed facts, reasoned inferences, and open questions.\nPrefer breadth first, then go deeper only where the evidence changes the recommendation.\n\n\n\nBack important claims with explicit references to the sources you inspected.\nPrefer primary sources.\n\n```\n\n## Prompt-Patching\n\n```xml\n\nDiagnose why this existing prompt is underperforming and propose the smallest high-leverage changes to improve it for Codex or GPT-5.4.\n\n\n\nReturn:\n1. failure modes\n2. root causes in the current prompt\n3. a revised prompt\n4. why the revision should work better\n\n\n\nBase your diagnosis on the prompt text and the failure examples provided.\nDo not invent failure modes that are not supported by the examples.\n\n\n\nBefore finalizing, make sure the revised prompt resolves the cited failure modes without adding contradictory instructions.\n\n```\n","isInternal":false,"tokens":867,"sizeBytes":4175},{"name":"prompt-blocks.md","path":"plugins/codex/skills/gpt-5-4-prompting/references/prompt-blocks.md","rawUrl":"https://raw.githubusercontent.com/openai/codex-plugin-cc/HEAD/plugins/codex/skills/gpt-5-4-prompting/references/prompt-blocks.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# Prompt Blocks\n\nUse these blocks selectively when composing Codex or GPT-5.4 prompts.\nWrap each block in the XML tag shown in its heading.\n\n## Core Wrapper\n\n### `task`\n\nUse in nearly every prompt.\n\n```xml\n\nDescribe the concrete job, the relevant repository or failure context, and the expected end state.\n\n```\n\n## Output and Format\n\n### `structured_output_contract`\n\nUse when the response shape matters.\n\n```xml\n\nReturn exactly the requested output shape and nothing else.\nKeep the answer compact.\nPut the highest-value findings or decisions first.\n\n```\n\n### `compact_output_contract`\n\nUse when you want concise prose instead of a schema.\n\n```xml\n\nKeep the final answer compact and structured.\nDo not include long scene-setting or repeated recap.\n\n```\n\n## Follow-through and Completion\n\n### `default_follow_through_policy`\n\nUse when Codex should act without asking routine questions.\n\n```xml\n\nDefault to the most reasonable low-risk interpretation and keep going.\nOnly stop to ask questions when a missing detail changes correctness, safety, or an irreversible action.\n\n```\n\n### `completeness_contract`\n\nUse for debugging, implementation, or any multi-step task that should not stop early.\n\n```xml\n\nResolve the task fully before stopping.\nDo not stop at the first plausible answer.\nCheck whether there are follow-on fixes, edge cases, or cleanup needed for a correct result.\n\n```\n\n### `verification_loop`\n\nUse when correctness matters.\n\n```xml\n\nBefore finalizing, verify the result against the task requirements and the changed files or tool outputs.\nIf a check fails, revise the answer instead of reporting the first draft.\n\n```\n\n## Grounding and Missing Context\n\n### `missing_context_gating`\n\nUse when Codex might otherwise guess.\n\n```xml\n\nDo not guess missing repository facts.\nIf required context is absent, retrieve it with tools or state exactly what remains unknown.\n\n```\n\n### `grounding_rules`\n\nUse for review, research, or root-cause analysis.\n\n```xml\n\nGround every claim in the provided context or your tool outputs.\nDo not present inferences as facts.\nIf a point is a hypothesis, label it clearly.\n\n```\n\n### `citation_rules`\n\nUse when external research or quotes matter.\n\n```xml\n\nBack important claims with citations or explicit references to the source material you inspected.\nPrefer primary sources.\n\n```\n\n## Safety and Scope\n\n### `action_safety`\n\nUse for write-capable or potentially broad tasks.\n\n```xml\n\nKeep changes tightly scoped to the stated task.\nAvoid unrelated refactors, renames, or cleanup unless they are required for correctness.\nCall out any risky or irreversible action before taking it.\n\n```\n\n### `tool_persistence_rules`\n\nUse for long-running tool-heavy tasks.\n\n```xml\n\nKeep using tools until you have enough evidence to finish the task confidently.\nDo not abandon the workflow after a partial read when another targeted check would change the answer.\n\n```\n\n## Task-Specific Blocks\n\n### `research_mode`\n\nUse for exploration, comparisons, or recommendations.\n\n```xml\n\nSeparate observed facts, reasoned inferences, and open questions.\nPrefer breadth first, then go deeper only where the evidence changes the recommendation.\n\n```\n\n### `dig_deeper_nudge`\n\nUse for review and adversarial inspection.\n\n```xml\n\nAfter you find the first plausible issue, check for second-order failures, empty-state behavior, retries, stale state, and rollback paths before you finalize.\n\n```\n\n### `progress_updates`\n\nUse when the run may take a while.\n\n```xml\n\nIf you provide progress updates, keep them brief and outcome-based.\nMention only major phase changes or blockers.\n\n```\n","isInternal":false,"tokens":874,"sizeBytes":4160},{"name":"SKILL.md","path":"plugins/codex/skills/gpt-5-4-prompting/SKILL.md","rawUrl":"https://raw.githubusercontent.com/openai/codex-plugin-cc/HEAD/plugins/codex/skills/gpt-5-4-prompting/SKILL.md","title":"gpt-5-4-prompting","category":"anthropic-skill","format":"markdown","content":"---\nname: gpt-5-4-prompting\ndescription: Internal guidance for composing Codex and GPT-5.4 prompts for coding, review, diagnosis, and research tasks inside the Codex Claude Code plugin\nuser-invocable: false\n---\n\n# GPT-5.4 Prompting\n\nUse this skill when `codex:codex-rescue` needs to ask Codex or another GPT-5.4-based workflow for help.\n\nPrompt Codex like an operator, not a collaborator. Keep prompts compact and block-structured with XML tags. State the task, the output contract, the follow-through defaults, and the small set of extra constraints that matter.\n\nCore rules:\n- Prefer one clear task per Codex run. Split unrelated asks into separate runs.\n- Tell Codex what done looks like. Do not assume it will infer the desired end state.\n- Add explicit grounding and verification rules for any task where unsupported guesses would hurt quality.\n- Prefer better prompt contracts over raising reasoning or adding long natural-language explanations.\n- Use XML tags consistently so the prompt has stable internal structure.\n\nDefault prompt recipe:\n- ``: the concrete job and the relevant repository or failure context.\n- `` or ``: exact shape, ordering, and brevity requirements.\n- ``: what Codex should do by default instead of asking routine questions.\n- `` or ``: required for debugging, implementation, or risky fixes.\n- `` or ``: required for review, research, or anything that could drift into unsupported claims.\n\nWhen to add blocks:\n- Coding or debugging: add `completeness_contract`, `verification_loop`, and `missing_context_gating`.\n- Review or adversarial review: add `grounding_rules`, `structured_output_contract`, and `dig_deeper_nudge`.\n- Research or recommendation tasks: add `research_mode` and `citation_rules`.\n- Write-capable tasks: add `action_safety` so Codex stays narrow and avoids unrelated refactors.\n\nHow to choose prompt shape:\n- Use built-in `review` or `adversarial-review` commands when the job is reviewing local git changes. Those prompts already carry the review contract.\n- Use `task` when the task is diagnosis, planning, research, or implementation and you need to control the prompt more directly.\n- Use `task --resume-last` for follow-up instructions on the same Codex thread. Send only the delta instruction instead of restating the whole prompt unless the direction changed materially.\n\nWorking rules:\n- Prefer explicit prompt contracts over vague nudges.\n- Use stable XML tag names that match the block names from the reference file.\n- Do not raise reasoning or complexity first. Tighten the prompt and verification rules before escalating.\n- Ask Codex for brief, outcome-based progress updates only when the task is long-running or tool-heavy.\n- Keep claims anchored to observed evidence. If something is a hypothesis, say so.\n\nPrompt assembly checklist:\n1. Define the exact task and scope in ``.\n2. Choose the smallest output contract that still makes the answer easy to use.\n3. Decide whether Codex should keep going by default or stop for missing high-risk details.\n4. Add verification, grounding, and safety tags only where the task needs them.\n5. Remove redundant instructions before sending the prompt.\n\nReusable blocks live in [references/prompt-blocks.md](references/prompt-blocks.md).\nConcrete end-to-end templates live in [references/codex-prompt-recipes.md](references/codex-prompt-recipes.md).\nCommon failure modes to avoid live in [references/codex-prompt-antipatterns.md](references/codex-prompt-antipatterns.md).\n","frontmatter":{"name":"gpt-5-4-prompting","description":"Internal guidance for composing Codex and GPT-5.4 prompts for coding, review, diagnosis, and research tasks inside the Codex Claude Code plugin","user-invocable":false},"isInternal":false,"tokens":784,"sizeBytes":3644},{"name":"marketplace.json","path":".claude-plugin/marketplace.json","rawUrl":"https://raw.githubusercontent.com/openai/codex-plugin-cc/HEAD/.claude-plugin/marketplace.json","title":"openai-codex","category":"marketplace","format":"json","content":"{\n \"name\": \"openai-codex\",\n \"owner\": {\n \"name\": \"OpenAI\"\n },\n \"metadata\": {\n \"description\": \"Codex plugins to use in Claude Code for delegation and code review.\",\n \"version\": \"1.0.6\"\n },\n \"plugins\": [\n {\n \"name\": \"codex\",\n \"description\": \"Use Codex from Claude Code to review code or delegate tasks.\",\n \"version\": \"1.0.6\",\n \"author\": {\n \"name\": \"OpenAI\"\n },\n \"source\": \"./plugins/codex\"\n }\n ]\n}\n","frontmatter":{"name":"openai-codex","owner":{"name":"OpenAI"},"metadata":{"description":"Codex plugins to use in Claude Code for delegation and code review.","version":"1.0.6"},"plugins":[{"name":"codex","description":"Use Codex from Claude Code to review code or delegate tasks.","version":"1.0.6","author":{"name":"OpenAI"},"source":"./plugins/codex"}]},"isInternal":false,"tokens":138,"sizeBytes":454},{"name":"plugin.json","path":"plugins/codex/.claude-plugin/plugin.json","rawUrl":"https://raw.githubusercontent.com/openai/codex-plugin-cc/HEAD/plugins/codex/.claude-plugin/plugin.json","title":"codex","category":"plugin-manifest","format":"json","content":"{\n \"name\": \"codex\",\n \"version\": \"1.0.6\",\n \"description\": \"Use Codex from Claude Code to review code or delegate tasks.\",\n \"author\": {\n \"name\": \"OpenAI\"\n }\n}\n","frontmatter":{"name":"codex","version":"1.0.6","description":"Use Codex from Claude Code to review code or delegate tasks.","author":{"name":"OpenAI"}},"isInternal":false,"tokens":54,"sizeBytes":165}],"systemPromptSnippet":"\n\n---\nname: codex-cli-runtime\ndescription: Internal helper contract for calling the codex-companion runtime from Claude Code\nuser-invocable: false\n---\n\n# Codex Runtime\n\nUse this skill only inside the `codex:codex-rescue` subagent.\n\nPrimary helper:\n- `node \"${CLAUDE_PLUGIN_ROOT}/scripts/codex-companion.mjs\" task \"\"`\n\nExecution rules:\n- The rescue subagent is a forwarder, not an orchestrator. Its only job is to invoke `task` once and return that stdout unchanged.\n- Prefer the helper over hand-rolled `git`, direct Codex CLI strings, or any other Bash activity.\n- Do not call `setup`, `review`, `adversarial-review`, `status`, `result`, or `cancel` from `codex:codex-rescue`.\n- Use `task` for every rescue request, including diagnosis, planning, research, and explicit fix requests.\n- You may use the `gpt-5-4-prompting` skill to rewrite the user's request into a tighter Codex prompt before the single `task` call.\n- That prompt drafting is the only Claude-side work allowed. Do not inspect the repo, solve the task yourself, or add independent analysis outside the forwarded prompt text.\n- Leave `--effort` unset unless the user explicitly requests a specific effort.\n- Leave model unset by default. Add `--model` only when the user explicitly asks for one.\n- Map `spark` to `--model gpt-5.3-codex-spark`.\n- Default to a write-capable Codex run by adding `--write` unless the user explicitly asks for read-only behavior or only wants review, diagnosis, or research without edits.\n\nCommand selection:\n- Use exactly one `task` invocation per rescue handoff.\n- If the forwarded request includes `--background` or `--wait`, treat that as Claude-side execution control only. Strip it before calling `task`, and do not treat it as part of the natural-language task text.\n- If the forwarded request includes `--model`, normalize `spark` to `gpt-5.3-codex-spark` and pass it through to `task`.\n- If the forwarded request includes `--effort`, pass it through to `task`.\n- If the forwarded request includes `--resume`, strip that token from the task text and add `--resume-last`.\n- If the forwarded request includes `--fresh`, strip that token from the task text and do not add `--resume-last`.\n- `--resume`: always use `task --resume-last`, even if the request text is ambiguous.\n- `--fresh`: always use a fresh `task` run, even if the request sounds like a follow-up.\n- `--effort`: accepted values are `none`, `minimal`, `low`, `medium`, `high`, `xhigh`.\n- `task --resume-last`: internal helper for \"keep going\", \"resume\", \"apply the top fix\", or \"dig deeper\" after a previous rescue run.\n\nSafety rules:\n- Default to write-capable Codex work in `codex:codex-rescue` unless the user explicitly asks for read-only behavior.\n- Preserve the user's task text as-is apart from stripping routing flags.\n- Do not inspect the repository, read files, grep, monitor progress, poll status, fetch results, cancel jobs, summarize output, or do any follow-up work of your own.\n- Return the stdout of the `task` command exactly as-is.\n- If the Bash call fails or Codex cannot be invoked, return nothing.\n\n\n---\nname: codex-result-handling\ndescription: Internal guidance for presenting Codex helper output back to the user\nuser-invocable: false\n---\n\n# Codex Result Handling\n\nWhen the helper returns Codex output:\n- Preserve the helper's verdict, summary, findings, and next steps structure.\n- For review output, present findings first and keep them ordered by severity.\n- Use the file paths and line numbers exactly as the helper reports them.\n- Preserve evidence boundaries. If Codex marked something as an inference, uncertainty, or follow-up question, keep that distinction.\n- Preserve output sections when the prompt asked for them, such as observed facts, inferences, open questions, touched files, or next steps.\n- If there are no findings, say that explicitly and keep the residual-risk note brief.\n- If Codex made edits, say so explicitly and list the touched files when the helper provides them.\n- For `codex:codex-rescue`, do not turn a failed or incomplete Codex run into a Claude-side implementation attempt. Report the failure and stop.\n- For `codex:codex-rescue`, if Codex was never successfully invoked, do not generate a substitute answer at all.\n- CRITICAL: After presenting review findings, STOP. Do not make any code changes. Do not fix any issues. You MUST explicitly ask the user which issues, if any, they want fixed before touching a single file. Auto-applying fixes from a review is strictly forbidden, even if the fix is obvious.\n- If the helper reports malformed output or a failed Codex run, include the most actionable stderr lines and stop there instead of guessing.\n- If the helper reports that setup or authentication is required, direct the user to `/codex:setup` and do not improvise alternate auth flows.\n\n\n# Codex Prompt Anti-Patterns\n\nAvoid these when prompting Codex or GPT-5.4.\n\n## Vague task framing\n\nBad:\n\n```text\nTake a look at this and let me know what you think.\n```\n\nBetter:\n\n```xml\n\nReview this change for material correctness and regression risks.\n\n```\n\n## Missing output contract\n\nBad:\n\n```text\nInvestigate and report back.\n```\n\nBetter:\n\n```xml\n\nReturn:\n1. root cause\n2. evidence\n3. smallest safe next step\n\n```\n\n## No follow-through default\n\nBad:\n\n```text\nDebug this failure.\n```\n\nBetter:\n\n```xml\n\nKeep going until you have enough evidence to identify the root cause confidently.\n\n```\n\n## Asking for more reasoning instead of a better contract\n\nBad:\n\n```text\nThink harder and be very smart.\n```\n\nBetter:\n\n```xml\n\nBefore finalizing, verify that the answer matches the observed evidence and task requirements.\n\n```\n\n## Mixing unrelated jobs into one run\n\nBad:\n\n```text\nReview this diff, fix the bug you find, update the docs, and suggest a roadmap.\n```\n\nBetter:\n- Run review first.\n- Run a separate fix prompt if needed.\n- Use a third run for docs or roadmap work.\n\n## Unsupported certainty\n\nBad:\n\n```text\nTell me exactly why production failed.\n```\n\nBetter:\n\n```xml\n\nGround every claim in the provided context or tool outputs.\nIf a point is an inference, label it clearly.\n\n```\n\n\n# Codex Prompt Recipes\n\nUse these as starting templates for Codex task prompts or other Codex/GPT-5.4 prompt construction.\nCopy the smallest recipe that fits the task, then trim anything you do not need.\nIn `codex:codex-rescue`, run diagnosis and fix-oriented recipes in write mode by default unless the user explicitly asked for read-only behavior.\n\n## Diagnosis\n\n```xml\n\nDiagnose why the failing test or command is breaking in this repository.\nUse the available repository context and tools to identify the most likely root cause.\n\n\n\nReturn a compact diagnosis with:\n1. most likely root cause\n2. evidence\n3. smallest safe next step\n\n\n\nKeep going until you have enough evidence to identify the root cause confidently.\nOnly stop to ask questions when a missing detail changes correctness materially.\n\n\n\nBefore finalizing, verify that the proposed root cause matches the observed evidence.\n\n\n\nDo not guess missing repository facts.\nIf required context is absent, state exactly what remains unknown.\n\n```\n\n## Narrow Fix\n\n```xml\n\nImplement the smallest safe fix for the identified issue in this repository.\nPreserve existing behavior outside the failing path.\n\n\n\nReturn:\n1. summary of the fix\n2. touched files\n3. verification performed\n4. residual risks or follow-ups\n\n\n\nDefault to the most reasonable low-risk interpretation and keep going.\n\n\n\nResolve the task fully before stopping.\nDo not stop after identifying the issue without applying the fix.\n\n\n\nBefore finalizing, verify that the fix matches the task requirements and that the changed code is coherent.\n\n\n\nKeep changes tightly scoped to the stated task.\nAvoid unrelated refactors or cleanup.\n\n```\n\n## Root-Cause Review\n\n```xml\n\nAnalyze this change for the most likely correctness or regression issues.\nFocus on the provided repository context only.\n\n\n\nReturn:\n1. findings ordered by severity\n2. supporting evidence for each finding\n3. brief next steps\n\n\n\nGround every claim in the repository context or tool outputs.\nIf a point is an inference, label it clearly.\n\n\n\nCheck for second-order failures, empty-state handling, retries, stale state, and rollback paths before finalizing.\n\n\n\nBefore finalizing, verify that each finding is material and actionable.\n\n```\n\n## Research Or Recommendation\n\n```xml\n\nResearch the available options and recommend the best path for this task.\n\n\n\nReturn:\n1. observed facts\n2. reasoned recommendation\n3. tradeoffs\n4. open questions\n\n\n\nSeparate observed facts, reasoned inferences, and open questions.\nPrefer breadth first, then go deeper only where the evidence changes the recommendation.\n\n\n\nBack important claims with explicit references to the sources you inspected.\nPrefer primary sources.\n\n```\n\n## Prompt-Patching\n\n```xml\n\nDiagnose why this existing prompt is underperforming and propose the smallest high-leverage changes to improve it for Codex or GPT-5.4.\n\n\n\nReturn:\n1. failure modes\n2. root causes in the current prompt\n3. a revised prompt\n4. why the revision should work better\n\n\n\nBase your diagnosis on the prompt text and the failure examples provided.\nDo not invent failure modes that are not supported by the examples.\n\n\n\nBefore finalizing, make sure the revised prompt resolves the cited failure modes without adding contradictory instructions.\n\n```\n\n\n# Prompt Blocks\n\nUse these blocks selectively when composing Codex or GPT-5.4 prompts.\nWrap each block in the XML tag shown in its heading.\n\n## Core Wrapper\n\n### `task`\n\nUse in nearly every prompt.\n\n```xml\n\nDescribe the concrete job, the relevant repository or failure context, and the expected end state.\n\n```\n\n## Output and Format\n\n### `structured_output_contract`\n\nUse when the response shape matters.\n\n```xml\n\nReturn exactly the requested output shape and nothing else.\nKeep the answer compact.\nPut the highest-value findings or decisions first.\n\n```\n\n### `compact_output_contract`\n\nUse when you want concise prose instead of a schema.\n\n```xml\n\nKeep the final answer compact and structured.\nDo not include long scene-setting or repeated recap.\n\n```\n\n## Follow-through and Completion\n\n### `default_follow_through_policy`\n\nUse when Codex should act without asking routine questions.\n\n```xml\n\nDefault to the most reasonable low-risk interpretation and keep going.\nOnly stop to ask questions when a missing detail changes correctness, safety, or an irreversible action.\n\n```\n\n### `completeness_contract`\n\nUse for debugging, implementation, or any multi-step task that should not stop early.\n\n```xml\n\nResolve the task fully before stopping.\nDo not stop at the first plausible answer.\nCheck whether there are follow-on fixes, edge cases, or cleanup needed for a correct result.\n\n```\n\n### `verification_loop`\n\nUse when correctness matters.\n\n```xml\n\nBefore finalizing, verify the result against the task requirements and the changed files or tool outputs.\nIf a check fails, revise the answer instead of reporting the first draft.\n\n```\n\n## Grounding and Missing Context\n\n### `missing_context_gating`\n\nUse when Codex might otherwise guess.\n\n```xml\n\nDo not guess missing repository facts.\nIf required context is absent, retrieve it with tools or state exactly what remains unknown.\n\n```\n\n### `grounding_rules`\n\nUse for review, research, or root-cause analysis.\n\n```xml\n\nGround every claim in the provided context or your tool outputs.\nDo not present inferences as facts.\nIf a point is a hypothesis, label it clearly.\n\n```\n\n### `citation_rules`\n\nUse when external research or quotes matter.\n\n```xml\n\nBack important claims with citations or explicit references to the source material you inspected.\nPrefer primary sources.\n\n```\n\n## Safety and Scope\n\n### `action_safety`\n\nUse for write-capable or potentially broad tasks.\n\n```xml\n\nKeep changes tightly scoped to the stated task.\nAvoid unrelated refactors, renames, or cleanup unless they are required for correctness.\nCall out any risky or irreversible action before taking it.\n\n```\n\n### `tool_persistence_rules`\n\nUse for long-running tool-heavy tasks.\n\n```xml\n\nKeep using tools until you have enough evidence to finish the task confidently.\nDo not abandon the workflow after a partial read when another targeted check would change the answer.\n\n```\n\n## Task-Specific Blocks\n\n### `research_mode`\n\nUse for exploration, comparisons, or recommendations.\n\n```xml\n\nSeparate observed facts, reasoned inferences, and open questions.\nPrefer breadth first, then go deeper only where the evidence changes the recommendation.\n\n```\n\n### `dig_deeper_nudge`\n\nUse for review and adversarial inspection.\n\n```xml\n\nAfter you find the first plausible issue, check for second-order failures, empty-state behavior, retries, stale state, and rollback paths before you finalize.\n\n```\n\n### `progress_updates`\n\nUse when the run may take a while.\n\n```xml\n\nIf you provide progress updates, keep them brief and outcome-based.\nMention only major phase changes or blockers.\n\n```\n\n\n---\nname: gpt-5-4-prompting\ndescription: Internal guidance for composing Codex and GPT-5.4 prompts for coding, review, diagnosis, and research tasks inside the Codex Claude Code plugin\nuser-invocable: false\n---\n\n# GPT-5.4 Prompting\n\nUse this skill when `codex:codex-rescue` needs to ask Codex or another GPT-5.4-based workflow for help.\n\nPrompt Codex like an operator, not a collaborator. Keep prompts compact and block-structured with XML tags. State the task, the output contract, the follow-through defaults, and the small set of extra constraints that matter.\n\nCore rules:\n- Prefer one clear task per Codex run. Split unrelated asks into separate runs.\n- Tell Codex what done looks like. Do not assume it will infer the desired end state.\n- Add explicit grounding and verification rules for any task where unsupported guesses would hurt quality.\n- Prefer better prompt contracts over raising reasoning or adding long natural-language explanations.\n- Use XML tags consistently so the prompt has stable internal structure.\n\nDefault prompt recipe:\n- ``: the concrete job and the relevant repository or failure context.\n- `` or ``: exact shape, ordering, and brevity requirements.\n- ``: what Codex should do by default instead of asking routine questions.\n- `` or ``: required for debugging, implementation, or risky fixes.\n- `` or ``: required for review, research, or anything that could drift into unsupported claims.\n\nWhen to add blocks:\n- Coding or debugging: add `completeness_contract`, `verification_loop`, and `missing_context_gating`.\n- Review or adversarial review: add `grounding_rules`, `structured_output_contract`, and `dig_deeper_nudge`.\n- Research or recommendation tasks: add `research_mode` and `citation_rules`.\n- Write-capable tasks: add `action_safety` so Codex stays narrow and avoids unrelated refactors.\n\nHow to choose prompt shape:\n- Use built-in `review` or `adversarial-review` commands when the job is reviewing local git changes. Those prompts already carry the review contract.\n- Use `task` when the task is diagnosis, planning, research, or implementation and you need to control the prompt more directly.\n- Use `task --resume-last` for follow-up instructions on the same Codex thread. Send only the delta instruction instead of restating the whole prompt unless the direction changed materially.\n\nWorking rules:\n- Prefer explicit prompt contracts over vague nudges.\n- Use stable XML tag names that match the block names from the reference file.\n- Do not raise reasoning or complexity first. Tighten the prompt and verification rules before escalating.\n- Ask Codex for brief, outcome-based progress updates only when the task is long-running or tool-heavy.\n- Keep claims anchored to observed evidence. If something is a hypothesis, say so.\n\nPrompt assembly checklist:\n1. Define the exact task and scope in ``.\n2. Choose the smallest output contract that still makes the answer easy to use.\n3. Decide whether Codex should keep going by default or stop for missing high-risk details.\n4. Add verification, grounding, and safety tags only where the task needs them.\n5. Remove redundant instructions before sending the prompt.\n\nReusable blocks live in [references/prompt-blocks.md](references/prompt-blocks.md).\nConcrete end-to-end templates live in [references/codex-prompt-recipes.md](references/codex-prompt-recipes.md).\nCommon failure modes to avoid live in [references/codex-prompt-antipatterns.md](references/codex-prompt-antipatterns.md).\n\n\n{\n \"name\": \"openai-codex\",\n \"owner\": {\n \"name\": \"OpenAI\"\n },\n \"metadata\": {\n \"description\": \"Codex plugins to use in Claude Code for delegation and code review.\",\n \"version\": \"1.0.6\"\n },\n \"plugins\": [\n {\n \"name\": \"codex\",\n \"description\": \"Use Codex from Claude Code to review code or delegate tasks.\",\n \"version\": \"1.0.6\",\n \"author\": {\n \"name\": \"OpenAI\"\n },\n \"source\": \"./plugins/codex\"\n }\n ]\n}\n\n\n{\n \"name\": \"codex\",\n \"version\": \"1.0.6\",\n \"description\": \"Use Codex from Claude Code to review code or delegate tasks.\",\n \"author\": {\n \"name\": \"OpenAI\"\n }\n}\n"}