The Repo Buying-Signal Reference: Intent, Noise, and Shelf Life

A developer or a company just did something in a repository in your category, and you need to know whether it is worth acting on and for how long. This reference is for founders selling their own devtool, account executives, SDR leads, and partnerships teams triaging a signal queue. It defines each repo-derived action - star, fork, watch, issue, PR, dependency adoption, telemetry event - by what it proves about buying intent, the specific ways it lies, and how fast it decays.

Every ranking answer to this question is a devtool vendor grading repo signals to sell its own monitoring product, and none treats the pre-funnel false-positive problem or per-signal shelf life as a lookup you can jump into row by row. This is the vendor-neutral catalog instead. Jump to the row you need and leave.

What repo actions can you actually see, and what does each prove?

The public GitHub surface exposes stars, forks, watches, issues, pull requests, commits, dependency edges, and package pulls; product-side telemetry like trials and GitHub-login signups requires your own instrumentation. Each action sits on a spectrum from passive awareness to hands-on evaluation, and hands-on behavior beats passive consumption every time.

The first thing to understand is that the star signal degraded twice. The fake-star market means a star spike can be bought - 1,000 stars for as little as $84 on some platforms - and as of 30 June 2026 GitHub restricted the stargazer listing endpoint to a repository's own admins and collaborators, citing scraping for spam. The subscribers and subscriptions endpoints were similarly limited, and the endpoint listing a user's watched repos was deprecated. The practical effect: who-starred-when is now admin-only on repos you do not own, which pushes sellers toward forks, issues, and dependency edges that are both harder to fake and still legible.

Here is the ordering that matters, from strongest to weakest intent, with what each action proves and how it misleads.

The reason clustering beats volume is mechanical: a single action is indistinguishable from noise, but two or more category repos starred in a short window is costly to fake, unlike a lone click. That is why category clustering, not raw star count, is the strongest evaluation signal GitHub produces.

How the repo you watch changes the meaning

The same action proves different things depending on which repo it lands on. Activity on your own repo proves direct interest; the same action across a competitor or adjacent repo proves category evaluation, which is often the earlier and more valuable read.

Build your watchlist in three tiers, because the tier sets the meaning:

• Your own repo. Direct interest. A fork or integration issue here is the shortest path to a conversation.
• Direct competitors and adjacent tools. Category evaluation. If a developer has actively done something in a competing or complementary repo, there may be a live opportunity inside that organization - and they are not yet your customer.
• Dependencies your buyers already ship. Installed base. The dependents graph shows which repositories and packages depend on a given repo, so you can monitor who already runs your category. Remember dependents are computed for public repositories only.

There is a structural reason repo signals outperform title-based lists in devtools: the evaluator is usually the buyer. The senior engineer starring repos is often the same person who greenlights the purchase, so repo activity beats a job-title list that targets a VP three layers removed from the decision.

What each signal is worth against cold outreach

Signal-based outreach reports reply rates several times the cold baseline, but the figures are self-published vendor and agency data, not peer-reviewed, so read the range rather than any single number. The cold baseline itself is well anchored: the average cold email reply rate is 3.43% in Instantly's 2026 benchmark.

The high-end signal-based number is roughly four to seven times the 3.43% cold baseline. Even the conservative read is a two-to-four-times improvement. The honest caveat: these come from firms that sell signal tooling, so treat the shape of the lift as reliable and the exact multiple as directional. What is not in dispute is that the lift only materializes when the touch lands inside the signal's window, which is the subject of the next two sections.

Speed is the multiplier, not copy. The buyer's evaluation clock runs whether or not your cadence keeps up.

Shelf life: how long each signal stays actionable

Repo signals decay in days to weeks, and the early drop is steep. The mechanism is simple: the buyer's evaluation clock runs independently of your outreach, so a signal is a snapshot of where they were, not where they are.

The sources converge on a fast half-life. One practitioner reports that after 72 hours you have already lost 40% of the value, and after two weeks you are running a nurture program on a memory. A Forrester figure cited by vendors puts the loss at about 50% within 30 to 45 days for typical B2B software with three-to-six-month cycles. Acting within 24 to 48 hours is where GitHub-specific reads claim a three-to-five-times lift in reply rates. Scoring systems commonly reset signal scores on a 7-to-30-day clock depending on type.

This is the point where a signal queue either compounds or leaks. If your identity resolution and routing take longer than the signal's window, you are spending enrichment budget to reach people who have already moved on. Naming the actor, resolving them to a company, and finding a verified work email is the slow, expensive part - and it is exactly the part Refolk collapses, so you can go from a fresh repo action to a routable contact inside the 24-to-48-hour window rather than losing the signal to your own backlog.

