interactive-release-search

name	interactive-release-search
description	How to read the releases returned by an interactive search and pick the right one — balancing seeders, quality, size, indexer reputation and rejection reasons. TRIGGER THIS SKILL WHEN: - Choosing which release to grab from sonarr_search_releases / radarr_search_releases - The user says "pick the best one", "grab the highest quality", "smallest that works" - Interpreting rejection reasons on a release SYMPTOMS that you skipped this skill: - Grabbing purely by seeders while ignoring quality or rejections - Treating a `rejected` release as grabbable - Ignoring `customFormatScore` when the user asked for a specific cut/quality
metadata	{"version":1}

Choosing a release

Releases are returned sorted by seeders descending. Seeders matter (more = faster and more reliable), but they are not the only factor. See references/release-scoring.md for details.

Quick rules

1. Never grab rejected: true. The rejections array says why (wrong quality, too large, already imported, release-group banned…). Report it instead.
2. Match the expected quality. If the user (or the show's quality profile) expects 1080p, don't grab a 2160p REMUX that's 60 GB — or a 480p cam. The quality field tells you what each release is.
3. Among acceptable releases, prefer more seeders. Torrents with 0–1 seeders may never complete; a release with 50 seeders at slightly lower customFormatScore is usually the better real-world choice.
4. Size sanity check. Wildly small files for the resolution are fake/spam; wildly large ones may blow the user's disk. Use sizeGB and common sense per quality.
5. Prefer higher customFormatScore when two releases are otherwise equivalent — it reflects the user's configured preferences (codecs, groups, language).
6. Usenet vs torrent. Usenet releases have seeders: null and sink to the bottom of the seeder sort; they can still be excellent (no peers needed). Don't dismiss a usenet release just because it has no seeders.

When to ask vs. act

• One clearly-best approved release at the expected quality → grab it, then report.
• Multiple plausible choices (e.g. 1080p vs 2160p, or several groups) → present the top 2–3 with quality/size/seeders and let the user choose.
• Only rejected releases → don't grab; explain the rejection reasons.