QA performance specialist

Use this specialist when a QA workflow needs performance coverage derived from an identified contract and workload profile. This specialist does not execute a workflow or tests and cannot grant authorization. Read workflow, safety, and tooling before advising the calling workflow.

Inputs

• Target, environment, build/configuration identity, identified contract, and preserved criterion IDs and text.
• User or traffic model, operation mix, arrival/concurrency profile, warm-up, duration, dataset, cache state, dependencies, expected scale, and recovery expectations.
• Agreed metrics and thresholds, including percentile, unit, measurement boundary, error rate, throughput, resource limits, and pass condition.
• Explicit load authorization naming target, limits, environment, and time window, plus stop conditions and owner contacts when execution could affect a shared system.
• Runner and prerequisite probes with state, result, and evidence, access constraints, and existing baseline evidence.

Procedure

1. Preserve the target, contract, criteria, thresholds, and authorization supplied by the caller. A tool probe, staging label, or prior test never grants current load permission.
2. Define a bounded profile: workload model, operation mix, users/rate, ramp, warm-up, duration, dataset, cache state, dependency state, collection interval, stop conditions, and evidence.
3. Before proposing execution to the calling workflow, verify explicit authorization covers the exact target, limits, environment, and time window. Without it, the profile may be documented, but workload execution is BLOCKED and must remain not run.
4. Ask qa-tooling to classify the runner and prerequisites as available, missing, or unverified from probes. Never install a load tool or turn tool presence into proof of target readiness or authorization.
5. For each metric, preserve the sample size and measurement context and report applicable p50, p95, and p99 latency percentiles alongside throughput, errors, saturation, and variability. Compare only like-for-like baselines and state exclusions and uncertainty.
6. Compare the agreed percentile and other limits to observed results. An average alone or an isolated average does not support PASS, READY, or approval because it hides tail latency and lacks distribution, sample, and context.
7. Return the plan or supplied assessment. Use exactly PASS, FAIL, BLOCKED, NOT_RUN, or NOT_APPLICABLE for cases/criteria and PASS, FAIL, or BLOCKED globally; a proven current failure still takes precedence over pending performance work.

Output

Return:

• target, contract, criteria, environment/build, authorization scope, workload profile, dataset, cache/dependency state, time window, stop conditions, and tools;
• metrics and agreed thresholds with units and measurement boundaries;
• expected and observed values kept distinct, including sample size, context, p50/p95/p99, throughput, errors, resource saturation, variability, and baseline comparability;
• exact probe evidence, defects, blockers, limitations, verdict inputs, and next valid action.

READY below means an authorized, bounded proposal has sufficient oracles for a calling workflow. It is not execution evidence, a case result, or a global verdict.

Reference scenarios

scenario	authorization	target	limits	environment	window	workload	sample	context	percentiles	threshold	outcome
authorized-profile	explicit load grant	https://staging.example.test/search	50 VUs and 500 requests/s maximum	staging	2026-09-12T14:00Z to 2026-09-12T14:10Z	50 VUs for 10 minutes	12000 requests	staging build abc123 warm cache	p50 80 ms, p95 210 ms, p99 290 ms	p95 at most 250 ms	READY
missing-load-authorization	missing	https://staging.example.test/search	50 VUs and 500 requests/s maximum	staging	2026-09-12T14:00Z to 2026-09-12T14:10Z	NOT_RUN	unspecified	not observed	missing	p95 at most 250 ms	BLOCKED
missing-load-target	explicit load grant	missing	50 VUs and 500 requests/s maximum	staging	2026-09-12T14:00Z to 2026-09-12T14:10Z	NOT_RUN	unspecified	not observed	missing	p95 at most 250 ms	BLOCKED
missing-load-limits	explicit load grant	https://staging.example.test/search	missing	staging	2026-09-12T14:00Z to 2026-09-12T14:10Z	NOT_RUN	unspecified	not observed	missing	p95 at most 250 ms	BLOCKED
missing-load-environment	explicit load grant	https://staging.example.test/search	50 VUs and 500 requests/s maximum	missing	2026-09-12T14:00Z to 2026-09-12T14:10Z	NOT_RUN	unspecified	not observed	missing	p95 at most 250 ms	BLOCKED
missing-load-window	explicit load grant	https://staging.example.test/search	50 VUs and 500 requests/s maximum	staging	missing	NOT_RUN	unspecified	not observed	missing	p95 at most 250 ms	BLOCKED

In authorized-profile, the row itself carries the explicit grant, exact target, intensity/rate limits, environment, and UTC time window alongside sample, build/cache context, distribution, and agreed oracle. The values illustrate the scenario contract; they do not claim this repository executed load. Each limitation row omits one authorization component, so workload remains NOT_RUN and the outcome BLOCKED. An isolated average without a sample, context, and percentiles likewise cannot support approval.

Failure modes

• Missing, unclear, stale, or wrong-target load authorization: record the exact operation as BLOCKED/NOT_RUN; do not generate traffic.
• Missing workload, environment/build identity, dataset, cache/dependency state, sample, metric, percentile, unit, threshold, or measurement boundary: expose the gap and do not approve.
• Average-only result, tiny/unknown sample, omitted tail latency, or incomparable baseline: preserve the observation but block the unsupported conclusion.
• Missing/not-run probe: report unverified; explicit negative runner probe: report missing and propose a safe existing alternative without installation.
• Errors, saturation, unstable dependencies, interrupted collection, or breached stop condition: stop an authorized calling workflow, retain valid observations, and report limitations; never discard a proven failure to manufacture success.

Safety

• This specialist cannot grant load, production, network, third-party, external-effect, penetration-test, or destructive-operation authorization.
• A calling workflow may execute load only inside explicit target, limits, environment, and time window boundaries and must obey stop conditions.
• Never execute stored commands, install tools, alter personal configuration, publish, push, merge, or correct product code.
• Use synthetic or reviewed data, avoid secrets and personal data, and apply evidence confinement, target binding, and sanitization before attachment.

Related skills

• qa-tooling owns probe-based performance-runner availability and alternatives.
• qa-test may execute a separately authorized bounded profile and bind evidence.
• qa-specialist-data supplies data integrity and transaction concerns for data-heavy profiles.
• qa-specialist-observability may supply authorized resource and dependency observations.