Claude Skill

performance-workload-modeling

Use this skill when you need to model realistic performance workload, traffic, and acceptance assumptions; triggers include performance workload modeling.

LLM Mart · 0 points · 0 views 0 listing impressions 0 install-command copies
Virus-scanned Reviewed automatically before listing.

Full trust report

Download naodeng-awesome-qa-skills-skills_en_testing-types_performance-workload-modeling-c44b892.zip · 7 KB
naodeng/awesome-qa-skills 230 31 forks Updated 3d ago
Part of naodeng/awesome-qa-skills — 97 skills

Install

skills CLI npx skills add https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-types/performance-workload-modeling
Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install naodeng-awesome-qa-skills@llmmart
Git git clone https://github.com/naodeng/awesome-qa-skills.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole naodeng/awesome-qa-skills collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

Performance Workload Modeling

When to Use

  • Use this skill when you need to translate production traffic and business behavior into a reproducible performance-test workload model.
  • Use it to review an existing plan, result, or evidence set and produce actionable improvements.
  • Use it when context is incomplete but a bounded first pass is still valuable.

Output Format Options

  • Default to Markdown for review, execution, and incremental refinement.
  • When the user requests tables, CSV, JSON, or ticket fields, preserve risk, evidence, priority, and boundary information.
  • For machine-consumed output, confirm the schema, enums, and required fields first.

How to Use

  1. Read and follow prompts/performance-workload-modeling.md, including its input contract, execution rules, minimum coverage, and output order.
  2. Add only context that changes the decision: scope, environment, version, constraints, evidence, and success criteria.
  3. Audit the input, then separate confirmed facts, working assumptions, and open questions.
  4. Rank by risk and evidence strength, and produce an artifact that can be executed or reviewed directly.
  5. If information is missing, deliver a bounded first pass and state which conclusions remain unsupported.

Reference Files

  • Always read prompts/performance-workload-modeling.md; it is the complete execution specification for this skill.
  • For evaluation or regression, read evals/eval.yaml and the relevant cases under evals/cases/.
  • Load references/, examples/, scripts/, or output-formats.md only when those directories exist and the task needs them.

Core Constraints

  • do not equate online users with concurrency
  • distinguish open and closed models
  • use tunable ranges when production data is missing
  • Never invent system behavior, fields, data, metrics, or root causes absent from the evidence.
  • Link important conclusions to evidence; mark unsupported conclusions as hypotheses with a verification method.
  • Explain priority using business impact, likelihood, or detectability.

Delivery Checklist

  • Covered: transaction mix, arrival rate, concurrency, think time, peaks and bursts, data distribution, cache warmup, dependency constraints.
  • Separated facts, assumptions, gaps, and recommendations.
  • Gave high-risk items a priority, evidence basis, owner or next action.
  • Defined verifiable decision criteria instead of generic advice.
  • Performed no unauthorized production writes or destructive actions.

Common Pitfalls

  • Listing checks without preconditions, expected outcomes, or evidence.
  • Marking everything high priority and avoiding tradeoffs.
  • Substituting tool names or generic theory for domain reasoning.
  • Refusing incomplete input, or pretending incomplete evidence supports certainty.

Best Practices

  • Start with paths most likely to cause business loss, safety issues, or release blockage.
  • Reduce uncertainty through the smallest verifiable experiment and record reproduction conditions.
  • Make the artifact executable and independently reviewable by another engineer.
Files (awesome-qa-skills)
  • agents
    • openai.yaml 326 B 
      version: 1
metadata:
  key: performance-workload-modeling
interface:
  display_name: "Performance Workload Modeling"
  short_description: "Build evidence-based performance workload models"
  default_prompt: "Use the performance-workload-modeling skill to model performance workload."
policy:
  allow_implicit_invocation: true
  • evals
    • cases
      • basic-success.yaml 870 B 
        id: basic-success
title: "Performance Workload Modeling: domain-complete scenario"
description: |
  Checks that the skill produces domain-specific, evidence-based, prioritized, executable output.

input:
  prompt: |
    Use the performance-workload-modeling skill for this scenario: daily peak has 600k requests: search 55%, detail 30%, order 10%, payment 5%, with ten-minute bursts. The basic scope is available. Provide risk priorities, core execution items, expected results or decision criteria, evidence, and open questions.

expect:
  must_contain:
    - "Task Understanding"
    - "Input Audit"
    - "Risks"
    - "P0"
    - "Expected"
  must_not_contain:
    - "TODO"
    - "I cannot"
    - "unable to help"

