Claude Skill

api-rate-limit-testing

Use this skill when you need to design evidence-bounded API quota, burst, and recovery scenarios; triggers include API 限流测试 and API rate limit testing.

LLM Mart · 0 points · 0 views 0 listing impressions 0 install-command copies
Virus-scanned Reviewed automatically before listing.

Full trust report

Download naodeng-awesome-qa-skills-skills_en_testing-types_api-rate-limit-testing-c44b892.zip · 6 KB
Part of naodeng/awesome-qa-skills — 97 skills

Install

skills CLI npx skills add https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-types/api-rate-limit-testing
Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install naodeng-awesome-qa-skills@llmmart
Git git clone https://github.com/naodeng/awesome-qa-skills.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole naodeng/awesome-qa-skills collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

API Rate Limit Testing

design rate-limit candidates from quota, window, burst, tenant-isolation, and recovery-response evidence. Produce ARL-## findings. This Skill organizes traceable API-quality candidates only; it does not execute tests or turn a design inventory into coverage, pass, or release evidence.

When to Use

  • When you need API rate limit testing candidates from rate-limit policies, quota windows, tenant or user dimensions, 429 responses, Retry-After, monitoring, and load-test boundaries.
  • When you need selection rationale, applicability constraints, evidence gaps, and the smallest validation action.
  • When inputs are incomplete but a bounded first pass can preserve blocked or unassessed boundaries.

Do not use it to execute tests, invent contract or behavior, replace a complete strategy, or accept risk for a Human.

Output Format Options

  • Use Markdown by default; use tables, JSON, or CSV only when explicitly requested or required by the delivery format.
  • Separate static analysis, unexecuted work, evidence states, and Human decisions; keep items unassessed, blocked, or NOT_RUN when runtime evidence is absent.

How to Use

  1. Read prompts/api-rate-limit-testing.md and provide the objective, scope, material, environment, and evidence.
  2. Complete the known, missing, conflicting, stale, out_of_scope, and assumptions input audit before findings.
  3. Record ARL-## with the subject, preconditions, behavior of concern, source evidence, and validation, plus impact/priority, owner role, close condition, and evidence state.
  4. Preserve conflicts, unknown constraints, and open questions when evidence is incomplete.

Core Constraints

  • Do not execute tests, assume missing rules, versions, thresholds, data, or responses, or treat candidate counts as coverage proof.
  • File presence, names, design declarations, and Eval configuration are not runtime evidence.
  • Mark unknowns unassessed, blocked, or pending clarification instead of filling them with convention.
  • Do not edit requirements, code, test assets, or target systems.

Pre-delivery Check

  • Recorded the known, missing, conflicting, stale, out_of_scope, and assumptions input audit.
  • Every ARL-## has source, evidence state, impact/priority, owner role, close condition, and validation.
  • Facts, inferences, recommendations, unexecuted work, and Human decisions remain separate.
  • Findings are not execution results, coverage proof, or release claims.

Reference Files

  • Read evals/eval.yaml and matching cases for regression; configuration does not prove project results.
  • Use evals/trigger-prompts.csv and evals/local-rules.json for trigger checks; missing skill.selection evidence is BLOCKED.

Common Pitfalls

  • Do not turn a method name, file presence, or candidate count into test execution, coverage, pass, or release evidence when scope or evidence is incomplete.
  • Do not fill in missing rules, thresholds, data, environments, or results from convention; preserve unassessed, blocked, and pending items.
  • Do not expand this specialist design or review into a complete strategy, full test cases, runtime execution, or a release decision.

Best Practices

  • Complete the six-part input audit before selecting the smallest traceable and verifiable finding scope.
  • Keep the source, evidence state, impact/priority, owner role, close condition, validation method, and residual risk for every finding.
  • Write validation suggestions as next actions; do not upgrade package structure, candidate counts, or local Eval configuration into real quality conclusions.
