Difficulty-Progressive Example Ordering Prompt Template

This prompt template is for prompt engineers who need to maximize few-shot learning transfer in long-context classification and reasoning tasks. Use it when you have a pool of candidate examples that vary in complexity, a measurable accuracy target, and a token budget that forces you to choose which examples to include and in what order. The core job-to-be-done is converting an ad-hoc list of examples into a deliberate sequence where each example builds on the previous one, moving from simple canonical cases to complex edge cases. This strategy exploits the model's tendency to use early examples as pattern anchors while using later examples to refine decision boundaries. You should already have a task definition, a way to score example difficulty, and an evaluation harness that can measure output accuracy before attempting this ordering.

Do not use this prompt when you have fewer than five candidate examples, when all examples are of similar complexity, or when your task is purely format-driven with no reasoning depth variation. In those cases, a simpler recency-primed or primacy-optimized ordering is sufficient. Do not use this prompt for safety boundary teaching where refusal examples must appear early to establish guardrails—use the Example Ordering for Refusal Boundary Teaching Prompt instead. This prompt also assumes you are working with a single-turn task, not a multi-turn conversation where turn order and state tracking dominate example design. If your examples require tool calls or function invocations, combine this ordering strategy with the Example-Based Tool Use and Function Calling Demonstrations prompt to ensure argument construction patterns are preserved alongside difficulty progression.

Before applying this template, verify that you have a difficulty scoring method for your examples. This can be as simple as input length, number of entities, presence of negation, or number of reasoning steps required. Without a consistent difficulty signal, progressive ordering becomes arbitrary and may harm performance compared to random ordering. Also confirm that your evaluation harness can run A/B comparisons between progressive ordering and at least one baseline—random ordering or reverse-difficulty ordering—so you can measure whether the ordering strategy actually improves accuracy on your hardest test cases. If you cannot measure the effect, you are optimizing blindly.

This template is the core of the playbook. It takes your task definition, a pool of candidate examples, and your constraints, and instructs the model to produce an ordered sequence of few-shot examples arranged from simplest to most complex. The goal is to maximize the model's learning transfer by starting with unambiguous, low-noise demonstrations and gradually introducing edge cases, ambiguity, and complexity. Copy the block below, replace the square-bracket placeholders with your specific content, and run it against your candidate example pool before wiring it into your application's prompt assembly step.

textCopy
You are an expert prompt engineer optimizing few-shot example sequences for a target language model.

Your task is to take a pool of candidate input-output example pairs and order them into a final few-shot sequence that progresses from the simplest, most prototypical example to the most complex, ambiguous, or edge-case example.

# INPUTS

## Task Definition
[TASK_DESCRIPTION: Describe what the model must do. Include the input type, output type, and success criteria.]

## Candidate Example Pool
[CANDIDATE_EXAMPLES: Provide a list of input-output pairs. Each pair should include the raw input and the ideal output. You may include metadata such as difficulty labels, edge-case flags, or expected failure modes if available.]

## Constraints
[CONSTRAINTS: Specify token budget, maximum number of examples, required coverage of specific categories, or any examples that must be included or excluded.]

# ORDERING RULES

1. **Difficulty Progression**: Order examples from lowest difficulty to highest difficulty. Difficulty is defined by:
   - Number of reasoning steps required.
   - Presence of distractors, ambiguity, or conflicting signals.
   - Proximity to a decision boundary or edge case.
   - Input length and complexity.
2. **Prototype First**: Place the most representative, unambiguous example of the core task in the first position to establish a strong prior.
3. **Boundary Last**: Place edge cases, refusal-required examples, and maximum-ambiguity examples at the end of the sequence.
4. **No Difficulty Regression**: Once complexity increases, do not insert a simpler example later in the sequence unless required for a contrastive pair.
5. **Token Budget Compliance**: If the full ordered sequence exceeds [MAX_TOKENS], drop the lowest-salience examples first, prioritizing retention of boundary and edge-case examples at the high-difficulty end.

# OUTPUT SCHEMA

Return a JSON object with the following structure:
{
  "ordered_examples": [
    {
      "position": 1,
      "difficulty_rationale": "Why this example is the simplest or most prototypical.",
      "input": "<input text>",
      "ideal_output": "<output text>"
    }
  ],
  "dropped_examples": [
    {
      "input": "<input text>",
      "drop_rationale": "Why this example was excluded (token budget, redundancy, or quality)."
    }
  ],
  "sequence_metadata": {
    "total_examples_included": <count>,
    "total_examples_dropped": <count>,
    "estimated_token_count": <count>,
    "difficulty_range": "<lowest_difficulty_label> to <highest_difficulty_label>"
  }
}

# EVALUATION CRITERIA

After generating the sequence, self-evaluate against these criteria:
- Does the first example represent the most common, clean case?
- Does the last example represent the hardest case the model must handle?
- Are there any difficulty regressions in the middle of the sequence?
- Are all required categories from [CONSTRAINTS] represented?
- Is the estimated token count within [MAX_TOKENS]?

