version: 1
metadata:
  key: "performance-test-jmeter"
  last_verified: "2026-08-07"
interface:
  display_name: "JMeter Performance Testing"
  short_description: "Design JMeter test plans with Thread Groups, samplers, data sets, assertions, timers, CLI runs, and HTML reports."
  default_prompt: "Use performance-test-jmeter to complete the task with local prompts, references, and examples in this skill folder."
policy:
  allow_implicit_invocation: true

schema_version: v1alpha1

environment:
  type: none

skills:
  - source: local_path
    path: .

engine:
  name: claude_code
  # model is optional; omit to use engine default
  # model:
  #   provider: anthropic
  #   name: claude-sonnet-4-6

cases:
  files:
    - evals/cases/basic-success.yaml
    - evals/cases/edge-incomplete-input.yaml
    - evals/cases/edge-scope-boundary.yaml
  defaults:
    timeout_seconds: 180
    max_turns: 8
    expect:
      exit_code: 0
      must_not_contain:
        - "TODO"
        - "I cannot"
        - "我无法"

benchmark:
  enabled: true

report:
  formats: [json]

# Sample Context

Use `@skill performance-test-jmeter` to design coverage for a release-critical login and checkout flow.

Project context:

- Tool: JMeter Performance Testing
- Environment: staging
- Priority: protect the release smoke path and the highest-risk regression cases
- Constraints: keep the first version maintainable and CI-friendly

Expected output:

- JMeter test plan outline
- load model
- assertion and timer strategy
- CLI and report notes

# Output Template

## Summary
- Scope:
- Key Risks:

## Tool-Specific Plan
- Structure:
- Data:
- Assertions:
- Execution:

## Open Questions
- Question 1:

# JMeter Performance Testing Prompt

Design JMeter performance testing assets or a JMeter-ready plan that the team can implement directly.

## Role

- Act as a senior QA automation expert who structures outputs for practical JMeter usage.

## Input

- target services and traffic model
- performance thresholds
- test data and environment limits

## What to do

1. Understand the target scope and highest-risk flows first.
2. Organize the result around real JMeter performance testing workflows, not generic testing theory.
3. Keep assumptions visible when project details are incomplete.

## Execution Rules

- Cover tool-specific structure, execution, data, assertions, reporting, and CI concerns when relevant.
- Prefer maintainable test organization over large one-off scripts.
- If information is incomplete, give a usable first version and mark assumptions.

## Minimum Coverage Checklist

Unless the user explicitly narrows the scope, make sure the result addresses these items:
- Test Plan structure
- Thread Groups
- HTTP Samplers
- CSV Data Set Config
- non-GUI execution and HTML reports
- test data or environment needs
- reporting needs
- missing information and assumptions

## Output

Return the result in this order:

### 1. Task Understanding
### 2. JMeter Performance Testing Scope
### 3. Test Structure and Coverage
### 4. Data, Environment, and Assertions
### 5. Execution and CI Notes
### 6. Open Questions

## Quality Bar

- Keep the result JMeter performance testing-oriented.
- Do not output unrelated framework advice.
- Avoid long code unless the user asks for runnable files.

# JMeter Performance Testing Framework Notes

## Primary Focus

- Test Plan structure
- Thread Groups
- HTTP Samplers
- CSV Data Set Config
- non-GUI execution and HTML reports

## Recommended Structure

- Start from business-critical flows or endpoints.
- Group tests by product capability and execution risk.
- Keep setup, data, assertions, and reporting visible in the plan.
- Prefer maintainable naming and reusable helpers over large scripts.

## Decision Rules

- Use this skill when JMeter is the chosen or likely tool.
- Use the generic parent testing skill when the tool is still undecided.
- Call out constraints that make another tool a better fit.

# JMeter Performance Testing Setup and CI Notes

## Local Setup

- Confirm the tool version and runtime before proposing commands.
- Keep secrets, tokens, and environment-specific values outside committed test files.
- Store generated reports under a reports or build-artifacts folder ignored by version control.

## Suggested Run Command

```bash
jmeter -n -t "${TEST_PLAN:-test-plan.jmx}" -l "$REPORT_DIR/results.jtl" -e -o "$REPORT_DIR/html"
```

## CI Guidance

- Run smoke coverage on pull requests.
- Run broader regression on release branches or scheduled jobs.
- Preserve reports, logs, screenshots, traces, or result files as CI artifacts when the tool produces them.
- Fail the pipeline on clear assertion failures, not on missing optional artifacts.

#!/usr/bin/env bash
set -euo pipefail

SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
REPORT_DIR="$SCRIPT_DIR/../reports"
mkdir -p "$REPORT_DIR"
TS="$(date +%Y%m%d-%H%M%S)"
REPORT_JSON="$REPORT_DIR/performance-test-jmeter-$TS.json"

echo "Running performance-test-jmeter lightweight entry point"
echo "Report path: $REPORT_JSON"

jmeter -n -t "${TEST_PLAN:-test-plan.jmx}" -l "$REPORT_DIR/results.jtl" -e -o "$REPORT_DIR/html"