Time to address the 2nd elephant in the room: There are too many really bad and/or pointless vibecoded PRs for vibecoded new apps.

Note that it would probably not benefit anyone if I am to list all of the ≥500 involved currently open PRs, but long-timers to Winget's repos will have a general understanding of what I'm thinking about.

Over the course of the summer and autumn of 2026, there's been a massive rush of PRs for new GitHub-hosted packages, in which both the PR itself is poorly formatted, and the app that the PR is for is vibecoded experimental pre-alpha… at best. Most cases I don't think had human coding involved in the apps at all, and some I don't think had even been *tested* by any humans.

Making the matter even worse, is that trying to help out any of those PRs' OPs will either have the advices be completely ignored, or their implementations be mangled beyond fathom (and with random textwall replies) by the same Aİs they used to both code the app and submit the app. On one occasion (and yes, this is a true story), an Aİ of one of those PRs wrote an unhinged and wildly angry rant comment to me after I wrote disapprovingly of a Copilot review.

It's time for Winget as a whole to put down the foot on these. To say to the world that we need to have at least **some** standards. Usually I'm almost never on the same side in tech as the hardcore "Security first" philosophy followers, but we could **really** need to stop PRs for outright untested apps that someone cooked up in OpenAI a couple days before.

Therefore, I hereby propose that PRs get automatically instantly closed if they meet **all** of the following 5 criteria:
* Its app is hosted on github.com.
* Its repo has 2 or fewer ★.
* Its repo was created ≤249 days before the PR was created.
* The PR submitter's GitHub account is the same account as the owner of the app's repo.
* The PR has the `New-Package` label.

Even my lowest estimates of how many PRs that would be closed, so that we could all focus on reviewing better apps, is at 550. My highest estimate is around 850.

Start by reviewing the five proposed criteria for New-Package pull requests and the issue's estimate of affected submissions. Define what automation should inspect and what should happen to matching pull requests; done means qualifying pull requests are closed consistently without affecting those outside the criteria.

Written by the indexing model from the issue text.