git:20260525.a483ef2 to git:20261014.0f16275

- You are reviewing code written in this session (or in a prior session whose work this session is clearly continuing) for DRY violations. The scope is _just the work that was done_ — not the whole codebase.

- The output of this skill is **edits, not a report**. Apply the obvious wins yourself and only ask the user about the genuinely ambiguous calls.

- - After implementing a feature in the current session and before / during housekeeping.

- - When resuming a summarized session that has a clear concrete deliverable in flight (e.g. a flow task), the scope is the deliverable's diff.

- - Skip if the session has no concrete recent code work (research-only, planning-only, conversation-only).

- 1. **Uncommitted changes**: `git diff HEAD` and untracked files via `git status --short`. If non-empty, that's the scope.

- 2. **Commits made in this session**: `git log --oneline @{u}..HEAD` (commits ahead of upstream on the current branch). If non-empty, that's the scope.

- 3. **Restored session with concrete prior work**: if the session summary references specific files modified in named commits on the current branch, use the SHA range from the summary (`git diff <start-sha>..HEAD`). Confirm with the user before assuming.

- Run `git diff <range> --stat` first to confirm the scope and surface the file count.

- Read every file in scope fully. For test files, read them too — duplicated assertion patterns or fixture builders are fair game.

- If the user provided focus guidance ("focus on the streaming changes"), narrow accordingly but still glance at the rest.

- For every duplication you spot, check whether it's **real** (the code already says the same thing twice) vs **speculative** (the code _might_ need to be the same later). Only real duplication counts.

- - **Callsite count**: 2 callsites is the threshold for considering an extraction; 3+ makes it a clear win. 2 is borderline — extract only if the rule itself is non-trivial or coupled (e.g. provider-namespacing, a magic string with semantic meaning).

- - **Coupling**: do the duplicates need to change together? If yes, dedupe protects against drift. If no (they happen to look alike now), don't dedupe — premature abstraction.

- - **Abstraction cost**: a 1-line predicate or a Sass `%placeholder` is cheap; a new component with props is expensive. Match the cost to the win.

- - **Distance**: same file = local extraction. Cross-file in the same slice = small helper. Cross-slice = check if it belongs in `shared/`.

- A clear win on every dimension: real coupled rule, ≥2 callsites, cheap extraction, no naming or placement ambiguity. Examples:

- - A magic string with semantic meaning duplicated in 2+ places in the same file → extract a 1-line predicate or constant.

- - A 4+ line CSS rule block repeated in 2+ classes in the same module → extract a Sass `%placeholder`.

- The duplication is real, but at least one dimension is genuinely unclear and a code reviewer might reasonably prefer either choice. Examples:

- - Naming or placement uncertain: should the helper live in this file, the slice's `lib`, or `shared`?

- - Semantic ambiguity: the duplicates _look_ identical but might be expressing different intent that future edits would diverge.

- - A new shared component would replace the duplication but with non-trivial prop API design.

- - **Belt-and-suspenders patterns** (e.g. `.done()` in both success and `.finally()`): intentional, not duplication.

- - **Same shape, different semantics** (e.g. one helper returns last value, another returns all): merging hides intent.

- - **Boilerplate the framework requires** (e.g. `'use client'`, `import` lines, mock setup blocks).

- - **Test fixtures across files** with different scenarios — duplication there documents intent.

- - **Visual similarity without rule similarity** — e.g. two CSS classes with the same color but for unrelated UI concepts.

- Make the edits surgically — one DRY fix per logical change, minimal surrounding churn. Do not bundle unrelated cleanups. Do not rename things that aren't part of the dedupe.

- - A one-sentence statement of _why it's ambiguous_ — what dimension is unclear and what choices the user has.

- Do **not** rank these or recommend one. The point of surfacing them is that you don't know.

- - **Don't propose extractions you wouldn't make in a code review.** If a 2-line repetition is genuinely fine, treat it as a non-issue and skip silently.

- - **Don't invent abstractions.** New helpers must replace existing duplication, not anticipate future duplication.

- - **Don't widen scope.** If a file in the diff calls a duplicate that exists _elsewhere_ in the codebase (outside the diff), mention it once but don't fix it — that's a separate task.

- - **Don't ask permission for OBVIOUS fixes.** That's the whole point of triaging — if it's obvious, just do it.