SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场unslop-review

unslop-review

编程与开发

查看项目

更新于 10-16 06:04

技能介绍

用途

Unslop Review 用于改写或生成 PR 评审评论，使其听起来像队友写的，而不是礼貌引擎生成的。核心原则是：对问题直接，对修复具体，对人友善。

主要能力

  • 去掉客套开场：如“I noticed that...”“It seems like...”“It looks like to me...”
  • 去掉堆叠式模糊措辞：如“I was wondering if perhaps we might want to potentially...”
  • 去掉礼貌填充：如“I would kindly suggest...”“just a small suggestion...”
  • 去掉逐条赞美：如“Nice work on this function but...”“Great pattern, however...”
  • 去掉复述 diff：如“Here on line 42 you have a function called getUser which returns...”
  • 去掉没有修复建议的纯主观意见：如“This is bad”且无建议
  • 保留精确行号和范围
  • 保留反引号中的标识符：如 findUser、req.body.id
  • 保留具体修复或具体问题
  • 仅在修复不明显时保留“为什么”

使用方式

触发方式包括：/unslop-review、/review、“review this PR”、“code review”、“humanize review”、“de-slop this comment”、“make this feedback sound human”。在评审 pull request 时可自动触发。

默认格式：L<line>: <severity prefix> <observation>. <fix>.

严重级别前缀（可选，但在严重性重要时使用）：

  • bug: — 代码已损坏或将会损坏
  • risk: — 今天能工作，明天脆弱（性能、竞态、缺少测试）
  • nit: — 风格、命名、死代码、“顺便一提”
  • q: — 真正的问题，不是隐藏的抱怨

多文件格式：<file>:L<line>: <severity> <observation>. <fix>.

范围格式：当问题跨多行时使用 L88-140: ...

语气

人性化，而非企业化。例如用“This throws if X”，而不是“It may potentially be worth considering that this could throw under certain conditions.”。适度的不确定是可以的（“I think”“probably”），但表演式的软化不行。

自动清晰模式

以下情况使用完整段落，而非单行短句：

  • 安全发现（CVE 级别、认证、密钥）
  • 需要真正讨论的架构分歧
  • 为新贡献者提供的上手背景
  • 当答案确实是“this is fine”时

在这些情况下使用短段落，然后其余部分恢复简洁。

示例

差 → 好

差：I would kindly suggest that we might want to potentially consider adding a null check here as it could maybe lead to issues in some scenarios.

好：L42: bug: findUser returns undefined when no match. Guard before user.email or early-return 404.

差：Great work on this implementation! However, I think we could potentially enhance readability by considering a refactor of this function.

好：L88-140: nit: this function does validation, I/O, and mapping. Splitting them would make the happy path easier to follow. Happy to pair on a cut if helpful.

差：I noticed that there's no retry logic here which could be problematic.

好：L23: risk: no retry on 429. Wrap the call in withBackoff(3) so we don't drop legitimate requests.

差：This implementation leverages a robust caching strategy.

好：（删除——空洞的赞美。如果缓存确实有趣，具体解释为什么。）

批准

如果改动扎实且没有具体意见：单独一行写 LGTM。不要套话。

边界

  • 仅评论。不提交、不 git push、不自动批准、不运行 linter。
  • 输出可直接粘贴：每行一条评论，或清晰分隔的列表。
  • 严重级别必须诚实。不要为了软化信息而把 bug 降级为 nit。

限制

  • 仅当任务明确匹配其上游来源和本地项目上下文时使用此技能。
  • 在应用更改前，验证命令、生成的代码、依赖、凭据和外部服务行为。
  • 不要将示例视为环境特定测试、安全审查或破坏性/高成本操作的用户批准的替代品。