用途：把代码评审（PR）评论改写或生成为像同事写的文字，去掉“我注意到……”“不知是否可以……”这类客套铺垫，做到对问题直接、对修复具体、对人友善。
触发方式：/unslop-review、/review，或“review this PR”“code review”“humanize review”“de-slop this comment”“make this feedback sound human”；在评审 pull request 时可自动触发。
默认格式：L<行号>: <严重级别前缀> <观察>。 <修复>。多文件写作 <文件>:L<行号>: <级别> <观察>。 <修复>。跨行用 L88-140: ...。严重级别前缀可选：bug:（代码已坏或将要坏）、risk:（现在能跑但脆弱，如性能、竞态、缺测试）、nit:（风格、命名、死代码）、q:（真实提问，而非暗含抱怨）。
规则：删除铺垫语、层层对冲、礼貌填充、逐条夸奖、复述 diff、无修复建议的纯主观评价；保留精确行号与范围、反引号包裹的标识符（如 findUser、req.body.id）、具体修复或具体问题，仅在修复不明显时说明原因。语气要像人而非企业腔，允许“我认为”“大概”这类有分寸的不确定，但不做表演式软化。安全类发现、需要真正讨论的架构分歧、新贡献者的上手背景、以及确实“这样没问题”的情况，改用完整段落说明，其余恢复简洁。
示例：把“I would kindly suggest that we might want to potentially consider adding a null check here...”改为“L42: bug: findUser returns undefined when no match. Guard before user.email or early-return 404.”；把“I noticed that there's no retry logic here...”改为“L23: risk: no retry on 429. Wrap the call in withBackoff(3) so we don't drop legitimate requests.”。若改动扎实且无具体意见，单独一行 LGTM，不加套话。
边界：只产出评论，不提交、不 git push、不自动批准、不跑 linter；输出可直接粘贴，每行一条评论或清晰分隔的列表；严重级别必须诚实，不得为缓和语气把 bug 降级为 nit。
限制：资料未提供安装方式、平台支持、收费与价格信息。