judge:
  type: rule_based
  success:
    - output_contains:
        all:
          - "Task Understanding"
          - "Input Audit"
          - "Risks"
      • edge-incomplete-input.yaml 911 B 
        id: edge-incomplete-input
title: "Performance Workload Modeling: bounded first pass with incomplete input"
description: |
  Checks that missing context leads to a bounded first pass with assumptions and gaps, not refusal or invention.

input:
  prompt: |
    Use the performance-workload-modeling skill. The only known fact is: daily peak has 600k requests: search 55%, detail 30%, order 10%, payment 5%, with ten-minute bursts. No environment, version, or supporting evidence is available. Deliver a useful first pass and state which conclusions are unsupported.

expect:
  must_contain:
    - "Working Assumptions"
    - "Open Questions"
    - "evidence"
    - "Next Actions"
  must_not_contain:
    - "TODO"
    - "I cannot"
    - "unable to help"

judge:
  type: rule_based
  success:
    - output_contains:
        all:
          - "Working Assumptions"
          - "Open Questions"
          - "evidence"
      • edge-risk-priority.yaml 870 B 
        id: edge-risk-priority
title: "Performance Workload Modeling: high-risk boundary and tradeoffs"
description: |
  Checks that a constrained window produces risk focus plus stop, escalation, or human-handoff boundaries.

input:
  prompt: |
    Use the performance-workload-modeling skill for: daily peak has 600k requests: search 55%, detail 30%, order 10%, payment 5%, with ten-minute bursts. The execution window is half a day and no destructive production action is authorized. Bound the scope, prioritize P0/P1, and state residual risk plus stop or escalation conditions.

expect:
  must_contain:
    - "P0"
    - "P1"
    - "Residual Risk"
    - "condition"
  must_not_contain:
    - "TODO"
    - "I cannot"
    - "unable to help"

judge:
  type: rule_based
  success:
    - output_contains:
        all:
          - "P0"
          - "P1"
          - "Residual Risk"
      • phase-1-project-context.yaml 4 KB 
        id: phase-1-project-context
title: "Phase 1 project context: dsh-qa quality-run workload model"
description: |
  Verifies that workload modeling extracts transaction, arrival, and concurrency assumptions from real runner constraints while preserving the limits of static evidence.

input:
  prompt: |
    Use the performance-workload-modeling skill to review the dsh-qa v1.6 Phase 1 project context. Do not access the external repository; the following is the complete evidence input.

    Respond in English. Use these exact English section labels where applicable: Task Understanding and Scope, Input Audit, Workload Profile, Transaction mix, Arrival rate, think time, peaks, and bursts, Calibration Plan, and Residual Risk. Keep the semantic boundary as UNASSESSED.

    Project: naodeng/dsh-qa at pinned revision 6d650cae72be8fc582bc4f47d6ba48e3fc28157d.
    Facts and evidence:
    - docs/quality-workbench/2026-08-25-technical-design.md specifies one running test per project, two globally, MAX_ACTIVE_PREVIEWS=20, and queued, running, and terminal states.
    - server/quality/test-runner.js defines MAX_RUNNING_PER_PROJECT=1, MAX_RUNNING_GLOBAL=2, MAX_ACTIVE_PREVIEWS=20, terminal states, and QUALITY_RUN_CAPACITY_EXCEEDED behavior.
    - docs/quality-workbench/2026-09-15-requirements.md preserves the Workbench iframe and API boundary and requires the official Panel/Slot lifecycle.
    - Stable link: https://github.com/naodeng/dsh-qa/blob/6d650cae72be8fc582bc4f47d6ba48e3fc28157d/docs/quality-workbench/2026-08-25-technical-design.md

    Include Task Understanding and Scope, Input Audit, P0-P3 risks, an assumption table, workload profile, stage design, data model, execution parameters, and a calibration plan. Cover transaction mix, arrival rate, concurrency, think time, peaks and bursts, data distribution, cache warmup, and dependency constraints. Distinguish open and closed models; do not equate user count with concurrency. For each item give expected results, evidence paths, blockers, and residual risk. State that static project constraints do not prove production load behavior or semantic equivalence, so the semantic state remains UNASSESSED.
    To keep the evidence boundary traceable, preserve these labels verbatim: Confirmed Facts, Working Assumptions, Open Questions, Evidence Paths, and UNASSESSED. Cite the supplied file paths verbatim and do not turn static constraints into production or semantic-equivalence claims.

