Playbook · operator how-to
How to read a GitHub trendline like a partner (not a star-counter)
A 30-minute playbook for interpreting GitHub momentum charts the way a seed-stage partner does, separating durable commit-velocity from one-week star spikes.
Most people read a GitHub trendline by looking at the star count. That's the worst signal in the file. Stars are a function of attention, a single Hacker News front-page placement can add 2,000 stars in 18 hours and tell you nothing about whether the repo will still be alive in six months.
The signals that survive contact with the rest of the year are commit velocity, contributor influx, and infrastructure build-out. They're the ones venture partners use because they're noisy on a 7-day window but very predictive on a 28-day rolling average.
This playbook walks you through reading those three signals on any repo's GitHub page in 30 minutes, plus the two cross-checks (issue cadence and dependency-graph density) that catch the most common false positives.
Before you start
Prerequisites
- · A specific GitHub repo URL you want to evaluate
- · Browser access to github.com (no auth required for public repos)
Tools
- · GitHub web UI (Insights tab)
- · GitDealFlow lookup at /signals/[org]/[repo] (free)
Steps
- 01
Open Insights → Contributors first, not Stars
5mGo to github.com/[org]/[repo]/graphs/contributors. Set the window to last 4 weeks. You want to see at least three distinct contributors with non-trivial commit counts. One-person commit graphs almost never become companies; they become hobbies or pivot-to-employment stories.
- 02
Check Code frequency on a 28-day window
5mSwitch to Insights → Code frequency. The Y-axis is lines added per week. You're looking for a sustained right-leaning trendline, three or four consecutive weeks at higher-than-baseline volume. A single huge week followed by silence is usually a one-time documentation drop or a code-import event, not real momentum.
- 03
Read commits over the last 90 days
5mOpen the commits tab and scroll to 90 days back. Count the number of distinct days with at least one commit. Above 50 of 90 = high cadence. Below 20 of 90 = abandoned or weekend-warrior. The cadence number is more predictive than the total commit count.
- 04
Cross-check with issue cadence
5mOpen the issues tab. Sort by recently updated. If the top 20 are all from the maintainer themselves answering their own questions, it's a solo project. If the top 20 are from external users reporting bugs and the maintainer is responding within 48 hours, it's a real product.
- 05
Cross-check with infra build-out
5mLook for CI workflows in .github/workflows/, a Dockerfile or docker-compose, and a populated dependencies graph. A repo with no CI and no container config at month 6 is signalling "hobby"; a repo that builds CI in month 2 is signalling "company".
- 06
Pull the GitDealFlow lookup as a sanity check
5mOpen
https://signals.gitdealflow.com/signals/[org]/[repo]. The page renders the four-signal composite score we computed last Monday. If your read disagrees with the score by more than 20 points, re-read the contributor graph, usually the disagreement is a contributor-influx event you missed.
Run the play
Look up any repo's composite score →Frequently asked questions
What about repos under one main maintainer that look great?
Solo-maintainer repos can become companies, but the conversion rate is roughly 1 in 30 vs roughly 1 in 5 for 3+-contributor repos in our validation set. We don't filter them out, we just weight them lower.
Doesn't the dependency graph favor older repos?
Yes, that's why we use a 'density' metric, declared dependencies per file, normalized by repo age. A 6-month-old repo with 40 dependencies declared is signalling infra build-out; a 4-year-old repo with the same 40 might just be cruft.
Where does the issue cadence number live?
It's signal #5 in the public methodology document. The threshold we use internally is: weekly external-issue rate > 2 AND median-time-to-first-maintainer-response < 72 hours.
Related playbooks
The rubric above is the same one I run on the operating side every week. I keep my name off it on purpose, the edge is in the timing, not the messenger. Trust the math, not me.