Prompt Fuzzing Mutation Strategy Prompt

This prompt is for QA-automation engineers and red-team testers who need to build a systematic fuzzing pipeline for any target prompt. Instead of manually guessing what might break a prompt, this prompt generates a structured, repeatable mutation strategy. Use it when you need to define the operators, intensity levels, and stability thresholds before writing a single line of fuzzing code. The output is a plan, not the fuzzed inputs themselves. This belongs in the pre-production testing phase, right after a prompt is drafted and before it faces a golden dataset or live traffic.

The ideal user has a target prompt ready for testing and needs a configurable attack plan. Required context includes the target prompt's full text, its expected output schema, any known failure modes, and the operational risk level of the system. You must also define the fuzzing budget: how many mutations to generate, which mutation classes are in scope (insertions, deletions, swaps, noise injection, encoding tricks), and what constitutes a stability failure. Without this context, the generated strategy will be generic and miss system-specific vulnerabilities. Do not use this for one-off ad-hoc testing; it is designed for building automated, configurable QA harnesses that can be versioned alongside the prompt.

Avoid using this prompt when you have not yet stabilized the target prompt's core instructions. Fuzzing a prompt that is still undergoing fundamental rewrites wastes effort and produces noisy results. Also avoid it when you need actual fuzzed inputs immediately—this prompt produces a strategy document, not the mutated test cases themselves. For generating the actual test inputs, pair this with a downstream harness that executes the strategy. After receiving the strategy, your next step should be to review the proposed mutation operators for relevance, adjust intensity levels to match your risk tolerance, and implement the plan in your CI/CD pipeline with clear pass/fail assertions tied to each operator class.

This template is the core engine for generating a mutation strategy. It takes a target prompt, your testing constraints, and a desired output schema, then produces a detailed fuzzing plan. The plan will specify mutation operators, intensity levels, and stability thresholds tailored to the target prompt's structure and risk profile. Paste this directly into your orchestration layer, replacing the square-bracket placeholders with your specific inputs.

textCopy
You are a senior QA automation architect specializing in adversarial testing for large language models. Your task is to design a comprehensive fuzzing strategy for a given target prompt. The strategy must systematically probe the target prompt's boundaries, reveal brittle instructions, and uncover failure modes before they reach production.

## TARGET PROMPT

[TARGET_PROMPT]

codeCopy

## FUZZING CONTEXT
- **Application Context:** [APPLICATION_CONTEXT]
- **Risk Level:** [RISK_LEVEL]
- **Specific Vulnerabilities to Probe:** [VULNERABILITIES]
- **Model(s) Under Test:** [MODELS]

## OUTPUT SCHEMA
Your response must be a valid JSON object conforming to this structure:
[OUTPUT_SCHEMA]

## CONSTRAINTS
- [CONSTRAINT_1]
- [CONSTRAINT_2]
- [CONSTRAINT_3]

## EXAMPLES OF GOOD MUTATION OPERATORS
[EXAMPLES]

## TOOLS AVAILABLE FOR TEST EXECUTION
[TOOLS]

Generate the fuzzing strategy document now, ensuring every mutation operator is directly linked to a potential failure mode in the target prompt.

To adapt this template, start by pasting your complete target prompt into the [TARGET_PROMPT] placeholder. For [APPLICATION_CONTEXT], describe what the prompt does in production (e.g., 'customer support ticket classifier'). The [RISK_LEVEL] should be one of low, medium, or high and will influence the intensity of the generated mutations. Crucially, define a strict [OUTPUT_SCHEMA]—a JSON schema that includes fields for mutation_operators, intensity_levels, and expected_stability_thresholds. This structured output is essential for wiring the results into an automated testing harness. If you are testing a high-risk prompt, such as one handling PII or financial data, add a constraint like 'All generated test inputs must be logged for human review before execution.' After generating the strategy, your next step is to feed this JSON plan into your fuzzing engine, using the defined operators to generate the actual mutated inputs for your test suite.

This prompt is designed to be the first stage in a multi-step fuzzing pipeline. It does not execute the fuzzing; it produces a mutation plan that a downstream harness reads and applies. The harness should parse the JSON output, validate the mutation operators and intensity levels against a predefined schema, and then use the plan to drive a separate fuzzing engine that mutates inputs and sends them to the target prompt under test. Treat the output as a configuration artifact, not as executable code.

The implementation harness should enforce a strict contract. After calling the LLM, validate the response against a JSON schema that requires mutation_operators (an array of objects with name, type, intensity, and target fields), intensity_levels (an ordered list), and stability_thresholds (a map of metric names to numeric bounds). If validation fails, retry once with the validation error injected into the [CONSTRAINTS] field. Log the raw prompt, the model response, and the validation result for every run. For high-risk target prompts (e.g., safety policies, PII redaction), require a human to approve the mutation plan before execution begins. Use a model with strong JSON mode and low temperature (0.1–0.2) to maximize output stability.

Once the mutation plan is approved, feed it into a fuzzing executor that iterates over each operator and intensity level, generates mutated inputs, and sends them to the target prompt. The executor should track which mutations cause schema violations, policy refusals, or output drift beyond the stability thresholds defined in the plan. Store all results—mutation plan, mutated inputs, target outputs, and pass/fail flags—in a structured log for later analysis. Avoid running destructive mutations directly against production endpoints; use a staging or shadow deployment of the target prompt. The harness should also enforce a maximum mutation count per run to prevent runaway resource consumption.