Convert user-provided requirements, PRDs, prototype descriptions, or change descriptions into reviewable general internet testing documents. Deliverables cover test plans, normal/boundary/exception/data flow cases, regression checklists, and requirement acceptance mappings; does not replace business-side confirmation of ambiguous product rules.
Customer-readable description
What this skill can do
Provide requirement materials, target platforms, and known constraints; materials can be pasted text, files explicitly provided by the user, or public links. The skill first identifies verifiable behaviors and open questions, then produces executable, traceable test designs.
| What the customer wants | What the skill will do | What the customer can see |
|---|---|---|
| Create a test plan for a new feature | Define scope, risks, environment, data, and entry/exit criteria | Test plan and risk priorities |
| Design test cases from a PRD | Cover observable behavior by normal, boundary, exception, and data flow | Numbered case table and items to be confirmed |
| Pre-release regression and acceptance | Extract affected paths and map requirements item by item to acceptance evidence | Regression checklist and acceptance mapping table |
How customers use it
Specify the requirement source, feature goals, roles, platforms, change scope, existing rules, and expected delivery format. For example:基于以下订单取消需求，设计 Web 与 API 的测试计划、用例、回归清单和验收对照表：<需求文本>。
Only read materials explicitly provided or authorized by the customer in the current conversation; when requirements, observable results, permission rules, or data constraints are missing, first list them as items to be confirmed, and do not write guesses as acceptance conclusions.
Workflow
- Confirm input boundaries: record the material version, target ends (such as Web, mobile, API), roles, out-of-scope content, and delivery language; refuse to read unauthorized sources.
- Extract requirement atoms: split each rule into trigger conditions, preconditions, actions, observable results, and immutable constraints, and assign a requirement ID to each item.
- Mark uncertainties: distinguish the original material text, test assumptions that can be derived from the original text, and questions to be confirmed with product/R&D; when key rules are missing, do not fabricate pass criteria.
- Create a test plan: prioritize by user impact, change scope, data risk, and integration dependencies, and specify test scope, strategy, environment/data prerequisites, entry and exit criteria, and risks.
- Design cases: for each atom, consider at least the normal path, boundary conditions, exception handling, and data flow; supplement with permission, idempotency, concurrency, compatibility, recoverability, or observability checks based on risk.
- Form a regression checklist: derive the minimum regression set from change entry points, affected pages/APIs, shared data, and critical paths; mark high-risk or core transaction paths as mandatory regression.
- Establish acceptance mappings: map each requirement ID to case IDs, acceptance evidence, status, and open questions; requirements without corresponding test evidence must not be marked as covered.
- Self-check deliverables: check whether each case is executable, whether expected results are observable, whether any of the four coverage types is missing, whether the data flow is closed-loop, and whether conflicting rules have been explicitly reported.
Output contract
Delivered in Markdown by default; when the customer specifies a table, test management system fields, or a CSV template, keep the following semantics unchanged.
Dependencies and Installation
Install the entire domain (Claude Code and Codex share the same domain plugin):
claude plugin marketplace add soia-team/soia-open-skills
claude plugin install soia-dev@soia
Install only this one skill:
npx skills add soia-team/soia-open-dev-skills -g -a '*' -s soia-dev-test-draft-doc -y
WorkBuddy 's loading unit is role-based experts rather than a plugin,npx skills add -a '*' cannot cover it, and it needs to be installed separately, see docs/install/workbuddy.md。
1. Test Plan
| Field | Content |
|---|---|
| Objectives and Scope | Objectives, included/excluded scope, target ends and versions |
| Risks and Strategy | Risk level, priority, coverage strategy, dependencies and mitigation measures |
| Environment and Data | Environment prerequisites, account roles, data construction/masking requirements |
| Entry and Exit Criteria | Objective conditions for starting and finishing |
| Items to Be Confirmed | Missing rules, responsible roles and blocking impact |
2. Test Cases
| Case ID | Requirement ID | Type | Preconditions | Steps | Expected Result | Priority |
|---|---|---|---|---|---|---|
| TC-001 | R-001 | Normal | Logged-in test user | Perform the target operation | The system returns or displays an observable expected state | P0/P1/P2 |
- Types must at least use: normal, boundary, exception, data flow; when not applicable, state the reason.
- Data flow cases simultaneously verify the results of input, processing/storage, reading or downstream consumption, as well as data consistency after failure.
- Exception cases verify error prompts, status codes or failure states, and absence of side effects/recoverability, not just "an error was reported".
3. Regression Checklist and Acceptance Comparison Table
The regression checklist includes entry points, critical paths, cross-end/API, shared data, permissions and known high-risk items, and marks them as mandatory regression or triggered by changes.
| Requirement ID | Acceptance Criteria | Case ID | Acceptance Evidence | Status | Items to Be Confirmed |
|---|---|---|---|---|---|
| R-001 | Observable business result | TC-001, TC-002 | Execution record or system-visible result | Not executed/Passed/Failed/Blocked | None or issue number |
Coverage Design Rules
- Normal: verify that the primary role completes the core objective when preconditions are met.
- Boundary: verify minimum/maximum values, critical dates, null values, length, pagination, capacity and state transition boundaries; include only when relevant to the requirements.
- Exception: verify format errors, insufficient permissions, dependency failures, duplicate submissions, timeouts or unavailable operations; expectations should include user-visible results and state preservation requirements.
- Data flow: verify segment by segment from creation/input to validation, saving, querying, updating, syncing, exporting or deletion (if applicable), especially checking for duplication, omission, mismatch and consistency.
- Do not treat implementation details, undisclosed interfaces or unprovided internal architecture as facts. If testing requires such information, list it under items to be confirmed.
Private Information and Intermediate Data
- This skill generates documents only in the conversation by default and does not write locally or remotely; when the customer requests saving, deliver to the specified location.
- Do not read company knowledge bases, browser materials, private repositories, accounts, credentials, or unauthorized files; examples use fictional characters, orders, and data.
- If customer-provided materials contain personal information, production data, tokens, or internal identifiers, extract only the minimum rules needed to complete the test design, and replace them in the output with role names, placeholders, or anonymized data.
- If temporary drafts need to be written to disk, use the operating system temporary directory and delete them after this task is completed; do not write runtime data, caches, or credentials to the skill installation directory or repository.
- Private configuration may only be located in
~/.config/soia-skills/soia-dev-test-draft-doc/config.yml, and this skill requires no configuration and this file should not be created.
Dependencies and Installation
No mandatory software or third-party skill dependencies. The hard dependency is customer-provided, authorized requirements materials; when materials are insufficient, deliver a list of questions and a partially covered design rather than fabricating complete test cases.
Installation:
claude plugin marketplace add soia-team/soia-open-skills
claude plugin install soia-dev@soia
When using only this one skill, the npx route can be used. Note that the skill will land in the shared source of truth ~/.agents/skills; if the plugin is also installed, the same skill will have two indexes and each will drift, so it is recommended to choose one of the two:
npx skills add soia-team/soia-open-dev-skills -g -a '*' -s soia-dev-test-draft-doc -y
Configuration convention: the schema v2 path is ~/.config/soia-skills/soia-dev-test-draft-doc/config.yml. This skill has no configuration items, and there is no need to create config.yml; do not store original requirements, production data, or credentials in it.
Logs and Completion Receipt
完成：已根据 <需求材料范围> 生成测试计划、用例、回归清单和验收对照表。
日志摘要：
- 输入：<材料版本、目标端和已授权范围>
- 覆盖：<需求项数> 项；正常/边界/异常/数据流分别 <数量> 条
- 风险：<高风险项或“无”>
- 待确认：<问题编号或“无”>
验证：已核对需求 ID 到用例 ID 与验收证据的映射；未把待确认项标为已覆盖。
残余风险：<未提供的接口、规则、环境或“无”>
Quality Gates
- Each requirement corresponds to at least one acceptance condition and one test case, or explicitly states why it is untestable.
- Each test case has executable preconditions, clear steps, and observable expectations; avoid unverifiable expressions such as "the system is normal" or "meets expectations."
- High-risk requirements have at least one failure or boundary verification; when data changes are involved, have at least one data flow verification.
- Do not claim that testing has been executed: this skill generates test designs. Only after the customer provides actual execution records should the acceptance status be updated.