performance-test-k6

Performance Testing (k6) (Chinese Version)

English version: See the corresponding English skill.

When to Use

You need to fit performance testing results into the k6 structure.
The project is already using k6, or you want the output to be directly compatible with k6.

Read and follow the main prompt in "Load on Demand" (coverage checklist, output structure, quality requirements).
Only supplement project context that truly affects the results: 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.

Prioritize by risk/business impact; do not spread effort evenly.
Write "confirmed facts" and "current assumptions" separately; when there is no SLA/no traffic, mark all numbers as "assumptions" and provide a list of items to be confirmed.
Do not fabricate interfaces, fields, environments, or root cause details not provided by the user; use only placeholders for secrets / __ENV; real tokens are prohibited.
Results must be actionable: scenarios specific, prioritized, and able to guide the next step.
By default, select only the most critical 1-2 types of performance scenarios; do not by default do baseline/load/stress/spike/soak all at once.

Before producing output, you must read and follow prompts/performance-test-k6.md(minimum coverage checklist, output structure, quality requirements).
When you need to apply an existing template: read the matching template in output-templates/ ; do not invent a conflicting structure.
When the user wants examples or to benchmark against existing assets: read the relevant examples in examples/ .
When you need in-depth materials such as framework specifications, troubleshooting, or report schema: read only the files in references/ that are relevant to the current problem; do not read the entire directory.
When you need format conversion or auxiliary validation: prefer using the existing scripts in scripts/ rather than rewriting them.
When you need to evaluate/regress this skill: use evals/, and validate and run it with skill-up.

The output structure of the main prompt has been followed
Minimum coverage concerns: target scenarios, load model, data requirements, VU or duration configuration, thresholds, environment and monitoring, key bottlenecks, result reporting requirements... (details are subject to the main prompt)
The minimum checklist has been covered, or it is indicated why items were omitted
High-risk items have clear 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 fully 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.