review-pr 是来自 prefecthq/fastmcp 的一个技能，用途是评审 FastMCP 的 Pull Request。它要回答的核心问题是：这项变更是否应当被合并，并且需要给出关于预期行为与实现两方面的证据。按照官方说明，维护者、贡献者和智能体提交的草稿都使用同一套流程。
在建立范围阶段，需要阅读 AGENTS.md、开发指南中的贡献政策、issue 的完整讨论、相对合并基线的完整差异，以及此前的评审线程与回复，记录基线与头部的修订号，查找所有状态下的相关 issue 与 PR，并检查触及相同文件的开放 PR 是否存在重叠行或行为，即便它们没有关联该 issue。还要区分已发布行为、已在 main 上的修复以及相互竞争的提案；当提案竞争时，记录 issue 报告者、原始实现作者、维护者方向、正确性与覆盖范围，推荐应当保留的提案并保留已延续的署名；提交顺序和通过 CI 并不能决定胜出者，合理的重叠提案应称为冗余而非虚假。
在评判修复之前，需要先确立契约：依据协议、已发布文档、历史与维护者决定，说明 FastMCP 对所报告输入承诺了什么。现有代码与测试只是行为的证据，不足以证明该行为是预期的；一个复现脚本可以展示出乎意料的行为，却不能证明存在 bug；回归测试也可能断言错误的结果。变更需要分类为恢复契约的缺陷修复、有意的行为变更、公共 API 新增或修改、文档或测试，一个 PR 可以跨多个类别。要指出行为发生变化的既有输入，包括默认值和显式覆盖。bug 标题本身不能确立类别。在评估实现质量之前，先判断该行为与持续支持是否应属于 FastMCP。普通评审不确定性问题应依据协议、已发布文档、历史和既有维护者决定解决，并在既定契约内给出建议。仅通过测试不足以确立该契约。
设计意见归维护者所有。只有在调查后仍未解决、且会实质改变受支持行为或 FastMCP 承诺维护范围的具体产品或兼容性选择，才需要上报。需要指出受支持的场景、相互竞争的结果、既有权威为何无法裁定，以及推荐方向。普通的实现判断、命名偏好、推测性边界情况以及可通过进一步调查解决的不确定性，都不是停下来等待决定的理由。真正未解决的政策选择不是贡献者缺陷，不应仅因该选择未定就提交正式的 changes-requested 评审，也不应要求贡献者去获取或敲定它。一旦维护者选定方向，就按该方向评估实现。当预期行为已确立且修正很小时，应在授权范围内做局部修复，而不是提交 changes-requested 评审。正式的 changes 请求应保留给方向明显错误或行为需要重新思考的情况，并在维护者确定方向后说明具体的行为修正。
对于面向协议的变更（线字段、认证挑战、能力、错误或缓存语义），需要引用适用的规范修订版和规范性一手来源，区分协议要求或允许什么、SDK 实现或默认什么，以及 FastMCP 选择什么策略。仅有 SDK 支持不能确定框架策略，不应把协议提示强化为保证。
在追踪原因与兼容性时，要在上下文中阅读每个变更文件、其调用方、生产者与消费者以及共享抽象。对于缺陷修复，要说明因果归属：契约是 X，故障源于 Y，本补丁修复 Y。在接受新的框架行为之前，检查现有配置、扩展钩子和共享抽象。如果补丁在别处补偿，解释为何拥有该行为的层无法解决原因。搜索相同的缺陷模式并追踪受影响的工具、资源、模板和提示，使用规范组件标识。比较省略的默认值、显式覆盖、错误、序列化与受支持配置。说明哪些既有输入行为发生变化、为何必要，以及任何保留旧行为的迁移。补丁建议中应避免破坏性变更。检查 API 人体工学、文档，以及依赖最低版本是否支持新用到的 API；在声称兼容性时测试旧的最低版本，并保持锁文件变更范围可控。
独立验证行为时，对于缺陷修复，要用 python-tests 在未更改的基线和提议的头部上亲自运行回归测试，确认它因声称的原因失败，并断言预期的值与类型，而不只是存在某个结果。对于其他变更，用适当的检查验证承诺的行为。还要练习共享更改分支的相邻受支持路径。对于共享分发、安全边界或其他组件依赖的行为，需要获得独立的对抗性复核：给一个全新的智能体提供 PR 与要调查的路径，让它在一次性工作树中运行复现脚本，并保留已确认的发现。在实质性返工后重复该复核。记录实际运行的修订与检查；无法进行的验证仍属于待定证据。
在评估反馈与解决发现时，要用下面的命令一起获取 CI、评审摘要、内联线程与回复，并评估 CodeRabbit、Copilot、Codex 和维护者反馈的实质内容。在一次遍历中收集所有独立且有影响的发现，给出可触发的条件与后果；不要在没有新证据的情况下重复已解决或被有力反驳的发现。避免表面性的阻塞和推测性的范围扩大。在授权范围内，维护者修复应是对已被接受范围与设计、且接近就绪的贡献所做的局部收尾，包括有针对性的回归覆盖。维护者确定方向后，实质性的 API、协议、行为或架构返工仍由贡献者负责，应说明该工作而不是接管，即便启用了维护者编辑。对于小型修复，一起修复真正的缺陷、验证相邻行为、运行必需检查并推送。解决已验证的修复；如果授权发布，在拒绝某个发现时回复原因。不要无限迭代假设性后续事项。
跟随当前修订得出裁决。一次推送会使仅与旧头部绑定的证据失效。在任务内发布或更新后，利用宿主调度能力建立安静监控；仅在有意义的变化、决定、失败或完成时通知，并在最终报告后暂停。对于一次性评审，报告待定检查而不创建持续监控，除非被要求。如果无法进行持续监控，则在活动任务期间观察并说明该限制。检查失败的 CI 日志后再诊断或重试，区分断言、工作进程崩溃、依赖解析和基础设施故障。在基线上复现所谓无关的故障。分别报告范围与设计接受情况、实现正确性和剩余验证。当用户已授权且范围、设计与代码被接受时，带待定 CI 的批准可以是适当的；批准并不意味着可合并。待定 CI 无法解决未定的设计决定，流程门禁也不是代码缺陷。
GitHub 证据部分给出了两条命令：使用 gh pr view <number> --repo PrefectHQ/fastmcp 获取 baseRefOid、headRefOid、标题、正文、statusCheckRollup、reviews、comments、isDraft、labels；以及使用 gh api --paginate repos/PrefectHQ/fastmcp/pulls/<number>/comments。需要阅读评审线程与作者回复，而不只是摘要裁决。Codex 可能在不创建正式评审的情况下更新摘要 issue 评论，要匹配其报告的修订与完成状态。零条正式评审并不证明它没有运行。草稿可能不会触发评审。不要仅为满足轮询循环而标记就绪或请求评审。泛泛地请求人工评审不是具体缺陷，绿色 CI 也不能确立评审完成或解决兼容性决定。
除非用户授权更改，否则保持草稿状态。批准、发布与合并仍受 AGENTS.md 与现有授权约束。在授权合并之前，立即重新检查标题、正文、标签、头部、检查与分支保护；遵守所有草稿与 DNM 停止条件。
对于维护者实现社区 issue 的情况，把贡献者署名作为就绪检查的一部分：issue 作者经核实的共同作者 trailer 必须出现在实现提交和 PR 描述中。缺少社区署名属于 PR 准备未完成。维护者通常豁免：不要为另一位维护者标记缺少署名，也不要就此请求指导。常规反向移植保留现有社区署名，无需重新审计署名。在仅评审的工作中，报告适用的遗漏而不是编辑 PR。
无论选择哪种合并策略都要保留署名。对于 squash 合并，把精确的最终提交正文写入临时文件，包含 issue 链接以及 PR 描述和提交中的所有人类共同作者 trailer。检查它并通过 gh pr merge <number> --squash --body-file /tmp/merge-body.md --match-head-commit <reviewed-head> 显式传入，并加上任何已授权的合并标志。不要依赖 GitHub 默认的 squash 消息。对于 merge 或 rebase，确认带署名的提交会被保留。合并后检查落地提交并确认共同作者存在。这些步骤并不授权合并，也不规定合并策略。
裁决模板要求报告与变更规模相称，并明确以下事实：裁决（在 <head>、针对 <base> 是 ready for maintainer consideration / changes needed / maintainer decision needed / validation pending）；范围与设计（变更类别、承诺行为与支持来源、是否属于 FastMCP，以及是否仍需具体的维护者决定）；实现（补丁是否修复了因果层，有影响的缺陷或竞争提案选择）；兼容性（行为变化的输入、保留的相邻行为，以及任何迁移或发布约束）；验证（基线与头部的回归、相邻检查、对抗性结果或为何不需要、该修订下的 CI 与机器人状态，区分带待定 CI 的代码批准与可合并建议）；未决事项（仍有影响的发现、决定与待定检查）。
完成前检查：另一位维护者能否看出为何该行为可取、哪些既有行为发生变化、哪些声明已在报告的修订上被独立验证？如果任一答案缺失，就应限定裁决，而不是称 PR 已就绪。