unclebob/ub-mode

会写出看起来合理的代码，和会按工程纪律工作，是两回事。ub-mode 的做法是把一份技能文件放进 agent 的技能目录，让助手按 TDD、根因修复和确定性质量检查推进，而不是测试一过就宣布完成。

解决什么问题

你让 agent 增加一个功能或重构一个模块，它给出 diff，可能附带一些测试，然后说完成了。麻烦在于，这个循环里没有任何东西强迫助手质疑前提、控制函数复杂度、清除重复，或者检查测试是否真的覆盖了代码。装上 ub-mode 后，同样的请求会被带入分阶段流程：先让功能跑通，再用可量化的门禁把它做对，最后留下日志和有顺序的小提交。你得到的是一个按明确工程步骤塑造出来的改动，以及可以用工具核对的数字。

有什么不同

README 把流程分成三个阶段。第一阶段是一组工作原则：偷懒协议、基础思考、TDD、攻击前提、先减后加，以及领域建模、边界和类型纪律。第二阶段把这些想法变成门禁：每个函数的 CRAP 分数必须低于 10，重复代码的相似度必须低于 0.8，变异测试要覆盖未覆盖代码并杀掉存活变异体。第三阶段是实践：记日志、控制上下文窗口、清理 worktree，以及按顺序做小提交。

真正区分它的是质量门禁由独立工具计算，而不是交给模型自己判断。Crapper、Dryer 和 Mutator 是配套仓库，分别产出复杂度、覆盖率、重复度和变异测试结果；uml-viewer 则把组件、覆盖率、CRAP、变异分数和依赖方向可视化。这样一来，“做对”是一个可测量的步骤，而不是自我评价。代价是依赖：第二阶段是否有用，取决于你能否在项目里装好并运行这些配套工具。README 给出了技能文件的位置和阈值，但没有为每种语言或项目结构给出完整的端到端搭建说明。

谁值得试

适合已经在用 Claude、Grok、Cursor 等 agent 的开发者：你厌倦了审查那些忽略复杂度和测试质量的 diff，希望 agent 按可重复的 TDD 加重构流程工作。如果你本来就看重变异测试或 CRAP 指标，这个技能直接给出了可检查的阈值，也值得一试。反过来，如果你想要一个不依赖额外工具的独立提示词，或者你的项目没有现成方式运行这些分析器，它就不合适。只想快速生成样板代码的人也会觉得分阶段流程增加了额外负担。

使用条件与边界

文档里的安装方式是手工的：把技能文件复制到 agent 的技能目录，例如 ~/.claude/skills/ub-mode/ 或其他助手对应的目录，然后调用 /ub-mode 项目说明。README 列出了几个 agent 目录，但没有提供包管理器或一条命令安装。质量门禁依赖 Crapper、Dryer 和 Mutator Crapper Dryer Mutator；如果不运行它们，第二阶段就失去了可测量的依据。仓库元数据没有声明许可证，如果你要再分发或嵌入这个技能，需要留意这一点。README 对实操细节也讲得不多：没有解释各阈值之间如何相互影响、门禁失败后怎么处理，也没有说明技能是否能适配那些没有变异测试支持的语言。

HotRepo 点评

在 2026-10-26 的新项目榜上，ub-mode 共有 373 个 star，排第 18 名 项目。这是新项目榜上的单日快照，不是每日增长数据，而且 HotRepo 没有可比的历史记录，所以无法判断热度能否持续。只应把这个关注度当作一张快照。采用之前，先确认配套工具能否在你的技术栈上运行，因为这决定了技能里的质量门禁阶段是真能用，还是只是口号。