前言¶
用 dsh（DeepSeek Harness）这类“一切皆插件”的 harness 跑编码任务时，常见的问题不是模型不会写代码，而是它拿到需求就直接开写：需求模糊时实现方向跑偏，返工成本最高；“我假设”被当成事实，方案建立在流沙上；实现阶段做得太多，或者范围越滑越远。把规范写进系统提示词是一种做法，但约束停留在“自觉”层面，缺一道硬性门禁。
keel（龙骨）的思路是：先写规格、先验证假设，规格通过门禁之前不动手实现；实现中用规则防过度工程、用变更请求防范围蔓延；交付前逐条审计验收标准。纪律由技能约束 agent 行为、由工具做确定性检查，不依赖人的自觉。
下面介绍这个插件的构成、安装和用法。
这是什么¶
keel 是一个规格驱动开发（spec-driven）纪律技能包，由 GitHub 用户 JohnXu22786 维护，MIT 许可证，当前版本 1.0.0。它以技能 + 工具 + 模板的形式约束 agent 编码行为，为 dsh 等插件化 harness 提供自包含接入，也可以脱离 harness 用裸 CLI 独立使用。仓库关键词：dsh-plugin、spec-driven、spec-first、skill-pack、keel。
五步纪律循环¶
keel 的核心是一个五步循环，每步由一个技能约束，并各带一个门禁：
| 步骤 | 技能 | 动作 | 产物 | 门禁 |
|---|---|---|---|---|
| 1 Anchor | keel-anchor | 三个边界问题：做什么、不做什么、成功长什么样 | 三句话 | 三句均可验证 |
| 2 Spec | keel-spec | 按任务规模选模板，生成规格 | SPEC.md | keel_review 零错误 |
| 3 Probe | keel-probe | 登记假设、标记风险、优先验证高风险 | ASSUMPTIONS.md | 所有 [High] 假设已解决（KEEL-0303 强制） |
| 4 Build | keel-build | 按规格实现，遵循十条规则与范围护栏 | 代码 | 规格冻结，变更走变更请求 |
| 5 Audit | keel-audit | 逐条核对验收标准、记录偏差与复盘 | AUDIT.md | 无未处理 ❌（KEEL-0403 强制） |
失败复盘遵循同一纪律：先写失败原因规格、验证假设，再修复。
三个工具与六个模板¶
加载后模型获得三个工具：
keel_catalog：列出技能与模板，是路由入口；keel_spec：从模板生成规格类文件，参数为 template/path/fields，任一字段缺失即拒绝整个调用；keel_review：审查 SPEC/ASSUMPTIONS/AUDIT 文件，输出带规则 ID 与行号的报告。
模板共六个（含变体），按任务规模选：
spec.minimal：微型任务；spec：标准任务；spec.feature：大型任务；assumptions：假设登记，含风险等级与验证结论；audit：验收审计表，含结果、证据、偏差、复盘；change-request：规格冻结后范围变更的唯一入口。
安装与启用¶
keel 自带 dsh.bundle 清单（cordis.patch.yml，由 package.json 的 dsh.bundle.patch 字段引用），一条命令即可安装并激活：
dsh plugin --profile demo add github:JohnXu22786/spec-driven
bundler 会向 profile 插入插件行（name: keel），dsh 解析包入口 src/index.ts，加载时注册三个工具与五个技能。
也可以不走 bundle，手动通过 cordis.yml patch 本地加载：把插件目录放入项目或复制到任意位置，创建 patch 指向插件入口（可复制仓库根目录的 cordis.example.yml 修改）：
- insert:
- id: keel
name: '/absolute/path/spec-driven/src/index.ts'
然后启动 harness 并加载 patch：
dsh web --patch ./cordis.yml
更多集成细节（加载、注册接口、三种加载技能方式、卸载与重载）见仓库的 docs/INTEGRATION.md。
配置¶
配置经宿主 patch line 的 config 字段传入，无 harness 时使用默认值。三个配置项：
strictness：relaxed | strict，strict 将警告升级为错误；requireAssumptions：审查 spec 时要求同目录存在 ASSUMPTIONS*.md；maxFindings：每份审查报告的 findings 上限，取值 1–1000。
非法配置在加载时失败，错误信息包含修复指引。各配置项的默认值在资料中未列出，接入前以仓库文档为准。
裸 CLI：脱离 harness 使用¶
没有 harness 也能用，直接以 Node 运行：
node src/cli.ts catalog
node src/cli.ts scaffold spec SPEC.md "--title=Example" "--goal=Goal" "--in_scope=- behavior" "--out_of_scope=- not doing" "--requirements=- R-01" "--acceptance=- AC-01" "--verification=command"
node src/cli.ts review SPEC.md
三个子命令分别是：catalog 列出技能与模板，scaffold spec 从模板生成规格文件，review 审查规格文件。含空格的取值必须加引号（如上）。
review 无错误时退出码 0，有错误时退出码 1，因此可以直接用作 CI 门禁。
开发与自检¶
npm test # node --test 全部测试（零测试依赖）
npm run typecheck # tsc --noEmit
npm run cli # 裸 CLI
keel 零运行时依赖，npm install 只安装开发期类型包（typescript、@types/node）。运行测试与类型检查需要 Node ≥ 22.18（package.json 的 engines 字段要求 node >=22.18.0）。
文档与示例¶
- docs/METHODOLOGY.md：方法论、十条反过度工程规则、范围蔓延护栏、KEEL-* 审查规则清单；
- docs/INTEGRATION.md：dsh 集成细节；
- docs/PLANNING_BRIDGE.md：向规划/任务拆解技能桥接；
- examples/：正反例，演示审查引擎的 findings。
适用场景与注意¶
适合谁：
- 在 dsh 等插件化 harness 里跑编码任务，希望 agent 先立规格、验证假设，而不是直接开写；
- 想约束 agent 的过度工程与范围蔓延，且不满足于只靠提示词约束；
- 需要把规格审查接进 CI（review 的退出码可作门禁）；
- 任务规模从微型到大型都有对应模板可选。
注意：
1、运行环境需要 Node ≥ 22.18；
2、插件以当前 dsh 进程的权限运行，安装前应检查源码与许可证（MIT，见仓库 LICENSE 文件）；
3、安装命令中的 –profile demo 按你的实际 profile 替换；
4、keel 约束的是流程与规格质量，写出来的代码仍按常规做评审。
结尾¶
keel 把“先写规格、再写代码”从口号落成技能、工具与门禁：五步循环约束 agent 行为，keel_review 提供带规则 ID 与行号的确定性审查，规格冻结后的变更收口到 change-request。如果你在 dsh 里跑编码任务、苦于方向跑偏与范围蔓延，可以按上面的命令接入试试。
- 目录页：https://www.skillhub.cn/plugins/JohnXu22786/spec-driven
- GitHub：https://github.com/JohnXu22786/spec-driven
