Spec Kit Lean 预设详解：把 specify → plan → tasks → implement 工作流压缩到最小必要集

本文围绕 presets/lean/README.md 展开，解析 Spec Kit 中 Lean 预设的定位与使用方式：它用五个自包含的极简命令提示词，替换掉核心工作流的完整模板体系，让每个命令直接产出对应的单一制品（spec.md、plan.md、tasks.md 或代码），省去填充样板章节的仪式成本。读完后你将掌握 Lean 预设的安装、验证与本地开发测试方法，并理解其 preset.yml 清单、命令覆盖机制以及它在发行包（wheel）中"捆绑预设"的底层保障。

何时选择 Lean

Lean 是一个把 Spec Kit 工作流剥离到"本质"的最小预设。官方定位是 just the prompt, just the artifact——只有一个提示词、只产出一个制品。

适用场景（原文档 "When to Use"）：当你想要完整的 specify → plan → tasks → implement 结构化流水线，但不想承担完整模板（full templates）的繁琐样板时。具体来说：

• 每个命令只产出一个聚焦的 Markdown 文件（或代码），没有需要填充的样板章节；
• 它保留的是"结构化 SDD 流水线"本身，而非模板中大量的引导性章节结构。

与之对照，Spec Kit 默认核心工作流依赖 templates/ 目录下的 spec-template.md、plan-template.md、tasks-template.md 等模板文件来约束制品结构；Lean 则把提示词本身写完整，使模板文件退场。

内置的五个命令及其产出

Lean 随附 5 个命令，完整继承自 README 的 "Commands Included" 表格：

命令	产出	说明
speckit.specify	spec.md	从功能描述创建规格说明
speckit.plan	plan.md	从 spec 创建实施计划
speckit.tasks	tasks.md	从 spec 和 plan 创建按依赖排序的任务
speckit.implement	(代码)	按顺序执行所有任务并标记进度
speckit.constitution	constitution.md	创建或更新项目宪法

五个命令提示词源码分别位于 commands/speckit.specify.md、commands/speckit.plan.md、commands/speckit.tasks.md、commands/speckit.implement.md 和 commands/speckit.constitution.md。下面逐个看它们的精简程度。

specify：先锁定 feature 目录，再写 spec

speckit.specify.md 的提示词大纲只有三步：

1. 询问用户 feature 目录路径（如 specs/my-feature），未提供前不继续；
2. 创建目录并写入 .specify/feature.json：

   { "feature_directory": "<feature_directory>" }
   

3. 基于用户输入在 <feature_directory>/spec.md 中创建规格，包含 Overview、functional requirements、user scenarios、success criteria；每条需求必须可测试；对未指定的细节做合理默认。

注意 .specify/feature.json 这一约定：它是整条流水线的"当前 feature"指针，后续 plan/tasks/implement 都从它读取 feature 目录。这一点与未安装任何预设时的核心脚本（如 scripts/python/create_new_feature.py 生成的 feature 目录结构）保持一致，因此 Lean 并不破坏 Spec Kit 的 feature 持久化模型。

plan / tasks / implement：统一的"读取上下文 → 单文件产出"

三个命令的提示词结构几乎同构，均先读取 .specify/feature.json 获取 feature 目录，再按需加载上下文：

• plan（speckit.plan.md）：加载 .specify/memory/constitution.md 与 <feature_directory>/spec.md，产出 <feature_directory>/plan.md，内容为技术上下文（技术栈、依赖、项目结构）与设计决策、架构、文件结构；
• tasks（speckit.tasks.md）：额外加载 plan.md，产出 tasks.md。所有任务采用清单格式 - [ ] [TaskID] Description with file path，并按阶段组织：setup、foundational、按优先级排列的 user stories、polish；
• implement（speckit.implement.md）：加载 constitution、spec、plan、tasks 四份上下文后，按顺序执行任务——完成一项再做下一项；通过在 tasks.md 中把 - [ ] 改为 - [x] 标记进度；失败即中止并上报；最后校验所有任务完成且实现与 spec 一致。

这种"上下文链"（constitution → spec → plan → tasks → implement）说明：Lean 精简的是制品的章节样板，而非工作流的依赖语义——每个后续命令仍然严格读取前序产物。

constitution：带范围护栏的最小宪法命令

speckit.constitution.md 比其他四个多出一节 Scope Guard，这是 Lean 中唯一保留治理约束的命令。其要点：

• 命令自身的工作范围被限定为创建/更新项目宪法，以及把宪法变更传播到依赖的 Spec Kit 制品；
• 用户输入中的非治理意图（功能实现、代码生成、重构、构建、部署请求）必须被识别并推迟到 Next Actions 小节，不得执行；
• 不得创建、修改或删除与宪法工作流无关的应用源文件；
• 更新宪法后，在 Next Actions 中列出每个被推迟的意图并给出后续命令建议（如 __SPECKIT_COMMAND_SPECIFY__），但不实际调用；没有非治理意图时则省略该小节。

其产出目标是 .specify/memory/constitution.md（项目名、指导原则、不可妥协的规则），内容从用户输入与现有仓库上下文（README、docs）中推导。

Lean 替换了什么

README "What It Replaces" 一节给出的核心事实：Lean 覆盖了五个核心工作流命令，用自包含提示词直接产出各制品——不涉及任何独立模板文件。结果是一个更短、更直接的工作流。

