Token-Efficient Example Selection Prompt

This prompt is for prompt engineers and AI builders who need to maximize the behavioral coverage of a few-shot example set within a strict token budget. The job-to-be-done is ranking candidate examples by their coverage-per-token value and producing a budget-aware selection that preserves the widest possible range of input patterns, edge cases, and output behaviors. The ideal user is someone who already has a pool of candidate examples and a known token limit—such as a context window constraint for a specific model or a cost cap for high-throughput inference—and needs a principled way to trim the set without gutting its diversity.

Use this prompt when you are optimizing an existing example set for production deployment and token cost is a binding constraint. It is appropriate when you have more candidate examples than you can fit and need to understand the marginal coverage loss of each removal. The prompt expects you to provide the candidate examples, a token budget, and optionally a set of coverage dimensions you care about—such as demographic representation, difficulty tiers, language registers, or domain terminology. It is not a prompt for generating new examples from scratch, nor is it a replacement for evaluating whether your examples actually produce correct model behavior. If you haven't yet validated that your candidate examples teach the right thing, run an example quality scoring or behavioral consistency check first.

Do not use this prompt when your token budget is not yet fixed, when you lack a defined set of coverage dimensions, or when the primary problem is example quality rather than example quantity. It also should not be used as a substitute for measuring real production coverage gaps—this prompt optimizes selection from what you already have, but it cannot detect that your candidate pool is missing entire categories of inputs. Pair it with a coverage gap detection prompt or a production data distribution comparison before finalizing your example set. For high-risk domains where example selection errors could cause harmful model behavior, always include a human review step after the ranked selection is produced, and validate the trimmed set against a golden test suite before deployment.

This prompt template is designed to be dropped directly into your application or evaluation harness. It takes a candidate pool of examples, a target token budget, and a coverage specification, then returns a ranked selection with marginal coverage loss estimates. The square-bracket placeholders let you swap in your own example pool, budget, and coverage dimensions without rewriting the core logic.

textCopy
You are an example selection optimizer for few-shot prompting. Your task is to select a subset of examples from a candidate pool that maximizes coverage within a strict token budget.

## INPUTS
[CANDIDATE_EXAMPLES]

## COVERAGE DIMENSIONS
[COVERAGE_DIMENSIONS]

## TARGET TOKEN BUDGET
[MAX_TOKENS]

## CONSTRAINTS
[CONSTRAINTS]

## INSTRUCTIONS
1. Score each candidate example against every coverage dimension on a 0-1 scale, where 1 means the example fully represents that dimension.
2. Calculate a coverage-per-token score for each example: sum of dimension scores divided by the example's token count.
3. Rank examples by coverage-per-token score in descending order.
4. Select examples from the ranked list until adding the next example would exceed [MAX_TOKENS].
5. For each example that was not selected, estimate the marginal coverage loss: the coverage dimensions that become unrepresented or under-represented if that example is excluded.
6. If any coverage dimension has zero representation in the selected set, flag it as a critical gap.

## OUTPUT SCHEMA
Return a JSON object with this exact structure:
{
  "selected_examples": [
    {
      "example_id": "string",
      "example_text": "string",
      "token_count": number,
      "coverage_scores": { "dimension_name": number },
      "coverage_per_token": number
    }
  ],
  "total_tokens_used": number,
  "budget_remaining": number,
  "excluded_examples": [
    {
      "example_id": "string",
      "marginal_coverage_loss": ["dimension_name"],
      "loss_severity": "critical" | "moderate" | "minor"
    }
  ],
  "coverage_gaps": ["dimension_name"],
  "trimming_recommendations": [
    {
      "action": "remove" | "replace" | "add_budget",
      "target_example_id": "string",
      "rationale": "string",
      "estimated_token_savings": number
    }
  ]
}

## RULES
- Never exceed [MAX_TOKENS] in the selected set.
- If two examples have identical coverage-per-token scores, prefer the one with fewer tokens.
- If a coverage dimension is only represented by examples that would exceed the budget, flag it in coverage_gaps and suggest a budget increase in trimming_recommendations.
- Do not fabricate coverage scores. If a dimension cannot be assessed from the example text, score it as 0.

