tag-duplicate-prs-issues

Files (2)

• SKILL.md
• openai.yaml · agents/

SKILL.md (first lines)

# Tag Duplicate PRs and Issues

Use this skill when a maintainer needs to decide whether a pull request or issue is a duplicate of existing work.

This skill is for maintainer triage and grouping.
It is not for reviewing the implementation quality of a PR.

## Required Setup

Do not start duplicate triage until this setup is complete.

### Install the companion skills

Install these skills first because they teach the agent how to use the two main CLIs correctly:

- `ghreplica` skill from the `ghreplica` repo at `skills/ghreplica/SKILL.md`
- `prtags` skill from the `prtags` repo at `skills/prtags/SKILL.md`

This skill assumes those two skills are available and can be used during the same run.

### Install the CLIs

Install `ghreplica` and `prtags` from their latest GitHub releases.
Do not rely on an old local build unless the maintainer explicitly wants to test unreleased behavior.

`ghreplica` CLI install path:

```bash
curl -fsSL https://raw.githubusercontent.com/dutifuldev/ghreplica/main/scripts/install-ghr.sh | bash -s -- --bin-dir "$HOME/.local/bin"
```

`prtags` CLI install path:

```bash
curl -fsSL https://raw.githubusercontent.com/dutifuldev/prtags/main/scripts/install-prtags.sh | bash -s -- --bin-dir "$HOME/.local/bin"
```

Use the `pr-search-cli` project with `uvx`.
The command itself is `pr-search`.
Do not require a permanent install unless the maintainer explicitly wants one.

```bash
uvx --from pr-search-cli pr-search status
uvx --from pr-search-cli pr-search code similar 67144
```

### Authenticate prtags

`prtags` should be logged in with the maintainer's own GitHub account through OAuth device flow.
Do not use a shared maintainer token for interactive triage.

```bash
prtags auth login
prtags auth status
```

The expected outcome is that `prtags` stores the logged-in maintainer identity locally and uses that account for authenticated writes.

## Missing-Setup Rule

Do not require an up-front preflight before starting the workflow.
Proceed with the normal steps until you actually need a tool or account state.

As soon as you discover that a required CLI is missing or `prtags` is not logged in, stop immediately.
Do not continue in a partial mode after that point.

If `ghr` is missing, ask the user to run the `ghreplica` install command.

If `prtags` is missing, ask the user to run both CLI install commands:

```bash
curl -fsSL https://raw.githubusercontent.com/dutifuldev/ghreplica/main/scripts/install-ghr.sh | bash -s -- --bin-dir "$HOME/.local/bin"
curl -fsSL https://raw.githubusercontent.com/dutifuldev/prtags/main/scripts/install-prtags.sh | bash -s -- --bin-dir "$HOME/.local/bin"
```

If `uvx --from pr-search-cli pr-search ...` fails because `uvx` or the `pr-search` launcher is not available, ask the user to make that command work before continuing.

If `prtags auth status` shows that the user is not logged in, ask the user to run:

```bash
prtags auth login
```

Resume only after the missing tool or login state has been fixed.

## Read-Path Default

For read-only GitHub operations in this workflow, use `ghr` as the default CLI.
Treat it as a drop-in replacement for the `gh` read operations you would normally use for PRs, issues, comments, reviews, and duplicate-search evidence.

Only fall back to `gh` when `ghr` is failing for a concrete reason, such as:

- the mirrored object is not present yet
- the mirror data is clearly stale or incomplete for the decision you need to make
- the `ghr` command errors, times out, or does not expose the specific read you need

When you fall back to `gh`, note that you did so and why.

If `ghr` is missing a fresh PR or issue but `gh` can read it, you may use `gh` for the read-side judgment.
If a later `prtags` target-level write fails because the same object is still missing from `ghreplica`, stop and report that the mirror has not caught up yet instead of forcing the write.

## Goal

For each target PR or issue:

1. gather duplicate evidence
2. decide whether it is a real duplicate
3. create or reuse one `prtags` group for that duplicate cluster
4. save the maintainer judgment in `prtags`
5. rely on normal `prtags` group writes to drive GitHub comment sync when that integration is configured

## Tool Roles

Use the tools with these boundaries:

- `ghreplica` is the raw evidence source
  - use `ghr` first for normal GitHub read operations in this workflow
  - use it for title/body/comment search, related PRs, overlapping files, overlapping ranges, and current PR or issue status
  - resort to `gh` only when `ghr` cannot provide the needed read cleanly

From rudofopelomi-cell/10h, MIT.

More from rudofopelomi-cell/10h