test-runtime-optimization

Test Execution Time Optimization (Chinese Version)

When to Use

When evidence-based analysis, design, or verification preparation is needed around slow tests, profiling evidence, setup/teardown, parallelism, isolation, and baselines.
When existing solutions, results, or metrics need review, and actionable improvement items need to be produced.
When inputs are incomplete, but a constrained initial version still needs to be delivered with assumptions, information gaps, and Human decision boundaries.

The default output is Markdown, organized by domain risk, evidence status, priority, and boundaries.
When the user requests table, CSV, JSON, or ticket formats, retain the same finding fields, evidence, and decision boundaries.
Before output enters an automated process, first confirm the schema, enum values, required fields, and evidence sources.

First read and follow prompts/test-runtime-optimization.md, including input audit, domain coverage, and output order.
Extract scope, environment, version, time window, constraints, success criteria, and available evidence, with a focus on slow tests, profiling evidence, setup and teardown, parallelism, and isolation.
First distinguish confirmed facts, evidence-supported inferences, candidate recommendations, and Human decisions, then sort by risk and evidence strength.
Convert high-risk items into preconditions, steps, expected results or judgment criteria, required evidence, and verification methods.
When information is insufficient, deliver a constrained initial version, make clear which conclusions cannot hold, and do not write static materials as execution results.

When calibrating domain results, correct controls, or evidence gaps, read references/domain-decision-example.md 's redacted inputs, item-by-item expectations, and recomputation basis.
Each execution must read prompts/test-runtime-optimization.md; it is the complete execution specification for this Skill.
When evaluation is needed, read evals/eval.yaml and the matching test cases under evals/cases/ .
Only read references/、examples/、scripts/ or output-formats.mdwhen the directory actually exists and the task requires it; do not assume assets that do not exist.

Use event profiles for the same commit/test obligations/data/resources/window to split setup, execute, teardown, and retries; derive the critical path along the dependency DAG, and do not add overlapping jobs together.
Separately list cold/warm caches, runner limits, concurrency, independent data, and resource contention; record the factors candidates change, and do not infer speedups from different test scales or environments.
Check whether the same business failures are still detected by valid assertions, with failures and logs/traces retained; adding parallelism must not share accounts or swallow exceptions, and time improvements must not offset lost protection.
Give baseline/candidate durations, resource costs, benefit ratios, and rollback signals; only actually comparable runs count as observed benefits, design estimates remain candidates, and must not be treated as production guarantees.

Only analyze slow tests, profiling evidence, setup/teardown, parallelism, isolation, and baselines; do not replace business owners or Human decisions on risk acceptance, exception approval, and release decisions.
Do not fabricate system behavior, fields, metrics, thresholds, data, root causes, execution records, or pass conclusions.
Static designs, plans, file existence, or dry-runs can only retain the original evidence status and cannot be upgraded to proof of real execution.
When evidence is insufficient, use pending confirmation, blocked, unassessed, or NOT_SCORED, and provide a minimal verification method.
When production, privacy, or security is involved, use least privilege, desensitized data, mock, dry-run, or an isolated environment.

Slow tests, profiling evidence, initialization and cleanup, parallelism, and isolation are covered, and the source, evidence status, and verification method are recorded for each item.
Facts, inferences, candidate recommendations, information gaps, and Human decisions are separated.
High-risk items have P0/P1/P2/P3 or equivalent priority, responsible role, and closure conditions.
Plans, static checks, or dry-runs are not written as test execution, all passing, or release approval.
Remaining risks, stop/escalation conditions, and next steps are stated.

Listing only checkpoints without explaining trigger conditions, expected points of attention, responsible roles, closure conditions, and evidence.
Treating metrics or tool names from adjacent domains as a complete judgment of test runtime.
Using unexplained numbers to create false precision, or writing correlation as causation.
Directly refusing when the input is incomplete, or conversely pretending the conclusion is already certain.

Start from the path most likely to cause business loss, quality regression, or decision blockage.
Use the smallest verifiable experiment to reduce uncertainty, and record conditions, versions, sources, and evidence.
Enable another engineer to independently install, execute, and review the outputs of this Skill.