Files (awesome-qa-skills)
  • agents
    • openai.yaml 344 B
      version: 1
      metadata:
        key: "api-rate-limit-testing"
      interface:
        display_name: "API Rate Limit Testing"
        short_description: "Design evidence-backed candidates without claiming execution."
        default_prompt: "Use the api-rate-limit-testing skill to produce ARL-## findings without claiming execution."
      policy:
        allow_implicit_invocation: true
      
  • evals
    • cases
      • basic-success.yaml 900 B
        id: basic-success
        title: "API Rate Limit Testing: basic-success"
        description: |
          This case checks the api-rate-limit-testing evidence and boundary contract.
        
        input:
          prompt: |
            Use api-rate-limit-testing for this material: a login endpoint has a per-minute quota and 429 response, but burst behavior, window rollover, tenant isolation, and recovery conditions are unspecified. Start with known, missing, conflicting, stale, out_of_scope, and assumptions, then produce ARL-## with source, evidence state, priority, close condition, and validation. Do not claim tests ran.
        
        expect:
          must_contain:
            - "ARL-"
            - "known"
            - "evidence"
            - "validation"
            - "rate limit"
          must_not_contain:
            - "TODO"
            - "I cannot"
        
        judge:
          type: rule_based
          success:
            - output_contains:
                all:
                  - "known"
                  - "evidence"
                  - "validation"
                  - "rate limit"
        
      • edge-incomplete-input.yaml 650 B
        id: edge-incomplete-input
        title: "API Rate Limit Testing: edge-incomplete-input"
        description: |
          This case checks that missing inputs remain explicit and bounded.
        
        input:
          prompt: |
            Use api-rate-limit-testing with only an endpoint name and one business sentence. List missing evidence and open questions, then produce bounded ARL-## candidates without inventing a contract or execution result.
        
        expect:
          must_contain:
            - "ARL-"
            - "missing"
            - "open question"
          must_not_contain:
            - "TODO"
            - "I cannot"
        
        judge:
          type: rule_based
          success:
            - output_contains:
                all:
                  - "missing"
                  - "open question"
        
      • edge-scope-boundary.yaml 722 B
        id: edge-scope-boundary
        title: "API Rate Limit Testing: edge-scope-boundary"
        description: |
          This case checks that execution and out-of-scope requests remain explicit.
        
        input:
          prompt: |
            Use api-rate-limit-testing for design review only. The user asks to execute every check and guarantee release. State scope, unexecuted work, and Human decisions before producing ARL-##.
        
        expect:
          must_contain:
            - "ARL-"
            - "scope"
            - "unexecuted"
          must_not_contain:
            - "TODO"
            - "I cannot"
            - "tests were executed"
            - "all tests passed"
            - "release approved"
        
        judge:
          type: rule_based
          success:
            - output_contains:
                all:
                  - "scope"
                  - "unexecuted"
                  - "rate limit"
        
    • eval.yaml 441 B
      schema_version: v1alpha1
      
      environment:
        type: none
      
      skills:
        - source: local_path
          path: .
      
      engine:
        name: claude_code
      
      cases:
        files:
          - evals/cases/basic-success.yaml
          - evals/cases/edge-incomplete-input.yaml
          - evals/cases/edge-scope-boundary.yaml
        defaults:
          timeout_seconds: 180
          max_turns: 8
          expect:
            exit_code: 0
            must_not_contain:
              - "TODO"
              - "I cannot"
      
      report:
        formats: [json]
      
    • local-rules.json 141 B
      {
        "skill": "api-rate-limit-testing",
        "max_commands": 20,
        "max_total_tokens": 100000,
        "permissions": {
          "max_escalations": 0
        }
      }
      
    • trigger-prompts.csv 559 B · in bundle
  • prompts
    • api-rate-limit-testing.md 3.4 KB
      # API Rate Limit Testing Prompt
      
      Act as an evidence-driven QA test-design specialist. Based only on supplied material, design rate-limit candidates from quota, window, burst, tenant-isolation, and recovery-response evidence. Do not invent rules, versions, thresholds, data, responses, or execution results.
      
      ## Input
      
      Start with:
      - known: sourced facts about rate-limit policies, quota windows, tenant or user dimensions, 429 responses, Retry-After, monitoring, and load-test boundaries;
      - missing: absent stable IDs, scope, version, unit, threshold, constraint, data, environment, or raw execution result;
      - conflicting: contradictory contracts, behavior, applicability, expected outcomes, or evidence;
      - stale: version, rule, model, test, or report material whose current applicability is unclear;
      - out_of_scope: systems, platforms, stages, combinations, or execution actions excluded from this pass;
      - assumptions: minimum assumptions used for a bounded first pass and their impact.
      
      ## What to do
      
      Prefer rate-limit policies, quota windows, tenant or user dimensions, 429 responses, Retry-After, monitoring, and load-test boundaries, requirements, acceptance criteria, designs, changes, defects, existing tests, and raw reports.
      1. Restate the subject, scope, and success criteria.
      2. Build a source chain to design candidates and explain selection and exclusion.
      3. Select the smallest high-risk, verifiable set.
      4. Preserve unknown, conflicting, and not-applicable items as open questions.
      5. Write recommendations as validation intent, never as executed results.
      
      ## Execution Rules
      
      ### ARL-## Finding Contract
      
      Each finding contains the subject, preconditions, behavior of concern, source evidence, and validation, plus evidence state, impact/priority, owner role, and close condition.
      
      - Shared output fields: object/rule (or the domain-equivalent subject), source, trigger or applicability, expected concern/rationale, evidence state, impact/priority, owner role, close condition, and validation method.
      
      ## Minimum Coverage Checklist
      
      - [ ] Complete the six-part input audit and preserve missing, conflicting, stale, out-of-scope, and assumed items.
      - [ ] Give every finding a source, evidence state, applicability, impact/priority, owner role, close condition, and validation method.
      - [ ] Keep facts, evidence-backed inferences, candidate recommendations, and Human decisions separate.
      
      ## Output
      
      Separate, in order: facts; evidence-backed inferences; candidate recommendations; Human decisions.
      
      Objective and boundaries; six-part input audit; applicable dimensions and selection rules; ARL-## finding table; unknown, conflicting, blocked/unassessed items and residual risk; validation suggestions, Human decisions, and self-check.
      
      ## Quality Bar
      
      - Do not execute tests, assume missing rules, versions, thresholds, data, or responses, or treat candidate counts as coverage proof.
      - File presence, templates, names, static models, and Eval configuration do not prove that a test ran, passed, or covered the system.
      - Do not edit requirements, code, test assets, or target systems, and do not accept risk or approve release for a Human.
      - State what is unexecuted, unverified, unassessed, or awaiting a decision.
      
      ## Pre-delivery Self-check
      
      Did you record the six-part input audit? Does every ARL-## have source, evidence, impact/priority, owner role, close condition, and validation? Are facts, inferences, recommendations, and Human decisions separate?
      
  • SKILL.md 3.7 KB
    ---
    name: api-rate-limit-testing
    description: Use this skill when you need to design evidence-bounded API quota, burst, and recovery scenarios; triggers include API 限流测试 and API rate limit testing.
    ---
    
    # API Rate Limit Testing
    
    design rate-limit candidates from quota, window, burst, tenant-isolation, and recovery-response evidence. Produce ARL-## findings. This Skill organizes traceable API-quality candidates only; it does not execute tests or turn a design inventory into coverage, pass, or release evidence.
    
    ## When to Use
    
    - When you need API rate limit testing candidates from rate-limit policies, quota windows, tenant or user dimensions, 429 responses, Retry-After, monitoring, and load-test boundaries.
    - When you need selection rationale, applicability constraints, evidence gaps, and the smallest validation action.
    - When inputs are incomplete but a bounded first pass can preserve blocked or unassessed boundaries.
    
    Do not use it to execute tests, invent contract or behavior, replace a complete strategy, or accept risk for a Human.
    
    ## Output Format Options
    
    - Use Markdown by default; use tables, JSON, or CSV only when explicitly requested or required by the delivery format.
    - Separate static analysis, unexecuted work, evidence states, and Human decisions; keep items unassessed, blocked, or NOT_RUN when runtime evidence is absent.
    
    ## How to Use
    
    1. Read prompts/api-rate-limit-testing.md and provide the objective, scope, material, environment, and evidence.
    2. Complete the known, missing, conflicting, stale, out_of_scope, and assumptions input audit before findings.
    3. Record ARL-## with the subject, preconditions, behavior of concern, source evidence, and validation, plus impact/priority, owner role, close condition, and evidence state.
    4. Preserve conflicts, unknown constraints, and open questions when evidence is incomplete.
    
    ## Core Constraints
    
    - Do not execute tests, assume missing rules, versions, thresholds, data, or responses, or treat candidate counts as coverage proof.
    - File presence, names, design declarations, and Eval configuration are not runtime evidence.
    - Mark unknowns unassessed, blocked, or pending clarification instead of filling them with convention.
    - Do not edit requirements, code, test assets, or target systems.
    
    ## Pre-delivery Check
    
    - [ ] Recorded the known, missing, conflicting, stale, out_of_scope, and assumptions input audit.
    - [ ] Every ARL-## has source, evidence state, impact/priority, owner role, close condition, and validation.
    - [ ] Facts, inferences, recommendations, unexecuted work, and Human decisions remain separate.
    - [ ] Findings are not execution results, coverage proof, or release claims.
    
    ## Reference Files
    
    - Read evals/eval.yaml and matching cases for regression; configuration does not prove project results.
    - Use evals/trigger-prompts.csv and evals/local-rules.json for trigger checks; missing skill.selection evidence is BLOCKED.
    
    ## Common Pitfalls
    
    - Do not turn a method name, file presence, or candidate count into test execution, coverage, pass, or release evidence when scope or evidence is incomplete.
    - Do not fill in missing rules, thresholds, data, environments, or results from convention; preserve unassessed, blocked, and pending items.
    - Do not expand this specialist design or review into a complete strategy, full test cases, runtime execution, or a release decision.
    
    ## Best Practices
    
    - Complete the six-part input audit before selecting the smallest traceable and verifiable finding scope.
    - Keep the source, evidence state, impact/priority, owner role, close condition, validation method, and residual risk for every finding.
    - Write validation suggestions as next actions; do not upgrade package structure, candidate counts, or local Eval configuration into real quality conclusions.
    

Comments (0)

Sign in to join the conversation.

No comments yet.

Reviews (0)

No reviews yet.

Related