gpt-5-4-prompting
Skill2 starsChanged 8 months agoApache-2.0View on GitHub
Internal guidance for composing Codex and GPT-5.4 prompts for coding, review, diagnosis, and research tasks inside the Codex Claude Code plugin
2 other projects use a version of this, 1 of them edited.
Adopted by
Steady: 0 new projects took it in the last 4 weeks, none the 4 weeks before.thin data
Most recently taken up by
- doctorplastic79-cmd/claude-skillsedited, first seen Oct 15, 2026
- openai/codex-plugin-ccword for word, first seen Mar 30, 2026
Other versions2 projects use a version of this.
Word for word · 1
- openai/codex-plugin-cc★ 33k100% same
Edited · 1
- doctorplastic79-cmd/claude-skills★ 099% same
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository2 other files it gives its agents.
- codex-cli-runtimeSkill
- codex-result-handlingSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
17 rules. About 0 are common, 12 are distinctive, and 5 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈12
Distinctive · estimate
This author's own choices. Worth a look.
5
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 9
Use this skill when codex:codex-rescue needs to ask Codex or another GPT-5.4-based workflow for help.
- Distinctive: line 14
Prefer one clear task per Codex run.
- Distinctive: line 16
Add explicit grounding and verification rules for any task where unsupported guesses would hurt quality.
- Distinctive: line 17
Prefer better prompt contracts over raising reasoning or adding long natural-language explanations.
- Distinctive: line 18
Use XML tags consistently so the prompt has stable internal structure.
- Distinctive: line 27
When to add blocks:
- Very specific: line 31
Write-capable tasks: add action_safety so Codex stays narrow and avoids unrelated refactors.
- Very specific: line 34
Use built-in review or adversarial-review commands when the job is reviewing local git changes.
- Very specific: line 35
Use task when the task is diagnosis, planning, research, or implementation and you need to control the prompt more directly.
- Very specific: line 36
Use task --resume-last for follow-up instructions on the same Codex thread.
- Distinctive: line 39
Prefer explicit prompt contracts over vague nudges.
- Distinctive: line 40
Use stable XML tag names that match the block names from the reference file.
- Distinctive: line 41
Do not raise reasoning or complexity first.
- Distinctive: line 42
Ask Codex for brief, outcome-based progress updates only when the task is long-running or tool-heavy.
- Distinctive: line 43
Keep claims anchored to observed evidence.
- Distinctive: line 49
Add verification, grounding, and safety tags only where the task needs them.
- Distinctive: line 50
Remove redundant instructions before sending the prompt.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
GPT-5.4 Prompting
Use this skill when codex:codex-rescue needs to ask Codex or another GPT-5.4-based workflow for help.
Prompt 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.
Core rules:
- Prefer one clear task per Codex run. Split unrelated asks into separate runs.
- Tell Codex what done looks like. Do not assume it will infer the desired end state.
- Add explicit grounding and verification rules for any task where unsupported guesses would hurt quality.
- Prefer better prompt contracts over raising reasoning or adding long natural-language explanations.
- Use XML tags consistently so the prompt has stable internal structure.
Default prompt recipe:
<task>: the concrete job and the relevant repository or failure context.<structured_output_contract>or<compact_output_contract>: exact shape, ordering, and brevity requirements.<default_follow_through_policy>: what Codex should do by default instead of asking routine questions.<verification_loop>or<completeness_contract>: required for debugging, implementation, or risky fixes.<grounding_rules>or<citation_rules>: required for review, research, or anything that could drift into unsupported claims.
When to add blocks:
- Coding or debugging: add
completeness_contract,verification_loop, andmissing_context_gating. - Review or adversarial review: add
grounding_rules,structured_output_contract, anddig_deeper_nudge. - Research or recommendation tasks: add
research_modeandcitation_rules. - Write-capable tasks: add
action_safetyso Codex stays narrow and avoids unrelated refactors.
How to choose prompt shape:
- Use built-in
revieworadversarial-reviewcommands when the job is reviewing local git changes. Those prompts already carry the review contract. - Use
taskwhen the task is diagnosis, planning, research, or implementation and you need to control the prompt more directly. - Use
task --resume-lastfor follow-up instructions on the same Codex thread. Send only the delta instruction instead of restating the whole prompt unless the direction changed materially.
Working rules:
- Prefer explicit prompt contracts over vague nudges.
- Use stable XML tag names that match the block names from the reference file.
- Do not raise reasoning or complexity first. Tighten the prompt and verification rules before escalating.
- Ask Codex for brief, outcome-based progress updates only when the task is long-running or tool-heavy.
- Keep claims anchored to observed evidence. If something is a hypothesis, say so.
Prompt assembly checklist:
- Define the exact task and scope in
<task>. - Choose the smallest output contract that still makes the answer easy to use.
- Decide whether Codex should keep going by default or stop for missing high-risk details.
- Add verification, grounding, and safety tags only where the task needs them.
- Remove redundant instructions before sending the prompt.
Reusable blocks live in references/prompt-blocks.md. Concrete end-to-end templates live in references/codex-prompt-recipes.md. Common failure modes to avoid live in references/codex-prompt-antipatterns.md.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

