automation-testing

Automation Testing (Chinese version)

English version: See the corresponding English skill.

When to use

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.

Use the table Candidate flow | Protection obligation | Repetition frequency evidence | oracle/observability | Data isolation/cleanup | Stability | Maintenance constraints | Adoption/deferral rationale for selection; list cost scenarios separately for ROI, and they cannot offset a missing oracle or an unauthorized environment.
Prefer to reuse the existing framework; first check whether there is a CI entry point with verifiable postconditions, independently available data, and propagatable failures; defer those that do not meet this and write the release conditions.
Execution scenarios include a unique account/business key, precondition state, actions, business postconditions, failure signals, and teardown; failures must make the runner/CI fail, not merely be logged.
Distinguish automation candidates, generated assets, real execution, and business acceptance; keep frequently changing prototypes or real deductions that cannot be isolated as manual/controlled verification candidates, and explain the trade-offs by risk and evidence.

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 executable: 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/automation-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 deep materials such as framework specifications, troubleshooting, or report schema are needed: read only the files in references/ that are relevant to the current problem; do not read the entire directory.
When format conversion or auxiliary validation is needed: prefer to use the existing scripts in 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。

Has followed the main prompt's output structure
Minimum coverage focus: scope and goals, parts suitable for automation, parts not to be automated for now, risk and benefit prioritization, fit with existing frameworks, environment and data requirements, flaky test risks, CI or execution approach... (details are subject 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 stretches of vague theory unrelated to the current toolchain.