To adapt this template, replace [CANDIDATE_EXAMPLES] with a JSON array of objects, each containing an example_id, example_text, and pre-computed token_count. The [COVERAGE_DIMENSIONS] placeholder should list the dimensions you care about—such as ["formality_register", "domain_terminology", "input_length", "demographic_persona"]—with brief descriptions so the model knows what to score. Set [MAX_TOKENS] to your context window limit minus the tokens consumed by instructions, system prompts, and the user input. The [CONSTRAINTS] field can specify hard requirements like "must include at least one example per demographic category" or "exclude examples with PII."

Before shipping this prompt, validate the output against your expected schema. Common failure modes include the model exceeding the token budget despite the instruction, producing coverage scores that don't sum correctly, or omitting the marginal_coverage_loss field for excluded examples. Add a post-processing validator that checks total_tokens_used <= [MAX_TOKENS], confirms every coverage dimension appears in at least one selected example's coverage_scores, and rejects outputs where coverage_gaps contains dimensions that are actually covered. For high-stakes example selection—such as medical or legal domains—route the ranked output to a human reviewer before injecting the selected examples into production prompts.

This prompt is designed to be called programmatically as part of a periodic example set optimization job, not as a one-off manual prompt. The typical integration pattern is a scheduled pipeline that fetches the current example pool, production input distribution statistics, and token budget constraints, then calls this prompt to produce a ranked, budget-aware selection. The output should be treated as a recommendation that requires validation before the new example set replaces the active prompt configuration. Because the prompt makes coverage-per-token trade-offs that affect model behavior in production, treat example set changes with the same rigor as a model update.

Integration steps: (1) Gather inputs: the candidate example pool (with metadata like category, difficulty, demographic tags), a production distribution sample or summary statistics, and the target token budget. (2) Render the prompt template with these inputs, ensuring the [EXAMPLE_POOL] placeholder contains structured JSON with id, text, tokens, and coverage_dimensions fields per example. (3) Call the model with response_format set to JSON mode and a defined output schema matching the expected ranked list structure. (4) Validate the output before applying it: check that total tokens are within budget, that coverage dimensions from the input are represented in the output, and that no example IDs were hallucinated. (5) Run a behavioral equivalence check by comparing model outputs on a golden eval set using the old and new example sets. Flag any regression above a threshold (typically 5% change in pass rate). (6) Log the selection decision, coverage scores, and marginal loss estimates for auditability. (7) If the prompt returns a [MARGINAL_LOSS] estimate above a configured threshold for any removed example, route for human review before finalizing.

Failure modes to handle in code: The model may return example IDs not present in the input pool (hallucination). Implement a strict ID membership check and reject selections with unknown IDs, retrying with a stronger constraint instruction. The model may exceed the token budget despite instructions; apply a hard truncation in application code, removing the lowest-ranked examples until the budget is satisfied, and log the override. The model may optimize for one coverage dimension at the expense of others; use the [COVERAGE_WEIGHTS] placeholder to encode business priorities explicitly. Model choice: Use a model with strong JSON mode and long-context handling (GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro). Avoid models with weak instruction following for structured outputs, as the ranking and marginal loss calculations require precise adherence to the output schema. Retry logic: If validation fails, retry once with the validation error message appended as a [CONSTRAINTS] update. If the second attempt fails, fall back to a deterministic greedy coverage algorithm and alert the team.

What to avoid: Do not run this prompt on every user request—it is a batch optimization prompt, not a real-time selector. Do not skip the behavioral equivalence check; token-efficient selections can inadvertently drop examples that were load-bearing for specific edge cases. Do not treat the marginal loss estimates as ground truth; they are model-generated approximations and should be calibrated against your own eval metrics over time. Finally, version your example sets alongside your prompt templates in your prompt registry so you can roll back if a new selection introduces regressions.