mobile-testing

Mobile Testing (Chinese Version)

English version: See the corresponding English skill.

When to Use

Read and follow the main prompt in "Load on Demand" (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 production distribution, changes, and incident evidence to select a risk matrix of OS × device × install/upgrade path × network × foreground/background, note samples and uncovered combinations, and do not fabricate a support list.
For deeplinks, preserve the original URI, decoding rules, routing/parameters, and authorization state; compare cold start, warm start, and restoration, and parameters must not be lost or double-decoded after restoration.
For interrupted payments, record the order/operation_id and submission point; after restoration, the server-side read-back accounting and UI state must be consistent; if the response is lost, check the status first and do not pay twice.
Verify data compatibility, permission changes, state after process termination, and resources for upgrades; unexecuted devices can only be candidates, and support scope conclusions must be separated from real device 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 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/mobile-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; do not read the entire directory.
When format conversion or auxiliary validation is needed: prefer using 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, device and system coverage, install/upgrade checks, core flows, permission handling, network and interruption behavior, push or deeplink (if relevant), performance or power consumption risks... (details are subject to the main prompt)
Has covered the minimum checklist, or indicated why it was omitted
High-risk items have clear priorities
Did not fabricate details not provided by the user
Assumptions and information gaps are marked

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.