api-rate-limit-testing

API rate limit testing

Design rate-limiting candidates based on quota, window, burst, tenant isolation, and recovery response evidence, and output ARL-## findings. It only organizes traceable API quality candidates; it does not execute tests, nor does it write the design checklist as coverage, pass, or release evidence.

When to use

• When you need to extract API rate limit testing candidates from rate-limiting policies, quota windows, tenant or user dimensions, 429 responses, Retry-After, monitoring, and load-testing boundaries.
• When you need to explain the rationale for selection, applicable constraints, evidence gaps, and minimal verification actions.
• When materials are incomplete but a constrained initial version must still be delivered, with blocked or unassessed boundaries clearly stated.

Not applicable to directly executing tests, generating contracts or behaviors without sources, replacing a complete test strategy, or accepting risk on behalf of the Human.

Output format options

• Default output is Markdown; use tables, JSON, or CSV only when the user explicitly needs them or the existing delivery format requires them.
• Separate static analysis, unexecuted items, evidence status, and Human decisions; keep unassessed, blocked, or NOT_RUN when there is no execution evidence.

How to use

1. Read prompts/api-rate-limit-testing.md, and provide the goal, scope, materials, environment, and existing evidence.
2. First complete the six-category input audit: known, missing, conflicting, stale, out_of_scope, assumptions.
3. Use ARL-## to record the object, preconditions, behavior of interest, source evidence, and verification method, retaining impact/priority, responsible role, closure conditions, and evidence status.
4. When materials conflict, constraints are missing, or there is no execution evidence, retain both sides and the open questions.

Domain execution points

• Extract the algorithm, quota N, window start/end and time source, burst allowance, counting object, user/tenant/route scope, and reset rules.
• List the quota ledger and expected/actual responses by subject and time; rate-limiting correctness includes both rejecting excess and allowing requests within the quota.
• When forming domain candidates, you must read and follow prompts/api-rate-limit-testing.md the domain operations and determination process, retaining legitimate controls, evidence gaps, and verification actions item by item.

Core constraints

• Do not execute tests, do not assume rules, versions, thresholds, data, or responses that were not provided, and do not treat the number of candidates as proof of coverage.
• File existence, name matching, design declarations, or Eval configuration do not equal real execution evidence.
• Mark unknowns as unassessed, blocked, or to be confirmed; do not fill them in with common sense.
• Do not modify requirements, code, test assets, or the target system.

Pre-delivery self-check

• The six-category input audit has been recorded: known, missing, conflicting, stale, out_of_scope, assumptions.
• Each ARL-## has a source, evidence status, impact/priority, responsible role, closure conditions, and verification method.
• Facts, inferences, recommendations, unexecuted items, and Human decisions have been distinguished.
• Design candidates have not been written as execution results, coverage proof, or release conclusions.

Reference files

• During regression, read evals/eval.yaml and the matching test cases; configuration does not prove real project results.
• Trigger validation uses evals/trigger-prompts.csv and evals/local-rules.json; when skill.selection evidence is missing, report BLOCKED.

Common Pitfalls

• When scope or evidence is incomplete, do not write method names, file existence, or candidate counts as test executed, covered, passed, or release evidence.
• Do not use common sense to fill in rules, thresholds, data, environments, or results that were not provided; retain unassessed, blocked, and to-be-confirmed items.
• Do not expand this Skill's specialized candidates into a complete strategy, complete test cases, actual execution, or release decisions.

Best Practices

• Complete the six-category input audit first, then choose the smallest, traceable, and verifiable discovery scope.
• For each finding, retain the source, evidence status, impact/priority, responsible role, closure conditions, and verification method, and clearly state the residual risk.
• Write verification recommendations as next-step actions, and do not upgrade the Skill package structure, candidate counts, or local Eval configuration into real quality conclusions.