正在打开每日关注
正在打开每日关注
作者每个 PR 都先用 /codebase-design 与 /zero-tech-debt 技能,借删除测试清理浅模块与多余抽象。
I don't push a single PR that doesn't use /codebase-design and /zero-tech-debt
mattpocock/skills prompt of the day: /codebase-design Take a look in the repo for shallow modules, applying the deletion test and look for candidates for deletion. Helps kill unnecessary abstractions.
是什么 Sahaj 声称自己提交的每个 PR 都必须经过 /codebase-design 和 /zero-tech-debt 两个技能的处理;引用的推文里,Matt Pocock 从 mattpocock/skills 仓库分享了 /codebase-design 的核心提示词:扫描仓库寻找浅模块(shallow modules),应用删除测试(deletion test),找出可删除的候选对象,从而消灭不必要的抽象。
核心设计 这条提示词把一条经典软件设计原则封装成 Agent 可执行的检查动作:浅模块指接口庞大而实际功能很少的模块(源自 Ousterhout《A Philosophy of Software Design》的思想),删除测试则要求追问「删掉它会发生什么」——若没有任何实质影响,就该删。/zero-tech-debt 从命名看承担技术债清理职责。两者的共同点是把抽象的工程品味转化为每次提交都会触发的标准化审查流程。
关键洞察 价值不在单个提示词的措辞,而在工作流纪律:让每个 PR 通过同一道代码质量关卡,把「依赖个人自觉」变成「依赖可复用的技能资产」。技能库因此成为可分享、可迭代的工程文化载体。
边界与风险 「零技术债」的命名略有夸大——技术债本质是权衡而非纯粹恶物;删除测试需要人对模块未来意图做判断,Agent 只能提供候选,不能替代架构决策;极端执行可能误删为后续功能预留的脚手架。