| name | pr-draft-summary |
| description | 生成所需的 PR-ready summary block、branch suggestion、title 和 draft description。用于中等及以上规模的运行时代码、测试、示例、构建/测试配置或有行为影响的文档变更完成后的最终交付；仅在 trivial/conversation-only、无行为影响的 repo-meta/doc-only 任务，或用户明确不要 PR draft block 时跳过。 |
PR 草稿总结
目的
在实质性代码工作完成后，生成本仓库需要的 PR-ready summary：简短总结、可用 PR title，以及以 "This pull request ..." 开头的 draft description。输出块应可直接粘贴进 PR。
触发条件
补全本节前请确认：
- 让触发规则匹配本仓库真实的 review 和发布预期。
- 对 docs-only、metadata-only 或 conversation-only 工作保留明确跳过条件。
- 不要为本仓库未使用的 PR 工作流强制要求 PR block。
- 本仓库任务已完成（或 ready for review），且触及运行时代码、测试、示例、有行为影响的 docs 或构建/测试配置。
- 对实质性代码工作，把它作为默认 final handoff step。在所需验证或 changeset 工作完成后、发送“完成”回复前执行。
- 仅在 trivial/conversation-only、无行为影响的 repo-meta/doc-only 任务，或用户明确不要 PR draft block 时跳过。
自动收集的输入（不要询问用户）
补全本节前请确认：
- 从仓库事实验证 branch、release tag、base reference 和代码托管平台假设。
- 用本仓库真实 runtime、test、template、docs 和 config 路径替换通用 category signals。
- 删除无法在本仓库正常环境中运行的命令。
- 当前 branch：
git rev-parse --abbrev-ref HEAD。
- Working tree：
git status -sb。
- Untracked files：
git ls-files --others --exclude-standard。
- Changed files：
git diff --name-only（unstaged）和 git diff --name-only --cached（staged）；sizes 用 git diff --stat 和 git diff --stat --cached。
- 最新 release tag（可用时）：
LATEST_RELEASE_TAG=$(git describe --tags --abbrev=0 2>/dev/null || true)。
- Base reference：
- 优先使用 branch upstream：
BASE_REF=$(git rev-parse --abbrev-ref --symbolic-full-name @{upstream} 2>/dev/null || true)。
- 如果没有 upstream，尝试 remote default branch：
BASE_REF=${BASE_REF:-$(git symbolic-ref --quiet --short refs/remotes/origin/HEAD 2>/dev/null || true)}。
- 如果存在 base reference，计算 base commit：
BASE_COMMIT=$(git merge-base --fork-point "$BASE_REF" HEAD 2>/dev/null || git merge-base "$BASE_REF" HEAD 2>/dev/null || true)。
- Base fork point 之后的 commits（可用时）：
test -n "$BASE_COMMIT" && git log --oneline --no-merges ${BASE_COMMIT}..HEAD。
- 典型仓库 category signals；根据本地证据调整，不要假设每个路径都存在：
- Runtime 或 product behavior：
src/**, app/**, lib/**, packages/**, cmd/**, internal/**, server/**, client/**。
- Tests：
test/**, tests/**, spec/**, __tests__/**。
- User-facing examples、fixtures、templates 或 generated assets：
examples/**, fixtures/**, templates/**。
- Build、packaging、dependency 或 CI configuration：package/build manifests、lockfiles、workflow files、Dockerfiles、Makefiles 和 tool config files。
- Documentation with behavior impact：
README*, CHANGELOG*, docs/**, migration guides, API docs。
- Agent 或 repository policy metadata：
AGENTS.md, .agents/**, 其他本地 agent guidance files。
工作流
- 运行上述命令，不要询问用户。如果无法发现
BASE_REF、BASE_COMMIT 或 LATEST_RELEASE_TAG，继续执行；只有当不确定性影响 PR summary 时才说明。
- 如果没有 staged/unstaged/untracked changes，且没有
BASE_COMMIT 或 ${BASE_COMMIT} 之后没有 commits，简短说明未检测到代码变更，并跳过 PR block。
- 根据 touched paths 和 diff content 推断 change type，分类为 feature、fix、refactor 或 docs-with-impact。只有 diff 改变已发布 public APIs、external config、persisted data、serialized state 或 wire protocols 时，才标记 backward-compatibility risk。有
LATEST_RELEASE_TAG 时按它判断；没有 tag 时按已记录 compatibility policy 判断。
- 用关键路径（top 5）和
git diff --stat output 在 1-3 句内总结变化；明确说明 untracked files，因为 --stat 不包含它们。如果 working tree 干净但 ${BASE_COMMIT} 之后有 commits，用 commit messages 总结。
- 选择 description lead verb：feature ->
adds，bug fix -> fixes，refactor/perf -> improves 或 updates，docs-only -> updates。
- 建议 branch name。如果已经不在 default branch，保留当前 branch；否则按主要领域建议
feat/<slug>、fix/<slug> 或 docs/<slug>。如果无法发现 default branch，不要假装已经知道。
- 如果当前 branch 匹配
issue-<number>（仅数字），保留该 branch suggestion。只有在已知仓库托管平台支持 auto-closing syntax 时，才包含类似 This pull request resolves #<number>. 的 line；否则只提及 issue reference，不声称 auto-close。
- 使用下方模板起草 PR title 和 description。
- 只输出 "Output Format" 中的 block。
输出格式
结束任务时，除非任务属于记录的跳过条件，或用户说不需要，否则在简短状态说明后添加下面的 Markdown block。
# Pull Request Draft
## Branch name suggestion
git checkout -b <kebab-case suggestion, e.g., feat/add-login-flow>
## Title
<single-line imperative title; conventional commit prefix like feat:, fix:, chore: preferred>
## Description
<start with "This pull request adds/fixes/improves ..."; explain the background and what changed; use bullets for detail if needed>
保持精简：不要在 block 周围添加重复说明，也避免在 changes 和 description 之间重复细节。除非用户特别要求，否则不需要列出 tests。
