# Reuse

> Find opportunities for code reuse in the changed code, both against existing code and within the change itself, without creating bad coupling or contrived abstractions.

- Skill: `tomeraberbach/reuse` (Agent Skill)
- Install (CLI): `npx skillmds add tomeraberbach/reuse`
- Raw SKILL.md: https://api.skillmd.com/api/skills/tomeraberbach/reuse/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: TomerAberbach (https://skillmd.com/u/tomeraberbach)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/tomeraberbach/reuse

---


Find opportunities for code reuse in the changed code, both against existing
code and within the change itself, without creating bad coupling or contrived
abstractions.

# Target

```!
jj show --git
```

Arguments: $ARGUMENTS

Find reuse opportunities in the target named in the arguments if given.
Otherwise find them in the changes in the current commit shown above. If there
are no arguments and the commit has no changes, ask the user which code to
review and stop.

# Principles

- Duplication is only a problem when the copies must change together. Two pieces
  of code that look alike but encode different decisions are coincidentally
  similar. Merging them couples unrelated change reasons
- Prefer reuse that adds no new code: call something that already exists in the
  codebase, the standard library, or an installed dependency
- A little duplication is cheaper than the wrong abstraction. When in doubt,
  leave the copies

# Workflow

1. For each changed function or code chunk, search for code that already does
   the job, in order of preference:
   1. The standard library of the language
   2. Dependencies already installed, listed in the manifest, e.g.
      `package.json`. Don't propose new dependencies
   3. Utilities and helpers elsewhere in the codebase
   4. Other code in the same module
2. Compare the added chunks against each other: a change often introduces the
   same logic twice in different files, and neither copy existed before, so
   searching existing code won't find it
3. For each duplication found in steps 1 and 2, decide whether to reuse or
   extract, using the tests below
4. If nothing passes the tests, say so and stop. Don't invent findings
5. Report each opportunity (see "Reporting"). Don't apply changes unless the
   arguments or a follow-up message ask for it

# Tests for a reuse opportunity

Flag an opportunity only when it passes all of these:

1. Same reason to change: if a requirement shifts, every call site must require
   the new behavior. If one caller might need to diverge, it's coincidental
   similarity
2. Precise name: the shared code has a name that describes one job. If the best
   available name is vague (`helper`, `util`, `process`, `handleData`), the
   abstraction is contrived
3. No parameter switches: the shared code needs no boolean flags, mode enums, or
   callbacks whose only purpose is to make callers behave differently. Each such
   parameter reintroduces the duplication
4. Dependencies point downward: callers depend on something at a lower level of
   abstraction. Never make a general module import from a specific feature, and
   never couple two unrelated features to share a few lines
5. Worth the cost: the shared code saves more than it costs. Extracting three
   trivial lines into a new shared module fails this; replacing a hand-rolled
   deep-clone with an existing utility passes

These aren't exhaustive. Reason from first principles when none fits cleanly.

# Reporting

For each opportunity, one paragraph: the duplicated or reimplemented logic (file
path and line range), the call sites it covers, what to reuse or extract
instead, and the test that came closest to failing, with why it still passes.
Order by impact, largest first.