用途：review-quality-gate 是一个自检质量门，用于在格式化输出或交付结果之前，对已生成的每一条审查发现（finding）逐条校验，用来捕捉单遍审查中最常见的失败模式：误报、噪声和严重度失准。
适用时机：审查代理生成发现之后（Step 2.5）；DX 或 UX 审查技能产出发现列表之后；任何会产出供人阅读的可执行建议的技能。
检查清单（每条发现都要如实回答）：1. 是否可执行——作者能否采取具体动作，不能只说“考虑”“也许可以”“可以改进”而无具体修复方案；2. 是否读过周边代码——不只看 diff 片段，还包括完整函数、调用方、上方三行的守卫子句；3. 严重度是否校准——风格小问题不写“required”，SQL 注入不写“suggestion”；4. 文件路径与行号是否准确，需对照实际文件内容核对；5. 是否与 linter/formatter/类型检查器输出重复，工具链能自动发现的不要上报，应聚焦语义问题；6. 是否属实——重新在完整上下文中阅读函数，检查“bug”是否在别处已处理、未用导入是否用于类型注解、缺失空值检查是否由调用方守卫、竞态是否已被未注意的锁避免。
门规则：2 项及以上检查失败则整条丢弃；恰好 1 项失败则严重度降一级（required → suggestion，suggestion → nitpick）并注明失败项；0 项失败则原样交付。降级时附简短说明，例如“(Downgraded: severity recalibrated — style concern, not a correctness issue.)”。
输出：对全部发现跑完门后，在发现正文前给出简要汇总，列出审查条数、丢弃条数、降级条数、通过条数，并为每条被丢弃的发现给出一行原因，便于审计。
反模式：不要因为“看起来都没问题”就跳过门，必须机械地对每条发现执行；不要放行只说“consider”“might want to”而无具体修复的发现；不要为了放宽而虚增通过数；不要对既有问题（pre-existing issues）跑门，这类属信息性内容，直接绕过。
限制：资料未提供具体安装方式、平台、收费或价格信息。