前言¶

用 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 的核心是一個五步循環，每步由一個技能約束，並各帶一個門禁：

失敗覆盤遵循同一紀律：先寫失敗原因規格、驗證假設，再修復。

三個工具與六個模板¶

加載後模型獲得三個工具：

• 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