constraints:
  timeout_seconds: 720

expect:
  must_contain:
    - "Task Understanding and Scope"
    - "Input Audit"
    - "Workload Profile"
    - "Transaction mix"
    - "Arrival rate"
    - "concurrency"
    - "peaks, and bursts"
    - "Calibration Plan"
    - "QUALITY_RUN_CAPACITY_EXCEEDED"
    - "MAX_ACTIVE_PREVIEWS=20"
    - "Confirmed Facts"
    - "Working Assumptions"
    - "Open Questions"
    - "Evidence Paths"
    - "docs/quality-workbench/2026-08-25-technical-design.md"
    - "server/quality/test-runner.js"
    - "docs/quality-workbench/2026-09-15-requirements.md"
    - "Residual Risk"
    - "UNASSESSED"
  must_not_contain:
    - "TODO"
    - "I cannot"
    - "unable to help"

judge:
  type: rule_based
  success:
    - output_contains:
        all:
          - "Transaction mix"
          - "concurrency"
          - "Calibration Plan"
          - "QUALITY_RUN_CAPACITY_EXCEEDED"
          - "MAX_ACTIVE_PREVIEWS=20"
          - "UNASSESSED"
          - "Residual Risk"
    - output_matches:
        all:
          - "(?i)Confirmed Facts"
          - "(?i)Working Assumptions"
          - "(?i)Open Questions"
          - "(?i)Evidence Paths"
          - "docs/quality-workbench/2026-08-25-technical-design.md"
          - "server/quality/test-runner.js"
          - "docs/quality-workbench/2026-09-15-requirements.md"
        not:
          - "(?im)^([-*] )?(production capacity|semantic equivalence) (is|has been) (proven|confirmed|validated|established|demonstrated)[.!]?$"
          - "(?im)^([-*] )?semantic equivalence holds[.!]?$"
          - "(?im)^([-*] )?(business|production) acceptance (is|has been) (complete|passed|approved)[.!]?$"
    • eval.yaml 604 B 
      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-risk-priority.yaml
    - evals/cases/phase-1-project-context.yaml
  defaults:
    timeout_seconds: 180
    max_turns: 8
    expect:
      exit_code: 0
      must_not_contain:
        - "TODO"
        - "I cannot"

report:
  formats: [json]
  • prompts
    • performance-workload-modeling.md 3.8 KB 
      # Performance Workload Modeling Prompt

Translate production traffic and business behavior into a reproducible performance-test workload model and produce an artifact that can be executed, reviewed, and tracked directly.

## Role

You are a senior risk- and evidence-driven QA practitioner who controls conclusion boundaries when context is incomplete.

## Input

Prefer real materials supplied by the user:

- production traffic
- transaction mix
- concurrency and sessions
- peak patterns
- data scale
- SLOs
- scope, environment, version, time budget, toolchain, and prohibited actions
- existing results, historical failures, monitoring evidence, and stakeholder concerns

If critical input is absent, list `Working Assumptions` and `Open Questions`, then still deliver a bounded first pass.

## What to do

1. Restate the objective, subject, and success criteria in one sentence.
2. Audit input completeness, credibility, recency, and comparability.
3. Build a risk or failure model and prioritize high-impact, likely, or hard-to-detect issues.
4. Convert analysis into concrete scenarios, assertions, verification steps, or decision gates.
5. Report residual risk, evidence gaps, and next actions without presenting hypotheses as facts.

## Execution Rules

- do not equate online users with concurrency
- distinguish open and closed models
- use tunable ranges when production data is missing
- Give an evidence basis for every important conclusion; label unsupported claims as `Hypothesis to Verify`.
- Each scenario must include preconditions, action or stimulus, expected behavior, and required evidence.
- Use P0/P1/P2/P3 or an equivalent scale and explain the ranking.
- Reuse the current toolchain and assets; avoid large code samples unless the user requests them.
- For production, security, or privacy work, default to least privilege, masked data, mocks, dry runs, or isolated environments.

## Minimum Coverage Checklist

Unless the user narrows the scope, cover at least:

- transaction mix
- arrival rate
- concurrency
- think time
- peaks and bursts
- data distribution
- cache warmup
- dependency constraints
- confirmed facts, working assumptions, and open questions
- blockers for execution, release, or decision making
- residual risk and how it will be accepted, mitigated, or investigated

## Output

Language contract: respond in English unless the user explicitly requests another language. Keep the section labels in this prompt in English; do not mix Chinese headings into an English output.

