---
description: Generate a k6 load test for a single provided endpoint using all the k6 skills
argument-hint: "<endpoint-url> [output-file] [test-type]"
---

Generate a complete, runnable k6 load test for the endpoint at `$1`, guided by the k6 skills in this package. The default output file is `${2:-tests/k6/endpoint-test.js}` and the default test type is `${3:-load}`.

## Step 1 — Load the k6 skills

Before writing any code, use `read` to load the SKILL.md files for these skills from the package `skills/` directory (follow the reference files they point to when relevant):

- **designing-test-scenarios** — always; needed for the load profile and thresholds.
- **generating-api-load-tests** — always; needed for the script structure and protocol patterns.
- **analyzing-test-results** — always; needed to verify and interpret the validation run.

Load these additional skills only when the corresponding condition applies:

- **generating-tests-from-openapi** — the user provides an OpenAPI spec for the endpoint.
- **generating-tests-from-code** — the endpoint's source code exists in the current workspace.
- **generating-browser-tests** — the endpoint serves HTML and the user wants browser-level (Web Vitals) testing instead of protocol-level.
- **testing-resilience** — the user asks for fault injection or chaos testing against the endpoint.
- **operating-k6-in-ci-cd** — the user asks for a CI pipeline snippet along with the test.

## Step 2 — Probe the endpoint

- Use `bash` with `curl -s -o /dev/null -w "%{http_code} %{time_total}"` (or similar) to verify the endpoint is reachable and note the status, latency, content type, and auth requirements.
- If the endpoint requires authentication, determine the scheme (Bearer token, basic, cookie, API key) and ask the user to supply credentials via an environment variable or env file. **Never hardcode credentials in the generated script** — read them from `__ENV`.
- If the endpoint is unreachable, still generate the script against the given URL and note that verification was skipped.

## Step 3 — Confirm the test design

Ask the user (or infer sensibly and state the assumptions) for:

- **Test type** (`$3`, default `load`): map it to an executor and load profile using the *designing-test-scenarios* skill — smoke, load, stress, spike, soak, or breakpoint.
- **Performance targets**: p95/p99 latency and error-rate thresholds; use the skill's threshold guidance (e.g. `http_req_failed: ['rate<0.01']`, `http_req_duration: ['p(95)<500']`) if none are given.
- **Auth and test data**: environment variables needed, any request body for POST/PUT endpoints, and whether test data should be parameterized per the *generating-api-load-tests* skill.

## Step 4 — Generate the script

- Write the test to `${2:-tests/k6/endpoint-test.js}` using kebab-case file names, following the *generating-api-load-tests* skill patterns:
  - All config via `__ENV` with sensible defaults (`BASE_URL`, `HEADERS`, `STAGES_*`).
  - `export const options` with the chosen executor, stages, thresholds, and tags (e.g. `{ name: '$1' }`).
  - A `default` function that hits the endpoint, applies `check`s for status and content, and `sleep`s with realistic think time.
  - `setup()`/`teardown()` only if auth tokens or shared data require them.
- If an OpenAPI spec was provided, follow *generating-tests-from-openapi* for request construction and auth mapping; if the API source is in the workspace, follow *generating-tests-from-code* to mirror real routes and payloads.
- If browser testing applies, generate the browser variant per the *generating-browser-tests* skill (import from `k6/browser`, `export async function default(page)`, Web Vitals measurements).
- If CI is requested, add a pipeline snippet per *operating-k6-in-ci-cd* (GitHub Actions unless specified otherwise).

## Step 5 — Validate and analyze

- Run `k6 inspect <output-file>` to confirm the script parses and options are exported.
- With the user's permission (and only for endpoints you are authorized to test), run a short smoke validation, e.g. `k6 run --iterations 2 <output-file>`.
- If a run was executed, apply the *analyzing-test-results* skill to read the summary: threshold pass/fail, percentiles, and any bottleneck signals.
- Report the results and suggested next steps (e.g. tuning VUs, adding scenarios, running a soak).

## Rules

- Only target endpoints the user owns or has explicit authorization to load test.
- Never fire load at production endpoints without the user's explicit confirmation; default to a 2-iteration smoke validation only.
- Never echo, log, or persist credentials; use `__ENV` exclusively.
- Do not overwrite existing test files; pick a new file name if the target exists.
- Keep the script idiomatic k6 (init context, options export, checks, tags); avoid dead code and unused imports.

After generating, summarize:
- The endpoint, chosen test type, executor, and thresholds (and why).
- The output file path(s) and any env variables required to run it.
- The probe/validation results and analysis from any executed run.
- Which k6 skills were loaded and how each shaped the result.