name: unslop-reviewdescription: ‘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: criticalsource: https://github.com/MohamedAbdallah-14/unslop/tree/main/plugins/unslop/skills/unslop-reviewsource_repo: MohamedAbdallah-14/unslopsource_type: communitydate_added: 2026-07-01license: MITlicense_source: https://github.com/MohamedAbdallah-14/unslop/blob/main/LICENSEUnslop 评审何时使用当你需要重写代码评审意见使其读起来像人类队友所写时使用此技能。去掉企业式 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”。审查拉取请求时自动触发。格式默认形式Lline: severity prefix observation. fix.严重性前缀可选但在严重性重要时请使用bug:— 代码已损坏或将会损坏risk:— 今天能用明天脆弱性能、竞态、缺少测试nit:— 风格、命名、死代码、“顺手改一下”q:— 真正的疑问不是隐含的抱怨多文件file:Lline: 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 calledgetUserwhich 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 theres 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。局限性仅当任务与上游来源和本地项目上下文明确匹配时使用此技能。在应用更改之前验证命令、生成的代码、依赖项、凭据和外部服务行为。不要将示例视为环境特定测试、安全审查或用户对破坏性或高成本操作批准的替代品。 
长河君 · 2026/9/29 3:28:53 · 阅读 1.2k unslop-review - SKILL
name: unslop-reviewdescription: ‘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: criticalsource: https://github.com/MohamedAbdallah-14/unslop/tree/main/plugins/unslop/skills/unslop-reviewsource_repo: MohamedAbdallah-14/unslopsource_type: communitydate_added: 2026-07-01license: MITlicense_source: https://github.com/MohamedAbdallah-14/unslop/blob/main/LICENSEUnslop 评审何时使用当你需要重写代码评审意见使其读起来像人类队友所写时使用此技能。去掉企业式 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”。审查拉取请求时自动触发。格式默认形式Lline: severity prefix observation. fix.严重性前缀可选但在严重性重要时请使用bug:— 代码已损坏或将会损坏risk:— 今天能用明天脆弱性能、竞态、缺少测试nit:— 风格、命名、死代码、“顺手改一下”q:— 真正的疑问不是隐含的抱怨多文件file:Lline: 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 calledgetUserwhich 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 theres 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。局限性仅当任务与上游来源和本地项目上下文明确匹配时使用此技能。在应用更改之前验证命令、生成的代码、依赖项、凭据和外部服务行为。不要将示例视为环境特定测试、安全审查或用户对破坏性或高成本操作批准的替代品。