关于 principle-build-the-lever
一项开发技能,主张非琐碎任务应优先制作可重复运行的工具,而非手工处理。它强调用可检查、可验证的确定性变更提升审查性。
主要功能
- 01为复杂工作编写脚本或 codemod
- 02先手动完成一个样例以摸清步骤
- 03重跑并对比以验证行为
- 04确保工具可安全重复运行
- 05将长期有用的工具提交到版本库
适用场景
- 01一致地应用重复代码修改
- 02生成重复结构的文件
- 03用可重复运行的查询分析数据
- 04围绕共享流程协调子 Agent
安装
复制下面的命令,在终端中运行。
$
npx skills add https:/ / github.com/ backnotprop/ pstack --skill principle-build-the-lever安装后在 Claude Code 中输入/principle-build-the-lever确认已加载。
详细介绍
构建杠杆
当工作并非微不足道时,构建一个能完成它的工具,而不是手动完成。
codemod、生成器或脚本每次都会以相同的方式完成工作,而且可以免费重新运行。这个工具是一份评审者可以阅读并重新运行以检查工作的产物。手动完成的更改只能通过重做来重新验证。确定性脚本能将“相信我”变成“运行这个”。
默认选择构建杠杆。只有当任务微不足道、只是几个一眼就能看出的明显改动时,才跳过。
- 先手动完成第一个单元,摸清做法,然后构建工具。在这个单元上重新运行工具,并与手动完成的版本做差异比较,以此证明工具有效。确保杠杆可以安全地重复运行。
- 编辑用 codemod 或脚本,重复性文件用生成器,分析用转储到 SQLite 的查询,验证用可重复运行的检查。
- 确定性的杠杆胜过分散任务。如果工具能一次处理所有单元,就自己运行它。不要把脚本能完成的工作分派给多个委派者手动处理。
- 将工作分派给子 Agent 时,把杠杆写成所有子 Agent 都会阅读的技能:将做法、验证约定和禁止触碰的边界写在同一份产物中。将其放在委派者的写入范围之外,避免他们悄悄修改约定。
- 应用这一原则会产出一个文件。如果你引用了它,但差异中没有 codemod、脚本、生成器或委派技能,那就说明你并未应用这一原则。
- 如果这项工作会超出当前会话,就提交这个杠杆。
衡量标准是任务是否微不足道,而不是是否重复。即使是一次性工作,只要杠杆能让工作可检查,也值得构建。根据 Laziness Protocol,构建能完成或证明任务的最小脚本,绝不要构建框架。
这与 Encode Lessons in Structure 不同;后者是将反复出现的指令变成持久的防护措施。这里关注的是眼前工作的吞吐量和可评审性。关于编写用于验证本身的脚本,请参阅 Prove It Works。
评论
支持 Markdown