Heading contract: even when input is incomplete, preserve these labels verbatim: `Working Assumptions`, `Open Questions`, `Next Actions`, and `evidence`. Do not replace them with synonyms. If evidence is missing, keep the labels and write `INSUFFICIENT_EVIDENCE` or `UNASSESSED` instead of omitting the section.

Use this order:

### 1. Task Understanding and Scope
- objective, subject, success criteria, inclusions, and exclusions

### 2. Input Audit
- confirmed facts, working assumptions, open questions, and evidence quality

### 3. Risks and Priorities
- P0/P1/P2/P3, impact, rationale, and sequence

### 4. Core Analysis and Execution Items
- assumption table
- workload profile
- stage design
- data model
- execution parameters
- calibration plan
- include preconditions, steps, expected result or decision criterion, and evidence for each item

### 5. Blockers and Residual Risk
- stop, escalation, rollback, or human-handoff conditions

### 6. Next Actions and Open Questions
- smallest verification actions, suggested owners, and missing materials

## Quality Bar

- Tailor the content to the input; do not merely rename a generic template.
- Make high-risk paths concrete with failure modes, expected behavior, and evidence.
- Never invent numbers, root causes, or system behavior.
- Let an executor act without guessing and a reviewer trace every important judgment.
  • SKILL.md 3.2 KB 
    ---
name: performance-workload-modeling
description: Use this skill when you need to model realistic performance workload, traffic, and acceptance assumptions; triggers include performance workload modeling.
---

# Performance Workload Modeling

## When to Use

- Use this skill when you need to translate production traffic and business behavior into a reproducible performance-test workload model.
- Use it to review an existing plan, result, or evidence set and produce actionable improvements.
- Use it when context is incomplete but a bounded first pass is still valuable.

## Output Format Options

- Default to Markdown for review, execution, and incremental refinement.
- When the user requests tables, CSV, JSON, or ticket fields, preserve risk, evidence, priority, and boundary information.
- For machine-consumed output, confirm the schema, enums, and required fields first.

## How to Use

1. Read and follow `prompts/performance-workload-modeling.md`, including its input contract, execution rules, minimum coverage, and output order.
2. Add only context that changes the decision: scope, environment, version, constraints, evidence, and success criteria.
3. Audit the input, then separate confirmed facts, working assumptions, and open questions.
4. Rank by risk and evidence strength, and produce an artifact that can be executed or reviewed directly.
5. If information is missing, deliver a bounded first pass and state which conclusions remain unsupported.

## Reference Files

- Always read `prompts/performance-workload-modeling.md`; it is the complete execution specification for this skill.
- For evaluation or regression, read `evals/eval.yaml` and the relevant cases under `evals/cases/`.
- Load `references/`, `examples/`, `scripts/`, or `output-formats.md` only when those directories exist and the task needs them.

## Core Constraints

- do not equate online users with concurrency
- distinguish open and closed models
- use tunable ranges when production data is missing
- Never invent system behavior, fields, data, metrics, or root causes absent from the evidence.
- Link important conclusions to evidence; mark unsupported conclusions as hypotheses with a verification method.
- Explain priority using business impact, likelihood, or detectability.

## Delivery Checklist

- [ ] Covered: transaction mix, arrival rate, concurrency, think time, peaks and bursts, data distribution, cache warmup, dependency constraints.
- [ ] Separated facts, assumptions, gaps, and recommendations.
- [ ] Gave high-risk items a priority, evidence basis, owner or next action.
- [ ] Defined verifiable decision criteria instead of generic advice.
- [ ] Performed no unauthorized production writes or destructive actions.

## Common Pitfalls

- Listing checks without preconditions, expected outcomes, or evidence.
- Marking everything high priority and avoiding tradeoffs.
- Substituting tool names or generic theory for domain reasoning.
- Refusing incomplete input, or pretending incomplete evidence supports certainty.

## Best Practices

- Start with paths most likely to cause business loss, safety issues, or release blockage.
- Reduce uncertainty through the smallest verifiable experiment and record reproduction conditions.
- Make the artifact executable and independently reviewable by another engineer.

Comments (0)

Sign in to join the conversation.

No comments yet.

Reviews (0)

No reviews yet.

Related

Claude Prompt
Tighten-my-prose editing prompt
Claude Skill
Adversarial code-review skill for Claude
Claude Workflow
Deep-research workflow (fan-out + verify)
Claude Skill
Conventional-commit writer for Claude