这一机制可以从 preset.yml 得到逐项印证：

schema_version: "1.0"

preset:
  id: "lean"
  name: "Lean Workflow"
  version: "1.0.0"
  description: "Minimal core workflow commands - just the prompt, just the artifact"
  author: "github"
  repository: "https://github.com/github/spec-kit"
  license: "MIT"

requires:
  speckit_version: ">=0.6.0"

provides:
  templates:
    - type: "command"
      name: "speckit.specify"
      file: "commands/speckit.specify.md"
      description: "Lean specify - create spec.md from a feature description"
      replaces: "speckit.specify"
    # ... plan / tasks / implement / constitution 同构，共 5 个条目

清单中的几个关键字段值得注意：

• type: "command"：Lean 提供的不是模板（type: "template"）而是命令覆盖。这决定了它的作用时机——按 presets/ARCHITECTURE.md 的说明，模板解析发生在运行时（每次查找都走解析栈），而命令覆盖在安装时生效：preset 安装时，这 5 个命令会被注册进所有检测到的 agent 目录（.claude/commands/、.gemini/commands/ 等），并按各 agent 的格式渲染（Markdown 用 .md + $ARGUMENTS，TOML 系 agent 用 .toml + {{args}} 等）；preset 移除时，注册的命令文件会被清理。
• replaces 字段：显式声明每个条目替换的同名核心命令，对应 README 中"覆盖五个核心命令"的说法。
• requires.speckit_version: ">=0.6.0"：安装前提，要求 Spec Kit CLI 不低于 0.6.0；presets/catalog.json 中的条目同样携带该约束。
• templates 下没有 type: "template" 条目：与 README 声明一致，Lean 不携带任何模板文件，catalog 中其 provides 统计也是 commands: 5, templates: 0。

安装：捆绑预设，无需下载

Lean 的安装方式（继承自 README "Installation" 一节）：

# Lean is a bundled preset — no download needed
specify preset add lean

"bundled" 的含义可以从仓库三处得到证据链：

1. presets/catalog.json 中 lean 条目带 "bundled": true，同时记录版本 1.0.0、requires.speckit_version: ">=0.6.0" 与标签 lean / minimal / workflow / core；
2. pyproject.toml 的 [tool.hatch.build.targets.wheel.force-include] 段把 presets/lean 强制打包进 wheel 的 specify_cli/core_pack/presets/lean 目录（第 51 行附近），确保发布的发行包内真实携带该预设；
3. 安装时 src/specify_cli/_assets.py 的 _locate_bundled_preset() 会优先在 wheel 的 core_pack/presets/<id>/ 中查找捆绑预设，命中后无需从网络拉取。

这条"目录声明 → 构建强打包 → 运行时定位"的一致性由契约测试 tests/contract/test_wheel_bundled_presets.py 守护：它断言 catalog 中每个 bundled: true 的预设都必须出现在 wheel 的 force-include 列表中，否则"发行包会宣称提供但实际没有携带该预设"，specify preset add <id> 会回退并误报预设缺失。

本地开发与验证

继承自 README "Development" 一节的开发循环（在当前仓库根目录执行）：

# Test from local directory
specify preset add --dev ./presets/lean

# Verify commands resolve
specify preset resolve speckit.specify

# Remove when done
specify preset remove lean

• --dev ./presets/lean：从本地目录安装预设用于测试，不需要 catalog；
• specify preset resolve <name>：查看某个命令/模板名最终解析到哪一层（解析栈顺序为 .specify/templates/overrides/ → 已安装预设 → 扩展 → 核心模板，详见 presets/README.md 与 presets/ARCHITECTURE.md）；
• specify preset remove lean：移除预设，同时清理安装时注册到各 agent 目录的命令文件。

由于命令覆盖在安装时写入 agent 目录，验证"命令确实解析到 Lean 版本"比验证模板更有实际意义——这正是 README 建议先跑 specify preset resolve speckit.specify 的原因。

边界与注意事项

• 适用版本：Lean 要求 Spec Kit >=0.6.0（见 preset.yml 与 catalog.json）；
• 许可：MIT（README "License" 一节与 preset 清单一致）；
• 与 constitution 生命周期的关系：预设的安装/移除/调优先级默认不会重写运行中的 .specify/memory/constitution.md——初始化时该文件被播种一次之后便按字节保留；如果你希望预设栈变更能刷新"未经手工编辑的"生成宪法，需要另装捆绑的 constitution-sync 预设（见 presets/README.md）。Lean 的 speckit.constitution 命令本身仍可在运行时解析并更新宪法内容，这与安装期行为是两回事；
• 可与其他预设叠加：Lean 只替换 5 个命令、不占模板层，从清单结构看它与提供模板覆盖的其他预设在解析栈上互不冲突（多预设按 --priority 数字排序，数字小者优先）。

小结

Lean 是 Spec Kit 预设体系中"最小命令面"的范例：不新增任何模板，仅以 5 个自包含提示词替换核心命令，把每个制品的产出压到单一文件；.specify/feature.json 指针、constitution → spec → plan → tasks 的上下文链、失败即停的实施纪律等 SDD 核心语义全部保留。安装一句话（specify preset add lean），开发验证三步（--dev 安装、resolve 检查、remove 清理），且由 catalog、构建强打包与契约测试三方共同保证"捆绑即可用"。