phantomstars

Automated detection and tracking of fake engagement on GitHub

A JS Labs project — part of the AI Slop Intelligence initiative.
Runs every day. Scores every suspicious account. Detects coordinated bot campaigns.
Files issues directly on compromised repos so maintainers can act.

---

Support this project

BTC   3QjWqhQbHdHgWeYHTpmorP8Pe1wgDjJy54
ETH   0x5851e6145F4773d1585b8686095FB16E368a4dA1
ZEC   t1KSR5YkNPbjqRSCoLKo5AddFWdm9Kzxh1B

---

Why this exists

GitHub stars are a trust signal. They are how developers decide what to evaluate, what to depend on, and what to recommend. That signal is being systematically corrupted.

During the AI boom of 2024-2026, an industry of bot farms emerged to manufacture credibility for low-quality, often malicious repositories. A project with 800 stars in 48 hours reads as legitimate to a developer scanning search results. That's the point. The goal of fake engagement isn't the stars themselves; it's the social proof those stars produce, and the downstream decisions that social proof influences.

The pattern is identifiable. Accounts created the same week, no bio, no followers, no original repositories, starring the same 15 repos within a 2-hour window. Not one campaign, but dozens running simultaneously, every day, across thousands of accounts. The data shows repos where 185 out of 185 engagers are bots. A 100% fakeness ratio. Entire trending placements built on nothing.

phantomstars was built because this problem is tractable. The signal-to-noise ratio in GitHub's public API is, for now, still high enough that coordinated campaigns leave clear fingerprints. This project reads those fingerprints, publishes the raw data, and notifies affected repository maintainers directly.

This is part of the broader AI Slop Intelligence work at JS Labs, ongoing research into the mechanics and measurable effects of low-quality AI-generated content flooding developer ecosystems. Fake engagement isn't a peripheral issue. It's the distribution mechanism that gets slop in front of real users.

---

What it does

phantomstars runs a daily GitHub Actions job that:

1. Scrapes the GitHub Trending page for repos gaining stars today
2. Queries the GitHub Search API for repos created in the last 7 days with sudden star activity (the wider window catches multi-day campaigns missed by 24h-only scans)
3. Seeds additional candidate repos from recent Reddit posts in r/osinttools and r/coolgithubprojects by extracting GitHub repo links from the last 2 days
4. Pulls recent engagement events (stars, forks) via the Events API (last 24 hours per repo)
5. Fetches the full profile of every engaging account via GraphQL: account creation date, follower/following counts, bio, repo history
6. Scores every account against a composite heuristics model: account age, profile completeness, repository patterns, and activity history
7. Detects coordinated campaigns using timestamp clustering and union-find: clusters of suspicious accounts that engaged within a 3-hour window
8. Applies the false-positive allowlist before ledger writes, repo-level ratios, dashboards, and notifications so every visible metric uses the same population
9. Appends all suspects to an append-only JSONL ledger committed back to this repo
10. Publishes a per-repo intelligence feed showing which repos are being targeted, which discovery sources found them, and whether the Events API window was complete or capped
11. Files GitHub issues directly on targeted repos so maintainers see the campaign data in their own issue tracker
12. Writes a formatted scan report to the GitHub Actions job summary

No servers. No databases. No infrastructure bill.

---

Frequently asked questions

Does it notify the targeted repo?

Yes. When a repo's fakeness ratio exceeds 40% or a coordinated campaign is detected, phantomstars opens an issue directly on that repository. The issue contains the full suspect table, campaign membership, composite scores, and account creation dates: everything a maintainer needs to investigate and report to GitHub.

If issues are disabled on a targeted repo, the notification is skipped silently and recorded in the scan log.

Can I request a check for one specific repository?

Yes.

• For a normal one-off check, submit a repo in owner/repo form and run a targeted scan.
• For a lifetime audit request, use the one-off lifetime mode. It is separate from the daily scan.

Why the split:

• The normal scan model is designed for recent public engagement and low operator cost.
• A lifetime audit can involve tens of thousands of stars and thousands of forks on larger repos.
• That is feasible for one-off investigation, but it is too expensive and too slow for the default daily path.
• Lifetime requests therefore run only in explicit one-off mode with guardrails.

Can I report a false positive?

Yes. If your account appears in data/suspects.jsonl and you believe the classification is incorrect, open a false positive issue using the provided template. Reports are reviewed manually before any allowlist addition. The allowlist is stored in data/allowlist.txt; accounts listed there are excluded from all future scans and from the suspects ledger.

What is the campaign ID?

A campaign ID (e.g. c-a3f9b2e1) is a deterministic 8-character hex fingerprint derived from the SHA-256 hash of the sorted set of member logins in that campaign. The same group of accounts will produce the same campaign ID across independent scan runs, enabling longitudinal tracking. It is not a repo name, a username, or any external identifier.

Stability: the ID is stable as long as the campaign's member set is unchanged. If bots are added or suspended between scans, the ID changes because the membership changed. This is expected and reflects real-world drift in bot farm composition.

Does it check account creation dates?

Yes. Every account's creation date is fetched from the GitHub GraphQL API (createdAt field) and stored in each suspect record as account_created_at. It's also the primary input to the account age score, the strongest single signal for fake accounts. Accounts created within 2 days of engaging score 1.0 on age alone.

How confident is it?

Individual scores carry meaningful false positive rates. A new developer with a sparse profile legitimately scores 0.75+. The tool accounts for this by requiring campaign-level evidence before filing issues; a single suspicious account is not enough. A coordinated cluster of 40+ accounts, all created the same week, all scoring 0.75+, all engaging within 90 minutes, is a different matter. That's where confidence becomes actionable.