四个工作流

工作流是插件的入口。每个工作流都是需要你自己调用的 skill： 即使某句话听起来很像，Agent 也不会自行启动它。 在 Claude Code 里把 skill 当命令输入，例如 /harness-md:harness-design； 在 Codex 里写 $harness-design；在 Antigravity 里，在请求中写出 skill 的名字。

四个工作流遵守三条共同的规则。第一，仓库里看得出来的，Agent 自己去读； 看不出来的，一次问完。然后它起草完整的设计，每个决定都带一个默认值和理由， 你只需要批准一次，不用一个决定一个决定地回答。 第二，在你批准相应的设计之前，项目里不会新增或改动任何文件。 第三，批准设计只是同意它写到的那些文件。 向仓库之外发布内容、修改远端设置、删掉已经做好的东西、 放宽 Agent 可以自行做的事，每一项都要等工作流做到那一步时，再单独征得你的同意。

harness-design

产出项目的 HARNESS.md，或者修订已有的那份。

新项目从你的目标出发，已有项目从仓库现在的做法出发。 如果你贴进来的是 hub 里的文件， 它先按你的项目重写 Context 一节（这一节描述设计必须适应的条件）， 再看哪些章节的理由建立在原来的 Context 上，把这些章节重新考虑一遍。

产出是仓库根目录下的一份 HARNESS.md，已经通过校验器的检查。

harness-build

把 HARNESS.md 变成 harness：入口文件、知识文件、检查、权限文件等等。 这份文件可以是你一分钟前贴进来的模板，也可以是项目的锚定文档， 也就是长期留在仓库里、很少改动的那份设计记录。 项目里已经有 harness 时，工作流会把它改得与设计一致。

它一层一层地建。层是文件描述的 harness 的七个部分， 按章节的顺序依次是 Environment（运行环境）、Knowledge（知识）、Feedback （反馈）、Gates（检查关卡）、Authority（权限）、Completion（完成标准）、Entropy （防止漂移）。Invariants、Style 和 File Structure 不是层， 工作流把其中的每条规则交给能落实它的那一层。 如果设计要求的某件事在这个仓库里做不到，工作流会跳过这一项，报告冲突， 把其余的建完。

最后由你决定 HARNESS.md 是留作锚定文档，还是删掉。

harness-extract

读一个项目，写出描述它现有 harness 的 HARNESS.md。 这个项目可以是你自己的，也可以是你想学习的别人的项目。

结果描述的是 harness 现在的样子。凡是意图靠推测得来的地方，它会标明是推测。

harness-audit

诊断一个 harness 并报告发现，不改动任何文件。它检查三件事：

1. HARNESS.md 是否符合规范；
2. 设计和产物（实现设计的那些文件）在哪些地方已经对不上；
3. 按项目的 Context 来看，这份设计是否还合适。

每条发现都给出证据，并说明该改哪一边：改产物，还是改设计。