# Duplicate Sweep

Find and merge duplicate Linear issues, group reports of the same underlying bug, pick...

- Repository: https://github.com/ParadevAI/Paradev (15823 stars)
- Category: Engineering
- License: see repository
- Last updated: 2026-11-01
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add ParadevAI/Paradev --skill duplicate-sweep -g -a claude-code -y`
Codex: `npx skills add ParadevAI/Paradev --skill duplicate-sweep -g -a codex -y`
Cursor: `npx skills add ParadevAI/Paradev --skill duplicate-sweep -g -a cursor -y`
Gemini CLI: `npx skills add ParadevAI/Paradev --skill duplicate-sweep -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add ParadevAI/Paradev`

## Description

Find and merge duplicate Linear issues, group reports of the same underlying bug, pick the survivor, and move the evidence across. Use when the backlog has grown noisy, someone asks whether an issue is already reported, or you are cleaning up before planning.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# Sweep duplicates

Two issues for one bug means two people investigate it and neither sees the other's findings.
The goal is one issue per underlying problem, holding everything anyone learned.

## 1. Search the way reporters write, not the way you think

The same bug gets filed as "export is broken", "CSV download 500s", and "can't get my data
out". No shared vocabulary. Run several searches, the error string, the feature name, the
user-facing verb, and pool the results rather than trusting one query.

Include closed issues. A closed one is not evidence the bug came back, triage closes far more
issues than fixes do. Treat it as a regression only when the issue records a fix that shipped
or was reopened; otherwise it is just another report of the same open problem.

## 2. Same symptom is not the same bug

Group only when the underlying cause is plausibly identical. Two issues that both say
"page is slow" are the same report only if they are slow for the same reason; merging them
buries whichever one nobody reproduced.

When you are unsure, link them as related and say why rather than merging. An incorrect merge
loses an issue silently, and nobody goes looking for what they think is already tracked.

## 3. Pick the survivor deliberately

Not simply the oldest. Prefer the one with the best reproduction, then the most discussion,
then the earliest. If the oldest is a one-line report and a later one has steps, logs, and
three participants, the later one survives.

## 4. Confirm the groups before you touch anything

Show the user each group you intend to merge: the survivor, the issues folding into it, and
what you will move across. Merging is destructive in the way that matters, an issue closed
as a duplicate stops being found by the people watching it, and an incorrect merge is only
discovered when someone re-reports the bug months later. Get an explicit go-ahead per group,
or on the set if the user prefers, before the first write.

The rest: https://github.com/ParadevAI/Paradev/blob/HEAD/plugins/linear/skills/duplicate-sweep/SKILL.md