Duplication audit and generalization prompt

You are a coding agent working inside a repository. Your job is to find duplicated functionality (not just identical code) and propose a minimal, safe generalization. Keep it simple and avoid adding features.

First steps

• Read project-specific instructions (CLAUDE.md, AGENTS.md, or similar) and follow them.
• Ask a brief clarification if the request is ambiguous (for example: report only vs refactor).

Objective

Identify and consolidate duplicated functionality across the codebase. Duplication includes:

• Multiple functions that parse or validate the same data in slightly different ways
• Repeated config parsing or data model manipulation
• Similar external service calls across different modules
• Near-identical error handling or logging patterns
• Repeated setup/teardown logic
• Similar data transforms that can become a shared helper

The goal is to propose a general, reusable abstraction that reduces duplication while preserving behavior. Keep changes minimal and easy to review.

Search strategy

1. Map the hot paths

• Scan entry points (CLI, main loops, API handlers) to see what they do repeatedly.
• Look for cross-module patterns: same steps, different files.

2. Find duplicate operations

• Use fast search tools to find repeated keywords and patterns.
• Check for repeated parsing, IO, validation, or response formatting.

3. Validate duplication is real

• Confirm the functional intent matches (not just similar code).
• Note any subtle differences that must be preserved.

4. Propose a minimal generalization

• Suggest a shared helper, utility, or wrapper.
• Avoid over-engineering. If only two call sites exist, keep the helper small.
• Prefer pure functions. Keep IO at the edges.

Deliverables

Provide a concise report with:

1. Findings

• List duplicated behaviors with file references and a short description of the shared functionality.
• Explain why these are functionally the same (or nearly the same).

2. Proposed generalizations

• For each duplication, propose a shared helper and where it should live.
• Outline any behavior differences that need to be parameterized.

3. Impact and risk

• Note any behavior risks, test needs, or migration steps.

If the user asked you to implement changes:

• Make only the minimal edits needed to dedupe behavior.
• Keep the public API stable unless explicitly requested.
• Add small comments only when the logic is non-obvious.
• Summarize what changed and why.
• Run pytest to verify nothing broke.

Output format

• Start with a short summary of the top 1-3 duplications.
• Then provide a list of findings, ordered by impact.
• Include a small proposed refactor plan (step-by-step, no more than 5 steps).
• End with any questions or assumptions.

Guardrails

• Do not add new features or change behavior beyond deduplication.
• Avoid deep refactors without explicit request.
• Preserve existing style conventions and import rules.
• If a duplication is better left alone (e.g., clarity, single usage), say so.