用途 review-rfc 用于在工程 RFC 对外分享或获得接受之前，对 RFC 现状进行评审并给出报告。作者拥有决策权：RFC 只有在作者要求时才改动，改动时适用 create-rfc 中的写作规则；把报告发布到 PR 或 issue 是独立动作，需要单独授权。
资料收集 阅读 RFC 本身、RFC 约定与模板；找到发起请求（issue、笔记、早先决策）以及 RFC 主张所涉及的代码、文档和其他 RFC。若 RFC 存在未提交或近期编辑，应与上一版对比，编辑中删除的内容也属于评审范围。所有来源读完，或在报告中列为不可用，才算完成；缺少发起请求则无法做范围检查，应索取或报告该缺口。
检查项 主张核查：凡关于现有行为的陈述都是主张，包括 gcx 代码与框架能力、产品 API、文档以及 RFC 声称沿用的先例。逐条对照一手来源核验，并引用 file:line 或文档章节；重点看设计所依赖的框架特性、所引先例是否真如描述、设计依赖的每个 API 操作是否存在且行为符合需要。每条主张须被证实、被反驳或标记为不可核验。
范围漂移：把发起请求中的每项需求映射到 RFC，分为已覆盖、明确排除或推迟到点名的后续工作，其余均为发现项；RFC 自行增加范围却未说明理由也属发现项。每项需求都须有映射。
仓库规则：按 AGENTS.md 中的合规层级依次检查，点名设计涉及的每条规则并给出结论；仅当实现层规则（如测试门槛、退出码、输出注册）会改变设计时才报告。每条涉及规则都须有结论。
一致性：将每个示例、图、表和走查与其所说明的规则对照阅读：规则要求的每一步都出现在走查中；示例中的每个字段和标志都由规则定义，每条规则也都在示例中体现；重命名的概念全局一致；链接和锚点可解析。
已定与待定：对 RFC 称为已定的每个选择，检查其使能契约是否已确立；建立在未决问题上的已定选择属于发现项，需给出回退方案或归入待定问题。每个待定问题应说明如何解决。已定决策只有在新证据下才重开，并应点名该证据。
结构：新提案按顺序与模板章节对比；历史记录可按 RFC 约定保留原结构。各节各司其职：Drawbacks 说明代价，Rationale and alternatives 说明每个重大选择的替代方案及其代价，Prior art 说明沿用或背离的模式及各自教益。每条规则只有一个归属位置，状态放在 RFC 标题附近。此检查最后执行，成本最低。
旁路问题 部分发现依赖 RFC 无法引用的来源，或属于不应写入 RFC 的细节。应把这些细节排除在 RFC 正文和建议措辞之外，单独列出问题，供作者通过其他渠道提出；当修复依赖此类细节时，建议措辞只陈述设计所需的属性。
报告 按对设计造成的代价从高到低排序，每条写成作者无需重读来源即可行动的形式：作者决策（评审无法代做的选择，如范围问题和被新证据动摇的已定选择，给出建议及主要权衡）；修复项（被反驳的主张、规则违反和一致性缺陷，给出 RFC 位置、证据和建议措辞）；旁路问题（上述单独列表）；结构与编辑（最多几行）。结尾说明本次评审无法检查的内容及原因。