mcpField
R
roast

roast

github.com/petr-korobeinikov测试与质量191 次安装15 周前更新
代码仓库

关于 roast

roast 是用于批判性审查文件、计划、设计或系统行为的技能，面向希望发现实际缺陷的用户。它要求依据目标和具体证据指出问题，不负责润色或改写。

主要功能

  1. 01依据目标设定审查标准
  2. 02按优先级查找问题
  3. 03引用具体位置或复现行为
  4. 04按影响程度整理发现
  5. 05只提供批评，不提供改写

适用场景

  1. 01检查计划是否违背自身目标
  2. 02定位文档或设计中的具体缺陷
  3. 03依据复现结果评估系统行为

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/petr-korobeinikov/skills --skill roast

安装后在 Claude Code 中输入/roast确认已加载。

详细介绍

roast

找出产物真正的问题， 而不是它哪里还能更漂亮。 以它自己的目标为标准， 并指出它具体在哪些地方未达标。

不适用场景

  • 润色或校对。
  • “这样看起来对吗？”之类的验证请求—— 这类请求属于评审，而不是 roast。
  • 改写—— roast 负责批评， 不负责产出新版本。

输入

开始前先确定目标：

  • 文件或文件中的某个章节 → 通读全文。
  • 对话中粘贴的片段 → 引用时把片段原文贴出来。
  • 计划、想法或设计 → 梳理用户陈述的主张和 范围。
  • 图表、截图或视觉产物 → 描述你所指的视觉区域 （例如“右上方的面板”、 “图表中的第三个步骤”）， 而不是行号。
  • 正在运行的系统或行为 → 通过复现来引用—— 运行的命令、 输入、 观察到的输出。

如果目标跨越多个产物 （整个仓库、多个文件、含糊的“我们的流程”）， 请先让用户缩小范围。

什么算作问题

一个问题由三部分组成：

  • 位置 — 指向具体的行、 章节、 主张或行为。
  • 问题所在 — 引用或转述相关内容，然后明确指出问题。
  • 影响 — 用一句话说明后果： “缺少这个，X 就会出错”， “这会导致 Y 得出错误结果”。

如果无法清楚说明这三点， 就不算问题—— 删除它。 这能避免生造问题。

流程

  1. 通读产物全文，明确评判标准。 按以下顺序：

    • 明确标准 — 产物本身明示的目标、 规则、 范围和示例。 若有，则照此采用。
    • 隐含标准 — 若没有明示标准，则根据产物内容 和上下文，推断它显然试图实现的目标。 在 roast 开头用一句话说明推断出的标准， 以便用户纠正。
    • 询问 — 如果标准确实含糊不清， 开始前先问用户一个问题： “它想实现什么目标？”

  2. 按以下优先顺序查找问题。 完成当前层级后，再检查下一个：

    1. 自相矛盾 — 产物在哪些地方违反了自己的规则？
    2. 空洞主张 — 没有提供实现机制的指令或规则 （“确认 X”，却没有方法； “始终执行 Y”，却没有步骤）。
    3. 违反所示规则的示例。
    4. 产物自身范围内未处理的边缘情况。
    5. 错误的环境假设 — 假设用户有 Git 仓库、 网络访问、 特定操作系统、 特定工具，却没有明说。
    6. 原则隐含要求但缺失的功能 — 产物明示的立场在逻辑上要求具备， 却没有提供的内容。
    7. 风格和冗余 — 优先级最低， 只有在实质性问题都检查完后才纳入。

  3. 按影响对问题分类，而不是按查找类别分类。

    • 实质性 — 产物未能实现其明确承诺的内容， 或关键机制失效。
    • 功能缺口 — 规则不明确、 脆弱， 或只有靠猜测才能执行。
    • 次要 — 冗余、 味道不佳， 或不影响正确性的清理事项。

    第 2 步中的查找类别只是搜索辅助， 并非严重程度标签。 自相矛盾（类别 1）带来的影响可能只是表面问题， 因此可以归为次要； 冗余（类别 7）如果会积极误导用户， 也可能是实质性问题。

  4. 引用具体内容。 对于每个问题， 指出相关行、章节或段落。 如果问题出在原文措辞上，就引用产物原文。

  5. 只列出问题。 不要在 roast 中提出修复方案。 最后用一行文字询问用户要处理哪些问题， 只有在范围确实不清楚时—— 才提出一个澄清问题。

规则

  • 直截了当。 不要用“这很不错，但是”之类的铺垫。 不要用委婉的限定语。 如果有问题， 就直说。
  • 按照产物自身的标准来评判。 不要引入外部偏好或风格标准； 应根据产物自身陈述或暗示的目标、 范围 和规则来评判。 **例外：**事实错误—— 语法错误、 虚构的命令或 API、 对工具 / 规范 / 系统实际运作方式的错误描述—— 无论产物是否对此表明立场， 都应指出。 事实本身就是评判标准。 对某项说法存疑时， 先核实再指出 （或决定不指出）。
  • **引用原文，不要改述，**尤其是措辞存在问题时。
  • 不要把批评和实现混在一起。 先批评，修复另开一轮。
  • 如果没有实质问题，就直说。 不要为了显得全面而杜撰问题。
  • 有问题时，不要在批评之后附带一段安慰式总结。 如果指出了问题， 不要以“但总体而言，这很不错”收尾。 如果产物完全没有问题， 可以用一句中性的话说明这一点—— 参见 Reporting。
  • 自我批评：提高审视力度。 如果产物是你（助手）在本轮对话中写的， 就当作是陌生人写的来审视。 本轮对话中的推理已经替你的选择辩护， 这会让你不自觉地放宽标准。
  • 根据产物规模调整。 短产物就简短批评。 对于长产物， 按严重程度列出最重要的问题， 不要逐一罗列所有情况。 每项问题控制在 2–3 句话； 用户可以在后续询问更多细节。

报告格式

输出结构：

  1. （可选）用一行说明你审阅的内容及审阅范围。
  2. 实质性问题——编号列出，每项附上引用。
  3. 功能缺陷——编号列出，每项附上引用。
  4. 轻微问题——编号列出，每项附上引用。
  5. 用一行收尾——询问用户希望处理哪些问题，或提出一个澄清问题。

没有问题的严重程度类别应省略。 如果产物完全没有实质性问题，用一行说明，然后结束。

问题示例格式

问题的格式如下：

  1. 示例违反了自身规则。 产物将 aqua-first 列为硬性规则 （Hard rules，规则 3）， 但第 122–124 行的示例代码块却展示了一个属于 aqua 注册表的工具的 cargo: 条目—— 这会让读者学到错误的做法。

以下三点缺一不可：

  • 引用依据—— Hard rules，规则 3，第 122–124 行；
  • 证据—— 规则与示例之间存在明确矛盾；
  • 影响—— 读者会学到错误的做法。

如果缺少其中任何一点， 就回去补上， 或者删掉该问题。

评论

支持 Markdown