One sentence to paste into an agent to set up 69 quality gates in your repo: where dev-quality-gates' 300 stars came from

On the afternoon of Oct 24, 2026, Kirill Mokevnin, co-founder of the Russian programming school Hexlet, posted in his Telegram channel under the title "Quality Gates всем и пусть никто не уйдет обиженным" ("Quality gates for everyone, and nobody leaves empty-handed"). He said he'd spent years trying out checking tools on Hexlet projects, had gathered enough, and turned them into one repo. Usage is a single step: open your coding agent, paste the link, and have it suggest improvements against your project. The post got about 7,000 views. Two days later the repo gained 55 stars in one day, and two weeks later it was at 299. Below: what it is, where the stars came from, how it differs from a pile of linter lists, and which parts of this you can copy and which you can't.

What it is: a conclusions-only checklist plus a paragraph for agents

dev-quality-gates is a tool list. The CC0 protocol, and the first line of the README says "This is not an awesome list." 11-06 counted the README: 31 categories, 69 tools. Half the categories are split by language (JS/TS, Python, Go, Rust, Ruby, PHP, Java, Kotlin, .NET, Swift, Elixir, Shell), and half cut across them (GitHub Actions, GitLab CI, database migrations, API contracts, secret leaks, Docker and Terraform, Git commit conventions, agent config files...).

What separates it from an ordinary list is in the principles at the top:

• One tool per job, rarely two. Python gets Ruff, ty, deptry, import-linter, each covering one thing.
• It must be able to fail the build. "A report nobody reads doesn't count": tools have to return a non-zero exit code on violations.
• Agent-friendly: non-interactive, machine-readable output, safe automatic fixes. The README's words: "AI coding agents are first-class users of these tools."
• No filler. One section lists categories it hasn't settled on yet, like container image scanning: Trivy's GitHub Action was compromised in March this year, so the author would rather leave the slot empty than fill it carelessly. Tools that were evaluated and rejected are recorded separately in a not-adopted document.

The list is generated from a single tools.json, and each tool records a review date and a source. A weekly automated job flags archived or long-unmaintained tools for re-review.

The most important part is the "Use it in your project" section of the README, a paragraph you can paste verbatim into Claude Code or Codex:

``text Apply https://github.com/mokevnin/dev-quality-gates to this repository. Read and follow https://raw.githubusercontent.com/mokevnin/dev-quality-gates/main/docs/adopt.md. Show me the plan before you change anything. ``

The agent reads an instruction written for it, checks what your project uses, picks only the relevant entries, shows you a plan first, then wires the checks into git hooks and CI, and "proves every check can fail." This paragraph was added on day three of the repo (10-25); the earlier TG post gave a single Russian prompt instead.

How the stars came in: two waves, both triggered by the author himself

The repo was created late at night on Oct 23; in 14 days it gained 299 stars and 15 forks (GitHub, 11-06). The curve is clean, with each of the two jumps lining up with one of the author's own launches:

