Code Duplication and DRY Violation Prompt

This prompt is designed for platform engineering teams and technical leads who need to systematically reduce maintenance burden caused by duplicated logic across a codebase. Its primary job is to analyze a provided diff or set of files, identify instances of copy-paste programming and near-duplicate code blocks, and produce a structured deduplication opportunity list. The output is not just a list of duplicates; it includes concrete abstraction suggestions, such as extracting a shared function, creating a base class, or introducing a utility module, making it directly actionable for a developer planning a refactoring sprint.

To use this prompt effectively, you must provide a well-scoped [INPUT] that contains the source code to be analyzed. This could be a unified diff from a pull request, the contents of several files in a repository, or a specific module. The prompt is most effective when the [CONTEXT] includes the programming language and the team's preferred abstraction patterns (e.g., 'we prefer composition over inheritance' or 'use functional utility libraries'). You should also define an [OUTPUT_SCHEMA] to structure the findings, typically a JSON array of objects, each containing the duplicate locations (file paths and line ranges), a similarity score, the suggested abstraction, and a rationale. Without a strict schema, the model may produce a narrative report that is difficult to integrate into an automated CI/CD pipeline or a project management tool.

This prompt is not a replacement for a dedicated static analysis tool like SonarQube or a specialized clone detector. It should not be used as a gate to block a pull request automatically, as it can generate false positives. A critical constraint is that intentional duplication—such as code kept separate to avoid premature coupling, to meet stringent performance requirements, or to maintain independent deployment lifecycles—must be handled carefully. Your evaluation criteria must include a step for a human reviewer to flag these as 'accepted duplication' to prevent the prompt from driving unnecessary and potentially harmful abstraction. The next step after generating the deduplication list is to feed each high-confidence finding into a follow-up prompt or a manual review process to design the specific refactoring, ensuring behavior is preserved with existing tests.

This prompt template is designed to be copied directly into your AI harness or prompt management system. It accepts a code diff, file set, or repository context and returns a structured analysis of duplication patterns. The square-bracket placeholders allow you to inject the specific code under review, define the output schema your tooling expects, and set constraints that match your team's tolerance for abstraction. Use this template as the foundation for a CI/CD integration, a code review assistant, or a technical debt quantification pipeline.

codeCopy
SYSTEM: You are a code duplication and DRY violation detector. Your task is to analyze the provided code and identify duplicated logic, cut-and-paste programming, and near-duplicate code blocks. You must distinguish between intentional duplication (e.g., for performance, clarity, or domain boundary reasons) and unintentional duplication that increases maintenance burden.

INPUT:
[CODE_DIFF_OR_FILE_SET]

CONTEXT:
[PROJECT_CONTEXT]

OUTPUT_SCHEMA:
{
  "findings": [
    {
      "id": "string",
      "severity": "high | medium | low",
      "pattern_type": "exact_duplicate | near_duplicate | structural_duplicate | boilerplate_duplicate",
      "locations": [
        {
          "file": "string",
          "start_line": "integer",
          "end_line": "integer",
          "snippet": "string"
        }
      ],
      "description": "string",
      "abstraction_suggestion": {
        "approach": "extract_function | extract_class | template_method | strategy_pattern | parameterize | configuration_driven",
        "rationale": "string",
        "pseudocode": "string",
        "risk_notes": "string"
      },
      "intentional_duplication_flag": "boolean",
      "intentional_duplication_reason": "string | null"
    }
  ],
  "summary": {
    "total_findings": "integer",
    "high_severity_count": "integer",
    "estimated_maintenance_impact": "high | medium | low",
    "deduplication_effort_estimate": "small | medium | large"
  }
}

CONSTRAINTS:
[CONSTRAINTS]

EXAMPLES:
[FEW_SHOT_EXAMPLES]

INSTRUCTIONS:
1. Analyze the entire input for repeated code patterns, not just identical lines.
2. For each finding, determine if the duplication is likely intentional based on domain context, performance requirements, or framework conventions.
3. Flag intentional duplication clearly and explain why it should not be abstracted.
4. For unintentional duplication, provide a concrete abstraction suggestion with pseudocode.
5. Do not flag duplication that is idiomatic to the language or framework unless it creates a maintenance risk.
6. If [CONSTRAINTS] specifies a severity threshold, suppress findings below that threshold.
7. Output ONLY valid JSON matching the OUTPUT_SCHEMA. No additional text.

To adapt this template for your team, start by defining the [CONSTRAINTS] placeholder. Common constraints include a minimum duplicate block size (e.g., ignore blocks under 5 lines), a severity threshold for reporting, or a list of files and patterns to exclude from analysis. The [PROJECT_CONTEXT] placeholder should include your language, framework, and any domain-specific conventions that help the model distinguish intentional from unintentional duplication. For example, a React project might note that some component structure duplication is idiomatic, while a data processing pipeline might flag any repeated transformation logic. The [FEW_SHOT_EXAMPLES] placeholder is critical for calibration: include 2-3 examples of findings your team considers true positives and 1-2 examples of intentional duplication you want the model to suppress. Without these examples, the model will default to flagging all structural similarity, producing a high false-positive rate that undermines trust in the output.

Before integrating this prompt into a production pipeline, validate the output against a golden dataset of known duplication cases. Test edge cases such as generated code, vendored dependencies, and macro-expanded templates, which often produce structural duplication that should not be refactored. If your team operates in a regulated domain or the code under review controls safety-critical systems, require human review of all high-severity findings before any refactoring is attempted. The intentional_duplication_flag field is your primary defense against false positives—monitor its accuracy in production and use misclassifications to improve your few-shot examples over time.

This prompt is designed to operate on a structured input containing a file set or unified diff, and it expects a machine-readable output schema. The most reliable integration pattern is to call the prompt from a CI job or a code review automation service (such as a GitHub Action, GitLab CI, or a custom pre-commit hook) that can supply the diff context and parse the JSON response. The prompt should be treated as a stateless function: given a set of code changes, it returns a list of duplication findings. Avoid using this prompt interactively in a chat interface for production use; instead, wrap it in an API call with strict timeout, retry, and validation logic.

Before sending the prompt, assemble the [INPUT] by extracting the diff or file contents from the version control system. For pull requests, use the PR's unified diff. For batch repository analysis, chunk the codebase into logical groups (e.g., by module or directory) to stay within context window limits. The [CONSTRAINTS] field should be populated with your team's duplication threshold (e.g., minimum number of duplicated lines, similarity percentage) and any domain-specific patterns to ignore (e.g., boilerplate, license headers, generated code). The [OUTPUT_SCHEMA] should be enforced by the application layer: parse the model's JSON response, validate it against a schema that requires file_path, line_range, duplicate_of, similarity_score, and abstraction_suggestion fields, and reject any response that does not conform. Implement a retry loop with exponential backoff (max 3 attempts) for malformed responses, and log each attempt for observability. For high-risk codebases where a false negative could mask a critical maintenance issue, route findings with a similarity_score above 0.85 to a human review queue before auto-commenting on the PR.

Model choice matters for this task. Use a model with strong code understanding and a large context window, as duplication analysis often requires holding multiple files in context simultaneously. If the diff is too large, pre-filter it using a lightweight syntactic clone detector (e.g., a token-based tool) to identify candidate duplicate regions, then use this prompt only on those candidates to generate the contextual explanation and abstraction suggestion. Always log the prompt version, model identifier, and input hash alongside the output for auditability. Do not use this prompt as a gate that blocks merges automatically; instead, surface findings as non-blocking comments or tickets until the team has calibrated the false positive rate against their codebase norms.