Plan Similarity Matching Prompt for Reuse Candidates

This prompt is designed for plan library systems that need to find the closest archived plan to a new goal. It takes a new goal description and a set of candidate archived plans, then produces a ranked list with similarity scores and rationale. Use this when your agent framework maintains a library of previously successful plans and you want to reduce planning latency, cost, and variance by reusing proven workflows instead of generating plans from scratch. This prompt belongs in the retrieval-and-ranking stage of a plan reuse pipeline, after candidate plans have been fetched from a vector store or metadata index but before a plan is adapted for execution.

The ideal user is an AI engineer or agent architect building a plan reuse system. You need a structured, repeatable way to compare a new goal against archived plans and decide which ones are worth adapting. The prompt requires two inputs: a clear description of the new goal, including any constraints and success criteria, and a set of candidate plans retrieved from your plan library. Each candidate should include its original goal, steps, tools used, and any recorded outcomes or failure modes. The prompt works best when candidates have been pre-filtered by domain or tool availability to reduce noise before ranking.

Do not use this prompt when the new goal is fundamentally novel with no reasonable archived analogues, when the plan library is empty or contains only deprecated plans, or when the cost of adapting a similar plan exceeds the cost of generating a new one from scratch. This prompt is also insufficient on its own for high-risk domains such as healthcare, finance, or safety-critical operations—always add a human review step before executing a reused plan in those contexts. The prompt ranks similarity but does not validate that the top-ranked plan is safe to execute; pair it with a downstream plan gap analysis or confidence scoring prompt before committing to reuse.

Before wiring this into production, define your similarity thresholds. A score above 0.8 might trigger automatic adaptation, while scores between 0.5 and 0.8 might require human review, and scores below 0.5 should fall back to fresh plan generation. Log every ranking result with the new goal, candidate IDs, scores, and the rationale provided by the model. This trace data becomes your evaluation dataset for tuning retrieval quality and detecting ranking drift over time. Start with a small set of hand-labeled goal-to-plan pairs to calibrate whether the model's similarity judgments match your team's expectations before scaling to automated reuse.

This prompt template is designed to be pasted directly into your agent orchestrator, evaluation harness, or plan library service. It accepts a new goal description and a set of candidate archived plans, then returns a ranked list with similarity scores and rationale. Replace each square-bracket placeholder with real data before execution. The template includes explicit output schema constraints, evaluation criteria, and failure mode handling to make it production-ready.

textCopy
You are a plan similarity analyst for an agent workflow system. Your task is to compare a new goal against a set of archived plans and identify the best reuse candidates.

## INPUT
New Goal: [NEW_GOAL_DESCRIPTION]

Archived Plans:
[ARCHIVED_PLANS_LIST]

Each archived plan includes:
- plan_id: unique identifier
- goal: original goal description
- steps: ordered list of step descriptions
- tools_used: list of tool names invoked
- constraints: list of constraints that applied
- success_criteria: how success was measured
- failure_modes: known failure modes from execution logs (if available)

## OUTPUT_SCHEMA
Return a JSON object with this exact structure:
{
  "candidates": [
    {
      "plan_id": "string",
      "similarity_score": 0.0-1.0,
      "rank": integer starting at 1,
      "rationale": "string explaining why this plan is similar, what matches, and what differs",
      "matched_aspects": ["list of specific aspects that match the new goal"],
      "gaps": ["list of aspects from the new goal not covered by this plan"],
      "adaptation_effort": "low" | "medium" | "high",
      "reuse_confidence": 0.0-1.0
    }
  ],
  "no_suitable_match": false,
  "analysis_notes": "optional summary of overall matching landscape"
}

## CONSTRAINTS
- Rank by similarity_score descending.
- If no plan scores above [MINIMUM_SIMILARITY_THRESHOLD], set no_suitable_match to true and return an empty candidates array.
- similarity_score must reflect goal alignment, tool overlap, constraint compatibility, and step structure similarity.
- reuse_confidence must account for known failure modes and adaptation effort.
- Do not fabricate plan details. Only reference information present in the input.
- If fewer than [MINIMUM_CANDIDATES] plans are provided, return all of them ranked.

## EVALUATION CRITERIA
- Goal similarity: Does the archived plan address the same type of objective?
- Tool overlap: Are the required tools available in the current environment?
- Constraint compatibility: Do the original constraints conflict with current constraints?
- Step structure: Is the sequence of steps logically applicable to the new goal?
- Failure mode relevance: Are known failure modes likely to recur?

