后端工作流自动化流程编排低代码【免费下载链接】elsa-coreThe Workflow Engine for .NET项目地址https://gitcode.com/gh_mirrors/el/elsa-core点击查看免费下载本指南围绕 elsa-core 仓库中.agents/skills/speckit-plan/SKILL.md所定义的实施规划技能展开系统讲解 spec-kitSpeckit体系下的/speckit-plan命令如何把一个特性规格feature spec逐步转化为可落地的实施计划implementation plan。读者将掌握该工作流的完整执行链路——包括前置钩子检查、setup-plan.sh环境初始化、Constitution 门禁评估、Phase 0 研究与 Phase 1 设计产出物以及如何结合仓库中.specify/目录的真实脚本与模板复现这一流程。一、speckit-plan 是什么AI 驱动的实施规划技能在 elsa-core 仓库中.agents/skills/speckit-plan/SKILL.md是一份面向 AI Agent 的技能定义skill definition声明了名为speckit-plan的技能执行基于 plan 模板的实施规划工作流生成设计产物design artifacts。它隶属于仓库内一整套以.specify/为根目录的 spec-kit 项目结构该结构还包含speckit-specify、speckit-clarify、speckit-tasks、speckit-implement、speckit-checklist、speckit-analyze等一系列相邻技能见.agents/skills/目录共同构成规格→计划→任务→实现→检查的完整 AI 协作闭环。这份技能文档的实际价值在于它不是抽象理念而是与仓库内真实脚本、模板一一对应的可执行指令。文中的每一步都能在.specify/目录中找到具体实现例如环境初始化脚本.specify/scripts/bash/setup-plan.sh计划模板.specify/templates/plan-template.md团队宪法.specify/memory/constitution.mdAgent 上下文更新脚本.specify/scripts/bash/update-agent-context.sh。二、前置检查扩展钩子Extension Hooks/speckit-plan执行的第一步并非直接规划而是检查项目根目录是否存在.specify/extensions.yml。该文件用于注册可扩展命令钩子规划流程中涉及两类钩子before_plan 钩子在正式规划Outline之前触发after_plan 钩子在规划结束、生成报告之后触发。文档对钩子处理规定了严格的判定规则若.specify/extensions.yml不存在或无法解析为合法 YAML则静默跳过钩子检查继续正常流程钩子条目中enabled显式为false的被过滤未显式声明enabled字段的默认视为启用Agent不得自行解释或求值钩子中的condition表达式没有condition字段或为空的钩子直接视为可执行定义了非空condition的钩子则跳过把条件判定留给 HookExecutor 实现每个可执行钩子按optional标志输出不同格式可选钩子输出 Optional Pre-Hook 提示块含Command、Description、Prompt、To execute强制钩子则输出 Automatic Pre-Hook 块并直接执行EXECUTE_COMMAND且必须等待钩子命令结果后才进入 Outline。仓库中实际注册的钩子配置位于.specify/extensions/git/extension.yml对应的 Git 扩展模块在.specify/extensions/git/README.md中有完整说明。该扩展为各阶段注册了钩子例如before_constitution触发speckit.git.initialize初始化仓库、before_specify触发speckit.git.feature创建特性分支而before_plan、before_tasks、before_implement等阶段则注册可选的speckit.git.commit提交未完成变更。这说明钩子机制被用于把 Git 分支生命周期无缝织入规划工作流。三、Outline规划主流程的五步骨架1. Setup运行环境初始化脚本从仓库根目录执行.specify/scripts/bash/setup-plan.sh --json并以 JSON 格式解析输出中的四个关键变量FEATURE_SPEC特性规格文件路径、IMPL_PLAN实施计划文件路径、SPECS_DIR特性规格目录、BRANCH当前分支名。对照.specify/scripts/bash/setup-plan.sh的源码可以看到该脚本的完整行为支持--json、--help/-h参数第 11-19 行加载公共函数库common.sh解析特性路径第 26-32 行当feature.json未固定已有特性目录时会校验当前分支是否符合特性分支命名规范第 36-38 行确保特性目录存在mkdir -p第 41 行从模板解析逻辑resolve_template找到 plan 模板并复制到IMPL_PLAN第 43-52 行若模板缺失仅给出警告并创建一个空的 plan 文件兜底JSON 模式下优先用jq输出{FEATURE_SPEC, IMPL_PLAN, SPECS_DIR, BRANCH, HAS_GIT}否则用转义后的 printf 兜底第 55-67 行。一个值得注意的细节文档提醒当参数包含单引号例如Im Groot时需要使用转义语法I\m Groot或尽量改用双引号Im Groot包裹。2. 加载上下文读取FEATURE_SPEC与.specify/memory/constitution.md项目宪法并加载已复制好的IMPL_PLAN模板。3. 执行计划工作流严格遵循 plan 模板结构逐步填充填写Technical Context技术上下文未知项一律标注为NEEDS CLARIFICATION从宪法文件填充Constitution Check小节评估门禁gates若存在未加理由的违规必须输出 ERRORPhase 0生成research.md解决所有NEEDS CLARIFICATIONPhase 1生成data-model.md、contracts/、quickstart.md运行 agent 脚本更新 Agent 上下文设计完成后重新评估 Constitution Check。4. 停止并报告命令在 Phase 2 规划结束后停止报告内容包括分支名、IMPL_PLAN路径、已生成的产物列表。5. 检查 after_plan 钩子报告完成后再次检查.specify/extensions.yml的hooks.after_plan键规则与 before_plan 完全一致可选钩子输出 Optional Hook强制钩子输出 Automatic Hook 并执行。四、Phase 0研究与未知项消解Phase 0 的目标是把 Technical Context 中所有不确定性转化为已落地的研究结论。具体做法提取未知项每个NEEDS CLARIFICATION对应一个研究任务每个依赖对应一个最佳实践任务每个集成点对应一个模式任务派发研究任务按统一格式生成任务描述——对未知项输出Task: Research {unknown} for {feature context}对技术选型输出Task: Find best practices for {tech} in {domain}沉淀研究结论将所有发现汇总到research.md并采用三字段结构保证决策可追溯Decision最终选择什么Rationale为什么这样选Alternatives considered还评估过哪些备选方案。产出research.md中所有NEEDS CLARIFICATION全部消解作为进入 Phase 1 的前置条件。五、Phase 1设计与契约1. 数据模型data-model.md从特性规格中提取实体形成data-model.md内容包括实体名称Entity name、字段fields、关系relationships由需求推导出的校验规则validation rules适用的状态迁移state transitions。2. 接口契约contracts/若项目对外暴露接口则在/contracts/目录下定义接口契约识别项目面向用户或其他系统暴露的接口按项目类型记录合适的契约格式——库项目写公共 API、CLI 工具写命令 schema、Web 服务写端点、解析器写文法、应用写 UI 契约纯内部项目如一次性构建脚本可以跳过此步。3. Agent 上下文更新将AGENTS.md中!-- SPECKIT START --与!-- SPECKIT END --标记之间的计划引用更新为指向步骤 1 生成的 plan 文件即IMPL_PLAN路径。这一机制在仓库中有直观的实例AGENTS.md第 98-101 行正是用这对标记包裹了一句指引——readspecs/013-user-tasks/plan.md把当前活跃特性直接透传给 AI Agent。而负责实现该更新的脚本.specify/scripts/bash/update-agent-context.sh功能相当完整它从 plan 文件正则提取**Language/Version**、**Primary Dependencies**、**Storage**、**Project Type**字段自动过滤NEEDS CLARIFICATION与N/A再把这些技术栈信息追加到各 Agent 上下文文件的## Active Technologies与## Recent Changes小节并同步更新 Last updated 时间戳。该脚本另一个亮点是多 Agent 支持它内置了 Claude、Gemini、GitHub Copilot、Cursor、Qwen、opencode、Codex、Windsurf、Kilo Code、Auggie、Roo Code、CodeBuddy CLI、Qoder CLI、Amp、SHAI、Kiro CLI、Antigravityagy、IBM Bobbob等近二十种 Agent 的文件路径映射与命名约定未指定 Agent 类型时更新所有已存在的 Agent 文件若一个都没有则默认创建 Claude 文件对 Cursor 的.mdc规则文件还会自动补上 YAML frontmatter含globs与alwaysApply: true使其被 IDE 自动加载。产出data-model.md、contracts/*、quickstart.md、更新后的 Agent 上下文文件。六、关键规则与门禁语义文档最后以两条硬性规则收束整个工作流路径规范文件系统操作使用绝对路径文档与 Agent 上下文文件中的引用使用项目相对路径——这一区分避免了脚本执行与文档可移植性之间的冲突门禁语义门禁失败gate failures或未消解的澄清项unresolved clarifications一律输出 ERROR不允许静默放行确保任何含NEEDS CLARIFICATION的计划都无法在门禁不通过的情况下进入下一阶段。七、plan 模板剖析实施计划的最终形态/speckit-plan的全部输出都收敛到.specify/templates/plan-template.md所定义的实施计划文件中。模板头部包含分支名、日期、规格链接与输入规格路径正文由五个核心小节构成Summary从特性规格提取主要需求与来自 research 的技术方案。Technical Context一份覆盖技术选型关键维度的检查清单包括语言/版本、主依赖、存储方案、测试框架、目标平台、项目类型、性能目标、约束条件、规模/范围。每个字段允许填NEEDS CLARIFICATION占位交由 Phase 0 消解。Constitution Check标注为GATE: Must pass before Phase 0 research. Re-check after Phase 1 design.门禁必须在 Phase 0 研究之前通过Phase 1 设计之后复查。门禁的具体判定依据来自宪法文件。Project Structure分文档结构与源码结构两部分。文档结构给出特性目录的固定布局plan.md / research.md />specs/013-user-tasks/ ├── spec.md # 特性规格输入 ├── research.md # Phase 0 输出 ├──>赞分享后端工作流自动化流程编排低代码【免费下载链接】elsa-coreThe Workflow Engine for .NET项目地址https://gitcode.com/gh_mirrors/el/elsa-core点击查看免费下载相关推荐ScyllaDB Arbiter DC 实操指南用零 Token 节点防止对称多数据中心集群丢失 Raft QuorumScyllaDB Arbiter DC 实操指南用零 Token 节点防止对称多数据中心集群丢失 Raft Quorum 导读 本文基于 ScyllaDB 官后端工作流自动化流程编排低代码Bitwarden Android 开发规划指南从 Jira 需求到实施计划的全流程工作流Bitwarden Android 开发规划指南从 Jira 需求到实施计划的全流程工作流 导读 本文系统解析 Bitwarden Android 开源仓库移动开发应用安全密码学认证鉴权深蓝词库转换项目实施计划模板解析基于 SpecKit 的 /speckit.plan 规划工作流深蓝词库转换项目实施计划模板解析基于 SpecKit 的 /speckit.plan 规划工作流 导读本文围绕深蓝词库转换imewlconverter开桌面应用CLI开发工具上一篇awesome-low-level-design调试技巧大全下一篇Carbon React preview__DatePicker 迁移指南从 Flatpickr 时代走向 Temporal 状态机架构创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考