SKILL.md
soia-dev-test-draft-doc
将用户提供的需求、PRD、原型说明或变更描述转为可评审的互联网通用测试文档。交付物覆盖测试计划、正常/边界/异常/数据流用例、回归清单和需求验收对照；不替代业务方确认含糊的产品规则。
客户可读说明
这个技能可以做什么
提供需求材料、目标平台和已知约束；材料可以是粘贴文本、用户明确提供的文件或公开链接。技能先识别可验证行为与未决问题，再产出可执行、可追溯的测试设计。
| 客户想要 | 技能会做 | 客户能看到 |
|---|---|---|
| 为新功能制定测试计划 | 划定范围、风险、环境、数据和进入/退出准则 | 测试计划与风险优先级 |
| 从 PRD 设计测试用例 | 按正常、边界、异常和数据流覆盖可观察行为 | 编号用例表与待确认项 |
| 上线前回归和验收 | 提炼受影响路径，并把需求逐项映射到验收证据 | 回归清单与验收对照表 |
客户如何使用
说明需求来源、功能目标、角色、平台、变更范围、已有规则和期望交付格式。例如：基于以下订单取消需求，设计 Web 与 API 的测试计划、用例、回归清单和验收对照表：<需求文本>。
只读取客户在当前对话明确提供或授权的材料；缺少需求、可观察结果、权限规则或数据约束时，先列为待确认项，不把猜测写成验收结论。
工作流程
- 确认输入边界：记录材料版本、目标端（如 Web、移动端、API）、角色、范围外内容和交付语言；拒绝读取未授权来源。
- 提取需求原子项：将每条规则拆为触发条件、前置状态、动作、可观察结果和不可变约束，并为每项分配需求 ID。
- 标注不确定性：区分材料原文、可由原文推出的测试假设与待产品/研发确认的问题；关键规则缺失时不虚构通过标准。
- 制定测试计划：按用户影响、改动范围、数据风险和集成依赖排序，明确测试范围、策略、环境/数据前提、准入准出和风险。
- 设计用例：每个原子项至少考虑正常路径、边界条件、异常处理和数据流；按风险补充权限、幂等、并发、兼容、可恢复性或可观测性检查。
- 形成回归清单：从改动入口、受影响页面/API、共享数据和关键链路反推最小回归集；把高风险或核心交易链路标为必回归。
- 建立验收对照：将每个需求 ID 映射到用例 ID、验收证据、状态和未决问题；没有对应测试证据的需求不得标为已覆盖。
- 自检交付物：检查每个用例是否可执行、预期结果是否可观察、四类覆盖是否缺失、数据流是否闭环，以及相互矛盾的规则是否已显式上报。
输出契约
默认以 Markdown 交付；客户指定表格、测试管理系统字段或 CSV 模板时，保持下列语义不变。
依赖与安装
装整个域（Claude Code 与 Codex 共用同一份域插件）：
claude plugin marketplace add soia-team/soia-open-skills
claude plugin install soia-dev@soia只装这一个技能：
npx skills add soia-team/soia-open-dev-skills -g -a '*' -s soia-dev-test-draft-doc -yWorkBuddy 的装载单位是角色化专家而不是插件，npx skills add -a '*' 覆盖不到它，需要单独安装，见 docs/install/workbuddy.md。
1. 测试计划
| 字段 | 内容 |
|---|---|
| 目标与范围 | 目标、包含/排除范围、目标端与版本 |
| 风险与策略 | 风险等级、优先级、覆盖策略、依赖与缓解措施 |
| 环境与数据 | 环境前提、账号角色、数据构造/脱敏要求 |
| 准入与准出 | 可开始与可结束的客观条件 |
| 待确认项 | 缺失规则、负责人角色与阻塞影响 |
2. 测试用例
| 用例 ID | 需求 ID | 类型 | 前置条件 | 步骤 | 预期结果 | 优先级 |
|---|---|---|---|---|---|---|
| TC-001 | R-001 | 正常 | 已登录的测试用户 | 执行目标操作 | 系统返回或展示可观察的预期状态 | P0/P1/P2 |
- 类型至少使用：正常、边界、异常、数据流；当不适用时写明理由。
- 数据流用例同时核对输入、处理/存储、读取或下游消费的结果，以及失败后的数据一致性。
- 异常用例核对错误提示、状态码或失败状态、无副作用/可恢复性，不只核对“报错了”。
3. 回归清单与验收对照表
回归清单包含入口、关键路径、跨端/API、共享数据、权限和已知高风险项，并标注必回归或按变更触发。
| 需求 ID | 验收条件 | 用例 ID | 验收证据 | 状态 | 待确认项 |
|---|---|---|---|---|---|
| R-001 | 可观察的业务结果 | TC-001, TC-002 | 执行记录或系统可见结果 | 未执行/通过/失败/阻塞 | 无或问题编号 |
覆盖设计规则
- 正常：验证主角色在满足前置条件时完成核心目标。
- 边界：验证最小/最大值、临界日期、空值、长度、分页、容量和状态转换边界；只有与需求相关时才加入。
- 异常：验证格式错误、权限不足、依赖失败、重复提交、超时或不可用操作；预期应包含用户可见结果和状态保持要求。
- 数据流：从创建/输入到校验、保存、查询、更新、同步、导出或删除（如适用）逐段验证，尤其检查重复、遗漏、错配和一致性。
- 不将实现细节、未公开接口或未提供的内部架构当作事实。若测试需要这些信息，列入待确认项。
私密信息与中间数据
- 本技能默认只在对话中生成文档，不写入本地或远端；客户要求保存时，交付到其指定位置。
- 不读取公司知识库、浏览器资料、私有仓库、账号、凭据或未授权文件；示例使用虚构角色、订单和数据。
- 若客户提供材料含个人信息、生产数据、令牌或内部标识，仅抽取完成测试设计所需的最小规则，并在输出中用角色名、占位符或脱敏数据替代。
- 临时草稿如需落盘，使用操作系统临时目录并在本次完成后删除；不将运行数据、缓存或凭据写入技能安装目录或仓库。
- 私有配置仅可位于
~/.config/soia-skills/soia-dev-test-draft-doc/config.yml，且本技能无需配置，不应创建该文件。
依赖与安装
无强制软件或第三方技能依赖。强依赖是客户提供的、已获授权的需求材料；材料不足时交付问题清单和部分覆盖设计，而非伪造完整用例。
安装：
claude plugin marketplace add soia-team/soia-open-skillsclaude plugin install soia-dev@soia只要这一个技能时，可用 npx 路线。注意技能会落进共享真源 ~/.agents/skills；若同时装了插件，同一技能会出现两份索引且各自漂移，建议二选一：
npx skills add soia-team/soia-open-dev-skills -g -a '*' -s soia-dev-test-draft-doc -y配置约定：schema v2 路径为 ~/.config/soia-skills/soia-dev-test-draft-doc/config.yml。本技能无配置项，无需创建 config.yml；不要在其中存放需求原文、生产数据或凭据。
日志与完成回执
完成：已根据 <需求材料范围> 生成测试计划、用例、回归清单和验收对照表。
日志摘要：
- 输入：<材料版本、目标端和已授权范围>
- 覆盖：<需求项数> 项；正常/边界/异常/数据流分别 <数量> 条
- 风险：<高风险项或“无”>
- 待确认：<问题编号或“无”>
验证：已核对需求 ID 到用例 ID 与验收证据的映射；未把待确认项标为已覆盖。
残余风险：<未提供的接口、规则、环境或“无”>质量门槛
- 每条需求至少对应一个验收条件和一个用例，或明确说明为何不可测。
- 每个用例有可执行前置条件、明确步骤和可观察预期；避免“系统正常”“符合预期”这类不可验证表述。
- 高风险需求至少有一条失败或边界验证；涉及数据变化时至少有一条数据流验证。
- 不声称已执行测试：本技能生成的是测试设计。只有客户提供实际执行记录后，才更新验收状态。