pr-code-review-and-quality

PR 代码审查与质量

审查所请求的更改在正确性、可读性、架构、安全性和性能方面的表现。根据仓库规范和具体风险评估改进；追求完美或个人偏好不是合并的必要条件。

PR 目标： 必须由用户提供 PR 编号、owner/repo#number 或 URL，也可使用先前明确提及的目标。不要根据当前分支推断目标，也不要自行选择一个未合并的 PR。如果用户未提供目标，请询问。

输出规则： 用户明确调用此技能的 GitHub 发布工作流时，即表示授权发布一条 COMMENT 审查。不要再次询问。发布后，报告审查 URL 和一段摘要。自动选择技能或一般性的 PR 检查请求不代表授权发布；遵循明确提出的仅本地或只读请求。将已确定的交付选择传递给任何委派对象。

目标与授权

根据用户输入、已确认的对话上下文，或对话中先前明确提及的 PR，确定所有者、仓库、PR 编号和 head SHA。只有目标仍不明确时才询问。

使用上述输出规则确定的交付选择。审查期间不要修改实现代码。

证据与覆盖范围

检查 PR 意图、差异和相关 CI 结果。根据需要阅读已更改的文件、调用方和测试，以评估行为。根据风险选择阅读顺序和深度。对于大型更改，按连贯的部分分组审查，并说明任何未完整覆盖的部分。

使用 criteria.md 检查五个评估维度和团队标准。对于涉及安全的更改，加载 security-checklist.md；涉及性能时，加载 performance-checklist.md。

评估作者执行的检查是否足以证明更改后的行为。缺少证据时，进行有针对性的验证；如果没有新更改、失败或尚未解决的问题，不要重复已通过的检查。

发现项

统一使用以下严重程度标签：

前缀	含义
无前缀	必须更改
Critical:	阻止合并的安全漏洞、数据丢失或功能故障
Nit:	可选的轻微风格偏好
Optional: / Consider:	建议改进
FYI:	作者尚未了解的相关信息

每条发现都必须有具体证据、有用的文件/行号引用，以及对影响的说明。省略赞扬、对代码的复述和推测性问题。如果没有剩余发现，简洁地说明审查结果无问题。

交付

经授权发布时，使用 github-delivery.md。提交一条 event 为 COMMENT 的审查；绝不要使用 APPROVE 或 REQUEST_CHANGES。行内评论必须锚定到已审查的差异；其他发现应写在摘要中。遵循用户/仓库的署名政策。

完成意味着已审查所请求的范围，并在获授权的渠道上交付发现，同时说明验证方面的限制。通过 GitHub 交付时，核实已提交的审查并报告其 URL。出现新提交后，使用 re-review.md 评估差异，不要重复先前的发现。