x-cr
软件正确性调查 skill。用于用户说“XX 不太对”“这个功能有 bug”“结果和预期不一致”“帮我查原因”,也用于 review 模块、文件、diff 或 PR 的正确性。遇到已知异常、模块不变量、信任边界、授权范围扩张、服务端校验、租户/会话隔离或持久化一致性问题时优先使用本 skill。 本 skill…
和用户沟通完开发需求后使用。把需求用功能性描述(不涉及具体实现、不用技术词汇)写进 spec 文档,并把需求拆成一个个用户可感知的小功能,每个用 feat+序号(feat01 开始)作为标题,配合 Given/When/Then 场景描述。也适用于用户要求"写需求文档""整理 spec""把刚聊的方案记下来""记录需求"。
$ npx -y skills add KtKID/x-dev-pipeline --skill x-spec --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/x-specContext preview
The summary Claude sees to decide when to auto-load this skill.
和用户沟通完开发需求后使用。把需求用功能性描述(不涉及具体实现、不用技术词汇)写进 spec 文档,并把需求拆成一个个用户可感知的小功能,每个用 feat+序号(feat01 开始)作为标题,配合 Given/When/Then 场景描述。也适用于用户要求"写需求文档""整理 spec""把刚聊的方案记下来""记录需求"。
name: x-spec description: | 和用户沟通完开发需求后使用。把需求用功能性描述(不涉及具体实现、不用技术词汇)写进 spec 文档,并把需求拆成一个个用户可感知的小功能,每个用 feat+序号(feat01 开始)作为标题,配合 Given/When/Then 场景描述。也适用于用户要求"写需求文档""整理 spec""把刚聊的方案记下来""记录需求"。
把沟通完的需求写成一份纯功能性的 spec。只描述"用户能做什么、能看到什么",不描述代码怎么实现。
1. **只写做什么,不写怎么做。** 描述用户能感知的功能和结果,不写技术实现。 2. **用功能语言,不用技术词汇。** 写"保存""查询""加快""提醒",不写"数据库""API""缓存""消息队列"。用户能看懂每一行。 3. **feat 是用户可感知的功能点。** 一个 feat 对应一个用户能说出名字的功能(如"登录""搜索""导出"),不按技术层(如"接口层""数据层")拆。
一份 `docs/spec/<spec-name>/spec.md`。结构固定为:标题 + 概述 + feat 列表。完整读取 `templates/spec.md` 后填充,删除占位符和空示例。
从刚结束的对话里提取用户要的所有功能。不要先复述问用户、也不要停下来等确认——直接往下写完整 spec。
遇到题目没说死的地方(边界、异常、歧义),采用最小合理默认直接写进场景里,同时把这条默认**记到结尾的待确认清单**(见第 4 步),让用户一次性 review。常见需要做默认的点:功能的触发条件、边界情况、出错时用户看到什么。
按用户可感知的功能点拆分。编号规则:
一个 feat 是一个完整的功能点,不要拆得过细。判断标准:用户会把它当成"一个功能"来说,就归一个 feat。
每个 feat 下用多个 Given/When/Then 场景描述行为。至少覆盖:
格式:
## feat01: <功能名称> <一句话说明这个功能给用户做什么> 场景1: <正常流程名> - GIVEN <前置条件> - WHEN <用户操作> - THEN <可观察结果> 场景2: <边界或异常名> - GIVEN <前置条件> - WHEN <用户操作> - THEN <可观察结果>
**GWT 写法:**
**禁止出现**:技术实现细节。不写"调用 POST /api/order""写入订单表""返回 200 状态码""缓存失效"。只写用户视角。
写完后逐条检查:
最后在回复里附一份**待确认清单**,把第 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 都是用户能直接看到的。
An auditable development workflow for AI coding agents: requirement contracts, implementation evidence, deterministic checks, and risk-matched review.
软件正确性调查 skill。用于用户说“XX 不太对”“这个功能有 bug”“结果和预期不一致”“帮我查原因”,也用于 review 模块、文件、diff 或 PR 的正确性。遇到已知异常、模块不变量、信任边界、授权范围扩张、服务端校验、租户/会话隔离或持久化一致性问题时优先使用本 skill。 本 skill…
开发任务执行 skill。读取单个 task 的 dev-checklist.md,按行序以"先测试后实现"的方式逐行执行,dev-report 只记验证结论(全绿或 N 个 🔴),全部行验证通过后交付。触发:`x-dev {task-dir}`、用户要求执行/开发某个 task。
Bug 修复执行 skill。分三种入口: 1. 用户直接报告 Bug → 定位根因 → 修复 → 产出 fix-report-*.md 或 fix-note-*.md(无需 CR 报告) 2. 有 x-cr 的 CR 报告 → 按稳定 Bn/INV-ID 逐条修复 → 回写同一份 task 内或仓库级…
verify 通过后的质量审查。Q2/Q3 各由一个 reviewer 在单轮内按 q1-intent、q2-correctness、q3-evidence 三个独立 lens 穷尽检查;Q3 使用完整高风险输入和逐 lens 回执。发现 P0/P1 后登记 issue 并交 x-fix 批量修复,主 agent…
x-spec3 的任务拆解 skill。读取 `docs/spec/{spec-name}/spec.md` 的目标、边界与不变量、判断依据、验收清单和直接 GWT Scenarios,生成 `docs/spec/{spec-name}/tasks/{task-name}/dev-checklist.md`,并以…