Skip to content
Development
Skill

/x-spec

和用户沟通完开发需求后使用。把需求用功能性描述(不涉及具体实现、不用技术词汇)写进 spec 文档,并把需求拆成一个个用户可感知的小功能,每个用 feat+序号(feat01 开始)作为标题,配合 Given/When/Then 场景描述。也适用于用户要求"写需求文档""整理 spec""把刚聊的方案记下来""记录需求"。

From plugin
x-dev-pipeline
1220 skills
Install
$ npx -y skills add KtKID/x-dev-pipeline --skill x-spec --agent claude-code

How it fires

How this skill gets triggered: by you, by Claude, or both.

  • Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
  • You can call itInvoke it directly when you want it.
  • Slash command/x-spec

Context preview

The summary Claude sees to decide when to auto-load this skill.

和用户沟通完开发需求后使用。把需求用功能性描述(不涉及具体实现、不用技术词汇)写进 spec 文档,并把需求拆成一个个用户可感知的小功能,每个用 feat+序号(feat01 开始)作为标题,配合 Given/When/Then 场景描述。也适用于用户要求"写需求文档""整理 spec""把刚聊的方案记下来""记录需求"。

SKILL.md

x-spec.SKILL.md
name: x-spec
description: |
  和用户沟通完开发需求后使用。把需求用功能性描述(不涉及具体实现、不用技术词汇)写进 spec 文档,并把需求拆成一个个用户可感知的小功能,每个用 feat+序号(feat01 开始)作为标题,配合 Given/When/Then 场景描述。也适用于用户要求"写需求文档""整理 spec""把刚聊的方案记下来""记录需求"。

x-spec

把沟通完的需求写成一份纯功能性的 spec。只描述"用户能做什么、能看到什么",不描述代码怎么实现。

核心原则

1. **只写做什么,不写怎么做。** 描述用户能感知的功能和结果,不写技术实现。 2. **用功能语言,不用技术词汇。** 写"保存""查询""加快""提醒",不写"数据库""API""缓存""消息队列"。用户能看懂每一行。 3. **feat 是用户可感知的功能点。** 一个 feat 对应一个用户能说出名字的功能(如"登录""搜索""导出"),不按技术层(如"接口层""数据层")拆。

产物

一份 `docs/spec/<spec-name>/spec.md`。结构固定为:标题 + 概述 + feat 列表。完整读取 `templates/spec.md` 后填充,删除占位符和空示例。

工作流

1. 梳理需求

从刚结束的对话里提取用户要的所有功能。不要先复述问用户、也不要停下来等确认——直接往下写完整 spec。

遇到题目没说死的地方(边界、异常、歧义),采用最小合理默认直接写进场景里,同时把这条默认**记到结尾的待确认清单**(见第 4 步),让用户一次性 review。常见需要做默认的点:功能的触发条件、边界情况、出错时用户看到什么。

2. 拆分 feat

按用户可感知的功能点拆分。编号规则:

  • 从 `feat01` 开始,两位序号,按文档顺序连续递增(feat01、feat02、feat03...)。
  • 同一 spec 内序号不重复。
  • 每个 feat 标题写功能名称,用功能性描述(如 `feat01: 用户用手机号登录`,不写 `feat01: AuthService`)。

一个 feat 是一个完整的功能点,不要拆得过细。判断标准:用户会把它当成"一个功能"来说,就归一个 feat。

3. 写场景

每个 feat 下用多个 Given/When/Then 场景描述行为。至少覆盖:

  • **正常流程**:用户正常操作会发生什么。
  • **边界情况**:空输入、极值、特殊字符等。
  • **异常处理**:出错时用户看到什么。

格式:

## feat01: <功能名称>

<一句话说明这个功能给用户做什么>

场景1: <正常流程名>
- GIVEN <前置条件>
- WHEN <用户操作>
- THEN <可观察结果>

场景2: <边界或异常名>
- GIVEN <前置条件>
- WHEN <用户操作>
- THEN <可观察结果>

**GWT 写法:**

  • **GIVEN**:用户视角的前置条件或初始状态。例:"用户已登录""购物车里有3件商品"。
  • **WHEN**:用户的操作。例:"点击结算""输入手机号后点击获取验证码"。
  • **THEN**:用户能看到、能感知的结果。例:"显示订单确认页""提示手机号格式不正确"。

**禁止出现**:技术实现细节。不写"调用 POST /api/order""写入订单表""返回 200 状态码""缓存失效"。只写用户视角。

4. 自检并报告待确认项

写完后逐条检查:

  • 每个 feat 是不是用户能感知的完整功能点?(不是技术层、不是接口名)
  • GWT 里有没有混进技术词汇?(有就改成功能性描述)
  • 每个 feat 是否覆盖了正常、边界、异常三类场景?(缺哪类就补)
  • THEN 写的是不是用户能看到的结果?(不是内部状态变化)
  • feat 编号是否从 01 连续递增、无重复?

