detailed-pr-description

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Detailed PR Description

详细PR描述

Resolve the outcome

明确执行结果

Assessment: judge whether branch tests are strong enough; do not draft or update a PR body.
Draft: produce a proposed body locally or in the response; do not mutate GitHub.
Update/post: draft and update GitHub only when explicitly asked to update, edit, post, or publish.

Perform each requested outcome when combined. CLI access is never authorization to mutate a PR.

评估： 判断分支测试是否足够完善；不撰写或更新PR正文。
撰写： 在本地或响应中生成建议的PR正文；不修改GitHub内容。
更新/发布： 仅在明确要求更新、编辑、发布时，才撰写并更新GitHub上的PR内容。

若同时要求多个结果则逐一执行。CLI权限绝不代表拥有修改PR的授权。

Workflow

工作流程

Identify the PR and base. Prefer
```
gh pr view --json number,title,body,baseRefName,headRefName,url
```
; without a PR, compare against the user-provided or repository default base. Fetch before relying on stale refs.
Establish evidence from
```
git status --short
```
, diff stats and names, relevant commits, changed files, tests, docs, migrations, config, and generated artifacts. Treat
```
.context/
```
as scratch and restate any useful fact because it is untracked. Do not rely on chat or memory for behavioral claims.
Determine the problem, approach, outcome, deliberate exclusions, risk, compatibility, edge cases, operational gotchas, migrations, flags, cleanup, and reviewer focus. For close-review items, give a precise file/line reference and explanation. Every PR body must include one fenced excerpt of actual changed code, configuration, or documentation from the most review-critical hunk, capped at 15 lines; a link-only review section is insufficient.
Inventory affected and added tests. Run the narrowest reliable checks, then documented broader validation when feasible. Classify coverage as sufficient, partially sufficient, or insufficient; name regressions it catches, important gaps, and concrete follow-up tests. Never claim confidence from unrun or irrelevant tests.
Deliver only the authorized outcome:
- Assessment: report evidence and coverage judgment without creating a body.
- Draft: return the body or write
```
.context/pr-description.md
```
  ; never call
```
gh pr edit
```
  .
- Update/post: write
```
.context/pr-description.md
```
  , then use
```
gh pr edit <number> --body-file .context/pr-description.md
```
  . If posting fails, preserve the draft and explain why.

识别PR及基准分支。优先使用
```
gh pr view --json number,title,body,baseRefName,headRefName,url
```
命令；若无指定PR，则与用户提供的或仓库默认的基准分支进行对比。在依赖陈旧引用前先执行拉取操作。
从
```
git status --short
```
、差异统计及文件名、相关提交、变更文件、测试、文档、迁移脚本、配置文件和生成的工件中收集证据。将
```
.context/
```
视为临时目录，并重述其中有用的信息，因为该目录未被追踪。请勿依赖聊天记录或记忆来做行为相关的断言。
确定问题、解决方案、执行结果、刻意排除的内容、风险、兼容性、边缘情况、操作注意事项、迁移步骤、标志位、清理工作及评审重点。对于需要细致评审的内容，给出精确的文件/行号引用及解释。每个PR正文必须包含一段用围栏代码块包裹的实际变更代码、配置或文档片段，取自最关键的评审部分，最多15行；仅包含链接的评审部分是不充分的。
清点受影响及新增的测试。先运行最精准可靠的检查，若可行再执行文档中规定的更全面的验证。将测试覆盖率分为充足、部分充足或不足三类；说明其能捕获的回归问题、重要的覆盖缺口及具体的后续测试计划。绝不能从未运行或无关的测试中得出信心结论。
仅交付获授权的结果：
- 评估：报告证据及覆盖率判断，不生成PR正文。
- 撰写：返回PR正文或写入
```
.context/pr-description.md
```
  ；绝不调用
```
gh pr edit
```
  命令。
- 更新/发布：写入
```
.context/pr-description.md
```
  ，然后使用
```
gh pr edit <number> --body-file .context/pr-description.md
```
  命令。若发布失败，保留草稿并说明原因。

PR body

PR正文

For draft/update work, load

assets/pr-body.md.tmpl

unless the repository has a stronger template. The body must stand alone without chat or local notes. Prefer high-signal context; add screenshots, rollout, migrations, flags, performance, accessibility, security, or release notes only when relevant. Remove an empty section only when it genuinely does not apply; use

Not applicable

when omitting it could hide an important review dimension.

对于撰写/更新工作，除非仓库有更合适的模板，否则使用

assets/pr-body.md.tmpl

模板。PR正文必须独立完整，无需依赖聊天记录或本地笔记。优先保留高价值上下文；仅在相关时添加截图、部署计划、迁移步骤、标志位、性能、可访问性、安全或发布说明。仅当某部分确实不适用时才删除空章节；若省略该章节可能隐藏重要的评审维度，则使用“不适用”标注。

Quality bar

质量标准

Ground claims in code, tests, docs, commits, or command output; distinguish facts from assumptions and judgment.
Preserve the existing title and useful body content unless replacement is clearer.
Name behavior instead of saying “various fixes” or “improves behavior.”
Cite precise file/line references for close-review items. Include one actual changed excerpt in a fenced code block; it must be materially helpful and at most 15 lines.
Include failed, skipped, and unavailable validation with reasons.
Do not make unrelated code changes unless explicitly asked.

所有断言均需基于代码、测试、文档、提交记录或命令输出；区分事实、假设与判断。
保留现有标题及有用的正文内容，除非替换后更清晰。
明确说明具体行为，而非笼统表述“多项修复”或“改进行为”。
为需要细致评审的内容引用精确的文件/行号。包含一段实际变更的围栏代码块片段；该片段必须具备实质性帮助，且不超过15行。
说明失败、跳过及无法执行的验证及其原因。
除非明确要求，否则不进行无关的代码变更。

Final response

最终响应

Report the PR URL when one exists, whether the outcome was an assessment, local draft, or posted update, validation commands/results, and the bottom-line coverage assessment. If an authorized post failed, report the draft path.

若存在PR则报告其URL，说明执行结果是评估、本地草稿还是已发布更新，提供验证命令/结果，以及最终的覆盖率评估结论。若获授权的发布操作失败，报告草稿文件路径。