// Create a PR title and draft description after substantive code changes are finished. Trigger when wrapping up a moderate-or-larger change (runtime code, tests, build config, docs with behavior impact) and you need the PR-ready summary block with change summary plus PR draft text.
Perform a release-readiness review by locating the previous release tag from remote tags and auditing the diff (e.g., v1.2.3...<commit>) for breaking changes, regressions, improvement opportunities, and risks before releasing openai-agents-python.
Analyze main branch implementation and configuration to find missing, incorrect, or outdated documentation in docs/. Use when asked to audit doc coverage, sync docs with code, or propose doc updates/structure changes. Only update English docs under docs/** and never touch translated docs under docs/ja, docs/ko, or docs/zh. Provide a report and ask for approval before editing docs.
Improve test coverage in the OpenAI Agents Python repository: run `make coverage`, inspect coverage artifacts, identify low-coverage files, propose high-impact tests, and confirm with the user before writing tests.
Run python examples in auto mode with logging, rerun helpers, and background control.
Run the mandatory verification stack when changes affect runtime code, tests, or build/test behavior in the OpenAI Agents Python repository.
Use when working with the OpenAI API (Responses API) or OpenAI platform features (tools, streaming, Realtime API, auth, models, rate limits, MCP) and you need authoritative, up-to-date documentation (schemas, examples, limits, edge cases). Prefer the OpenAI Developer Documentation MCP server tools when available; otherwise guide the user to enable `openaiDeveloperDocs`.
| name | pr-draft-summary |
| description | Create a PR title and draft description after substantive code changes are finished. Trigger when wrapping up a moderate-or-larger change (runtime code, tests, build config, docs with behavior impact) and you need the PR-ready summary block with change summary plus PR draft text. |
Produce the PR-ready summary required in this repository after substantive code work is complete: a concise summary plus a PR-ready title and draft description that begins with "This pull request ...". The block should be ready to paste into a PR for openai-agents-python.
git rev-parse --abbrev-ref HEAD.git status -sb.git ls-files --others --exclude-standard (use with git status -sb to ensure they are surfaced; --stat does not include them).git diff --name-only (unstaged) and git diff --name-only --cached (staged); sizes via git diff --stat and git diff --stat --cached.origin/main):
BASE_REF=$(git rev-parse --abbrev-ref --symbolic-full-name @{upstream} 2>/dev/null || echo origin/main).BASE_COMMIT=$(git merge-base --fork-point "$BASE_REF" HEAD || git merge-base "$BASE_REF" HEAD || echo "$BASE_REF").git log --oneline --no-merges ${BASE_COMMIT}..HEAD.src/agents/), tests (tests/), examples (examples/), docs (docs/, mkdocs.yml), build/test config (pyproject.toml, uv.lock, Makefile, .github/).BASE_REF/BASE_COMMIT first so later commands reuse them.${BASE_COMMIT}, reply briefly that no code changes were detected and skip emitting the PR block.git diff --stat output; explicitly call out untracked files from git status -sb/git ls-files --others --exclude-standard because --stat does not include them. If the working tree is clean but there are commits ahead of ${BASE_COMMIT}, summarize using those commit messages.adds, bug fix → fixes, refactor/perf → improves or updates, docs-only → updates.feat/<slug>, fix/<slug>, or docs/<slug> based on the primary area (e.g., docs/pr-draft-summary-guidance).issue-<number> (digits only), keep that branch suggestion. Optionally pull light issue context (for example via the GitHub API) when available, but do not block or retry if it is not. When an issue number is present, reference https://github.com/openai/openai-agents-python/issues/<number> and include an auto-closing line such as This pull request resolves #<number>..When closing out a task and the summary block is desired, add this concise Markdown block (English only) after any brief status note. If the user says they do not want it, skip this section.
# Pull Request Draft
## Branch name suggestion
git checkout -b <kebab-case suggestion, e.g., feat/pr-draft-summary-skill>
## Title
<single-line imperative title, which can be a commit message; if a common prefix like chore: and feat: etc., having them is preferred>
## Description
<include what you changed plus a draft pull request title and description for your local changes; start the description with prose such as "This pull request resolves/updates/adds ..." using a verb that matches the change (you can use bullets later), explain the change background (for bugs, clearly describe the bug, symptoms, or repro; for features, what is needed and why), any behavior changes or considerations to be aware of, and you do not need to mention tests you ran.>
Keep it tight—no redundant prose around the block, and avoid repeating details between Changes and the description. Tests do not need to be listed unless specifically requested.