pr-draft-summary

PR 草稿摘要

目的

在符合条件的工作完成后，提供本仓库要求的、可用于 PR 的摘要：简要总结变更，并为 openai-agents-js 拟定可用于 PR 的标题和描述草稿。

收尾门槛

1. 发送最终回复前，检查实际任务差异。明确提出 PR 草稿请求时，优先于下方的自动触发排除条件。生成草稿并不授权创建分支、提交、推送或开启 PR。
2. 如果差异包含运行时代码、测试、示例、构建/测试配置，或会影响行为的文档，就运行此技能。不要因为认为变更规模较小而跳过符合条件的变更。
3. 在完成任何必要的验证和变更集工作后、发送“工作已完成”回复前运行此技能。
4. 仅在没有符合条件的文件变更、所有变更均为仓库元信息或不影响行为的纯文档变更、任务仅涉及对话，或用户明确选择不执行时跳过。

自动收集的输入（不要询问用户）

• 当前分支：git rev-parse --abbrev-ref HEAD。
• 工作树：git status -sb。
• 未跟踪文件：git ls-files --others --exclude-standard（与 git status -sb 一起使用；--stat 不会包含这些文件）。
• 已变更文件：git diff --name-only（未暂存）和 git diff --name-only --cached（已暂存）；变更规模使用 git diff --stat 和 git diff --stat --cached。
• PR 基础引用（使用 origin/main；绝不要使用功能分支的上游作为 PR 基础）：
  • BASE_REF=origin/main；如果本地不存在，则使用 main。
  • BASE_COMMIT=$(git merge-base "$BASE_REF" HEAD)。
• 已提交的分支差异：git diff --name-only "${BASE_COMMIT}..HEAD" 和 git diff --stat "${BASE_COMMIT}..HEAD"。
• 超出基础分叉点的提交：git log --oneline --no-merges ${BASE_COMMIT}..HEAD。
• 本仓库的类别信号：运行时（packages/、examples/、helpers/、scripts/）、测试（packages/**/test、integration-tests/）、文档（docs/、README.md、AGENTS.md、.github/）、构建/测试配置（package.json、pnpm-lock.yaml、pnpm-workspace.yaml、tsconfig*.json、tsc-multi.json、eslint.config.*、vitest*.ts）。

任务归属

使用完整的任务所属差异，包括已提交、已暂存、未暂存和未跟踪的变更。检查分支差异作为上下文，然后根据用户请求、任务初始状态和实现历史判断任务归属。不要将无关的既有分支或工作区变更纳入草稿。若请求涵盖整个分支，则包含该分支的完整差异。如果归属不明确且会实质影响草稿，应先解决具体疑问，再将草稿作为可直接使用的版本提交。

对于与无关功能分支上的主题相关的修正，仅描述该修正，并以纯文本形式建议合适的分支名称。保留实际检出状态和分支。不要沿用当前分支名称中与无关问题关联的引用。

工作流

1. 不要询问用户，直接运行上述命令；先计算 BASE_REF/BASE_COMMIT，以便后续命令复用。比较时使用 origin/main 或 main，不要使用当前分支的上游分支。
2. 合并任务相关的已提交差异，以及任务相关的暂存、未暂存和未跟踪更改。如果合并后的差异为空，简短回复未检测到代码更改，并跳过输出 PR 区块。
3. 根据“类别信号”中列出的已更改路径推断更改类型，将其归类为功能、修复、重构或有影响的文档；仅当差异更改了已发布的公共 API、外部配置、持久化数据或线协议时，才标记向后兼容性风险。应以最新发布标签为基准评估风险，而不是以尚未发布的分支变更为基准。
4. 用 1–3 句简短的话概述更改，使用最相关的任务相关路径，以及已提交、暂存和未暂存差异中的统计信息。明确指出未跟踪文件，因为 --stat 不会将其计入。将提交消息作为辅助上下文，不要用它们代替对已提交差异的检查。
5. 为描述选择一个开头动词：功能 → adds，错误修复 → fixes，重构／性能 → improves 或 updates，仅文档 → updates。
6. 建议一个分支名称。如果当前已在处理此任务的分支上，保留该分支；否则，根据主要领域提出 feat/<slug>、fix/<slug> 或 docs/<slug>（例如 docs/pr-draft-summary-guidance）。
7. 如果当前分支属于此任务且符合 issue-<number> 格式（仅包含数字），则保留该分支建议。当存在问题编号时，使用原生的同仓库引用 #<number>，并添加类似 This pull request resolves #<number>. 的自动关闭行。不要添加显式问题 URL，也不要将引用包装为 Markdown 链接。如果无法获取问题信息，不要因此阻塞。
8. 使用下方模板起草 PR 标题和描述。遵守仓库范围内的 GitHub 粘贴就绪规则：同仓库问题或 PR 使用 #123，跨仓库引用使用 owner/repo#123；绝不要在可直接复制的区块中输出 [PR #123](https://github.com/owner/repo/pull/123)、[#123](...)、Codex 导航链接、本地文件链接、仅 Codex 使用的引用标记或脚注，以及应用指令。保留指向 API 文档、设计说明及其他目标的普通描述性链接，但不要将 GitHub 问题或 PR 语法用作链接。
9. 返回区块前规范化引用：将每个同仓库 URL 或 openai/openai-agents-js#<number> 引用替换为 #<number>，将每个跨仓库问题或 PR URL 替换为 owner/repo#<number>，然后重新检查整个区块。如果仍有 Markdown 链接形式的问题或 PR 标签、带仓库限定的同仓库引用，或裸 GitHub 问题或 PR URL，则不要返回。
10. 仅输出“输出格式”中的区块。如果有简短状态说明，使用英文。

输出格式

结束任务时，除非符合文档规定的跳过情形或用户表示不需要，否则请在任何简短状态说明后添加此简洁的 Markdown 区块（仅使用英文）。

# 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.>

保持简洁——区块前后不要添加多余的说明，也不要在 Changes 和描述中重复细节。除非特别要求，否则无需列出测试。