I Got Into a 49k-Star Curated List With 1 PR. The Prep Took 7 Weeks

Last Tuesday I got a notification from GitHub: PR #1110 merged into 1c7/chinese-independent-developer. Bot user app/claude auto-merged it in 1 hour 33 minutes. The list has 49,000 stars. The side project I have been shipping for the last six months was now an entry on a list I had been staring at for almost two years. I want to write down what I actually did to get in, because the obvious story ("PR to a curated list, got merged") is the wrong story. The real story is seven weeks of prep for one line of diff.

What I assumed before I started

The naive plan was: find a curated list, ship a one-liner, ship a PR, win. I tried that on three different lists in 2025. Every time my PR sat open for weeks, then closed without comment or got rejected silently. I assumed the lists were gatekept by humans who never check the queue. I was wrong.

Some of them are auto-merged by bots. Some of them have rigid contribution templates that fail in subtle ways. None of them care about one-line pitches. What they actually care about: does your entry match the format of the entries around it. That was the lesson. Not product quality. Format.

The 7 weeks of prep that was actually one grep

I read the upstream README.md end to end, every day for a week, on mobile, on my laptop, in different orderings. What I was looking for was where the format breaks. Some sections use [GitHub] and others use [Github]. Some entries link only the product, some include a separate 查看仓库 line. The README is grouped by date, not by category. That took me longer than I want to admit to recognize, because every list aggregation I had previously seen was category-grouped.

The single most useful thing I did: I grepped the codebase for which features the extension actually supports. I had been writing one-liners that said "5 platforms" when the registry showed 10. Saying 5 when 10 was true left value on the table, and if a reviewer cross-checked it against my Chrome Web Store description, I would have been caught. So the prep was mostly: read the format, grep my own code, edit the diff until it was indistinguishable from the entries around it.

The one-line diff

The whole contribution is one insert under a ### 2026 å¹´ 7 月 15 号添åŠ header. Four lines of markdown:

#### mnbqwe10(Beijing) - [GitHub]

then a ✅ line with a Chrome Web Store link, a one-liner, and a repo link. The bot read the title, checked there was a product link, confirmed the GitHub handle matched an existing repo, and merged it. I never talked to a human.

The merge bot ran app/claude, which I had not heard of until the PR timeline. Worth checking which operator runs the merge bot on a list before you spend prep time on it.

What I would tell someone else trying this

• Pick a list you have actually used. If you have never opened the repo, you do not know its conventions and a reviewer will tell.
• Spend the time reading the entries near where your insertion will land, not the whole file. The format drift is local; sections have local conventions. Match the immediately preceding entry, not the README opener.
• Do not ask for permission to add yourself in the issue tracker first. Some lists auto-close self-nomination issues. Just open the PR with the right format. If they want to reject, they will, and a polite reply in the PR thread works better than a second PR.

The prep-to-diff ratio was not what I expected. Almost all the time was upstream format research. The diff itself took under a minute to write.

I built a small Chrome sidebar that summarizes whatever page you are on, in plain language, without sending the page to a third party. The extension is listed under my AI Buddy handle. List entry felt different from every launch I had done before. The list still works as a discovery channel even at a small user count.

Anyone else have a list they have been staring at forever?

Top comments (1)

What stood out to me is that almost none of the effort went into writing the PR itself. It went into reducing friction for the maintainer. That’s a useful reminder that successful open-source contributions are often more about understanding the target project’s conventions than about writing more code.