用途：在 openai-agents-python 仓库中，当符合条件的实现工作完成后，生成 PR 就绪的摘要，包括简洁总结、PR 标题和以“This pull request ...”开头的草稿描述，可直接粘贴到 PR 中。
触发时机：用户明确要求 PR 草稿时优先执行。自动触发时，仅拼写、注释或格式改动（即使位于运行时或测试路径）不改变行为或契约，应跳过。每次最终回复前检查当前任务是否改动了运行时代码（src/agents/）、测试（tests/）、示例（examples/）、构建/测试配置或影响行为的文档；若有，则在完成必要验证后、发送最终回复前运行本技能，不以改动大小判断。仅本地未提交工作也适用，即使未要求创建 PR。生成文本不授权创建分支、提交、推送或开 PR。跳过情形：琐碎或纯对话任务、无行为影响的仓库元数据/纯文档任务、显式调用 $release-candidate-prep 交接且使用完整 $final-release-review 报告作为发布专用 PR 描述，或用户明确不要该块。
自动收集输入（不询问用户）：当前分支 git rev-parse --abbrev-ref HEAD；工作树 git status -sb；未跟踪文件 git ls-files --others --exclude-standard；变更文件 git diff --name-only 与 git diff --name-only --cached，规模用 git diff --stat 与 git diff --stat --cached；最新发布标签 LATEST_RELEASE_TAG=$(.agents/skills/final-release-review/scripts/find_latest_release_tag.sh origin 'v*' 2>/dev/null || git tag -l 'v*' --sort=-v:refname | head -n1)；基准引用 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。类别信号：runtime（src/agents/）、tests（tests/）、examples（examples/）、docs（docs/、mkdocs.yml）、构建/测试配置（pyproject.toml、uv.lock、Makefile、.github/）。
工作流：先计算 BASE_REF/BASE_COMMIT 并复用；若无变更且无领先提交，简短说明未检测到代码改动并跳过。根据路径推断变更类型（feature、fix、refactor、docs-with-impact），仅当 diff 改动已发布公共 API、外部配置、持久化数据、序列化状态或线协议时标记向后兼容风险，并对照 LATEST_RELEASE_TAG 判断。用 1–3 句总结，引用前 5 个关键路径与 git diff --stat，并显式列出未跟踪文件。选择引导动词：feature→adds，bug fix→fixes，refactor/perf→improves 或 updates，docs-only→updates。建议分支名：已在非 main 分支则保留，否则按主要区域提议 feat/<slug>、fix/<slug> 或 docs/<slug>。若当前分支匹配 issue-<number>（纯数字），保留该建议，可选拉取 issue 上下文但不阻塞；有 issue 号时使用同仓库引用 #<number> 并加入自动关闭行如 This pull request resolves #<number>.，不要加 issue URL 或 Markdown 链接。按模板起草标题与描述，遵守 GitHub 粘贴就绪规则：同仓库用 #123，跨仓库用 owner/repo#123，禁止 PR #123、#123、Codex 导航链接、本地文件链接、Codex 专用引用标记或脚注、应用指令。返回前规范化引用并重新扫描。输出仅含指定 Markdown 块，周围状态说明尽量简短且用英文。
输出格式：任务收尾时，在简短状态说明后添加 Markdown 块，包含分支名建议（git checkout -b <kebab-case 建议>）、单行祈使式标题（可含 chore:、feat: 等前缀）、描述（以“This pull request resolves/updates/adds ...”开头，说明改动与背景，bug 需描述症状或复现，feature 需说明需求与原因，行为变化或注意事项，无需列出测试）。保持紧凑，避免重复。
限制：不授权创建分支、提交、推送或开 PR；不编造未提供的信息；具体收费、价格、平台、效果等资料未提供。