functional-testing

Functional Testing (Chinese Version)

English version: See the corresponding English skill.

When to Use

You need to handle functional 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 "current assumptions" and "questions to confirm / information gaps".
Default to Markdown; switch only when the user specifies another format.

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 not provided by the user.
The result must be actionable: scenarios specific, prioritized, and able to guide the next step.

Before producing output, you must read and follow prompts/functional-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 ready-made templates need to be applied: read output-templates/ for the matching template; do not invent conflicting structures.
When the user wants examples or to benchmark against existing assets: read examples/ for the relevant samples.
When in-depth materials such as framework specifications, troubleshooting, or report schemas are needed: read only references/ for files relevant to the current problem; do not read the entire directory.
When format conversion or auxiliary validation is needed: prefer using scripts/ existing scripts rather than rewriting them.
When evaluating/regressing this skill: use evals/, and validate and run with skill-up.
When the user only wants the shortest onboarding path: read quick-start.md。

The main prompt's output structure has been followed
Minimum coverage focus: scope, core flows, positive scenarios, exception scenarios, boundary scenarios, role or permission differences, data conditions, integration points… (details are subject to the main prompt)
The minimum checklist has been covered, or it is noted why items are omitted
High-risk items have explicit priorities
No details not provided by the user have been fabricated
Assumptions and information gaps have been marked

When both scope and context are unclear, do not pretend it is already complete and usable.
Do not write all items as equally important.
Do not skip assumptions and information gaps.
Do not output large sections of vague theory unrelated to the current toolchain.