最后在回复里附一份**待确认清单**,把第 1 步里所有"题目没说死、我用了合理默认"的点列出来让用户一次性 review,每条写清:在哪个 feat 的哪个场景、默认给了什么结果。示例:

> 待确认: > - feat02 场景2 邀请码无效时的提示文案,我默认写"邀请码无效" > - feat05 场景2 没人打卡时的进度展示,我给了"第 0 页"和"提示还没人打卡"两种,需二选一

完整示例

下面是一个三 feat 的小需求示例,展示目标形态:

# 二手书交易首页

让用户在首页看到正在出售的书,并能快速搜索和收藏感兴趣的图书。

## feat01: 浏览在售图书

用户打开首页可以看到当前所有正在出售的图书。

场景1: 正常浏览
- GIVEN 首页有多本在售图书
- WHEN 用户打开首页
- THEN 按上架时间从新到旧展示图书列表,每本显示书名、价格、成色和卖家昵称

场景2: 暂无图书
- GIVEN 当前没有任何在售图书
- WHEN 用户打开首页
- THEN 显示"暂无在售图书"的提示,并给出去发布闲置的入口

## feat02: 按书名搜索

用户可以通过书名快速找到想要的图书。

场景1: 匹配成功
- GIVEN 首页有《三体》和《三体2》在售
- WHEN 用户在搜索框输入"三体"
- THEN 展示《三体》和《三体2》两本书

场景2: 无匹配
- GIVEN 首页没有包含"小说"的书
- WHEN 用户搜索"小说"
- THEN 提示"没有找到相关图书"

## feat03: 收藏图书

用户可以把感兴趣的图书收藏起来,方便以后查看。

场景1: 收藏一本未收藏的书
- GIVEN 用户已登录,且这本书没有收藏过
- WHEN 用户点击这本书的收藏按钮
- THEN 按钮变成已收藏状态,这本书出现在用户的收藏列表里

场景2: 未登录时收藏
- GIVEN 用户没有登录
- WHEN 用户点击收藏按钮
- THEN 提示"请先登录",并跳转到登录页

注意示例里没有一个技术词:没有"数据库""接口""状态码""字段"。每条 THEN 都是用户能直接看到的。

Read more
Ships withx-dev-pipeline

An auditable development workflow for AI coding agents: requirement contracts, implementation evidence, deterministic checks, and risk-matched review.

Get the whole plugin
Stats
12
Stars
0
Forks
Active
Maintenance
Python
Language
MIT
License
8d ago
Last commit
5mo ago
Created

Repo: KtKID/x-dev-pipeline

Other skills on x-dev-pipeline.

x-cr
Skill

x-cr

软件正确性调查 skill。用于用户说“XX 不太对”“这个功能有 bug”“结果和预期不一致”“帮我查原因”,也用于 review 模块、文件、diff 或 PR 的正确性。遇到已知异常、模块不变量、信任边界、授权范围扩张、服务端校验、租户/会话隔离或持久化一致性问题时优先使用本 skill。 本 skill…

x-dev
Skill

x-dev

开发任务执行 skill。读取单个 task 的 dev-checklist.md,按行序以"先测试后实现"的方式逐行执行,dev-report 只记验证结论(全绿或 N 个 🔴),全部行验证通过后交付。触发:`x-dev {task-dir}`、用户要求执行/开发某个 task。

x-fix
Skill

x-fix

Bug 修复执行 skill。分三种入口: 1. 用户直接报告 Bug → 定位根因 → 修复 → 产出 fix-report-*.md 或 fix-note-*.md(无需 CR 报告) 2. 有 x-cr 的 CR 报告 → 按稳定 Bn/INV-ID 逐条修复 → 回写同一份 task 内或仓库级…

x-qa-gate
Skill

x-qa-gate

verify 通过后的质量审查。Q2/Q3 各由一个 reviewer 在单轮内按 q1-intent、q2-correctness、q3-evidence 三个独立 lens 穷尽检查;Q3 使用完整高风险输入和逐 lens 回执。发现 P0/P1 后登记 issue 并交 x-fix 批量修复,主 agent…

x-req3
Skill

x-req3

x-spec3 的任务拆解 skill。读取 `docs/spec/{spec-name}/spec.md` 的目标、边界与不变量、判断依据、验收清单和直接 GWT Scenarios,生成 `docs/spec/{spec-name}/tasks/{task-name}/dev-checklist.md`,并以…

x-spec3
Skill

x-spec3

在开发方案已经讨论清楚、需要固化保存时使用。也适用于用户明确要求保存方案、编写规格文档,或希望在开发前明确目标、边界、约束和验收标准的场景。将已确认的方案整理成可供后续任务拆解、开发和验证共同使用的规格文档。