If any criterion fails, revise the ordering before returning the final output.

After pasting the template, replace each square-bracket placeholder with your concrete content. [TASK_DESCRIPTION] should be a clear, one-paragraph statement of what the model must do—include the input format, output format, and what counts as success. [CANDIDATE_EXAMPLES] is your raw material: dump in every example you have, including ones you suspect are low-quality or redundant; the ordering logic will filter them. [CONSTRAINTS] is where you enforce real-world limits: set a token budget, require at least one example from each of your high-priority categories, and flag any examples that must appear regardless of difficulty score. If you don't have explicit difficulty labels on your examples, the model will infer difficulty from input complexity, ambiguity, and number of reasoning steps—but providing your own difficulty annotations in the candidate pool will produce more reliable ordering.

Before wiring this into your production prompt assembly step, run the output through a validation harness. At minimum, confirm that the ordered_examples array is non-empty, that position values are sequential starting from 1, and that the estimated_token_count is within your budget. For high-stakes workflows, add a human review step: have a domain expert spot-check the first three and last two examples to confirm the difficulty progression matches their intuition. If you're A/B testing this ordering against random or recency-optimized ordering, use the sequence_metadata to log which examples were included and dropped so you can attribute performance differences to ordering rather than example selection.

The difficulty-progressive example ordering prompt is not a one-shot generation call—it is a pre-processing step that produces an ordered example sequence consumed by a downstream classification or reasoning prompt. The harness must therefore separate example ordering from inference. The ordering prompt receives a pool of candidate examples (with difficulty labels or proxy scores) and returns a sequenced list. That list is then injected into the [EXAMPLES] placeholder of the task prompt. This separation lets you cache ordered sequences, swap ordering strategies without touching the task prompt, and measure ordering impact independently of model behavior on the target task.

Model choice and invocation pattern. Use a fast, instruction-following model for the ordering step (e.g., gpt-4o-mini, claude-3-haiku) to keep latency and cost low. The ordering prompt should be called with temperature=0 for deterministic sequencing. The downstream task prompt may use a stronger model and higher temperature if creative variation is desired. Input validation before ordering: confirm that each candidate example has a non-empty input and expected_output field, that difficulty scores (if provided) are numeric and normalized to a consistent scale (e.g., 0.0–1.0), and that the total token count of all examples does not exceed the allocated budget. Reject or truncate the pool if validation fails, and log the event for later diagnosis. Output validation after ordering: verify that the returned sequence contains exactly the same example IDs as the input pool (no dropped or hallucinated examples), that the order progresses from lowest to highest difficulty score (monotonic non-decreasing), and that the total token count of the ordered sequence plus separators stays within budget. If validation fails, fall back to a default ordering (e.g., random shuffle with a fixed seed) and increment a ordering_failure_count metric.

A/B testing harness. To measure whether difficulty-progressive ordering improves accuracy over random or recency-optimized ordering, implement a split-testing layer. For each incoming task, randomly assign it to one of three ordering arms: difficulty-progressive, random-shuffle, or recency-last (hardest examples at the end). Route the ordered sequence to the same downstream task prompt and model. Log the ordering arm, the ordered example IDs, the model's output, and the ground-truth label (if available) to an evaluation store. Compute per-arm accuracy, format compliance rate, and latency. Use a statistical test (e.g., bootstrap confidence intervals on accuracy difference) to decide whether the progressive ordering provides a meaningful lift before hard-coding it into production. Retry and fallback logic. If the ordering prompt fails (timeout, invalid JSON, validation error), retry once with the same request. If the retry also fails, fall back to the random-shuffle ordering and log the failure with the original error payload. Do not retry more than once—ordering is a pre-processing step, and blocking the downstream task on ordering retries adds latency without proportional benefit.

Production integration points. Expose the ordering step as a standalone function or microservice with a clear contract: accept a list of Example objects (each with id, input, expected_output, difficulty_score) and a max_tokens budget, and return an ordered list of Example objects. Cache ordered sequences keyed by a hash of the example pool and difficulty scores so that repeated calls with the same pool skip the LLM call entirely. Invalidate the cache when examples are added, removed, or re-scored. Observability. Emit structured logs containing: ordering_strategy, example_count, total_tokens_used, validation_passed, fallback_used, and latency_ms. If using the A/B harness, also emit the arm label. These logs feed into dashboards that track ordering reliability and the cost-performance trade-off of the progressive strategy versus simpler baselines. What to avoid. Do not call the ordering prompt inline inside the task prompt's system message—this couples ordering to inference, prevents caching, and makes debugging order-specific failures nearly impossible. Do not skip output validation; a hallucinated or truncated example sequence silently degrades downstream accuracy and erodes trust in the entire pipeline.