Instruction Compression Prompt for Production Deployments

This prompt is for prompt engineers and AI operators who need to reduce the token count of a system message or instruction block without losing behavioral fidelity. The core job-to-be-done is taking a verbose, human-readable instruction set and producing a compressed version that preserves the same output quality, refusal boundaries, and task performance. The ideal user already has a working prompt that is too expensive or too large for the target context window and needs a repeatable compression method rather than manual guesswork. Required context includes the original instruction text, a representative set of test inputs, and the expected output schema or behavioral contract. You should also have a target token budget or compression ratio in mind.

Do not use this prompt when the original instructions are already under 200 tokens, when the behavior is not yet stable, or when you lack a regression test suite to verify that the compressed version behaves identically. Compression is lossy by nature, and without eval checks you risk silently dropping critical constraints. This prompt is also inappropriate for compressing few-shot examples, retrieved evidence, or conversation history. Those require separate salience-ranking or summarization prompts. If your instructions contain legal disclaimers, safety policies, or compliance language, compression must be followed by human review and behavioral regression testing before any production deployment.

Before running this prompt, assemble a golden test set of at least 20 inputs that exercise normal paths, edge cases, refusal triggers, and format requirements. Run the original prompt against this set and capture the outputs as your baseline. After compression, run the same test set through the compressed prompt and compare outputs using both automated checks (exact match on structured fields, schema compliance, refusal rate) and LLM-as-judge evaluation for semantic equivalence. If the compressed prompt fails any test, iterate with targeted fixes rather than accepting degraded behavior. The next section provides the copy-ready prompt template you can adapt for your own instruction set.

The following template accepts a verbose system instruction block and produces a compressed version that retains the original behavioral contract. Use it when you need to reduce token consumption in production without silently dropping constraints. The prompt is designed to be wired into a pre-deployment compression pipeline, not used as a one-off chat interaction.

textCopy
You are an instruction compressor for production AI systems. Your task is to rewrite the provided system instructions into a compact, token-efficient form while preserving all behavioral constraints, refusal boundaries, tone requirements, and output contracts.

## INPUT
[ORIGINAL_INSTRUCTIONS]

## COMPRESSION RULES
1. Remove all redundancy, filler words, and conversational politeness that does not change model behavior.
2. Preserve every constraint, rule, refusal condition, format requirement, and behavioral boundary exactly as stated.
3. Do not add new constraints, remove existing ones, or change the meaning of any instruction.
4. Use concise, imperative language. Prefer lists and structured blocks over prose paragraphs.
5. Maintain the original instruction priority order. If the original implies a hierarchy, preserve it.
6. If the original contains examples, keep them only if they are essential to disambiguate behavior. Otherwise, summarize the pattern they demonstrate.
7. Output only the compressed instructions. Do not add explanations, commentary, or meta-notes.

## OUTPUT FORMAT
[COMPRESSED_INSTRUCTIONS]

## CONSTRAINTS
- The compressed output must be self-contained and usable as a drop-in replacement for the original system message.
- Target at least [TARGET_COMPRESSION_RATIO]% token reduction without behavioral loss.
- If compression would risk ambiguity, err on the side of preserving the original wording for that section.

Adapt this template by replacing [ORIGINAL_INSTRUCTIONS] with your current system message and setting [TARGET_COMPRESSION_RATIO] to your desired reduction percentage. For high-risk domains such as healthcare, legal, or finance, add a human review step after compression and run behavioral regression tests comparing compressed vs. original instruction performance before deployment. Never ship a compressed instruction block without validating that refusal boundaries, output schemas, and critical constraints remain intact.

The instruction compression prompt is not a one-off optimization tool—it should be integrated into your prompt lifecycle as a pre-deployment step. Before shipping a new system message to production, run the original instruction through the compression prompt to produce a candidate compressed block. The harness must then validate that the compressed version preserves behavioral fidelity before it replaces the original in live traffic. This means the compression prompt itself is part of a larger pipeline: compress, validate, compare, and only then deploy.

Wire the compression prompt into your CI/CD or prompt management workflow as a gated step. After compression, run a behavioral regression test suite that sends identical inputs to both the original and compressed system messages and compares outputs using an LLM judge or structured eval rubric. Define pass/fail thresholds for semantic equivalence, instruction adherence, and refusal boundary preservation. If the compressed version fails any threshold, block deployment and flag the regression for manual review. Log the compression ratio, token savings, and eval scores as artifacts for each prompt version. For high-risk domains, require human approval on the diff between original and compressed outputs before the compressed version enters production.

Model choice matters for the compression step itself. Use a capable instruction-following model (such as GPT-4 or Claude 3.5 Sonnet) for the compression task, even if your production model is smaller or cheaper. The compression prompt should run with low temperature (0.0–0.2) to produce deterministic, repeatable results. Implement retry logic with a maximum of three attempts if the compressed output fails structural validation (missing sections, malformed output, or token count exceeding the target budget). After three failures, escalate to a human reviewer rather than silently falling back to the uncompressed version. Store the compressed instruction alongside the original in your prompt registry with version metadata, compression date, and the eval results that justified its promotion to production.