mcpField
P
principle-sequence-verifiable-units

principle-sequence-verifiable-units

github.com/hachej开发160 次安装3 天前更新
代码仓库

关于 principle-sequence-verifiable-units

一项开发原则,要求将工作拆成小型可验证单元,每次检查通过后再继续。它还建议按证据顺序组织提交和 PR,便于审查者逐步验证。

主要功能

  1. 01将工作拆成可检查单元
  2. 02每次变更后验证再继续
  3. 03从干净基线开始
  4. 04按证明顺序排列提交

适用场景

  1. 01逐项检查迁移变更
  2. 02在重复编辑中定位故障
  3. 03呈现便于审查的提交序列

安装

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

$npx skills add https://github.com/hachej/boring-stack --skill principle-sequence-verifiable-units

安装后在 Claude Code 中输入/principle-sequence-verifiable-units确认已加载。

附带文件LICENSE

详细介绍

将工作拆分为可验证的单元

将工作按顺序拆分为多个小单元,每个单元结束时都处于可检查的状态;当前单元未通过检查前,不要继续。

原因: 在导致问题的单元中发现故障,定位起来成本很低。等一批工作做完才发现故障,问题就被掩盖了,而且你已经基于有问题的基础继续构建。将相同的单元按顺序组织成审阅者可以重放的交付内容,就能把“相信我”变成“看它先失败,再通过”。

执行。 在批量检查、迁移或任何一系列类似编辑中,每次更改后都先验证,再开始下一项。每个单元都包含一次前后检查:确认当前状态良好,进行一项更改,运行检查,然后继续。先将变更变基到干净的主干上,这样每次检查都是针对真实基线进行的。如果由工具执行编辑,逐单元检查几乎不费成本。仍然要运行检查。

交付。 按照能证明工作正确的顺序组织提交和 PR。典型顺序是先提交失败的测试,再在其上提交修复。其他叙事顺序包括:先做减法,再重塑;先记录基线,再实施处理;先搭好脚手架,再开发功能。每个提交都独立落地,整个顺序读起来就像一套论证。

这是对 prove-it-works 原则技能的顺序补充,后者确保每次检查都切实有效;也是对 build-the-lever 原则技能的顺序补充,后者让逐单元检查成本低廉。

评论

支持 Markdown