manual-testing

Manual/Exploratory Testing (Chinese version)

English version: See the corresponding English skill.

When to use

You need to handle manual testing-related tasks in a real project.
You need a result that can be used directly for execution, review, or follow-up.

Read and follow the main prompt in "Load as needed" (coverage checklist, output structure, quality requirements).
Only supplement project context that truly affects the result: scope, environment, constraints, risks, dependencies, expected deliverables.
When information is incomplete, first provide a usable initial version and explicitly mark assumptions and information gaps.
Default to Markdown; switch only when the user specifies another format.

Establish a charter for each time box: task/risk, environment/build, data, exploration scope, deadline, and evidence; account separately for executing established paths and exploring new issues, and do not expand authorization on your own.
Step record: preconditions → action → expected → actual → evidence ID → status; not started is NOT_RUN, interrupted is INCOMPLETE, environment-blocked is BLOCKED, and do not treat the checklist as a completion record.
First prepare recoverable data and checkpoints; at the end, restore accounts, orders, and configurations according to project rules and verify leftovers; unauthorized deletion cannot be used as a cleanup shortcut.
If time is insufficient, first complete the critical risk loop and save unfinished items, owners, and recovery entry points; the report covers only real observations, and unknown expectations remain to be confirmed.

Prioritize by risk/business impact; do not spread effort evenly.
Write "confirmed facts" and "current assumptions" separately.
Do not fabricate interfaces, fields, environments, or root-cause details that the user did not provide.
The result must be actionable: scenarios specific, prioritized, and able to guide the next step.

When calibrating domain results, correct comparisons, or evidence gaps, read references/domain-decision-example.md 's desensitized inputs, item-by-item expectations, and recalculation basis.
Before producing output, you must read and follow prompts/manual-testing.md(minimum coverage checklist, output structure, quality requirements).
When Excel/CSV/JSON/Word or other formats are needed: read output-formats.md, and output according to the user's format requirements.
When a ready-made template needs to be applied: read the matching template in output-templates/ , and do not invent a conflicting structure.
When the user wants examples or to benchmark against existing assets: read the relevant samples in examples/ .
When in-depth materials such as framework specifications, troubleshooting, or report schemas are needed: read only the files in references/ that are relevant to the current issue, and do not read through the entire directory.
When format conversion or auxiliary validation is needed: prefer using the existing scripts in scripts/ , rather than rewriting them.
When this skill needs to be evaluated/regressed: use evals/, and validate and run it with skill-up.
When the user only wants the shortest onboarding path: read quick-start.md。

Has followed the main prompt's output structure
Minimum coverage focus: scope, critical paths, environment and account preparation, positive checks, exception checks, boundary checks, exploratory priorities, evidence to collect... (for details, refer to the main prompt)
Minimum checklist covered, or state why it is omitted
High-risk items have clear priorities
No details fabricated that the user did not provide
Assumptions and information gaps are identified

When neither the scope nor the context is clear, do not pretend it is already fully usable.
Do not write all items as equally important.
Do not skip assumptions and information gaps.
Do not output long passages of vague theory unrelated to the current toolchain.