The GitHub Buying-Signal Reference: What Each Repo Event Proves

A devtool seller sees a single repository event from an account - a star, a fork, an issue, a dependency add - and needs to decide, right now, whether it is worth a rep's time and how it might be lying. This is a lookup reference, not a scoring model: one row per event, with what it proves, its intent tier, its false-positive traps, and the confirmation step. It is for founders selling their own product, account executives, SDR leads, and partnerships teams who want to grade a signal in seconds and leave after reading one row.

Read the section that matches the event in front of you. The tables are the reference; the failure-modes section is the part that keeps you from routing garbage.

What a repository event can and cannot prove

A repository event proves someone touched your category. It does not prove they intend to buy, and the gap between those two things is where deals and wasted rep-hours both live. The job of this reference is to tell you, for each event, how far up the intent ladder it actually reaches.

Vendors converge on a low-to-high ranking of these events. Stars, forks and watches are early-funnel signals; pull requests, issues, commits and dependency adoptions are high-intent mid-funnel signals. Underneath sits an actor-progression model: a developer moves from lurking, to experimenting, to actively seeking a solution, to actively evaluating a product. The event type is a proxy for where the actor sits on that path.

Two cautions before you trust any single row. First, no public source publishes a numeric point value per event type, so exact tier weights are not established. Treat the tiers below as ordinal, not as scores you can sum. Second, the same event means different things in different categories - a point I return to with numbers later.

The event reference: intent tier, what it proves, how it misleads

Each row below is a single observable event. Read the one in front of you: what it proves, the tier it earns, the trap that inflates it, and the corroborating check that promotes it from a data point to a routable signal.

Star

A star is a bookmark. It proves attention and nothing more; in many cases the starrer never even cloned the repo. Tier: low, awareness-stage. The trap is twofold - it can be a bot (see the authenticity section) or a non-ICP human such as a student or hobbyist. Confirm by requiring a mid-funnel corroborating event before routing, and by filtering the starrer against your ICP on company size and industry.

Fork

A fork proves someone took the code to run, modify, or vendor it. It sits above a star for a structural reason: bots star without forking, which is exactly why a low fork-to-star ratio flags manipulation. Tier: mid, experimenting-stage. The trap is the archival or drive-by fork that never gets touched again. Confirm by checking whether the fork has commits or an open branch, and by resolving the actor's employer.

Watch

A watch proves sustained interest - the actor wants notifications on activity. Tier: low-to-mid, awareness-stage but stickier than a star. Its real value is diagnostic: the watcher-to-star ratio is one of your best fake-star tells. As a per-actor signal it is weak; as a repo-health signal it is strong.

Issue (feature request or bug report)

A detailed feature request or bug report proves active usage. On a competitor's repo it also indicates potential dissatisfaction - someone is using the tool hard enough to hit its limits. Tier: high, decision-stage. The trap is the low-effort or duplicate issue that signals nothing. Confirm by reading the issue: specificity, a reproduction case, or a described workflow is the tell.

Pull request / commit

A PR or commit proves hands-on engagement beyond reading documentation. Integration implementation code demonstrates evaluation, not curiosity. Tier: high, decision-stage. The trap is the trivial typo-fix PR, which proves goodwill but not evaluation. Confirm by reading what the change does and resolving the contributor's employer from the commit email.

Dependency addition

A dependency addition in a package manifest is treated as an adoption decision, not mere interest. Someone wired your category into a build. Tier: high, decision-stage, and often account-level. The trap is a transitive dependency pulled in by something else, or a test-only add. Confirm by checking whether the manifest change is a direct dependency in a real project.

SSO / SAML request

An SSO or SAML feature request is the rarest and most self-qualifying event. Per GitHub's own docs, single sign-on gives organization and enterprise owners a way to control and secure access to organization resources like repositories, issues, and pull requests - a need only larger, security-reviewed buyers raise. Tier: highest, enterprise-decision. It is low volume, so it rarely triggers on its own, but when it does the account is pre-qualified.

Star authenticity: the two ratios that catch a manufactured surge

Before you trust any star-based signal, screen the repo for manipulation. The dominant trap in this whole reference is fake stars, and the cheapest tells are two ratios you can compute in seconds. A Carnegie Mellon study presented at ICSE 2026 found approximately 6 million suspected fake stars distributed across 18,617 repositories by roughly 301,000 accounts, so this is not a rare edge case.

The two ratios below are your confirmation heuristics. Compute both before trusting a star surge.

Flask at 71,000 stars sits at a 23.5% fork-to-star ratio, squarely in the healthy band. Ratios below 5% on a repo with thousands of stars warrant inspection, because bots star without forking. The watcher-to-star ratio is even stronger: organic projects average 0.5% to 3%, while heavily manipulated repos drop to 0.1% or lower. Where the two ratios disagree, trust the watcher ratio.

Why bother? Because high star counts push a repo up in Trending and search, and a repo that jumps from 10 to 500 stars in a week gets algorithmic amplification. The fake stars create a self-reinforcing cycle where bot engagement attracts real attention, so a "hot repo" signal can be manufactured wholesale. The ratio check is the only cheap way to tell a manufactured surge from a real one.

