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

Instructions

1. 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.
2. Get the commits on this branch compared to main using git log main..HEAD
3. Get the diff using git diff main..HEAD to understand all changes
4. Read the PR template from .github/PULL_REQUEST_TEMPLATE.md
5. 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.
6. Push the branch to origin if needed
7. 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.
8. 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
9. 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.