performance-test-gatling (EN) - QA Skill Library

Why this Skill

It turns this Skill's method into a quality input that can be executed, reviewed, and reused.

Need performance outputs that should land in Gatling structure.
Prioritize by risk / business impact — do not treat everything equally.
Separate confirmed facts from current assumptions; with no SLA/traffic, label every number as Assumption and list Open Questions.
Do not invent endpoints, fields, environments, or root causes the user did not provide; secrets are placeholders / env vars only — never real tokens.
Do not pretend completeness when scope/context is missing.

When to use

Use this Skill

Need performance outputs that should land in Gatling structure.
The project already uses Gatling or wants Gatling-ready scenarios.

Common pitfalls

Do not pretend completeness when scope/context is missing.
Do not treat every item as equally important.
Do not skip assumptions and information gaps.
Do not dump generic theory unrelated to the current toolchain.

Input

Minimum Input

The current task scope, objective, and subject under review.

Recommended Input

Before producing output, read and follow prompts/performance-test-gatling.md (minimum coverage, output structure, quality bar).
When a ready-made template fits: use matching files under output-templates/.
When the user wants examples or alignment with existing assets: read relevant examples/.
For deep framework/troubleshoot/schema notes: read only the relevant file(s) under references/, do not load the whole directory.

Optional Context

For format conversion or helper checks: prefer existing scripts/ over reinventing.
For evaluating/regressing this skill: use evals/ with skill-up.

Output

The output follows this Skill's method and makes facts, assumptions, risks, and next steps explicit.

Judge the output value before installing

01Followed the main prompt's output structure
02Minimum coverage focus: target scenarios, load model, test data or feeder needs, ramp profile, thresholds, environment and monitoring, priority bottlenecks, reporting needs, ... (details in main prompt)
03Covered the minimum checklist, or explained omissions
04High-risk items have explicit priority

View full output structure

05Did not invent details the user did not provide
06Assumptions and gaps are marked

How It Works

01Read and follow the main prompt listed under Progressive disclosure (coverage, structure, quality bar).
02Add only project context that changes the result: scope, environment, constraints, risks, dependencies, expected deliverable.
03If input is incomplete, return a usable first draft and explicitly mark assumptions and gaps.
04Default to Markdown; switch formats only when the user asks.

Install & Quick Start

Install command / SHELL

npx skills add \
  https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-types/performance-test-gatling
  -g

performance-test-gatling.prompt

@skill performance-test-gatling

Using the current project context, produce an actionable result following this Skill.

Additional context:
[Paste project context or requirement]

---
name: performance-test-gatling
description: Use this skill when you need Gatling performance scope, simulations, or runnable entry points; triggers include Gatling, Gatling simulations, and Gatling performance testing.
---

# performance-test-gatling (EN)

**Chinese version：** See the corresponding Chinese skill.

## When to Use

- Need performance outputs that should land in Gatling structure.
- The project already uses Gatling or wants Gatling-ready scenarios.

## Workflow

1. Read and follow the main prompt listed under Progressive disclosure (coverage, structure, quality bar).
2. Add only project context that changes the result: scope, environment, constraints, risks, dependencies, expected deliverable.
3. If input is incomplete, return a usable first draft and explicitly mark assumptions and gaps.
4. Default to Markdown; switch formats only when the user asks.

## Core Constraints

- Prioritize by risk / business impact — do not treat everything equally.
- Separate confirmed facts from current assumptions; with no SLA/traffic, label every number as Assumption and list Open Questions.
- Do not invent endpoints, fields, environments, or root causes the user did not provide; secrets are placeholders / env vars only — never real tokens.
- Keep output executable: concrete scenarios, clear priority, clear next steps.
- Default to only the most critical 1–2 scenario types — do not run baseline/load/stress/spike/soak all by default.

## Progressive Disclosure

- Before producing output, read and follow `prompts/performance-test-gatling.md` (minimum coverage, output structure, quality bar).
- When a ready-made template fits: use matching files under `output-templates/`.
- When the user wants examples or alignment with existing assets: read relevant `examples/`.
- For deep framework/troubleshoot/schema notes: read only the relevant file(s) under `references/`, do not load the whole directory.
- For format conversion or helper checks: prefer existing `scripts/` over reinventing.
- For evaluating/regressing this skill: use `evals/` with skill-up.

## Pre-delivery Checklist

- [ ] Followed the main prompt's output structure
- [ ] Minimum coverage focus: target scenarios, load model, test data or feeder needs, ramp profile, thresholds, environment and monitoring, priority bottlenecks, reporting needs, ... (details in main prompt)
- [ ] Covered the minimum checklist, or explained omissions
- [ ] High-risk items have explicit priority
- [ ] Did not invent details the user did not provide
- [ ] Assumptions and gaps are marked

## Common Pitfalls

- Do not pretend completeness when scope/context is missing.
- Do not treat every item as equally important.
- Do not skip assumptions and information gaps.
- Do not dump generic theory unrelated to the current toolchain.