A fork is harder to fake than a star, so the fork-to-star ratio is both an intent gauge and a fraud detector.

Category breadth: why the same event means different things

The same star means less in a broad skill pool than in a niche one. This is not a heuristic guess - it falls straight out of population counts, and it should change how you weight raw stars before you route anything.

In Refolk's index of professional profiles, 13,722 US-based Software Engineers list Kubernetes as a skill, with top employers including Meta, Microsoft, and Red Hat. Only 610 US-based Software Engineers list Rust, with top employers including Google, Oxide Computer Company, and Meta. That is a 22.5x difference in the size of the talent pool that could plausibly generate a signal in each category.

The read: in a broad-skill category like Kubernetes, a "starred my repo" event is common and therefore dilutive - you should weight decision-stage events higher and discount raw stars aggressively. In a niche category like Rust, the population that can even produce the signal is small enough that a single well-resolved actor carries more weight. The country cut sharpens the same point.

Germany's 90 Rust engineers, with top employers including Helsing and Wolt, is roughly a sixth of the US pool. A signal that would be background noise in a large pool is a meaningful fraction of the addressable market in a small one. Calibrate your tier weights to the pool, not to a global default.

Once you have graded and screened an event, the next friction is resolving the anonymous actor to a real company and role. That is where a plain-English search over public profiles saves the most time.

The procedure: from raw event to a routed touch

The order below is signal-first: grade and screen the event, then resolve identity. Named-account teams sometimes invert steps 3 and 5, filtering by company fit before grading the event - either works, but pick one and keep it consistent.

Resolving the actor without guessing

GitHub links a commit to a user by matching the commit-header email to an account email, so the mechanism is simple: open a commit, read the author email domain, and cross-check the profile company field. The one caveat that breaks pipelines at scale: if a user enabled email address privacy, the commit author email is a no-reply placeholder by default. Domain resolution fails on those accounts, and the correct move is to fall back to the profile field, not to discard the actor.

How this goes wrong: the false positives that cost rep-hours

Every row in this reference has a way to lie. The seven traps below are the ones that survive a naive read of the event, ranked by how often they route the wrong person.

1. The star surge is bot-driven. A repo jumps from 10 to 500 stars in a week and looks hot; high star counts push it up in Trending and search, so it self-reinforces. Check: fork-to-star under 5% or watcher-to-star at or under 0.1%.

2. Aged bot accounts pass profile checks. Star-farming operations now use aged profiles with months of fake commit history, forked repositories, bio text, profile photos, and followers. Individual profile polish is no longer evidence of a real human. Check: look for coordinated same-window starring across accounts, not per-profile detail.

3. Commit-email resolution fails silently. You read a no-reply address and conclude the actor has no company. Check: fall back to the profile company field; treat no-reply as "privacy on," not "no employer."

4. Star equals usage. You treat a bookmark as adoption. A star does not mean usage, and in many cases the starrer never even cloned the repo. Check: require a mid-funnel corroborating event before routing.

5. Non-ICP starrer. A stargazer could be your ideal customer or a hobbyist far from the developer profile you sell to. Check: apply an ICP filter on company size and industry before a rep touch.

6. Single actor read as account intent. One engineer's star gets framed as a company evaluation. Check: require two or more engineers at one account, or a decision-stage event, before escalating. When three engineers at the same 200-person startup all star competing database repos within two weeks, that is a company-wide database evaluation - one is not.

7. Slow routing kills a real signal. A genuine signal actioned a week late converts like cold outreach. Adjacent web-intent data shows reaching out within an hour of a visit yields a 22.3% response rate, nearly 8x the five-or-more-day rate, and one vendor claims acting within 24 to 48 hours can 3 to 5x outbound reply rates. Against an average cold email reply rate of about 3.43%, latency is the single biggest lever. Check: enforce a 24-to-48-hour SLA and measure response by time-to-touch bucket.

Keeping the reference current and calling a signal done

The mechanics here drift. Trending algorithms change, bot operations adapt to detection, and GitHub's privacy defaults evolve. Re-check the two star-authenticity ratios against a known-healthy repo in your category every quarter so you are calibrating against a live baseline rather than a memorized number. When detection tooling flags accounts, remember the ceiling: in the CMU work, 90.42% of flagged repos but only 57.07% of flagged accounts were confirmed, so account-level fake calls are noisier than repo-level ones.

The outreach itself is where the grading pays off. Reference the specific technical action, not a generic sales trigger.

Subject: your issue on {repo}

Saw you opened {issue/PR} on {repo} about {specific behavior}. That is usually the point where teams hit {the limit the issue describes}.

We built {product} to handle exactly that. Worth a 15-minute look at how {specific capability} maps to what you described?

No deck, just the workflow.

Before you call any single event done and hand it to a rep, run the checklist below. It is the difference between a routed signal and a routed guess.

Two habits keep this reference honest over time. First, weight decision-stage events higher in broad categories, where raw stars are common and dilutive, and lower your bar in niche ones, where the addressable pool is small. Second, treat speed as a first-class variable: the response-rate gap by time-to-touch likely swamps most tier-weighting nuance, so a fast touch on a mid-tier signal often beats a slow touch on a high-tier one. Grade the event, screen the fakes, resolve the actor, and move.