translate claude skills into chatgpt or codex skills only after auditing purpose, target host, capability parity, resource portability, tool assumptions, and unrealizable behavior. use when the user uploads or points to a claude skill, asks to port a claude skill to chatgpt, codex, or openai skills, or wants a compatibility review before translation. requires a compatibility report, risk score, capability matrix, and user approval before packaging when behavior cannot be preserved faithfully.
83
90%
Does it follow best practices?
Impact
89%
2.34xAverage score across 2 eval scenarios
Passed
No known issues
Tessl allows only Claude eval runs when publishing. Given this is specifically an OpenAI/Codex skill, I would consider these eval results to be more accurate: https://tessl.io/eval-runs/019e1d88-f959-7338-a749-573b9ed90809
A note about best practices: Tessl's optimization suggestion would have resulted in a loss of functionality, so it was ignored.
Translate skills by preserving purpose, not by mechanically copying files.
A successful translation produces a ChatGPT/Codex skill that keeps the source skill's useful behavior while making host-specific assumptions explicit. Never hide incompatibilities. Never broaden the skill's purpose to compensate for missing capabilities.
chatgpt: ChatGPT skill packaging and ChatGPT interaction assumptions.codex: coding-agent usage, repository context, shell/script expectations, and minimal host assumptions.both: portable core that should work in ChatGPT and Codex, with target-specific notes when needed.What should the translated skill be called? If you do not provide a name, I will use the source skill name normalized to kebab-case.skill.zip.When a source archive or folder is available, inspect at minimum:
SKILL.md frontmatter and body.Use scripts/inspect_skill.py when a source folder or zip is available. Treat its report as a starting point; still apply judgment.
Before translating, return this report:
Source skill:
Target host: chatgpt | codex | both
Requested translated skill name:
Normalized translated skill name:
Name source: user-provided | source-skill-default
Purpose:
Expected input:
Expected output:
Resources found:
Scripts/tools found:
Connector or credential assumptions:
Host-specific assumptions:
Translation mode: translation | adaptation | minimum viable translation
Translation risk score: low | medium | high | blocked
Capability matrix:
| Capability | Claude/source assumption | ChatGPT/Codex equivalent | Status | Notes |
|---|---|---|---|---|
| ... | ... | ... | portable/adaptable/host-dependent/unrealizable | ... |
Required changes:
Capabilities preserved:
Capabilities adapted:
Capabilities reduced or omitted:
Risks / reduced behavior:
Recommendation:
Proceed? yes/noDo not package a translated skill until the user approves when risk is high or blocked, or when any capability is host-dependent or unrealizable.
Use direct approval wording:
I can translate this skill, but these capabilities will not be equivalent in ChatGPT/Codex:
- ...
Proceed with the adapted or minimum viable version?Keep the source skill's intended job. Do not broaden it to cover adjacent tasks.
If the source capability cannot be preserved, state the limitation. Do not silently replace it with a broader instruction such as "use whatever tools are available."
Before creating or editing the translated skill package, identify the desired translated skill name. If the user has not already provided a name, ask:
What should the translated skill be called? If you do not provide a name, I will use the source skill name normalized to kebab-case.Normalize the final skill package name to kebab-case:
The Cat Burglar -> cat-burglarClient Portal QA -> client-portal-qaclaude_to_chatgpt -> claude-to-chatgptUse the normalized name for the translated skill directory, SKILL.md frontmatter name, and package contents. Keep the display name in agents/openai.yaml human-readable.
If the user declines to name the skill or gives no name after the prompt, derive the name from the source skill's frontmatter name; if that is missing, derive it from the source folder name.
For ChatGPT/Codex, the frontmatter description must include both:
Keep it clear, concrete, and lower-case.
Create agents/openai.yaml with a readable display name, short description, icon, and accent color.
Keep SKILL.md compact. Move long details into one-level references/ files. Remove unused examples and placeholder files.
Replace host-specific references such as Claude, Claude Code, Claude Desktop, or Anthropic only when they describe the runtime user. Preserve them when they are the subject being analyzed.
Prefer neutral terms such as:
If scripts are portable, keep them and document how they are used.
If scripts require unavailable binaries, operating systems, credentials, network access, or connectors, classify the capability as host-dependent or unrealizable and ask before proceeding.
Never imply that ChatGPT/Codex can access a connector, account, repository, file, browser session, local app, or MCP server unless that access is actually available in the target environment.
If a source skill depends on a connector, include an explicit limitation or required setup step.
If the source skill includes refusals, access checks, approval gates, no-op rules, validation steps, or capability checks, preserve them unless they conflict with the target platform's rules.
If target=codex, include repository, shell, script, and file-edit assumptions only when the translated skill truly needs them.
If target=chatgpt, avoid implying persistent repo state, local shell access, or background work unless the actual target environment provides it.
If target=both, prefer the portable behavioral core and put host-specific execution details in a short "Target notes" section.
Use this when the source skill is useful but some host-specific machinery cannot be ported.
Rules:
When done, provide:
Translated skill:
Normalized skill name:
Name source: user-provided | source-skill-default
Target host:
Translation mode:
Risk score:
What changed:
Capabilities preserved:
Capabilities adapted:
Capabilities omitted or reduced:
Validation result:
Install/test checklist:
- upload skill.zip
- verify the trigger with a representative prompt
- run one simple source-equivalent task
- compare output against the original Claude skill expectation
- confirm any host-dependent setup or limitation
Round-trip review:
- What did the original skill do better?
- What became weaker?
- What assumptions remain?
Packaged file:Stop and explain when:
SKILL.md entrypoint exists.Use these references only when needed:
references/compatibility-checklist.md for detailed audit criteria.references/translation-examples.md for clean-port and reduced-port examples.