yeet

yeet is an official curated skill from the public openai/skills repository. It defines a narrowly scoped workflow for situations in which a person explicitly asks an agent to stage changes, create a commit, push the branch, and open a GitHub pull request as one connected flow. According to the provider, the skill is intended only for that explicit request. It is therefore not a general authorization to publish changes independently, and it does not replace review of the diff, branch, remote, or target organization. The primary source is the skills/.curated/yeet directory in the official repository. The matching OpenAI documentation is the official Codex documentation, which describes Codex as an environment for development tasks and pull request work.

Purpose and explicit trigger

The name yeet represents a deliberately bundled GitHub sequence. The skill should activate only when the user intent explicitly covers the important actions. Those actions include preparing the working tree, creating a commit, transferring the branch to a remote, and opening a pull request. A request for code review, a request for a commit, or a request for a local edit is not sufficient by itself. This boundary reduces the risk that an agent changes an external repository state in response to vague wording.

Before the flow starts, the provider instructions require checking whether the GitHub CLI gh is installed and whether an authenticated session is available. The skill also assumes a repository with an appropriate remote and sufficient permissions. If the CLI is missing or the session is not authenticated, the agent should stop and ask the responsible person to install or authenticate it. Credentials, tokens, and private configuration do not belong in this catalog entry and are not supplied by the skill.

A traceable pull request workflow

The described workflow begins by resolving the repository root and checking whether work is happening on the default branch. If necessary, it creates a descriptive branch. The agent then checks the working status, selects changes deliberately, and creates a concise commit with a description that matches the task. Before pushing, scope control remains essential: accidental files, local secrets, generated artifacts, and another person's work must stay out of the commit.

Before opening the pull request, the agent should discover and follow an active GitHub pull request template in the repository. The pull request needs a useful title and an explanatory body that reflects the actual change. The instructions distinguish between creating a new draft and updating an existing pull request. An existing ready-for-review state must not be silently changed back to draft. These requirements make the process easier for teams to audit and prevent automation from bypassing project-specific editorial conventions.

Boundaries, security, and responsibility

The skill performs actions that can be external and durable. A push changes the remote repository, while a pull request can trigger notifications, checks, or deployment workflows. The agent must therefore recognize the explicit user instruction clearly. Before committing, the diff should be checked for sensitive content, destructive changes, and an incorrect destination remote. GitHub permissions should follow the principle of least privilege. Successfully opening a pull request does not prove that the code is safe, correct, or ready to merge.

According to the provider, yeet is guidance for a particular agent workflow, not an independent GitHub service. Success depends on gh, local repository configuration, GitHub authentication, branch policies, review requirements, and the selected Codex environment. The skill does not state concrete prices and does not replace an organization's engineering policy. Teams should continue to check branch protection, required reviews, secret scanning, and CI independently. The official source and current source state should be reviewed again before productive use.