The English-speaking world barely reacted: nobody posted it on Hacker News, searches for the repo name or author on X turned up no discussion, and the only find was a small LinkedIn roundup. That the stars mainly came from Russian-speaking developers is an inference, based on the channels, the people opening PRs, and the adopters all being Russian-speaking (the stargazer list wasn't sampled).

One more detail: the repo's footer and every TG post carry links to the Hexlet AI course. The list is, in effect, a public sample of that course. The author 10-22 wrote in a post that developers today "no longer need to hear what MCP is or how to write agents.md; they want an automated workflow that produces reliable code," and this repo is that claim made concrete.

Why it took off

The author is the distribution channel. A 16k-subscriber Telegram channel, a podcast pulling tens of thousands of views per episode, a 1,343-follower GitHub account, and a whole community of Hexlet learners and volunteers. Both star waves line up with his own posts. Neither came from a third-party megaphone.

Timing was right. In the second half of 2026, "how to keep code written by agents under control" became a hot topic in the developer community. Similar repos kept popping up on GitHub from 6 through September, and several have already passed 1,000 stars.

Usable the same day. A typical linter list leaves you to pick and configure everything yourself. This one hands the picking and configuring to an agent, so a reader pastes one paragraph and sees results within a minute. There's proof it gets used: hexlet-sicp opened a refactor issue, and a learner's repo opened an "Adopt Dev Quality Gates" issue. Those issues link back to the repo, which gives it a second round of exposure.

Looks credible. Every tool has a review date and research notes, exclusions come with reasons, and an automatic freshness check runs. In the first week, about 6 external contributors opened PRs, so the repo looks active.

To be clear, these differences help it hold people and get used. But the reason it took off is mostly the author's audience. A star count of 300, almost all from Russian-speaking developers, shows that the format alone didn't spread it on its own.

Who's on the same path

"Linter lists" and "linter aggregators" are decade-old categories, with top repos above 10,000 stars. "AI agent quality gates" is a new topic this year, and a few repos on it already have thousands of stars. dev-quality-gates sits in a small overlap of the two: an opinionated curated list plus an integration guide written for agents. I haven't yet seen new repos copying this exact format.

If it were you

Bottom line: the format is worth learning from, but this project isn't worth copying as a whole. Its 300 stars came from the author's 16k Telegram subscribers and podcast. Someone without that audience making the same thing will most likely not get this number.

Who it suits: developers who already run a real set of checks in a specific domain and have some audience: a tech blog, a newsletter, an X account with a few thousand followers, an active community, or an internal platform team. For them, turning their experience into an "agent-executable checklist" costs a few weekends and yields a project that can stay on their résumé and homepage for years.

Who it doesn't suit: people with no distribution who expect GitHub traffic to carry them; people who want a "big and complete" list (that ground is taken by older lists above 10,000 stars); people who want to build agent gates as a prompt collection (guard-skills and vibe-coding-toolkit already exist).

How to do it:

• Switch domains, not packaging. This project covers general code quality. Mobile (pre-release checks for iOS/Android), data engineering (dbt, SQL, data contracts), frontend design systems, infrastructure as code, and game engine projects currently have no list that offers "one pick per job, can fail the build, one-sentence agent setup" (inference, based on finding no similar repos in this search).
• Switching languages is also a gap: Chinese, Japanese, and Spanish developer communities each have their own big accounts and forums. A list written in the native language with adoption instructions may spread more easily in local circles than an English version (inference).
• Copy three things: a paragraph you can paste to an agent, placed on the first screen of the README; an adopt.md written for agents that requires a plan first and proof that every check can fail; and a review date on every entry, plus a "not decided yet" section and reasons for each exclusion.
• Get it working on a few of your own real projects first. A README showing "what it caught after I plugged it in" is more persuasive than a list of tool names.

How to get users: follow the two waves it had. On launch day, post in your own channels with a "copy this to your agent" line. A week or two later, publish a long-form piece (video, podcast, or essay) on the trade-offs behind it. The second wave is often bigger than the first. Then reach out to communities and recommenders in the domain, not general dev circles, and have the first users open "adopt" issues in their own repos. Each issue is a backlink.

When to move: the topic "how to control agent-written code" is still heating up, but similar repos appear every month, so the first version should ship before year-end (inference).

Signs you've misread it: (1) an English-language "agent-executable gate list" backed by a big account gets past 1,000 stars quickly and covers the domain you want, which closes the gap; (2) agents like Claude Code or Codex build in the ability to auto-pick linters per project and wire up CI, making the "one-sentence setup" no longer novel; (3) the reverse: dev-quality-gates keeps gaining stars in the English-speaking world through large accounts sharing it on their own, without the author releasing anything new. That would show the format itself spreads, so people without an audience are worth trying, and the judgment should be raised.

---

Data and sources: GitHub repo page, README and issue/PR lists (11-06); daily star counts from daily scrapes (from 10-25); Telegram @orgprog posts #533, #534, #538 (view counts scraped on 11-06); YouTube podcast page (view counts before and after 11-05); LinkedIn roundup post; competitor stars from GitHub (11-06). The specific source of the 10-26 single-day peak, the geographic distribution of starring users, and course conversion are unverified.