## FAILURE MODE HANDLING
- If a plan has known failure modes that match the new goal's risk profile, reduce reuse_confidence proportionally.
- If tool overlap is below [MINIMUM_TOOL_OVERLAP], set adaptation_effort to "high" and cap reuse_confidence at 0.5.
- If constraint conflicts are detected, flag them in gaps and reduce similarity_score.

## EXAMPLES
[FEW_SHOT_EXAMPLES]

Return only the JSON object. No additional text.

To adapt this template, replace each placeholder with production data. [NEW_GOAL_DESCRIPTION] should be the user's stated objective, cleaned and normalized. [ARCHIVED_PLANS_LIST] should be a JSON array of plan objects retrieved from your plan library. Set [MINIMUM_SIMILARITY_THRESHOLD] based on your tolerance for false positives—start at 0.4 and tune with eval data. Set [MINIMUM_CANDIDATES] to control how many plans must be present before ranking proceeds. [FEW_SHOT_EXAMPLES] should include 2-3 annotated examples showing correct scoring for high-similarity, partial-match, and no-match cases. [MINIMUM_TOOL_OVERLAP] should reflect your environment's tool availability tolerance.

Before deploying, validate that the output JSON parses correctly and that similarity_score values are monotonically decreasing by rank. Run this prompt against a golden dataset of known goal-to-plan pairs where you have ground-truth relevance judgments. Measure ranking quality with NDCG or recall@k. Watch for false positives where the model assigns high scores to structurally similar but semantically irrelevant plans. If your plan library is large, pre-filter candidates with a lightweight retrieval step before invoking this prompt to stay within context limits.

The Plan Similarity Matching Prompt is designed to be called from a plan library service, not used as a standalone chat. The typical integration pattern is a retrieval-augmented generation (RAG) pipeline: a lightweight embedding-based retrieval step first narrows the candidate pool from thousands of archived plans to a manageable top-N (e.g., 20–50), then this prompt performs the high-precision semantic ranking and rationale generation. This two-stage approach keeps latency and token costs predictable while preserving ranking quality. The prompt expects a structured [NEW_GOAL] object and a [CANDIDATE_PLANS] array, both of which should be assembled by the application layer before the model call.

Validation is critical because the output drives downstream reuse decisions. Implement a post-processing validator that checks: (1) the response is valid JSON matching the [OUTPUT_SCHEMA]; (2) every plan_id in the ranked list exists in the input candidate set; (3) similarity scores are within the declared range (e.g., 0.0–1.0); and (4) each entry includes a non-empty rationale string. If validation fails, retry once with the same prompt plus the validation error message appended as a [CONSTRAINTS] amendment. After two failures, log the raw response and candidate set for manual review and return a degraded result—either an empty ranking or the embedding-based ordering as a fallback. For high-stakes reuse (e.g., plans that trigger financial transactions or infrastructure changes), require human approval on any match below a configurable similarity threshold, typically 0.7.

Model choice matters for ranking consistency. Use a model with strong instruction-following and structured output capabilities, such as GPT-4o, Claude 3.5 Sonnet, or equivalent. Avoid smaller or older models that may collapse scores toward the middle of the range or omit rationales. Set temperature=0 for deterministic rankings. If your plan library exceeds 100 candidates even after embedding pre-filtering, consider batching: split candidates into groups of 25–30, rank each group independently, then run a second merge-ranking pass with the top 5 from each batch. Log every similarity query with the goal fingerprint, candidate count, model version, and top-3 results for observability. This log becomes the foundation for offline evaluation—periodically sample queries and have domain experts rate the top-3 relevance to calibrate your similarity threshold and detect ranking drift after model updates.

For evaluation, maintain a golden test set of 20–50 goal-to-plan pairs with known relevance judgments (highly relevant, partially relevant, not relevant). Run this prompt against the golden set on every prompt or model change and measure Precision@3, Recall@3, and the false-positive rate at your production similarity threshold. A false positive here means recommending a plan that a human reviewer would reject as irrelevant—these are more costly than false negatives because they waste downstream adaptation effort. Set a release gate: if Precision@3 drops below 0.85 or the false-positive rate exceeds 0.15, block the change and investigate. Pair this with a periodic human review sample of production matches to catch distribution shifts that your golden set doesn't cover.