Spec Kit 落地实现指南:speckit-implement 如何按 tasks.md 驱动 Elsa 的代码实现

📅 发布时间:2026/9/27 7:47:44
Spec Kit 落地实现指南:speckit-implement 如何按 tasks.md 驱动 Elsa 的代码实现
后端工作流自动化流程编排低代码【免费下载链接】elsa-coreThe Workflow Engine for .NET项目地址https://gitcode.com/gh_mirrors/el/elsa-core点击查看免费下载本篇文章详解 Elsa 仓库中 Claude Code Skill 体系下的speckit-implement命令它是 Spec-Driven Development规范驱动开发工作流中负责“把实现计划真正落成代码”的执行器。读完本文你将掌握如何解析任务清单、执行前置/后置扩展钩子、按阶段推进 TDD 落地、处理并行任务与失败恢复并能在当前仓库的.specify/基础设施和specs/013-user-tasks实际案例中直接对照验证。一、speckit-implement 在 Spec Kit 工作流中的定位.claude/skills/speckit-implement/SKILL.md定义了一条名为speckit-implement的 Claude Code Skill其元数据声明namespeckit-implementdescription执行实现计划处理并执行tasks.md中定义的全部任务compatibility要求 spec-kit 项目结构存在.specify/目录disable-model-invocationtrue即该 Skill 不会被模型自发调用只能由用户显式触发/speckit.implement命令在完整 SDD 周期中它处于流水线的最后一环。.specify/workflows/speckit/workflow.yml定义的完整流程为specify → plan人工审查门→ tasks人工审查门→ implement即先产出规范spec.md、再产出计划plan.md、再产出任务清单tasks.md最后才由speckit-implement负责执行。当前仓库即为一个已初始化的 spec-kit 项目.specify/feature.json中记录了feature_directory为specs/013-user-tasks对应的实现任务清单见 tasks.md技术方案与架构见 plan.md。二、前置检查执行前的扩展钩子before_implementSkill 在开始任何工作之前会先检查项目根目录是否存在.specify/extensions.yml并读取hooks.before_implement下的钩子配置。当前仓库的 extensions.yml 注册了一个git扩展before_implement: - extension: git command: speckit.git.commit enabled: true optional: true prompt: Commit outstanding changes before implementation? description: Auto-commit before implementation condition: null钩子处理规则有三个要点容错跳过YAML 无法解析时静默跳过钩子检查不阻断流程。启用过滤enabled显式为false的钩子被过滤未声明enabled的钩子默认视为启用。不解析 condition钩子若有非空conditionSkill 直接跳过该钩子把条件求值留给 HookExecutor 实现绝不自行解读表达式——这是为了避免 Skill 与钩子执行器之间的语义重复。对于可执行的钩子按optional标志输出两种协议文本可选钩子optional: true输出Optional Pre-Hook区块包含 Command、Description、Prompt并提示用户可通过/{command}手动执行。当前仓库的speckit.git.commit钩子即属此类。强制钩子optional: false输出Automatic Pre-Hook区块与EXECUTE_COMMAND: {command}要求等待钩子命令执行完毕后再进入 Outline 步骤。若没有注册任何钩子或extensions.yml不存在则静默跳过直接进入主体流程。三、Outline 第一步运行前置检查脚本并解析路径Skill 主体流程的第一步是在仓库根目录运行.specify/scripts/bash/check-prerequisites.sh --json --require-tasks --include-tasks该脚本由 check-prerequisites.sh 实现参数含义如下参数作用--json以 JSON 格式输出FEATURE_DIR与AVAILABLE_DOCS--require-tasks强制要求tasks.md存在实现阶段必备--include-tasks将tasks.md纳入AVAILABLE_DOCS列表--paths-only只输出路径变量不执行校验--help/-h显示用法说明脚本核心逻辑是加载 common.sh调用get_feature_paths()解析仓库根、当前分支、特性目录等路径所有路径统一输出为绝对路径。校验FEATURE_DIR目录与plan.md文件必须存在--require-tasks模式下tasks.md也必须存在否则给出明确错误提示例如提示先运行/speckit.plan或/speckit.tasks。组装AVAILABLE_DOCSresearch.md、data-model.md存在即加入contracts/目录非空即加入quickstart.md存在即加入--include-tasks且tasks.md存在时再加入tasks.md。路径解析的优先级从 common.sh 的get_feature_paths()实现可以确认FEATURE_DIR的解析顺序为SPECIFY_FEATURE_DIRECTORY环境变量显式覆盖相对路径会被规范化到仓库根下.specify/feature.json的feature_directory键由/speckit.specify持久化写入当前仓库指向specs/013-user-tasks分支名前缀回退查找如分支004-fix-bug匹配specs/004-*目录。此外common.sh 还实现了check_feature_branch()分支名校验要求当前分支符合001-feature-name、1234-feature-name或20260319-143022-feature-name三种形态通过spec_kit_effective_branch_name剥离feat/之类单段前缀后再校验。非 git 仓库时只输出警告、跳过校验。四、检查清单状态PASS / FAIL 门禁若FEATURE_DIR/checklists/目录存在Skill 会扫描其中的全部清单文件如ux.md、test.md、security.md按行统计完成状态总条目匹配- [ ]、- [X]、- [x]的行已完成匹配- [X]或- [x]的行未完成匹配- [ ]的行。随后生成状态表并计算总体结论| Checklist | Total | Completed | Incomplete | Status | |-----------|-------|-----------|------------|--------| | ux.md | 12 | 12 | 0 | ✓ PASS | | test.md | 8 | 5 | 3 | ✗ FAIL | | security.md | 6 | 6 | 0 | ✓ PASS |PASS所有清单未完成项均为 0展示表格后自动进入下一步FAIL存在未完成清单则必须停下并询问用户是否仍要继续实现只有用户明确回答yes/proceed/continue才放行no/wait/stop则中止执行。这相当于实现阶段前的一道质量门禁用于阻止在需求、安全或可访问性尚未验收的情况下贸然写代码。当前specs/013-user-tasks的清单位于 checklists/包含 requirements、security、accessibility 三份门禁清单。五、装载实现上下文必须读与按需读确认门禁通过后Skill 会读取特性目录下的一系列文档作为实现上下文文档读取要求提供的信息tasks.md必需完整任务清单与执行计划plan.md必需技术栈、架构、文件结构data-model.md存在则读实体与关系contracts/存在则读API 规范与测试要求research.md存在则读技术决策与约束quickstart.md存在则读集成场景以specs/013-user-tasks为例plan.md 明确了技术栈C#nullable 与隐式 using 开启、主依赖Elsa 特性/模块基础设施、FastEndpoints、Mediator 通知、SignalR、EF Core 提供程序包、存储方案内存仓库 各数据库提供程序 VNext 文档存储适配器、性能量级每租户约十万级进行中任务与百万级终结任务以及硬约束不依赖 Elsa.Identity、不改通用 RunTask、任务与书签在失败与集群竞争下保持一致、受保护数据绝不通过摘要/搜索/实时通道泄露。六、项目设置验证忽略文件的检测与创建实现开始前Skill 会根据实际项目技术栈创建或校验各类忽略文件检测逻辑为git rev-parse --git-dir 2/dev/null成功即 git 仓库→ 创建/校验.gitignore存在Dockerfile*或 plan.md 提及 Docker → 校验.dockerignore存在.eslintrc*→ 校验.eslintignore存在eslint.config.*→ 校验其ignores配置覆盖所需模式存在.prettierrc*→ 校验.prettierignore存在.npmrc或package.json且要发布→ 校验.npmignore存在 terraform 文件*.tf→ 校验.terraformignore存在 Helm charts → 校验.helmignore。对已存在的忽略文件只追加缺失的关键模式缺失时则按检测到的技术栈写入完整模式集。SKILL.md 为各语言给出了推荐模式例如C#/.NETbin/、obj/、*.user、*.suo、packages/Node.js/TypeScriptnode_modules/、dist/、build/、*.log、.env*通用.DS_Store、Thumbs.db、*.tmp、*.swp、.vscode/、.idea/。当前仓库根目录已存在 .gitignore该步骤在此场景下主要做“校验并补齐”而非新建。七、解析 tasks.md阶段、依赖与并行标记Skill 从tasks.md中提取三类结构信息任务阶段Setup、Tests、Core、Integration、Polish任务依赖顺序执行 vs 并行执行的规则任务明细ID、描述、文件路径、[P]并行标记。[P]标记的任务在文件所有权不重叠的前提下可以并行运行。以 specs/013-user-tasks/tasks.md 为实例可看到完整的七阶段任务清单Phase 1 Durable specificationT001–T008产出 PRD、research、data-model、contracts、checklists、plan并把术语同步到CONTEXT.md与AGENTS.mdPhase 2 Core domain and workflow sliceT009–T020搭建src/modules/Elsa.UserTasks模块、状态机、内存仓库、UserTask 阻塞活动、书签投影与终结、定时协调器Phase 3 REST and realtime sliceT021–T027权限、DTO、光标搜索、claim/release/assign/priority 更新端点、异步 complete/cancel/retry 端点Phase 4 Guest invitationsT028–T032邀请签发、令牌哈希、过期、Data Protection 出站箱、限流验证端点、访客会话Phase 5 Persistence providersT033–T041EF Core 上下文与五个数据库提供程序SQLite/SQL Server/PostgreSQL/MySQL/Oracle及 VNext 文档存储Phase 6 Elsa StudioT042–T050Studio 模块、队列视图、详情页、操作交互、访客验证页Phase 7 Documentation and local gatesT051–T053模块文档、示例工作流、运行测试记录显示 2026-08-27 验证时 UnitTests 103/103、Persistence.ConformanceTests 123 通过。任务清单的复查记录也展示了未完成项的处理方式T017reconciler 修复逻辑缺测试、T026SignalR Hub 缺失、T041SQLite 部分未落地等被明确标注“Still open / Partially done”并说明理由部分属于 elsa-studio 独立仓库无法在本仓库闭环。这正体现了清单驱动实现中“如实标注进度、不虚报完成”的纪律。八、分阶段执行TDD、依赖与文件级协调Skill 按以下规则执行实现逐阶段推进每个阶段完成后才进入下一阶段尊重依赖顺序任务串行[P]并行任务可同时推进TDD 优先先执行测试任务再执行对应的实现任务文件级协调涉及同一文件的任务必须串行执行避免写冲突验证检查点每个阶段完成时先验证再继续。执行顺序的总体编排是先 Setup初始化项目结构、依赖、配置→先写测试再写代码为契约、实体与集成场景编写测试→Core 开发模型、服务、CLI 命令、端点→集成工作数据库连接、中间件、日志、外部服务→打磨与验证单元测试、性能优化、文档。在 Elsa 场景中可以对照src/modules/Elsa.UserTasks/Activities/UserTask.cs看到典型落地形态该阻塞活动通过context.CreateBookmark(new CreateBookmarkArgs { BookmarkName nameof(UserTask), Stimulus materialization, Callback ResumeAsync })挂起工作流并以ResumeAsync从工作流输入UserTaskStimulus中取出ActionKey、CompletionData、CompletedBy等字段写入类型化输出UserTaskResult后完成活动——这正是 plan.md 架构图里“Bookmark resumer → UserTask activity”一环的实现。九、进度跟踪与错误处理执行期间 Skill 要求每个任务完成后向用户汇报进度任何非并行任务失败即中止执行halt并行任务[P]失败则继续推进其余成功任务并单独汇报失败项提供带上下文的清晰错误信息便于调试无法继续时给出下一步建议完成任务必须在 tasks.md 中勾选为[X]保证任务清单与真实进度一致。任务清单中大量存在的[x]标记如 T001–T016、T018–T025 等即是这一规则在specs/013-user-tasks/tasks.md中的落痕。十、完成验证与后置钩子after_implement实现结束后Skill 执行完成验证核对所有必需任务已完成检查实现的功能与原规范spec.md一致验证测试通过且覆盖率达标确认实现遵循技术计划汇报最终状态与工作总结。若任务清单本身不完整或缺失SKILL.md 明确建议先运行/speckit.tasks重新生成任务清单。最后Skill 会再次检查.specify/extensions.yml中的hooks.after_implement钩子。当前仓库注册的是可选的speckit.git.commit提交实现变更输出Optional Hook区块并提供执行命令。处理规则与前置钩子完全对称YAML 损坏静默跳过、enabled: false过滤、非空condition留给 HookExecutor。十一、使用前提与适用边界以下几点是直接使用speckit-implement前需要明确的边界项目必须初始化 spec-kit 结构根目录需存在.specify/且feature.json或分支命名能解析出FEATURE_DIRplan.md 与 tasks.md 是硬前置check-prerequisites.sh --require-tasks下二者缺失会直接报错并提示先运行/speckit.plan、/speckit.tasksgit 分支命名有约束feature 分支需遵循数字前缀或时间戳前缀规范否则分支校验会拒绝执行钩子 condition 不在此 Skill 求值条件逻辑由 HookExecutor 负责Skill 只做过滤与协议输出本地仓库只读本文所述全部能力均围绕“查看、运行与配置”不涉及对当前仓库内容的修改建议。十二、小结从 Skill 到仓库实证speckit-implement的完整执行链可以概括为钩子检查 → 前置脚本路径解析 → 清单门禁 → 上下文装载 → 忽略文件校验 → 任务结构解析 → 分阶段 TDD 执行 → 进度/错误管理 → 完成验证 → 后置钩子。这套机制在当前仓库中几乎每个环节都有可对照的实体钩子配置在 extensions.yml路径解析与校验在 check-prerequisites.sh 与 common.sh完整工作流定义在 workflow.yml而最完整的“被实现对象”实例则是specs/013-user-tasks特性目录及其对应的 Elsa.UserTasks 模块。理解这一执行器也就理解了 Elsa 仓库中规范、计划、任务与代码之间的闭环关系。赞分享后端工作流自动化流程编排低代码【免费下载链接】elsa-coreThe Workflow Engine for .NET项目地址https://gitcode.com/gh_mirrors/el/elsa-core点击查看免费下载相关推荐Apache APISIX jwe-decrypt 插件实战基于 JWE 的授权请求头解密与内部加密 API 使用指南Apache APISIX jwe decrypt 插件实战基于 JWE 的授权请求头解密与内部加密 API 使用指南 jwe decrypt 是 Apach后端工作流自动化流程编排低代码深蓝词库转换 Speckit 实施指南基于 tasks.md 驱动规范开发的落地执行引擎深蓝词库转换 Speckit 实施指南基于 tasks.md 驱动规范开发的落地执行引擎 导读 .codebuddy/commands/speckit.imp桌面应用CLI开发工具Spec Kit 实战指南用 Specify CLI 落地规范驱动开发SDDSpec Kit 实战指南用 Specify CLI 落地规范驱动开发SDD Spec Kit 是 GitHub 出品的开源规范驱动开发Spec Dri开发工具CLI工作流自动化上一篇DiceDB混合云多云部署策略下一篇AgentScope扩展开发自定义元数据创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考