name: unslop-review
description: ‘Rewrites code review comments so they read like a human teammate wrote them. Cuts corporate-AI throat-clearing (“I noticed…”, “I was wondering if perhaps…”, “It might be worth considering…”). Each comment is direct: location, the issue, a concrete fix. Use when user says…’
risk: critical
source: https://github.com/MohamedAbdallah-14/unslop/tree/main/plugins/unslop/skills/unslop-review
source_repo: MohamedAbdallah-14/unslop
source_type: community
date_added: 2026-07-01
license: MIT
license_source: https://github.com/MohamedAbdallah-14/unslop/blob/main/LICENSE
Unslop 评审
何时使用
当你需要重写代码评审意见，使其读起来像人类队友所写时，使用此技能。去掉企业式 AI 客套开场（“I noticed…”、“I was wondering if perhaps…”、“It might be worth considering…”）。每条评论都直接了当：位置、问题、具体修复方案。当用户说…时使用
目的
重写或生成听起来像队友而非礼貌引擎的 PR 评审意见。对问题直接，对修复具体，对人友善。
触发方式
/unslop-review、/review、“review this PR”、“code review”、“humanize review”、“de-slop this comment”、“make this feedback sound human”。审查拉取请求时自动触发。
格式
默认形式：L<line>: <severity prefix> <observation>. <fix>.
严重性前缀（可选，但在严重性重要时请使用）：
bug:— 代码已损坏或将会损坏risk:— 今天能用，明天脆弱（性能、竞态、缺少测试）nit:— 风格、命名、死代码、“顺手改一下”q:— 真正的疑问，不是隐含的抱怨
多文件：<file>:L<line>: <severity> <observation>. <fix>.
范围：问题跨多行时使用L88-140: ...。
规则
去掉
- 客套开场：“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
getUserwhich returns…” - 没有修复建议的赤裸观点：“This is bad” 且无任何建议
保留
- 精确的行号和范围
- 反引号中的标识符：
findUser、req.body.id - 具体的修复建议或具体的问题
- 仅当修复方案不明显时才写"为什么"
语气
人性化，而非企业腔。“This throws if X” 而不是 “It may potentially be worth considering that this could throw under certain conditions.”。校准过的不确定性没问题（“I think”、“probably”）— 表演式软化则不行。
自动清晰化（使用完整叙述，而非一行式）
- 安全发现（CVE 级、认证、机密）
- 需要真正讨论的架构分歧
- 针对新贡献者的入职背景说明
- 当答案确实是"这样没问题"时
在这些情况下使用一个短段落，然后其余部分恢复简洁风格。
示例
差 → 好
差：
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。
局限性
- 仅当任务与上游来源和本地项目上下文明确匹配时使用此技能。
- 在应用更改之前，验证命令、生成的代码、依赖项、凭据和外部服务行为。
- 不要将示例视为环境特定测试、安全审查或用户对破坏性或高成本操作批准的替代品。
