mcpField
S
spec-workflow

spec-workflow

github.com/tencentcloudbase开发791.2k 次安装今天更新
代码仓库

关于 spec-workflow

spec-workflow 是用于规划中大型开发改动的技能，将工作拆分为需求、设计、任务和执行阶段。它强调明确验收标准及阶段间确认，并允许小而明确的改动直接实施。

主要功能

  1. 01判断是否需要完整规格流程
  2. 02编写 EARS 风格验收标准
  3. 03划分需求、设计与任务规划
  4. 04实施前要求用户确认
  5. 05允许小型明确改动直接执行

适用场景

  1. 01编码前规划跨模块功能
  2. 02明确新工作流的验收边界
  3. 03分阶段处理 UI 或数据库密集型改动
  4. 04无需额外文档地处理明确的小型修复

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/tencentcloudbase/skills --skill spec-workflow

安装后在 Claude Code 中输入/spec-workflow确认已加载。

附带文件LICENSE.md

详细介绍

兄弟技能（仅限本地）

兄弟 CloudBase 技能会与此技能一起提供。使用本地相对路径，例如 ../auth-tool-cloudbase/SKILL.md。

如果当前环境缺少引用的兄弟技能文件，请让用户安装完整的 CloudBase 插件（或缺失的技能）。不要通过 HTTP 将远程技能或协议 Markdown 获取到 Agent 上下文中。

规格工作流

激活约定

以下情况先使用此工作流
  • 请求涉及新功能、多步骤产品变更、跨模块集成或架构／设计任务。
  • 验收标准不明确，需要在实施前明确。
  • 工作涉及多个文件、用户流程、数据库设计或 UI 设计，需要分阶段确认。
编写代码前先阅读
  • 如果不确定任务应该直接进入编码，还是先进行需求、设计和任务规划。
  • 请求提到新页面、新系统、重新设计、工作流或多模块重构。
接下来也要阅读
  • 前端页面或视觉设计工作 -> ../ui-design/SKILL.md
  • 高级数据模型工作 -> ../data-model-creation/SKILL.md
以下情况不要使用
  • 范围明确的小型 Bug 修复。
  • 单文件文档更新。
  • 直接明了的配置变更。
  • 用户已给出准确实施指示的微小重构。
常见错误／注意事项
  • 在验收标准明确之前就开始编码。
  • 跳过需求、设计和任务各阶段之间的用户确认。
  • 编写含糊的任务，无法对应到用户可见的结果。
  • 将 UI 工作视为纯技术实施，而不澄清设计意图。
最简检查清单
  • 判断该变更是否真的需要完整的规格工作流。
  • 如果需要，先停下来编写需求。
  • 如果变更规模小、风险低且验收标准已明确，则无需强制创建规格文档，可直接执行。
  • 使用 EARS 风格的验收标准。
  • 进入下一阶段前先获得确认。

何时使用此技能

在需要进行结构化开发时，使用此工作流来：

  • 定义或完善新功能
  • 设计复杂架构
  • 协调跨模块变更
  • 规划数据库或以 UI 为主的工作
  • 提高需求质量并明确验收范围

决策规则

以下情况使用完整工作流
  • 任务规模中等或较大
  • 影响涉及多个模块
  • 验收范围模糊
  • 用户希望在实施前进行严谨规划
以下情况跳过完整工作流
  • 任务规模小、风险低且描述精准
  • 目标、范围和验收标准已足够明确，可直接执行
  • 用户明确要求直接修改代码，不要规划阶段

核心工作流

阶段 1：需求

创建 specs/<spec_name>/requirements.md。

要做的事：

  • 重述问题和范围
  • 编写用户故事
  • 使用 EARS 风格编写验收标准
  • 明确业务规则、约束和非目标

EARS 模式：

While <optional precondition>, when <optional trigger>, the <system name> shall <system response>

示例：

When the user submits the form, the booking system shall validate required fields before creating the record.
阶段 2：设计

创建 specs/<spec_name>/design.md。

要做的事：

  • 描述架构和模块边界
  • 说明技术选型及权衡
  • 根据需要定义数据模型、API、安全和测试策略
  • 仅在图表能显著提升清晰度时使用 Mermaid
阶段 3：任务

创建 specs/<spec_name>/tasks.md。

要做的事：

  • 将设计拆分为可执行任务
  • 确保任务具体且便于审查
  • 将每个任务关联到相关需求
  • 随工作进展更新任务状态

任务格式：

# Implementation Plan

- [ ] 1. Task title
  - Specific work item
  - Another concrete step
  - _Requirement: 1
阶段 4：执行

只有在用户确认任务计划后，才能开始实施。

执行期间：

  • 保持任务状态为最新
  • 每次完成一个有意义的工作单元
  • 保持变更 -> 任务 -> 需求之间的可追溯性

Agent 工作规则

  1. 如果请求信息不充分，请提出后续问题；不要猜测核心产品行为。
  2. 在需求、设计和任务拆分之间要求确认。
  3. 如果变更涉及面向最终用户的页面或视觉决策，请尽早引入 ui-design。
  4. 文档应简洁且可测试。
  5. 优先使用面向用户可见结果的任务名称，而非实现细节。

输出预期

  • requirements.md -> 问题、范围、用户故事、EARS 验收标准
  • design.md -> 架构、技术方案、数据/API/安全/测试说明
  • tasks.md -> 与需求对应的可执行实施清单

评论

支持 Markdown