abstraction-finder

Abstraction Finder

Find repetition that has earned an abstraction, then propose the smallest general-purpose form of it. Scan the code (whole repo or a named area), cluster genuine duplicates, and for each cluster propose a shared helper/service/base class/template/util with the concrete call sites it replaces.

The point isn't to list every near-match — it's to surface a short set of extractions that remove real duplication without over-abstracting. This is the counterweight to kiss: kiss strips a change to its minimum and resists new abstractions; this skill argues for an abstraction, but only once the duplication is real and repeated. Hold both — the target is the abstraction the code has actually earned, not the one you can imagine needing.

Scope first

State what you're scanning before you scan — the whole repo, a directory, a domain, one feature — and list it so the user can confirm you're pointed at the right code. A whole-repo scan is noisy; a scoped scan is actionable. Ask for a scope if the user didn't give one.

Process

1. Find repetition. Search for near-identical logic, duplicated markup, parallel utilities, and copy-paste clusters within the scope.
2. Read the real occurrences. Surface similarity is not sameness — two functions can look alike and differ in a way that matters. Open each candidate before calling it a duplicate. (This is evidence-check territory: "these are duplicates" and "no existing helper covers this" are claims to confirm by reading, not assert from memory.)
3. Cluster and count. Group true duplicates and record every call site (file:line). Count is the primary signal: three or more genuine occurrences is a candidate, two is a watch-item, one is not a duplicate.
4. Check the rule of three and what already exists. Before proposing anything, confirm the language/framework or an existing shared helper doesn't already cover it. Don't reinvent what the stack provides. Two occurrences is a coincidence; three is a pattern. The exception: if two known sites are already drifting (the same fix had to be applied in both, or they've started to disagree), unify early — drift is itself a reason.
5. Propose the smallest form. For each qualifying cluster: its shape (helper / service / base class / template / util), where it lands, a concrete signature, and the call sites it replaces.
6. Weigh the trade-off. Name the cost (indirection, coupling, a new thing to maintain) against the benefit (call sites removed, single source of truth). Not every duplicate is worth collapsing.