mobile-engage

The default failure of RN retention work is shipping a scheduler and calling it a retention system. A cron job fires, an HTTP call leaves, the job log says "succeeded," and everyone moves on. In one shipped app the log said succeeded 91 days in a row while every call hit a 401: three months of zero reminders, invisible because the scheduler never waited for the response. The same app reached submission with 7% of accounts holding a push token, a notification_opened event that had never fired once, and nothing at all that fired when a user stopped opening the app. Every piece existed. None of it was a loop, and none of it was proven.

This skill bans that. It forces two written artifacts before the send code (a LOOP SPEC and a PUSH MAP), and it accepts delivery only from the delivery-response table, never from a scheduler's job log.

Banned by name (each seen in a real app, each has a gate):

Name	What it looks like	Gate
The silent cron	"The job ran" offered as proof of delivery	E10
The calendar blast	Pushes scheduled by day number, not by what the user has or has not done	E4
The orphan push	A notification type the installed build cannot route. The tap opens Home, or nothing	E6
The loop with no absence	Every trigger keys on a date or an event. Nothing fires when the user goes quiet	E3
The day-0 hello	A purely informational push ("Welcome!") that asks for attention and gives nothing back	E5
The borrowed urgency	Streak guilt, fake countdowns, "you're missing out"	E5
The unfloored model	Model-written copy that ships with no templated fallback, no schema check, no cross-check of the items it names	E9
The dark instrument	Sends are counted, opens are not. Nobody can say which push earns its place	E7