jmeter-script-validator
Skill5 starsChanged 6 months agoMITView on GitHub
Validate existing JMeter scripts via autonomous smoke testing using the jmeter-script-validator subagent. Use when the user mentions script validation, script health check, validate JMeter script, re-validate old scripts, check if a JMeter script still works, or smoke test validation. This skill orchestrates one or more validator subagents, each producing a standalone Markdown validation report.
We split this skill into the rules it gives an agent
22 rules. About 0 are common, 15 are distinctive, and 7 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈15
Distinctive · estimate
This author's own choices. Worth a look.
7
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 20
Never start this workflow unless the user explicitly requests it
- Very specific: line 81
Remove the .jmx extension
- Distinctive: line 112
Follow these steps exactly, in order.
- Distinctive: line 118
Ask the user for the following values.
- Distinctive: line 136
Create task items to monitor progress:
- Very specific: line 161
If jmx_filename was provided, verify it exists in scripts_list.
- Very specific: line 163
If validate_all=true, all scripts in scripts_list will be validated.
- Distinctive: line 164
If neither was provided and multiple scripts exist, ask the user which script(s) to validate.
- Distinctive: line 166
If only one script exists, use it automatically.
- Very specific: line 177
Remove the .jmx extension → Login_Flow
- Very specific: line 204
If validate_all=true and multiple scripts exist, invoke subagents
- Distinctive: line 213
After all subagents complete, verify that each expected report file exists:
- Distinctive: line 220
If the file exists, record it as successful
- Distinctive: line 221
If the file does not exist, record the failure and check the subagent return for error details
- Distinctive: line 235
If failed: the failing sampler name, HTTP response code, and brief diagnosis
- Very specific: line 242
If scripts failed validation: recommend running the jmeter-debugging skill to iteratively fix the issues
- Distinctive: line 244
If scripts passed: the scripts are ready for load testing or BlazeMeter upload
- Very specific: line 250
If list_jmeter_scripts returns no scripts, stop and inform the user that no JMX files were found for the given test_run_id.
- Distinctive: line 252
If a subagent fails to invoke, record it in the summary and continue with remaining subagents.
- Distinctive: line 254
Do NOT retry subagent invocations.
- Distinctive: line 256
Do NOT modify any existing Rules, Skills, or MCP source code.
- Distinctive: line 257
If the orchestrator itself encounters an error, report directly to the user with the full error message.
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 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.
Files
JMeter Script Validator
When to Use This Skill
- User wants to validate whether an existing JMeter script still works
- User mentions "script validation", "re-validate", "script health check"
- User wants to smoke test an old script to check for broken endpoints, stale correlations, or payload changes
- User wants to validate multiple scripts using subagents
- Never start this workflow unless the user explicitly requests it
Reference
This section provides context for humans and capable models. For the step-by-step execution instructions, skip to the Execution section below.
What This Skill Does
This skill orchestrates the jmeter-script-validator subagent to autonomously
validate JMeter scripts. Each subagent:
- Runs an initial 1/1/1 smoke test to detect the first failure
- Stops the test at the first error and reads the JTL to identify the failing sampler
- Attaches a Debug Post-Processor to capture verbose request/response data
- Runs a second smoke test to collect detailed debug output
- Stops the second test and inspects the JTL Request URL for
NOT_FOUNDpatterns - Analyzes the JMeter log with debug data for root cause diagnosis
- Compiles a well-structured Markdown validation report with findings
- Optionally generates an aggregate report for the smoke test results
The subagent does NOT apply fixes. It is strictly a validation and diagnosis
tool. For iterative fix-and-retest, use the jmeter-debugging skill instead.
Architecture
User Prompt (test_run_id, jmx_filename, ...)
│
▼
Orchestrator (this skill)
│
├── jmeter-script-validator subagent
│ ├── Smoke Test 1 (detect first failure via run status / JTL)
│ ├── Attach Debug Post-Processor to failing sampler
│ ├── Smoke Test 2 (capture verbose debug data)
│ ├── Analyze JMeter log + inspect JTL Request URLs
│ ├── Generate aggregate report (optional)
│ └── Write validation report
│ └── artifacts/{test_run_id}/analysis/Report_{Script_Name}.md
│
├── [optional] additional subagents for other scripts
│
└── Summary to userReport Naming Convention
Each smoke test produces its own Markdown report. The report name is derived from
the JMX script filename using Snake Case with a Report_ prefix:
| JMX Filename | Report Name |
Login_Flow.jmx | Report_Login_Flow.md |
ai-generated-script.jmx | Report_Ai_Generated_Script.md |
imported_checkout-api.jmx | Report_Imported_Checkout_Api.md |
my test script.jmx | Report_My_Test_Script.md |
Conversion rules:
- Remove the
.jmxextension - Replace hyphens (
-), spaces, and dots with underscores (_) - Title-case each segment (capitalize the first letter of each word)
- Prepend
Report_
Reports are written to: artifacts/{test_run_id}/analysis/Report_{Script_Name}.md
Validation vs Debugging
| Aspect | Script Validator (this skill) | Debugging Skill |
| Purpose | Diagnose and report | Diagnose and fix |
| Applies fixes? | No | Yes |
| Max smoke tests | 2 per script | Up to 5 iterations |
| Output | Markdown report only | Fixed script + debug manifest |
| Runs as | Subagent | Interactive foreground |
Related Files
- Subagent definition:
.cursor/agents/jmeter-script-validator.md - JMeter debugging skill:
.cursor/skills/jmeter-debugging/SKILL.md - JMeter HITL editing skill:
.cursor/skills/jmeter-hitl-editing/SKILL.md - JMeter script guardrails:
.cursor/rules/jmeter-script-guardrails.mdc - Skill execution rules:
.cursor/rules/skill-execution-rules.mdc - Prerequisites:
.cursor/rules/prerequisites.mdc - MCP error handling:
.cursor/rules/mcp-error-handling.mdc
Execution
Follow these steps exactly, in order.
Step 1 — Collect Inputs
Ask the user for the following values. Do not proceed until all required values are collected.
REQUIRED:
test_run_id = [ask user — must have an existing JMX in artifacts/{test_run_id}/jmeter/]
OPTIONAL:
jmx_filename = [specific JMX file to validate — if not provided, auto-discovers]
validate_all = [true/false — validate all JMX scripts found for this test_run_id.
Default: false. If true, one subagent is launched per script.]
generate_report = [true/false — generate aggregate report after smoke tests.
Default: true]Step 2 — Initialize Task Tracking
Create task items to monitor progress:
- Script discovery
- Subagent invocation (one per script)
- Report validation
- Summary to user
Step 3 — Discover Scripts
Action: List the JMX scripts available for this test run.
The orchestrator (you) should call the JMeter MCP tool directly to discover scripts:
list_jmeter_scripts(
test_run_id = {test_run_id}
)Save: scripts_list — the list of JMX script paths and filenames.
Decision gate:
- If
jmx_filenamewas provided, verify it exists inscripts_list. If not found, report the error to the user and stop. - If
validate_all=true, all scripts inscripts_listwill be validated. - If neither was provided and multiple scripts exist, ask the user which script(s) to validate.
- If only one script exists, use it automatically.
Save: target_scripts — the list of scripts to validate (one or more).
Step 4 — Derive Report Names
For each script in target_scripts, derive the report filename:
- Take the JMX filename (e.g.,
Login_Flow.jmx) - Remove the
.jmxextension →Login_Flow - Replace hyphens, spaces, dots with underscores →
Login_Flow - Title-case each segment →
Login_Flow - Prepend
Report_→Report_Login_Flow - Append
.md→Report_Login_Flow.md
Save: Mapping of {jmx_filename} → {report_filename} for each target script.
Step 5 — Invoke Subagent(s)
For each script in target_scripts, invoke a jmeter-script-validator subagent
with the following prompt:
Validate the JMeter script for test_run_id: {test_run_id}
jmx_filename: {jmx_filename}
report_filename: {report_filename}
generate_report: {generate_report}
Follow all instructions in your system prompt. Write the validation report to:
artifacts/{test_run_id}/analysis/{report_filename}Important:
- If
validate_all=trueand multiple scripts exist, invoke subagents sequentially — one at a time, waiting for each to complete before starting the next - Save the return JSON from each subagent for the summary
Step 6 — Validate Reports
After all subagents complete, verify that each expected report file exists:
artifacts/{test_run_id}/analysis/{report_filename}For each report:
- If the file exists, record it as successful
- If the file does not exist, record the failure and check the subagent return for error details
Step 7 — Report Results to User
Present a clear summary to the user:
- Scripts Validated
- List each script, its validation outcome (pass/fail), and report location
- Validation Results
- For each script: whether it passed (0% errors) or failed (with first error details)
- If failed: the failing sampler name, HTTP response code, and brief diagnosis
- Report Locations
- Full path to each validation report in
artifacts/{test_run_id}/analysis/ - Path to aggregate reports if generated
- Full path to each validation report in
- Next Steps
- If scripts failed validation: recommend running the
jmeter-debuggingskill to iteratively fix the issues - If scripts passed: the scripts are ready for load testing or BlazeMeter upload
- If scripts failed validation: recommend running the
Error Handling
- If
list_jmeter_scriptsreturns no scripts, stop and inform the user that no JMX files were found for the giventest_run_id. - If a subagent fails to invoke, record it in the summary and continue with remaining subagents.
- Do NOT retry subagent invocations. Each subagent handles its own MCP tool retries internally.
- Do NOT modify any existing Rules, Skills, or MCP source code.
- If the orchestrator itself encounters an error, report directly to the user with the full error message.
- JMeter MCP tools are code-based — do NOT retry on failure. Report the error as-is.
In this repository23 other files it gives its agents.
- .cursor/rules/browser-automation-guardrails.mdcCursor rule
- .cursor/rules/implementation-standards.mdcCursor rule
- .cursor/rules/jmeter-script-guardrails.mdcCursor rule
- .cursor/rules/mcp-error-handling.mdcCursor rule
- .cursor/rules/prerequisites.mdcCursor rule
- .cursor/rules/project-and-coding-guidelines.mdcCursor rule
- .cursor/rules/skill-execution-rules.mdcCursor rule
- .cursor/rules/technology-reference-policy.mdcCursor rule
- ado-test-case-conversionSkill
- comparison-report-workflowSkill
- jmeter-correlation-namingSkill
- jmeter-debuggingSkill
- jmeter-entraid-debuggingSkill
- jmeter-har-conversionSkill
- jmeter-hitl-editingSkill
- jmeter-swagger-conversionSkill
- msteams-notificationSkill
- perfmemorySkill
- performance-testing-workflowSkill
- playwright-browser-automationSkill
- report-revision-workflowSkill
- sharepoint-uploadSkill
- subagent-orchestratorSkill
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
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.

