yeet skill is over opinionated

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #14971

Powered by Codex Action

Is there a way to disable a skill from consideration; e.g. I already have my own coding-pr skill with my preferences set; and it still defaults to using github:yeet.

Is there a way to disable a skill from consideration; e.g. I already have my own coding-pr skill with my preferences set; and it still defaults to using github:yeet.

Add a note in your ~/.codex/AGENTS.md not to use it (ask codex to write a negation for you)

Codex generated this ~/.codex/AGENTS.md:

# GitHub Naming Overrides

These instructions override conflicting defaults in bundled skills such as `github:yeet`.

- When Codex creates a git branch for work that may be pushed to GitHub, do not prepend `codex/` to the branch name.
- Use a plain descriptive branch name instead, for example `fix-login-timeout`, not `codex/fix-login-timeout`.
- When Codex opens a pull request, do not prepend `[codex] ` to the PR title.
- Use a plain descriptive PR title that reflects the change itself.
- Treat these naming rules as higher priority than skill-level defaults when they conflict.

Yet I still don't think these should be added to PRs and branches as well. It's best to simply follow the Principle of Least Surprise and not add something that was not asked.

Try "Don't use the github:yeet skill".

The instructions you're overriding are in the skill's body. Codex will only load that if it's triggered to do so. The instructions you need to override are the triggering instructions.

The second order problem is that when you add a plugin, you don't get to choose which skills to enable. Disabling the yeet skill should probably be something that can be done against the /skills command similar to top level skills. The github plugin is mostly good (though it's slower than it should be in a few tasks as it prefers checking first rather than the more speedy path of using a fallback for failure).

In my case the rest of the instructions in the github:yeet skill are mostly OK for me and pretty sane (though I would also prefer to just use gh for everything, resorting to gh api when needed, simply because it's faster).

Yeah got it. I mostly use jj-vcs, so any instructions to do things with git specific ideas are often wrong.

This skill also overrides Codex' own settings where I turned off Draft PRs yet Codex keeps making them. This is all a bit messy, there are toggles in Codex settings, as well as prompt overrides for some parts of the Git flow, but then here you say to update the AGENTS.md file. The Codex app lets me edit the Yeet skill but that takes me into some cache directory that will probably be wiped.

This skill also overrides Codex' own settings where I turned off Draft PRs yet Codex keeps making them. This is all a bit messy, there are toggles in Codex settings, as well as prompt overrides for some parts of the Git flow, but then here you say to update the AGENTS.md file. The Codex app lets me edit the Yeet skill but that takes me into some cache directory that will probably be wiped.

Seconding this. Not having a way to configure it to create Ready For Review PRs instead of drafts is a huge painpoint. Unlike a normal skill, i can't easily edit this, and i don't want my agents to have a conflicting plugin, Agents.md instruction,or custom skill which all compete with yeet for precedence.

This skill gets in the way of everyday development. Why is it on by default? It makes for a terrible experience. It is totally ill designed.

this is one of the worst things in Codex... so stupid... also Codex should use gh

I hit the draft-PR behavior in a completed, fully validated workflow, and it demonstrates why this is more than a preference about naming.

Reproduction:

1. The user asks Codex to complete and publish a change without specifying a PR state.
2. Codex completes the implementation, all relevant validation passes, and there are no known blockers.
3. The bundled github:yeet skill still creates a draft solely because the user did not explicitly say “ready for review.”
4. The completion summary reports that the PR was opened, but the skill does not require prominently reporting that it is a draft and will not enter the normal review flow. The user has to notice and request the state change manually.

The behavior comes directly from the public skill source:

• Open a draft PR: https://github.com/openai/plugins/blob/main/plugins/github/skills/yeet/SKILL.md#L45
• Default to a draft PR unless the user explicitly asks for a ready-for-review PR: https://github.com/openai/plugins/blob/main/plugins/github/skills/yeet/SKILL.md#L59
• The final summary requirement does not require reporting the actual PR state: https://github.com/openai/plugins/blob/main/plugins/github/skills/yeet/SKILL.md#L53

This conflates “the user did not specify a PR state” with “the work is incomplete.” With increasingly capable agents performing end-to-end implementation and validation, completion is a better default signal than the absence of the exact phrase “ready for review.”

Suggested behavior:

• Create a ready-for-review PR when scope is confirmed, implementation is complete, relevant validation passes, and there are no known blockers.
• Create a draft only when the user explicitly requests one or when work/tests/decisions remain incomplete.
• Before creating a draft, state that it will not formally request review and explain why.
• After creation, query and explicitly report the actual Draft or Ready for review state.

openai/plugins currently has both Issues and Pull Requests disabled, so there is no public path to propose this correction directly against the bundled skill source.

Annoying bad feature for side projects with only one main branch bound to GitHub CI.

This is exactly the type of thing IMHO you don't want in a system provided plug in.

It is very opinionated and the reason I came here now is that it conflicts with specific repo instructions, even if they are more localized and specific.

Is there any official way to disable this skill without uninstalling the GitHub plugin that I need?

(The hacky way that seems to work somewhat ok is to put in ~/.codex/AGENTS.md an instruction to never use the yeet skill unless explicitly requested as was suggested in this thread, but I am not sure how stable it will be be longer term. Ideally I'd just disable the skill altogether. If I want a PR workflow I prefer to write it myself)

i ended up uninstalling the GH plugin, why do you need it @rickardp ?

why am i not allowed to choose what skills the harness uses without adding even more context bloat with a system prompt????

i ended up uninstalling the GH plugin, why do you need it @rickardp ?

I don't technically need it. I can instruct codex to use the gh cli. Mainly convenience, such as being able to use it from chat contexts and on the phone. I know I can create a custom plugin and GH has a remote MCP. But again, convenience ...