The Repo-Signal Qualification Standard: When a GitHub Lead Is Sales-Ready

Every repo-for-sales guide ranks what each GitHub event proves or scores intent on a sliding scale. None draws the line where a signal stops being noise and becomes a lead a rep should work. This guide is that line. It is written for founders selling their own product, account executives, SDR leads, and RevOps owners who need a fixed pass/fail bar so two people grading the same star, fork, issue, or pull request reach the same verdict. Adopt it as team policy and the arguments over which stargazers deserve a send end.

A qualification standard is not an opinion about intent. It is a definition of done: the criteria a signal must meet, stated precisely enough that grading is repeatable, plus the checklist to verify it. What follows is the gate, the order of the gates, and the specific ways this work goes wrong.

What "sales-ready" means for a repo signal

A repo signal is sales-ready when a real, ICP-matching person has taken a demonstrated action on a repo you trust, and you can contact them. That is the whole definition, and every word carries weight: real (not a bot), ICP-matching (fit recorded as pass), demonstrated action (an event, tiered by intent), trusted repo (screened for inflation), contactable (a verified email, not a bare handle).

This mirrors the product-qualified lead pattern, where a lead is qualified only when it shows ICP fit plus a usage trigger. The economics argue for a strict reading. In B2B SaaS, product-qualified leads convert to opportunity at roughly 25 to 35%, against 13 to 20% for marketing-qualified leads and 40 to 60% for sales-qualified ones. That is a 5-to-10x multiple between the loosest and the PQL-grade bar. A repo signal graded like a PQL, fit plus a real action, captures that multiple. A repo signal graded like a raw MQL, a handle on a list, throws it away.

The standard has three verdicts, not two. Rep-ready clears every gate. Nurture holds a signal that fits the ICP or shows intent but not both, or a real actor you cannot yet reach. Drop is anything that fails the disqualifier screen. Keeping nurture distinct from drop matters: a warm contact burned by a premature cold pitch is expensive to recover.

The five gates a signal must clear

A signal is rep-ready only when it passes all five gates below, in order. The order is deliberate: the cheapest disqualifying checks run first so you stop wasting enrichment budget on bots and non-fits.

The gates are AND-linked. A perfect ICP match from a 40-day-old empty account fails at the disqualifier gate and drops. A brilliant issue write-up from an anonymous handle with no resolvable company sits in nurture, not rep-ready, because attribution failed. Grading is the discipline of refusing to promote a signal that skips a gate, however promising the other gates look.

Grade the signal type before anything else

Grade the event by intent tier first, because it is instant and free and it tells you how hard the other gates need to work. The practitioner consensus, not a measured close-rate ranking, orders events as: issues and pull requests highest, then forks, then stars, then watches.

The reason deep-engagement events rank highest is scarcity with a cause. Filing an issue means the developer went far enough to hit friction and cared enough to report it. Opening a pull request means they modified the code. A star is a bookmark. That is why the standard weights one intent-bearing issue over dozens of stars, and why a lone watch or star should never clear the gate on its own.

Sources disagree at the margins. One taxonomy ranks package downloads above watches; another groups both as low-intent. Resolve this in your own policy by fixing the boundary: treat stars and watches as awareness, and forks, downloads, and time on API docs as consideration. Issues and PRs with a described pain point are the only events that can clear the gate on intent alone, and even then they still need attribution and a disqualifier pass.

Attribute the actor, then confirm ICP fit

The load-bearing step is attribution, and it is the real bottleneck, not detection. When a developer stars a repo, their username becomes visible in the stargazers list, but a handle alone is not workable. The documented minimum to qualify an actor is a public email in the bio, a company affiliation, a relevant job title, and recent activity, meaning a push within the last 30 days.

Only once you have a name, a company, and a contactable email do you test ICP fit. Fit is a recorded pass or fail against your firmographic thresholds: size, stage, industry, geography. Resist the "maybe" bucket. A maybe is a nurture verdict, not a fit pass.

Here is where market supply changes the bar. Refolk's index shows the population you are grading against is not uniform.

In a thin market such as Rust in Germany, with 87 matching people, a team can afford to work lower-intent signals because there is little else to work. In a deep market such as Go in the US, with 2,727, the gate should be stricter to control volume, or reps drown. The pass bar is a function of supply, and the supply is knowable before you set policy.

Attribution is also the highest-leverage step because the criterion you depend on, a verified company, is exactly the field most easily faked. GitHub's company field is free text and unverified. "@bigco" may be aspirational. The fix is corroboration, covered in the next section. This is the point where a tool that resolves handles to people saves the most friction. Refolk takes a plain-English description of the person and company you are after and returns matching profiles across the public GitHub graph, LinkedIn, and the open web, so attribution stops being manual page-scraping.

Run the disqualifier screen

The disqualifier screen decides whether the actor is a real, non-competitor developer, and it is where most bad signals die. Fake stars are the dominant disqualifier: a Dec 2024 study from CMU, Socket, and NC State built StarScout and identified roughly six million suspected fake stars across GitHub events from July 2019 to Dec 2024. Bot networks sell stars at about $0.06 each, so the supply of fake signal is effectively unlimited.

Screen the actor and the source repo separately. For the actor, apply fixed thresholds.

The account-age and completeness checks catch ghost accounts. The coordination check catches campaigns: four or more suspicious accounts engaging one repo inside a three-hour window is the one hard, documented multi-account rule. Note carefully what it does and does not prove: it flags bots, not buying committees. Do not use it to reject a genuine team evaluation.

