PR Draft Summary

Purpose

Produce the PR-ready summary required in this repository after eligible work is complete: a concise change summary plus a PR-ready title and draft description for openai-agents-js.

Close-out Gate

1. Inspect the actual task diff before sending the final response. An explicit request for a PR draft takes precedence over the automatic-trigger exclusions below. Producing a draft never authorizes creating a branch, committing, pushing, or opening a PR.
2. Run this skill when the diff includes runtime code, tests, examples, build/test configuration, or docs with behavior impact. Do not use perceived change size to skip an eligible change.
3. Run it after any required verification and changeset work and before sending the "work complete" response.
4. Skip only when no eligible files changed, every change is repo-meta or docs-only without behavior impact, the task is conversation-only, or the user explicitly opts out.

Inputs to Collect Automatically (do not ask the user)

• Current branch: git rev-parse --abbrev-ref HEAD.
• Working tree: git status -sb.
• Untracked files: git ls-files --others --exclude-standard (use with git status -sb; --stat omits them).
• Changed files: git diff --name-only (unstaged) and git diff --name-only --cached (staged); sizes via git diff --stat and git diff --stat --cached.
• Pull request base reference (use origin/main; never use a feature branch's upstream as the PR base):
  • BASE_REF=origin/main; if it does not exist locally, use main.
  • BASE_COMMIT=$(git merge-base "$BASE_REF" HEAD).
• Committed branch diff: git diff --name-only "${BASE_COMMIT}..HEAD" and git diff --stat "${BASE_COMMIT}..HEAD".
• Commits ahead of the base fork point: git log --oneline --no-merges ${BASE_COMMIT}..HEAD.
• Category signals for this repo: runtime (packages/, examples/, helpers/, scripts/), tests (packages/**/test, integration-tests/), docs (docs/, README.md, AGENTS.md, .github/), build/test config (package.json, pnpm-lock.yaml, pnpm-workspace.yaml, tsconfig*.json, tsc-multi.json, eslint.config.*, vitest*.ts).

Task ownership

Use the complete task-owned diff, including committed, staged, unstaged, and untracked changes. Inspect the branch diff as context, then identify ownership from the user's request and the task's initial state and implementation history. Do not include unrelated pre-existing branch or workspace changes in the draft. A request covering the entire branch includes that branch's complete diff. If ownership is unclear and would change the draft materially, resolve that concrete question before presenting it as ready.

For a topic-scoped correction on an unrelated feature branch, describe the correction and suggest an appropriate branch name as text only. Preserve the actual checkout and branch. Do not inherit an unrelated issue-closing reference from the current branch name.

Workflow

1. Run the commands above without asking the user; compute BASE_REF/BASE_COMMIT first so later commands reuse them. Compare against origin/main or main, not the current branch's upstream.
2. Combine the task-owned committed diff with task-owned staged, unstaged, and untracked changes. If that combined diff is empty, reply briefly that no code changes were detected and skip emitting the PR block.
3. Infer change type from the touched paths listed under "Category signals"; classify as feature, fix, refactor, or docs-with-impact, and flag backward-compatibility risk only when the diff changes released public APIs, external config, persisted data, or wire protocols. Judge that risk against the latest release tag, not unreleased branch-only churn.
4. Summarize changes in 1–3 short sentences using the most relevant task-owned paths and stats from the committed, staged, and unstaged diffs. Explicitly call out untracked files because --stat does not include them. Use commit messages as supporting context, not as a substitute for inspecting the committed diff.
5. Choose the lead verb for the description: feature → adds, bug fix → fixes, refactor/perf → improves or updates, docs-only → updates.
6. Suggest a branch name. If already on a branch for this task, keep it; otherwise propose feat/<slug>, fix/<slug>, or docs/<slug> based on the primary area (for example docs/pr-draft-summary-guidance).
7. If the current branch belongs to this task and matches issue-<number> (digits only), keep that branch suggestion. When an issue number is present, use the native same-repository reference #<number> and include an auto-closing line such as This pull request resolves #<number>.. Do not add the explicit issue URL or wrap the reference in a Markdown link. Do not block if the issue cannot be fetched.
8. Draft the PR title and description using the template below. Apply the repository-wide GitHub paste-readiness rule: use exactly #123 for same-repository issues or PRs and owner/repo#123 for cross-repository references; never emit [PR #123](https://github.com/owner/repo/pull/123), [#123](...), Codex navigation links, local file links, Codex-only citation markers or footnotes, or app directives in the copy-ready block. Preserve ordinary descriptive links to API docs, design notes, and other targets without native GitHub issue or pull-request syntax.
9. Normalize references before returning the block: replace every same-repository URL or openai/openai-agents-js#<number> reference with #<number>, replace every cross-repository issue or pull-request URL with owner/repo#<number>, then rescan the full block. Do not return it while a Markdown-linked issue or pull-request label, a same-repository qualified reference, or a bare GitHub issue or pull-request URL remains.
10. Output only the block in "Output Format". Keep any surrounding status note minimal and in English.

Output Format

When closing out a task, add this concise Markdown block (English only) after any brief status note unless the task falls under the documented skip cases or the user says they do not want it.

# 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: or 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 any 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.