Most project tracking watches for activity. Someone moves a card, closes a ticket, posts an update — the tool notices and reflects it back to you. The problem is that projects rarely die from too much activity. They die from silence. A task sits untouched. A thread trails off without a decision. A dependency goes quiet the week before it was supposed to unblock three other people. None of that trips a normal alert, because nothing happened — and "nothing happened" is exactly the signal you can't see when you're busy.
This tutorial shows you how to build a monitor that watches for the absence of movement instead of its presence, uses Claude to decide which silences actually matter, and drafts the nudge for you — all running automatically on a schedule. By the end you'll have a working mental model, a component-by-component architecture, the exact prompt that does the reasoning, and the wiring to run it in a tool like n8n or Make.
Track the absence of movement, not the presence of activity — and let Claude judge which absences are problems.
That second half is the part people skip, and it's the part that makes the difference between a useful assistant and a spam machine. Anyone can write a rule that says "if a task hasn't moved in 5 days, send an alert." That rule will bury you in noise within a week, because most stale things are stale for perfectly good reasons. The reasoning about why something is quiet is the hard part, and it's precisely what an LLM is good at and a threshold rule is not.
Imagine the naive version: a scheduled query pulls every task with status = in progress and last_updated > 5 days ago, then pings the owner. Run that against a real project and you immediately hit the reason nobody does this by hand:
Not all stale things are stuck. Some are fine. Some aren't even really "in progress." If your monitor can't tell those apart, every message it sends erodes trust until people mute it — and a muted monitor is worse than none, because now you believe you're covered.
So the real job isn't detection. Detection is trivial. The real job is triage, and triage is a judgment problem. That's the seam where Claude belongs.
Every quiet task falls into one of three buckets, and the whole system is built around telling them apart:
1. Stale-and-stuck. The task genuinely needs attention. It's blocked, waiting on someone who forgot, or quietly abandoned. This is the one you want surfaced, with a drafted nudge ready to send.
2. Stale-and-parked. The task is quiet on purpose. It's scheduled for later, deliberately deprioritized, waiting on an external date that hasn't arrived, or paused for a reason everyone already knows. Flagging it is noise. The system should stay silent.
3. Stale-but-actually-done. The work is finished — the tracker is just lying because someone forgot to move the card. This one doesn't need a nudge; it needs a status correction. Different problem, different action.
A regex sees all three as identical: "5 days, no movement." Claude, given the right context, can usually tell them apart the way a sharp PM would while skimming the board. That distinction is the entire value of the build. Hold onto it — every design decision below serves it.