mcpField
T
to-spec

to-spec

github.com/yahyabedirhan开发269 次安装1 天前更新
代码仓库

关于 to-spec

将当前对话和对代码库的理解整理为项目规格的 Skill。它会检查仓库、提出功能测试切入点，并按模板编写规格后发布到项目跟踪系统。

主要功能

  1. 01检查仓库状态与领域词汇表
  2. 02确定功能测试切入点
  3. 03撰写结构化规格
  4. 04添加分类标签并发布规格

适用场景

  1. 01将功能讨论整理为规格
  2. 02记录实现与测试决策
  3. 03为 Agent 准备可跟踪的开发任务

安装

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

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

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

附带文件agents/openai.yamlLICENSE.mattpocock

详细介绍

这项技能会根据当前对话上下文和对代码库的理解来编写规格说明。不要采访用户；只需综合已有信息。

问题跟踪器和分类标签词汇应已提供给你。如果没有，请先运行 set-up-project 技能。

流程

  1. 如果你尚未了解代码库的当前状态，请先探索代码库。在整个规格说明中使用项目的领域词汇表，并遵循你要修改的相关领域中的 ADR。

  2. 概述你打算在哪些边界测试此功能。优先使用现有边界，并尽可能选择最高层级的边界。如果需要新增边界，请尽量在最高层级提出。跨代码库的边界越少越好——理想情况下只有一个。

确认这些边界符合用户的预期。

  1. 使用以下模板编写规格说明，然后将其发布到项目问题跟踪器。应用 ready-for-agent 分类标签——无需额外分类。标题格式按 docs/agents/issue-tracker.md 中的“标题前缀”说明设置。

对于本地文件问题跟踪器，将规格说明写入 .efforts/<effort>/spec.md，其中 <effort> 是工作项的名称（如果没有工作项，则使用功能的简短 slug）。其工单放在旁边的 .efforts/<effort>/issues/ 中。

问题陈述

从用户的角度描述他们遇到的问题。

解决方案

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

用户故事

一份篇幅较长的编号用户故事列表。每条用户故事的格式如下：

  1. 作为一名<角色>，我希望拥有一项<功能>，从而<收益>
1. 作为一名移动银行客户，我希望查看账户余额，从而更好地了解自己的消费情况

这份用户故事列表应尽可能详尽，涵盖该功能的所有方面。

实现决策

列出已作出的实现决策，包括：

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

不要包含具体文件路径或代码片段。它们很快就可能过时。

例外：如果原型中有比文字更精确地表达某项决策的代码片段（如状态机、归约器、架构或类型形状），可将其内联到相关决策中，并简要说明该片段来自原型。只保留体现关键决策的部分，不要附上完整的演示代码。

测试决策

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

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

范围之外

描述不属于本规格说明范围的事项。

补充说明

关于该功能的其他补充说明。

评论

支持 Markdown