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 test 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.
| Customer wants | Skill will do | 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 test case table and items to be confirmed |
| Pre-release regression and acceptance | Identify 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 uncertainty: distinguish the original material text, test assumptions that can be derived from the original text, and questions to be confirmed by 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 clarify test scope, strategy, environment/data prerequisites, entry and exit criteria, and risks.
- Design test 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 according to 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 mapping: map each requirement ID to test 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 test 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 contradictory rules have been explicitly reported.
Output contract
Deliver in Markdown by default; when the customer specifies tables, test management system fields, or CSV templates, keep the following semantics unchanged.
1. Test plan
| Field | Content |
|---|---|
| Objectives and Scope | Objectives, inclusion/exclusion scope, target endpoints 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 being able to start and able to finish |
| Items to Be Confirmed | Missing rules, responsible roles and blocking impact |
2. Test Cases
| Case ID | Requirement ID | Type | Preconditions | Steps | Expected Results | Priority |
|---|---|---|---|---|---|---|
| TC-001 | R-001 | Normal | Logged-in test user | Execute 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, absence of side effects/recoverability, not merely that "an error was reported."
3. Regression Checklist and Acceptance Traceability Matrix
The regression checklist includes entry points, critical paths, cross-end/API, shared data, permissions and known high-risk items, and marks them as must-regress or change-triggered.
| 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 requirement.
- Exception: verify format errors, insufficient permissions, dependency failures, duplicate submissions, timeouts or unavailable operations; expectations should include user-visible results and state retention requirements.
- Data flow: verify segment by segment from creation/input to validation, saving, querying, updating, synchronization, export or deletion (if applicable), especially checking for duplication, omission, mismatch and consistency.
- Do not treat implementation details, undisclosed interfaces or internal architecture that has not been provided as facts. If testing requires such information, list it under items to be confirmed.
Private Information and Intermediate Data
- This skill by default only generates documents in the conversation and does not write locally or remotely; when the customer requests saving, deliver to their specified location.
- Do not read company knowledge bases, browser materials, private repositories, accounts, credentials or unauthorized files; examples use fictional roles, 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 masked data.
- If temporary drafts need to be persisted, use the operating system temporary directory and delete them after this completion; do not write runtime data, caches, or credentials into the skill installation directory or repository.
- Private configuration may only be located at
~/.config/soia-skills/soia-dev-draft-test-doc/config.yml, and this skill requires no configuration, so this file should not be created.
Dependencies and Installation
There are no mandatory software or third-party skill dependencies. The hard dependency is the customer-provided, authorized requirements material; when the material is insufficient, deliver a list of issues and a partially covered design rather than fabricating complete test cases.
Installation:
npx skills add soia-team/soia-open-dev-testing-skills -g -a '*' -s soia-dev-draft-test-doc -y
Configuration convention: the schema v2 path is ~/.config/soia-skills/soia-dev-draft-test-doc/config.yml. This skill has no configuration items, and there is no need to create config.yml; do not store original requirements text, production data, or credentials in it.
Logging 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 not testable.
- 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, there is at least one data flow verification.
- Do not claim that tests have been executed: this skill generates test designs. Only after the customer provides actual execution records should the acceptance status be updated.