leaving-pr-comments
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseLeaving PR Comments
留下 PR 评论
Prefix every agent-authored comment left on the user's behalf with this GitHub
note callout:
md
> [!NOTE]
> 🤖 **<model> responding on behalf of <user>**
Actual comment starts here.Use the verified public name of the model that wrote the comment, and the
user's name or GitHub login.
If the harness does not expose a model name, use the harness name. Do not guess.
Before posting, check the entire comment, including quoted text and
attachments, for secrets and private details.
Keep the attribution inside the note and the actual reply outside it. The
context line must start with the robot emoji. Do not add a horizontal rule,
Setext underline, heading, signature footer, or a second attribution.
Apply this format to top-level PR comments, inline review comments, replies to
bots or reviewers, and written explanations used before resolving or
dismissing feedback. Do not add it to PR descriptions, commit messages, or text
the user explicitly asked to post verbatim without attribution.
Write the comment itself in a direct style:
- Lead with the conclusion.
- Cite the relevant code, behavior, check, or reproduction.
- Keep it concise and avoid filler, canned thanks, or status narration.
- Distinguish verified facts from judgment.
Preview the final Markdown before posting so quoting and blank lines render as
shown. After posting, verify that GitHub returned the comment or review URL.
Resolve a review thread only after its response was posted successfully.
代理代表用户发表的每条评论,都要以这个 GitHub note callout 作为前缀:
md
> [!NOTE]
> 🤖 **<model> responding on behalf of <user>**
Actual comment starts here.使用经确认的模型公开名称,以及用户的姓名或 GitHub 登录名。
如果 harness 未提供模型名称,则使用 harness 名称。不要猜测。
发布前,检查整条评论(包括引用文本和附件),确认其中不含机密和隐私信息。
将署名信息保留在 note 内,实际回复放在 note 外。上下文行必须以机器人 emoji 开头。不要添加水平分隔线、Setext 下划线、标题、签名页脚或第二条署名信息。
此格式适用于顶层 PR 评论、行内审查评论、对机器人或审查者的回复,以及在解决或关闭反馈前使用的书面说明。不要将其添加到 PR 描述、commit message,或用户明确要求逐字发布且不带署名的文本中。
评论正文采用直接风格:
- 先给出结论。
- 引用相关代码、行为、检查或复现步骤。
- 保持简洁,避免填充内容、套话式致谢或状态叙述。
- 区分已验证事实与主观判断。
发布前预览最终 Markdown,确保引用和空行按所示方式渲染。发布后,验证 GitHub 已返回评论或审查 URL。只有在回复成功发布后,才能解决审查线程。