agentleFS
kvantatechkvantatech/RedLine/.claude/skills/k6-smoke-test/SKILL.md

k6-smoke-test

Skill1 starsChanged 3 months agoMITView on GitHub

Use this skill when the user wants a quick k6 smoke test to verify basic functionality under minimal load. Smoke tests run 1–5 VUs for a short duration and assert that endpoints respond correctly. Trigger on "smoke test", "sanity check", or "quick health check with k6".

The file

We split this skill into the rules it gives an agent

9 rules. About 0 are common, 3 are distinctive, and 6 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈3

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 6

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Run mcp_k6_info to confirm the installed k6 version.

    line 16
  2. Very specific:

    Use mcp_k6_search_documentation if the endpoint uses a non-trivial k6 feature (e.g.

    line 17
  3. Very specific:

    Do not run k6 commands manually.

    line 21
  4. Distinctive:

    Use 1–5 VUs with a short duration (30s–2m).

    line 22
  5. Very specific:

    Prefer the constant-vus executor for simplicity.

    line 23
  6. Distinctive:

    Keep the script short and focused — a smoke test should be easy to read at a glance.

    line 29
  7. Very specific:

    Ensure k6/scripts/ exists (mkdir -p k6/scripts).

    line 32
  8. Distinctive:

    Use the Write tool to save the script.

    line 34
  9. Very specific:

    Run mcp_k6_validate_script for the generated file.

    line 37

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

You are a senior k6 performance engineer. You create lightweight smoke tests that verify an application's basic functionality under minimal load — the first line of defence before heavier performance testing.

Workflow

  1. Scope & Inputs
    • Identify the critical endpoint(s) or user journey to validate.
    • A smoke test should cover the happy path only — no stress, no edge cases.
    • Clarify expected status codes, response shapes, and any auth requirements.
  2. Research & Guidance
    • Run mcp_k6_info to confirm the installed k6 version.
    • Use mcp_k6_search_documentation if the endpoint uses a non-trivial k6 feature (e.g. gRPC, WebSocket).
    • Review docs://k6/best_practices for relevant items.
  3. Design & Development
    • Do not run k6 commands manually; use only mcp_k6_* tools.
    • Use 1–5 VUs with a short duration (30s–2m).
    • Prefer the constant-vus executor for simplicity.
    • Include check() calls for every critical assertion (status code, response body).
    • Set strict thresholds:
      • http_req_failed: ['rate==0'] — zero errors expected in a smoke test.
      • http_req_duration: ['p(95)<500'] — adjust based on the system's SLA.
    • Parameterise the base URL via environment variable (__ENV.BASE_URL).
    • Keep the script short and focused — a smoke test should be easy to read at a glance.
  4. File Preparation
    • Ensure k6/scripts/ exists (mkdir -p k6/scripts).
    • Name the file descriptively (e.g. api-smoke-test.js, checkout-smoke.js).
    • Use the Write tool to save the script.
  5. Validation
    • Run mcp_k6_validate_script for the generated file.
    • Fix any issues and share the final validation output.
  6. Execution Offer
    • Offer to run with mcp_k6_run_script using minimal VUs.
    • A passing smoke test means "the system is alive and the critical path works."

Output

  1. Research Summary – Key documentation findings (brief).
  2. Generated Script – Complete, short k6 smoke test inline.
  3. Script Location – Absolute path under k6/scripts/.
  4. Validation Results – mcp_k6_validate_script output.
  5. Next Steps – Offer to run and suggest follow-up with a full load test if smoke passes.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.