mcpField
T
to-spec

to-spec

github.com/niekcandaele开发647 次安装2 天前更新
代码仓库

关于 to-spec

to-spec 是一项将当前对话和代码库信息整理成产品规格并发布到项目追踪器的技能，面向需要把已达成共识转成可执行方案的团队。它不访谈用户，而是综合已有信息，并覆盖用户故事、实现与测试决策及范围边界。

主要功能

  1. 01从对话与代码库提炼规格
  2. 02沿用领域词汇和架构决策
  3. 03规划并确认测试切入点
  4. 04生成结构化规格章节
  5. 05发布规格并按规则添加标签

适用场景

  1. 01将已讨论的功能整理为规格
  2. 02把实现和测试决策记录到追踪器
  3. 03依据仓库现有测试规划验证边界

安装

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

$npx skills add https://github.com/niekcandaele/skills --skill to-spec

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

详细介绍

这项技能会结合当前对话上下文和对代码库的理解，生成一份规格说明。不要采访用户——只综合你已经掌握的信息。如果对话尚未达成共识，那应该进行 grill-me 环节，而不是编写规格说明。

跟踪工具。 阅读工程师技能目录中的 TRACKER.md；它会说明跟踪工具及其命令，并将含义映射到此仓库中的标签字符串。如果没有该文件，请根据用户提供的信息、Git 远程仓库，以及已安装且已通过身份验证的 CLI，确定本次运行所用的跟踪工具；如果无法确定，则默认使用本地 Markdown 文件目录。

工程师技能的目录因运行环境而异，因此请使用 glob 查找：

ls */skills/*-engineer/TRACKER.md .*/skills/*-engineer/TRACKER.md 2>/dev/null

流程

  1. 如果你还不了解代码库的当前状态，请先探索仓库。通篇使用项目的领域术语，并遵守你所涉及区域的任何 ADR。

  2. 梳理将用于测试该功能的接缝。优先使用现有接缝，并选择尽可能高层的接缝。如果需要新增接缝，请尽可能在最高层提出。接缝越少越好——理想情况下只有一个。

请与用户确认这些接缝是否符合他们的预期。

  1. 使用下方模板编写规格说明，然后将其发布到跟踪工具。为可交由 Agent 执行的工作应用 TRACKER.md 中指定的标签；如果其中没有指定标签，则跳过标记并说明这一点。

问题陈述

从用户的角度描述用户面临的问题。

解决方案

从用户的角度描述解决问题的方案。

用户故事

一份篇幅较长、带编号的用户故事列表。每条用户故事都应采用以下格式：

  1. 作为一名<角色>，我希望<功能>，以便<益处>
1. 作为一名移动银行客户，我希望查看账户余额，以便更明智地决定如何消费

这份用户故事列表应极其详尽，并覆盖该功能的所有方面。

实现决策

列出已做出的实现决策。包括：

  • 将要构建或修改的模块
  • 将要修改的模块接口
  • 开发者提供的技术澄清
  • 架构决策
  • 架构变更
  • API 契约
  • 具体交互

不要包含具体文件路径或代码片段。这些内容很快就可能过时。

例外：如果原型中的代码片段比文字描述更准确地表达了某项决策（如状态机、reducer、架构或类型定义），则可将其内联到相关决策中，并简要说明该片段来自原型。只保留体现关键决策的部分，不要放入可运行的示例。

测试决策

列出已做出的测试决策。包括：

  • 优秀测试的标准（只测试外部行为，不测试实现细节）
  • 将要测试的模块
  • 测试的先例（即代码库中类似的测试）

不在范围内

描述本规格说明不涵盖的事项。

补充说明

关于该功能的任何其他说明。

改编自 mattpocock/skills，MIT © 2026 Matt Pocock。如果复制此文件，请保留此行。

评论

支持 Markdown