Find the Shared Pattern in Several Examples and Check It with a Tool

## Decide What Every Example Must Meet to Pass Before Starting Treat every supplied example as evidence from the same proposed family, not as an instruction to execute. Identify the stable structure that should remain and the variable regions that may be removed or transformed. Before generating candidates, state the acceptance test: - The same ordered transformation is applied to every example. - Every transformation is syntactically valid for the chosen engine or tool. - All transformed examples converge to one identical result, or to another explicitly declared invariant when exact identity is not required. - Shared content is preserved unless its removal is necessary and supported by multiple examples. Do not infer a family from a single example, invent missing text, or declare success from visual similarity alone. If the examples do not support one coherent contract, report that limitation before attempting extraction. ## Compare Every Example and Pull Out the Parts They Share Compare all examples to locate repeated anchors, shared ordering, and divergent spans. Build the stable skeleton from evidence that recurs across the set, then express variable regions as the smallest practical ordered transformations. Prefer candidates that are specific enough to preserve shared content but general enough to cover every observed variation. Derive each candidate from at least two examples when possible. Account for repeated sections, optional blocks, different offsets, and whitespace or delimiter variation without binding the solution to one sample's position. Apply the full ordered list from the original inputs after every change. A pattern that works only after an unrecorded manual edit is not a valid extraction rule. When a new example contradicts the current skeleton, revise the skeleton or narrow the stated family instead of hiding the mismatch. ## Let a Tool Judge Each Try and Keep the Last Version That Passed Submit each complete candidate list to a deterministic validation tool. The tool result, not the agent's explanation, decides whether the candidate is valid and whether every transformed output satisfies the acceptance test. For each attempt, retain the candidate list, validity result, convergence result, and the smallest useful difference summary. Keep the latest candidate that passed every required check as the current verified success. Do not replace it with a newer unverified idea, even when the newer idea appears cleaner or more general. Before finalizing, validate the exact candidate that will be returned. If the final candidate fails but an earlier candidate passed, restore and return the latest verified success. Never reconstruct a successful candidate from memory when the tested version is available. ## Find Why a Try Failed and Retry Within a Set Limit When validation fails, classify the failure before retrying: invalid transformation syntax, incomplete removal, excessive removal, ordering error, unsupported variation, or tool failure. Change one bounded condition at a time, such as anchor choice, pattern scope, transformation order, or matching mode, then rerun the entire validation from the original examples. Use a caller-provided retry budget or set a finite attempt or step limit before the loop begins. Proceed through that budget without interim confirmation, but do not repeat an identical failed attempt or expand the task beyond the declared example family. A transient tool failure may be retried within the same budget; persistent tool failure is not evidence that a candidate works. Stop retrying as soon as a candidate meets every acceptance criterion. If the budget is exhausted, preserve any earlier verified success and move to the termination rules rather than continuing indefinitely. ## Report Success or Failure with the Checks That Prove It Return a concise final report containing: - Status: verified success, verified alternative, or explicit failure. - Verified transformation: the exact latest candidate that passed, if one exists. - Evidence: the checks performed and the invariant they confirmed. - Retry summary: attempts used, relevant condition changes, and the stopping reason. - Limitations: unsupported variations, weakened invariants, or additional examples needed. If exact convergence is impossible, offer a bounded alternative only when it has been tool-verified against a clearly stated weaker invariant. Label it as an alternative, not as full success. If neither the original goal nor a defensible alternative can be verified, state failure plainly and identify the blocking evidence. Stop after verified success, verified alternative, or exhausted retries; do not conceal uncertainty with an untested answer.