Create Pr Skill for Codex

Create a pull request for the current branch following the Datadog Agent contributing guidelines.

Instructions

• Check the current branch. If the current branch is main (or the default branch):
• Check for uncommitted or staged changes (git status). If there are changes, create a new feature branch from the default branch (git checkout -b <branch-name>), stage the changes, commit, and push.
• If there are no changes at all, stop and inform the user there is nothing to open a PR for.
• Get the commits on this branch compared to main using git log main..HEAD
• Get the diff using git diff main..HEAD to understand all changes
• Read the PR template from .github/PULL_REQUEST_TEMPLATE.md
• Codex review (optional): Check if codex is installed (command -v codex). If it is, run a review against the default branch:

   DEFAULT_BRANCH=$(git rev-parse --abbrev-ref origin/HEAD | sed 's|^origin/||')
   codex review --base "$DEFAULT_BRANCH"

Show the review output to the user. If codex is not installed, skip this step silently.

• Push the branch to origin if needed
• Open the PR: By default, open as Draft using gh pr create --draft. If $ARGUMENTS contains --real, open as a regular (non-draft) PR instead (omit the --draft flag). Remove --real from $ARGUMENTS before processing remaining arguments as labels.
• PR title: Use conventional commits format, prefixed with the general area of change. Examples:
• fix(e2e): Fix flaky diagnose test
• feat(logs): Add new log pipeline
• refactor(config): Simplify endpoint resolution
• Labels: Choose appropriate labels (plus any additional labels passed as $ARGUMENTS):
• If the PR only changes tests, docs, CI config, or developer tooling (no Agent binary code changes), use changelog/no-changelog and qa/no-code-change
• If the PR changes Agent binary code and QA was done, use qa/done
• If the PR changes Agent binary code, a reno release note is expected (remind the user)
• Add backport/<branch-name> if the user asks for a backport

10. PR body: Fill in the PR template sections:

• What does this PR do?: A clear description of what is changed. Must be readable independently, tying back to the changed code.
• Motivation: A reason why the change is made. Point to an issue if applicable. Include drawbacks or tradeoffs if any.
• Describe how you validated your changes: How you validated the change (tests added/run, benchmarks, manual testing). Only needed when testing included work not covered by test suites.
• Additional Notes: Any extra context, links to predecessor PRs if part of a chain, notes that make code understanding easier. Only include this section if there is genuinely useful context to add — omit it entirely rather than filling it with filler.

PR Description Guidelines (from CONTRIBUTING.md)

The PR description should incorporate everything reviewers and future maintainers need:

• A description of what is changed
• A reason why the change is made (pointing to an issue is a good reason)
• When testing had to include work not covered by test suites, a description of how you validated your change
• Any relevant benchmarks
• Additional notes that make code understanding easier
• If part of a chain of PRs, point to the predecessors
• If there are drawbacks or tradeoffs, raise them

Example

gh pr create --draft \
  --title "fix(e2e): Fix flaky diagnose test by adding missing fakeintake redirect" \
  --label "changelog/no-changelog" \
  --label "qa/no-code-change" \
  --body "$(cat <<'EOF'
### What does this PR do?

<description of changes>

### Motivation

<why this change is needed>

### Describe how you validated your changes

<testing done>

### Additional Notes

<any extra context>
EOF
)"

Usage

• /create-pr — creates a draft PR (default)
• /create-pr --real — creates a non-draft PR
• /create-pr --real team/my-team — non-draft PR with an extra label

Output

Return the PR URL when done.