The procedure: from a watchlist to a touch inside the window

Run this loop once to set it up, then keep the last three steps running continuously. The order is deliberate: filter and score before you enrich, because identity resolution is the cost gate and you do not want to pay it on curiosity traffic.

On step four, be honest that the sources disagree on ordering. Some rank event attendance, forks, and issues highest; others rank category-clustered stars highest. The specific per-signal weights are vendor-defined and not independently validated, so the only trustworthy weighting is the one your own signal-to-opportunity data produces over time. Ship a default, then let step eight correct it.

How this goes wrong: false positives and the checks that catch them

Most bad outreach from a repo queue traces to one of eight failure modes, each with a distinct false-positive shape and a check that catches it. This is the most valuable part of the reference: a signal that looks strong and lies costs you more than a signal you never saw, because acting on it burns trust.

Fake stars. A star spike reads as demand but is purchased. The false positive is a growth curve that jumps overnight. Check velocity anomalies and low-activity accounts before trusting a star count; projects have gamed the system to look more popular than they are.

Star does not equal evaluation. A single star is a bookmark. The false positive is treating one star as active intent. Require category clustering - two or more repos in a short window - before you act.

Competitor-shopping mirage. A prospect active on a competitor's surface may be renewing, not switching. Their existing customer checking the competitor's pricing looks like intent but is just shopping for better terms on the current vendor. Check whether the actor is already a known customer of that competitor before reading switch intent.

Stale signal worked as fresh. A 90-day-old fork is history. Check the timestamp against the decay clock before routing anything.

Login-to-company misresolution. Enrichment attaches the wrong employer or email, so a personal-project actor gets tagged as a company buyer. Check the employer against commit history and a verified work address, not a guess.

Learning mistaken for buying. Docs deep-dives and tutorial forks are curiosity. One developer reading your docs is not a buyer. Require a hands-on action plus an ICP fit before you route, because learning signals do not equal buying signals.

Creepy over-personalization. Naming the exact digital action can read as invasive and trigger distrust. Reference the category or problem, not the precise click, timestamp, or file.

Germany compliance trap. Generic automated sequences to DACH prospects are high-risk. The UWG sets a very high bar for presumed interest, and successful firms there treat legitimate interest as a mandate for hyper-personalization.

Identity, legal basis, and the market you are sending into

A login is not a contact, and resolving one to a company and a verified work email is the real cost gate - so score first and enrich only signals that clear the bar. Legal basis and market size then decide whether the resolved contact is worth a send at all.

For most of the EU and UK, B2B cold email is legal under GDPR's legitimate-interest basis, Article 6(1)(f), provided you run a legitimate-interest assessment, disclose your data source, and offer an easy opt-out. Business emails sourced from public professional profiles generally pass the balancing test, because someone who lists their professional contact information publicly has a reasonable expectation of professional contact. The stakes for getting this wrong are large: GDPR fines reach 20 million euros or 4% of global revenue. Keep sends inside safe volume limits, typically 50 to 100 emails per mailbox per day for cold outreach.

Germany is the structural exception, and it is worth a hard look because it is thin and hard at once. Refolk's index makes the thinness concrete.

The consequence is direct: Germany's smaller pool cannot absorb generic volume, and the UWG's presumed-interest bar means generic sequences are high-risk anyway. Both facts point the same way - in DACH, personalize hard or do not send. For scale comparison, the US pool for the same titles with Go plus Kubernetes is 5,096, about 1.09 times the Terraform pool, so skill choice shifts the addressable set by roughly a tenth while geography shifts it fivefold.

Keeping the reference current

Repo signals are a moving target, so the catalog above is a starting weighting, not a fixed one. Two things change underneath it: GitHub's own API surface and your conversion data.

The API surface shifts by policy. The 2026 stargazer restriction is the clearest example - a signal that was public became admin-only overnight. Re-check the starring and watching endpoint access rules on a schedule, and note that historical stars still live in the public event archive if you need to reconstruct them. When a surface locks down, shift weight toward the actions that remain legible: forks, issues, PRs, and dependency edges.

Your conversion data is the only authority on weighting. Run step eight monthly - pipeline per signal type - and let it re-weight the model. If category-clustered stars convert better than forks in your data, weight them higher, regardless of what any vendor's fixed rubric says. Reconcile the disagreement in the sources against your own numbers, not against someone else's blog.

Finally, watch for corroborating off-repo signals that raise a repo action's confidence. A company posting five DevOps roles in 30 days is investing in infrastructure, which turns an ambiguous repo star from that org into a much stronger read. The best signal is rarely one action - it is a repo action that lines up with a hiring surge, a dependency you can see, and an ICP fit, all inside the same two-week window.