For the source repo, run star-authenticity scoring before you trust any signal from it. A repo that jumps from 10 to 500 stars in a week gets algorithmic amplification and lands on trending pages, which reads as legitimate to anyone scanning results. If the repo is inflated, every signal from it is statistically likelier to be a bot, so repo screening belongs before actor scoring, not after.

The other disqualifiers lack a published verification protocol beyond manual review, so state your policy plainly: exclude your own org members, known competitors scouting your project, existing customers, and archived repos. Corroborate the company field with a commit email domain or an external profile. A free-text employer that cannot be corroborated is not an ICP pass.

The procedure

Run these steps in order for each signal. The verdict at the end is the standard's whole output.

How this goes wrong

The most valuable part of any standard is its false positives, because a false positive costs a rep's time and a burned contact. These are the seven ways a repo signal fools a grader, and the check that catches each.

Star-count trust trap. A signal inherits its repo's inflated reputation. A project with 800 stars in 48 hours reads as legitimate. The false positive is crediting intent to a coordinated farm. Check: run star-authenticity scoring on the source repo before you trust the signal.

Empty-account pass. A handle with no bio or company looks like a lead but is a ghost. The false positive is enriching a bot into your CRM. Check: apply the account-age and completeness screen.

Company field spoof. The free-text company field may be aspirational or fake. The false positive is an ICP match on an employer that does not exist. Check: corroborate with a commit email domain or an external profile.

Watch or star treated as consideration. These are awareness-stage. Sending outbound treats a bookmark as buying intent. The false positive is burning a warm contact too early. Check: require a second signal or a clean ICP match before hand-off.

Self-star or maintainer noise. The actor is your own user, a contributor, or a competitor scouting. The false positive is outreach to a non-buyer. Check: exclude your org members, known competitors, and existing customers by domain.

Stale signal, cold pitch. No published repo decay window means teams sit on signals. The false positive is a "fresh" lead who already chose a competitor. Check: enforce an internal SLA and a max-age drop rule.

Coordination read as fraud, or fraud read as a committee. The four-accounts-in-three-hours rule flags bots, not buying teams. The false positive runs both ways: rejecting a genuine team eval, or trusting a farm as a committee. Check: separate by whether the accounts share a real corporate domain and have organic histories.

Speed: the one lever you can pull without a decay number

There is no published decay curve for repo signals, so do not pretend to know how many days a star stays warm. What is documented is that speed matters in adjacent inbound work, and the effect is large. Responding within five minutes makes contact 100 times more likely and qualification 21 times more likely. A 2025 study of 4 million form submissions found instant response booked meetings at 66.7% against 30% for standard follow-up.

Those numbers are about web-form leads, not repo events, so treat them as a direction, not a promise. The direction is clear enough to design around: a qualified repo signal loses value faster than a nurture cadence assumes, so the gate should be automated enough to route in minutes. The bottleneck is rarely the rep's willingness; it is the manual capture and attribution work between the event and the queue. Automate steps one through five and the SLA becomes achievable.

Mind the API limits when you build the capture side. The GitHub REST API allows 60 requests an hour unauthenticated and 5,000 authenticated, with GitHub Apps owned by an Enterprise Cloud org getting 15,000. Poll within that budget, store the last known count per repo, and fetch the final stargazer page to detect new stars, since the API returns oldest to newest with no starred_at sort.

The verification checklist

Before you call a signal rep-ready, verify every item below. If any item fails, the signal is nurture or drop, not rep-ready.

SIGNAL TYPE:   [ ] awareness (star/watch)  [ ] consideration (fork/download)  [ ] deep (issue/PR)
ATTRIBUTION:   name ____  company ____  title ____  email confirmed [Y/N]  activity <30d [Y/N]
ICP FIT:       size ____  stage ____  industry ____  geo ____   ->  PASS / FAIL
DISQUALIFIER:  age >60d [Y/N]  profile complete [Y/N]  not self/competitor/customer [Y/N]  repo authentic [Y/N]
CLUSTERING:    second signal or shared domain [Y/N]
VERDICT:       [ ] REP-READY  [ ] NURTURE  [ ] DROP     SLA logged: ____

Keeping the standard current

A standard drifts if you never re-check its assumptions, so schedule two reviews. The first is the intent ordering. It is vendor consensus, not a measured close-rate ranking, so once you have your own closed-won data, re-derive the tier order from your pipeline and replace the borrowed one. If your issues convert worse than your forks, trust your numbers over this guide.

The second is the ICP supply picture. Market populations shift, and the pass bar tracks them. Re-run your supply counts per skill and geography before each planning cycle, because a market that was thin enough to justify working awareness signals may deepen, at which point the gate should tighten. Refolk's index is the fastest way to pull those counts on demand, since a plain-English query returns the matching population for a segment without a manual scrape.

Finally, re-check the disqualifier thresholds against the current state of fake-star tooling. The six-million-fake-star finding and the under-60-days heuristic reflect one snapshot of the fraud market. When the tooling that scores authenticity changes, update Table C rather than trusting a number that has quietly gone stale. Where the evidence is thin, and it is thin on repo-specific decay windows and on buying-committee thresholds, the honest move is to say so in your policy and to check locally: instrument your own pipeline, watch what a stale signal actually converts at, and set the max-age drop rule from that, not from a number nobody has published.