perf-skills 1.0.4 → 2.0.0

package/.claude-plugin/marketplace.json

@@ -5,7 +5,7 @@
     "email": "contact@qainsights.com"
   },
   "metadata": {
-    "description": "Expert AI skill for performance testing — covers the full lifecycle using JMeter, k6, Gatling, Locust, NeoLoad, LoadRunner, and OctoPerf.",
+    "description": "Expert AI skill for performance testing - covers the full lifecycle using JMeter, k6, Gatling, Locust, NeoLoad, LoadRunner, and OctoPerf.",
     "version": "1.0.4"
   },
   "plugins": [

package/README.md

@@ -180,7 +180,8 @@ perf-skills/                              # Repository root
             └── topics/                   # Cross-cutting concepts (tool-agnostic)
                 ├── workload-design.md        # Concurrency models, load profiles, Little's Law
                 ├── test-data.md              # CSV, DB seeding, Faker, data isolation patterns
-                ├── script-generation.md      # Correlation, assertions, error handling, naming
+                ├── script-generation.md      # Assertions, error handling, naming, structure
+                ├── correlation.md            # Dynamic values, extractors, regex, tool mappings
                 ├── test-execution.md         # Distributed, CI/CD (GitHub Actions, GitLab, Jenkins)
                 ├── results-analysis.md       # Percentiles, bottleneck framework, reporting
                 ├── observability.md          # APM, Prometheus, Grafana, tracing, JVM metrics

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "perf-skills",
-  "version": "1.0.4",
-  "description": "Expert AI skill for performance testing — covers JMeter, k6, Gatling, Locust, NeoLoad, LoadRunner, OctoPerf across the full lifecycle",
+  "version": "2.0.0",
+  "description": "Expert AI skill for performance testing - covers JMeter, k6, Gatling, Locust, NeoLoad, LoadRunner, OctoPerf across the full lifecycle",
   "main": "skills/perf/SKILL.md",
   "files": [
     "skills/",

package/skills/perf/SKILL.md

@@ -5,7 +5,7 @@ description: Performance testing expert covering the full lifecycle for
   whenever writing or reviewing load test scripts, setting thresholds,
   choosing executors, configuring CI/CD pipelines, diagnosing latency
   issues, designing workloads, analyzing results, or recommending tools
-  — even if the tool is not named explicitly. Always consult before
+  - even if the tool is not named explicitly. Always consult before
   suggesting thresholds, executor types, or output configuration.
   Prefer this skill over general knowledge for any performance testing
   decision, debugging session, or tool comparison.
@@ -14,7 +14,7 @@ description: Performance testing expert covering the full lifecycle for
 # Performance Testing Skill
 
 This skill provides expert, opinionated guidance across the full
-performance testing lifecycle — from workload design through production
+performance testing lifecycle - from workload design through production
 observation. It covers both commercial tools (LoadRunner, NeoLoad,
 OctoPerf) and open-source tools (JMeter, k6, Gatling, Locust).
 
@@ -32,7 +32,7 @@ Multiple files may apply.
    the topic file only.
 3. **Both apply** (e.g., "JMeter CI/CD") → load the topic file first
    for patterns, then the tool file for syntax.
-4. **Never load all files at once** — select the 1–2 most relevant.
+4. **Never load all files at once** - select the 1–2 most relevant.
 5. **Cross-cutting principles** (assertions, think time,
    parameterization) → this file's Key Principles section is the
    single source of truth.
@@ -41,7 +41,7 @@ Multiple files may apply.
 
 | User needs help with...                          | Read this file                                    |
 |--------------------------------------------------|---------------------------------------------------|
-| Choosing the right tool                          | This file — see Tool Selection Matrix below       |
+| Choosing the right tool                          | This file - see Tool Selection Matrix below       |
 | JMeter scripts, plugins, config                  | `references/tools/jmeter.md`                      |
 | k6 scripting, extensions, cloud                  | `references/tools/k6.md`                          |
 | Gatling simulations, Scala/Java DSL              | `references/tools/gatling.md`                     |
@@ -51,7 +51,8 @@ Multiple files may apply.
 | OctoPerf cloud test management                   | `references/tools/octoperf.md`                    |
 | Designing workloads, concurrency, pacing         | `references/topics/workload-design.md`            |
 | Test data, parameterization, CSV feeds           | `references/topics/test-data.md`                  |
-| Script patterns, correlation, best practices     | `references/topics/script-generation.md`          |
+| Script patterns, best practices                  | `references/topics/script-generation.md`          |
+| Correlation, extractors, dynamic values           | `references/topics/correlation.md`                |
 | CI/CD, distributed execution, cloud runners      | `references/topics/test-execution.md`             |
 | Analyzing results, percentiles, SLAs             | `references/topics/results-analysis.md`           |
 | APM, metrics, tracing, dashboards                | `references/topics/observability.md`              |
@@ -113,70 +114,70 @@ Use this to recommend the right tool when the user hasn't decided yet.
 
 These are the mistakes that cause silent CI failures, misleading
 results, or test collapse at scale. Flag them proactively whenever
-reviewing scripts or diagnosing problems — users often don't know to
+reviewing scripts or diagnosing problems - users often don't know to
 ask about them.
 
 ### k6
 
-- **`check()` without `thresholds`** — checks log pass/fail but do
+- **`check()` without `thresholds`** - checks log pass/fail but do
   NOT fail the test run. Without thresholds, CI always reports green
   regardless of latency. Always add `thresholds` to `options`.
-- **Data loaded inside `default()`** — loading CSV or JSON inside the
+- **Data loaded inside `default()`** - loading CSV or JSON inside the
   VU function runs on every iteration, causing massive per-iteration
   overhead and OOM at scale. Always use `SharedArray` in the init
   scope.
-- **`shared-iterations` for user journeys** — VUs race to claim
+- **`shared-iterations` for user journeys** - VUs race to claim
   iterations and may skip steps, producing incomplete journey metrics.
   Use `per-vu-iterations` for any multi-step flow.
-- **No `sleep()` between steps** — 100 VUs with zero think time
+- **No `sleep()` between steps** - 100 VUs with zero think time
   generates the absolute maximum RPS for that iteration time, far
   exceeding what 100 real concurrent users produce. Always add
   realistic think time.
-- **`console.log` in `default()`** — causes 30–50% throughput drop
+- **`console.log` in `default()`** - causes 30–50% throughput drop
   under load. Use custom metrics (`Counter`, `Trend`) instead.
-- **Hardcoded `BASE_URL`** — use `__ENV.BASE_URL` for environment
+- **Hardcoded `BASE_URL`** - use `__ENV.BASE_URL` for environment
   portability.
 
 ### JMeter
 
-- **Listeners enabled in non-GUI runs** — View Results Tree, Aggregate
+- **Listeners enabled in non-GUI runs** - View Results Tree, Aggregate
   Report etc. buffer all samples in memory during headless runs,
   causing memory leak and eventual crash. Disable all listeners before
   CI execution; use `-l results.jtl` for output.
-- **Missing correlation on session-heavy apps** — JSESSIONID, CSRF
+- **Missing correlation on session-heavy apps** - JSESSIONID, CSRF
   tokens, ViewState, OAuth codes must be extracted and reused. Without
   correlation, the test fails for every user after the first.
-- **Hardcoded thread counts** — parameterize via JMeter properties
+- **Hardcoded thread counts** - parameterize via JMeter properties
   (`${__P(threads,10)}`) so CI can override without editing the JMX.
-- **Zero think time** — never reflects real user behavior; always add
+- **Zero think time** - never reflects real user behavior; always add
   at minimum a Constant Timer (300–500ms) between samplers.
-- **Throughput Controller % mode misuse** — percentage applies per
+- **Throughput Controller % mode misuse** - percentage applies per
   iteration of the parent controller, not globally. Most users expect
   global percentage; use `Total Executions` mode instead or be
   explicit.
 
 ### Gatling
 
-- **Blocking calls inside `exec()`** — any blocking I/O inside an exec
+- **Blocking calls inside `exec()`** - any blocking I/O inside an exec
   block stalls the entire Akka actor, killing simulation concurrency.
   Use Gatling's async feed/session API exclusively.
-- **Missing `.check()` on responses** — without checks, 4xx and 5xx
+- **Missing `.check()` on responses** - without checks, 4xx and 5xx
   responses are silently counted as successful. Always add at minimum
   `.check(status.is(200))`.
-- **Fixed `pause()` values** — use `uniformPaused(min, max)` or
+- **Fixed `pause()` values** - use `uniformPaused(min, max)` or
   `normalPausedWithPercentageDuration` for realistic think time
   distribution.
 
 ### Locust
 
-- **`self.client` without `catch_response=True`** — by default, Locust
+- **`self.client` without `catch_response=True`** - by default, Locust
   marks any HTTP response as success regardless of status code. Use
   `with self.client.get(..., catch_response=True) as r:` and call
   `r.failure()` explicitly.
-- **Unequal task weights without intent** — tasks default to equal
+- **Unequal task weights without intent** - tasks default to equal
   weight; if your user journey has unequal step frequency, set weights
   explicitly or the journey ratio will be wrong.
-- **Master + workers on same machine** — causes resource contention
+- **Master + workers on same machine** - causes resource contention
   that skews both throughput and latency measurements. Always run
   workers on separate machines or containers for distributed tests.
 
@@ -207,7 +208,7 @@ the specific mapping rather than a generic explanation.
 
 ## Threshold Starting Points
 
-These are community baselines — always tell the user to adjust these
+These are community baselines - always tell the user to adjust these
 to their actual SLA requirements. Never present them as universal
 targets.
 
@@ -215,15 +216,15 @@ targets.
 |------------------|-----------|------------|------------|------------------------------------|
 | Web page (HTML)  | < 3000ms  | < 5000ms   | < 1%       | Aligns with Google CWV LCP < 2.5s  |
 | REST API         | < 500ms   | < 1000ms   | < 1%       | Common industry baseline           |
-| Auth / Login     | < 300ms   | < 500ms    | < 0.1%     | Stricter — security-sensitive path |
+| Auth / Login     | < 300ms   | < 500ms    | < 0.1%     | Stricter - security-sensitive path |
 | Search / Query   | < 800ms   | < 1500ms   | < 0.5%     | Varies heavily by dataset size     |
 | Write (POST/PUT) | < 800ms   | < 1500ms   | < 0.5%     | Includes DB write latency          |
-| Checkout/Payment | < 1000ms  | < 2000ms   | < 0.1%     | Stricter — revenue-critical path   |
+| Checkout/Payment | < 1000ms  | < 2000ms   | < 0.1%     | Stricter - revenue-critical path   |
 | Background/async | < 5000ms  | < 10000ms  | < 2%       | Batch jobs, async processors       |
 
 **k6 specific:** Always define both `http_req_duration` AND
 `http_req_waiting` as separate thresholds. `http_req_waiting`
-(TTFB) isolates server-side latency from network overhead — it is
+(TTFB) isolates server-side latency from network overhead - it is
 the first metric to check when diagnosing high p95. Always include
 `checks: ['rate>0.99']`.
 
@@ -235,7 +236,7 @@ CI pass/fail; use the JMeter exit code driven by assertions.
 
 ## Performance Testing Lifecycle Overview
 
-Always think through these phases when helping a user — they often ask
+Always think through these phases when helping a user - they often ask
 about one phase but need context from others.
 
 ```
@@ -279,26 +280,26 @@ about one phase but need context from others.
 | **Soak/Endurance** | Detect memory leaks, slow degradation | Resource trend over time (hours)      |
 | **Spike**        | Behavior under sudden traffic burst   | Recovery time, error spike              |
 | **Capacity**     | Find max sustainable load             | Throughput ceiling at SLA thresholds    |
-| **Smoke**        | Quick sanity check                    | Single VU — no errors                   |
+| **Smoke**        | Quick sanity check                    | Single VU - no errors                   |
 | **Breakpoint**   | Incremental ramp until failure        | Failure threshold VU count              |
 
 ---
 
 ## Key Principles to Always Apply
 
-1. **Never test against production blindly** — always have a rollback
+1. **Never test against production blindly** - always have a rollback
    plan and alerting in place.
-2. **Baseline first** — always establish a baseline before stress or
+2. **Baseline first** - always establish a baseline before stress or
    soak runs.
-3. **Think time and pacing matter** — unrealistic zero-think-time tests
+3. **Think time and pacing matter** - unrealistic zero-think-time tests
    produce misleading results.
-4. **Parameterize everything** — hardcoded credentials, tokens, and IDs
+4. **Parameterize everything** - hardcoded credentials, tokens, and IDs
    will fail at scale.
-5. **Assertions are not optional** — tests without assertions are just
+5. **Assertions are not optional** - tests without assertions are just
    generating traffic, not validating behavior.
-6. **Isolate the system under test** — shared environments invalidate
+6. **Isolate the system under test** - shared environments invalidate
    results.
-7. **Correlate dynamic values** — session tokens, CSRF, ViewState etc.
+7. **Correlate dynamic values** - session tokens, CSRF, ViewState etc.
    must be extracted and reused.
 
 ---

package/skills/perf/evals/evals.json

@@ -1,149 +1,149 @@
-{
-  "skill_name": "perf",
-  "evals": [
-    {
-      "id": 1,
-      "prompt": "I'm using k6 checks to validate all my API responses. My CI pipeline shows all tests passing but users are complaining about slowness. What am I missing?",
-      "expected_output": "Identifies that checks do not fail the test run — thresholds are required for CI enforcement. Provides a concrete threshold example.",
-      "files": [],
-      "assertions": [
-        {
-          "id": "checks-vs-thresholds-distinction",
-          "text": "Explicitly states that checks do NOT produce a non-zero exit code and cannot fail a CI pipeline"
-        },
-        {
-          "id": "thresholds-required",
-          "text": "States that thresholds in options.thresholds are required to enforce SLA in CI"
-        },
-        {
-          "id": "concrete-example",
-          "text": "Provides a concrete threshold code example, not just an explanation"
-        }
-      ]
-    },
-    {
-      "id": 2,
-      "prompt": "I need to load test a Kafka consumer that processes order events. What tool should I use and how do I get started?",
-      "expected_output": "Recommends xk6-kafka with the custom build command, or JMeter with Kafka plugin. Does not suggest a generic HTTP tool.",
-      "files": [],
-      "assertions": [
-        {
-          "id": "correct-tool",
-          "text": "Recommends xk6-kafka or JMeter Kafka plugin — not a generic HTTP tool like plain k6 or Gatling HTTP"
-        },
-        {
-          "id": "xk6-build-command",
-          "text": "Includes the xk6 custom build command or JMeter plugin installation reference"
-        },
-        {
-          "id": "not-http",
-          "text": "Does not suggest testing Kafka via HTTP endpoints as a primary approach"
-        }
-      ]
-    },
-    {
-      "id": 3,
-      "prompt": "My JMeter test runs fine locally but JMeter crashes after 20 minutes in CI with an OutOfMemoryError. The test plan works on my machine with 50 threads.",
-      "expected_output": "Identifies listeners enabled in non-GUI run as the primary cause. Recommends disabling listeners and using -l flag for output.",
-      "files": [],
-      "assertions": [
-        {
-          "id": "listener-root-cause",
-          "text": "Identifies enabled listeners (View Results Tree, Aggregate Report etc.) in non-GUI runs as the memory leak cause"
-        },
-        {
-          "id": "disable-listeners",
-          "text": "Recommends disabling listeners in the test plan for CI runs"
-        },
-        {
-          "id": "jtl-output",
-          "text": "Mentions using -l results.jtl flag as the correct output method for non-GUI runs"
-        }
-      ]
-    },
-    {
-      "id": 4,
-      "prompt": "We're migrating our load tests from LoadRunner to k6. What does a VuGen Action map to in k6, and what about think time and correlation?",
-      "expected_output": "Maps VuGen Action → k6 default() function. Maps lr_think_time() → sleep(). Maps web_reg_save_param → res.json() or regex extraction.",
-      "files": [],
-      "assertions": [
-        {
-          "id": "action-mapping",
-          "text": "Maps VuGen Action() specifically to k6 default() function"
-        },
-        {
-          "id": "think-time-mapping",
-          "text": "Maps lr_think_time() to k6 sleep()"
-        },
-        {
-          "id": "correlation-mapping",
-          "text": "Maps web_reg_save_param or LoadRunner correlation to k6 res.json() or regex extraction"
-        }
-      ]
-    },
-    {
-      "id": 5,
-      "prompt": "I'm writing a k6 script for an e-commerce checkout flow: login → browse → add to cart → checkout. Should I use shared-iterations or per-vu-iterations?",
-      "expected_output": "Recommends per-vu-iterations. Explains that shared-iterations causes VUs to skip steps in multi-step journeys, producing incorrect metrics.",
-      "files": [],
-      "assertions": [
-        {
-          "id": "correct-executor",
-          "text": "Recommends per-vu-iterations for the user journey"
-        },
-        {
-          "id": "shared-iterations-problem",
-          "text": "Explains why shared-iterations is wrong for journeys — VUs race for iterations and may skip steps"
-        },
-        {
-          "id": "not-ambiguous",
-          "text": "Gives a clear recommendation, not a 'it depends' answer without a conclusion"
-        }
-      ]
-    },
-    {
-      "id": 6,
-      "prompt": "My Locust test shows zero failures even though I can see 404 and 500 errors in the server logs during the test run.",
-      "expected_output": "Identifies missing catch_response=True as the cause. Without it, Locust counts all HTTP responses as success regardless of status code.",
-      "files": [],
-      "assertions": [
-        {
-          "id": "catch-response-cause",
-          "text": "Identifies missing catch_response=True as the root cause"
-        },
-        {
-          "id": "failure-call",
-          "text": "Explains that r.failure() must be called explicitly inside the catch_response context manager"
-        },
-        {
-          "id": "code-example",
-          "text": "Provides a corrected code snippet using catch_response=True"
-        }
-      ]
-    },
-    {
-      "id": 7,
-      "prompt": "What are good starting threshold values for a REST API and a checkout payment endpoint in k6?",
-      "expected_output": "Provides differentiated thresholds: REST API p95<500ms, checkout p95<1000ms with stricter error rate. Includes both http_req_duration and http_req_waiting. Notes these are baselines to adjust.",
-      "files": [],
-      "assertions": [
-        {
-          "id": "differentiated-thresholds",
-          "text": "Gives different threshold values for REST API vs checkout — not the same value for both"
-        },
-        {
-          "id": "http-req-waiting",
-          "text": "Includes http_req_waiting as a separate threshold alongside http_req_duration"
-        },
-        {
-          "id": "checks-threshold",
-          "text": "Includes checks: rate>0.99 threshold"
-        },
-        {
-          "id": "adjust-caveat",
-          "text": "Notes that values are baselines and should be adjusted to actual SLA requirements"
-        }
-      ]
-    }
-  ]
+{
+  "skill_name": "perf",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "I'm using k6 checks to validate all my API responses. My CI pipeline shows all tests passing but users are complaining about slowness. What am I missing?",
+      "expected_output": "Identifies that checks do not fail the test run - thresholds are required for CI enforcement. Provides a concrete threshold example.",
+      "files": [],
+      "assertions": [
+        {
+          "id": "checks-vs-thresholds-distinction",
+          "text": "Explicitly states that checks do NOT produce a non-zero exit code and cannot fail a CI pipeline"
+        },
+        {
+          "id": "thresholds-required",
+          "text": "States that thresholds in options.thresholds are required to enforce SLA in CI"
+        },
+        {
+          "id": "concrete-example",
+          "text": "Provides a concrete threshold code example, not just an explanation"
+        }
+      ]
+    },
+    {
+      "id": 2,
+      "prompt": "I need to load test a Kafka consumer that processes order events. What tool should I use and how do I get started?",
+      "expected_output": "Recommends xk6-kafka with the custom build command, or JMeter with Kafka plugin. Does not suggest a generic HTTP tool.",
+      "files": [],
+      "assertions": [
+        {
+          "id": "correct-tool",
+          "text": "Recommends xk6-kafka or JMeter Kafka plugin - not a generic HTTP tool like plain k6 or Gatling HTTP"
+        },
+        {
+          "id": "xk6-build-command",
+          "text": "Includes the xk6 custom build command or JMeter plugin installation reference"
+        },
+        {
+          "id": "not-http",
+          "text": "Does not suggest testing Kafka via HTTP endpoints as a primary approach"
+        }
+      ]
+    },
+    {
+      "id": 3,
+      "prompt": "My JMeter test runs fine locally but JMeter crashes after 20 minutes in CI with an OutOfMemoryError. The test plan works on my machine with 50 threads.",
+      "expected_output": "Identifies listeners enabled in non-GUI run as the primary cause. Recommends disabling listeners and using -l flag for output.",
+      "files": [],
+      "assertions": [
+        {
+          "id": "listener-root-cause",
+          "text": "Identifies enabled listeners (View Results Tree, Aggregate Report etc.) in non-GUI runs as the memory leak cause"
+        },
+        {
+          "id": "disable-listeners",
+          "text": "Recommends disabling listeners in the test plan for CI runs"
+        },
+        {
+          "id": "jtl-output",
+          "text": "Mentions using -l results.jtl flag as the correct output method for non-GUI runs"
+        }
+      ]
+    },
+    {
+      "id": 4,
+      "prompt": "We're migrating our load tests from LoadRunner to k6. What does a VuGen Action map to in k6, and what about think time and correlation?",
+      "expected_output": "Maps VuGen Action → k6 default() function. Maps lr_think_time() → sleep(). Maps web_reg_save_param → res.json() or regex extraction.",
+      "files": [],
+      "assertions": [
+        {
+          "id": "action-mapping",
+          "text": "Maps VuGen Action() specifically to k6 default() function"
+        },
+        {
+          "id": "think-time-mapping",
+          "text": "Maps lr_think_time() to k6 sleep()"
+        },
+        {
+          "id": "correlation-mapping",
+          "text": "Maps web_reg_save_param or LoadRunner correlation to k6 res.json() or regex extraction"
+        }
+      ]
+    },
+    {
+      "id": 5,
+      "prompt": "I'm writing a k6 script for an e-commerce checkout flow: login → browse → add to cart → checkout. Should I use shared-iterations or per-vu-iterations?",
+      "expected_output": "Recommends per-vu-iterations. Explains that shared-iterations causes VUs to skip steps in multi-step journeys, producing incorrect metrics.",
+      "files": [],
+      "assertions": [
+        {
+          "id": "correct-executor",
+          "text": "Recommends per-vu-iterations for the user journey"
+        },
+        {
+          "id": "shared-iterations-problem",
+          "text": "Explains why shared-iterations is wrong for journeys - VUs race for iterations and may skip steps"
+        },
+        {
+          "id": "not-ambiguous",
+          "text": "Gives a clear recommendation, not a 'it depends' answer without a conclusion"
+        }
+      ]
+    },
+    {
+      "id": 6,
+      "prompt": "My Locust test shows zero failures even though I can see 404 and 500 errors in the server logs during the test run.",
+      "expected_output": "Identifies missing catch_response=True as the cause. Without it, Locust counts all HTTP responses as success regardless of status code.",
+      "files": [],
+      "assertions": [
+        {
+          "id": "catch-response-cause",
+          "text": "Identifies missing catch_response=True as the root cause"
+        },
+        {
+          "id": "failure-call",
+          "text": "Explains that r.failure() must be called explicitly inside the catch_response context manager"
+        },
+        {
+          "id": "code-example",
+          "text": "Provides a corrected code snippet using catch_response=True"
+        }
+      ]
+    },
+    {
+      "id": 7,
+      "prompt": "What are good starting threshold values for a REST API and a checkout payment endpoint in k6?",
+      "expected_output": "Provides differentiated thresholds: REST API p95<500ms, checkout p95<1000ms with stricter error rate. Includes both http_req_duration and http_req_waiting. Notes these are baselines to adjust.",
+      "files": [],
+      "assertions": [
+        {
+          "id": "differentiated-thresholds",
+          "text": "Gives different threshold values for REST API vs checkout - not the same value for both"
+        },
+        {
+          "id": "http-req-waiting",
+          "text": "Includes http_req_waiting as a separate threshold alongside http_req_duration"
+        },
+        {
+          "id": "checks-threshold",
+          "text": "Includes checks: rate>0.99 threshold"
+        },
+        {
+          "id": "adjust-caveat",
+          "text": "Notes that values are baselines and should be adjusted to actual SLA requirements"
+        }
+      ]
+    }
+  ]
 }