Week 4, Operationalize · Day 22 of 30
Day 22: Set alerts on score moves
When does a score change matter? When commit velocity flips by ≥0.4.
Day 22 in one paragraph: A weekly snapshot is a habit. An alert is leverage. The right alert threshold catches the score move before the round closes; the wrong threshold drowns you in noise. Calibrating thresholds is the difference between a watchlist and a deal-flow engine. You will spend about five minutes, end with a concrete artifact, and the whole curriculum stays free at this URL permanently.
Where this day sits in the 30
Week 4 wires the system into alerts, sharing, and agent integrations so it runs without you. Day 22 of 30 sits 73% of the way through, in week 4, operationalize, one of four one-week phases. This day also carries a bonus exercise for anyone with extra time. Everything in this challenge is built from public GitHub signals, the same data that powers the weekly deal-flow feed, and the day's lesson is worth roughly €79 in equivalent consulting time by the anchoring we use across the curriculum.
Yesterday
Yesterday you documented the system. Today you add the layer that catches the move between weekly checkpoints.
Why this signal matters
A weekly snapshot is a habit. An alert is leverage. The right alert threshold catches the score move before the round closes; the wrong threshold drowns you in noise. Calibrating thresholds is the difference between a watchlist and a deal-flow engine.
The 5-minute exercise
- 1Set a Slack/email alert (or just a Calendar reminder) on commit velocity flips ≥0.4 week-over-week.
- 2Add a second alert on README updates that change >50 lines.
- 3Add a third alert on new repo creation (any new repo in a watched org).
- 4Test by triggering one manually on a known org.
What you’re filtering for
Three alert types live, each with a clear noise floor. If you get more than 3 alerts/week per org, the threshold is too sensitive, narrow it.
Edge case
GitHub doesn't natively send velocity-change alerts. The MCP server has the tool; the manual workaround is GitHub's own watch settings + a weekly Monday recheck. Pick one.
Bonus
When an alert fires on a watchlist org, the response should be tight: 60-second context check, 5-minute composite recheck, a meeting request if the score crossed a meaningful threshold. Document the reaction loop.
Tomorrow
Tomorrow: the anti-signal, the orgs where 6/6 is wrong, and how to flag those before you waste a meeting.
Common questions about day 22
- How long does day 22 take?
- About five minutes of hands-on work against the org you picked on day one. The reading adds another two or three. If you are short on time the exercise alone still delivers the day's point.
- Do I need any tools or paid data for set alerts on score moves?
- No. Every exercise in the challenge runs on public GitHub data and a browser. The feed that automates the same checks is available, but the curriculum itself is deliberately tool-free so the habit lands before the tooling.
- What if I miss a day?
- Every day is permanent at its own URL, so you can pick up exactly where you stopped. The sequence matters, each day builds on the previous one's artifact, but the pace is yours. Many people run the 30 days across six or seven weeks instead of four.
Curriculum: /challenge · Methodology: /methodology · Paper: ssrn.com/abstract=6606558