Send iMessage notifications when long-running tasks complete

Sendblue Notify defines when to send a completion alert to the user's phone and how to write it. It supports outbound notifications from a local session, script, or scheduled job through Sendblue. The sending mechanism belongs to sendblue-cli, while hook configuration belongs to update-config. This skill coordinates the trigger and message rather than owning authentication or configuration formats.

The default pattern is a one-shot inline send for one task. Automatic Stop notifications are opt-in and project-scoped, with a duration gate to avoid messages for every short turn. Loop or scheduled routines can instead send a notification at the end of their body. A short task with an explicit notification request uses one send rather than installing an ongoing hook.

Notification copy leads with the outcome and stays on one line, roughly under 140 characters. It can include an actionable branch, review reference, duration, or short error summary. The source discourages self-narration and unnecessary emoji because the useful outcome should fit in the lock-screen preview.

Use it when the user asks for a text after a build, deployment, migration, long task, loop iteration, or scheduled job completes. It also fits long unattended work when the user has moved away from the terminal.

Avoid automatic messages for short interactive work, read-only commands, or tight loops. Before sending or configuring automation, preview the destination, message template, trigger, and duration threshold and obtain explicit confirmation. A duration gate must be demonstrated in a dry run before relying on an automatic hook. Global hooks require an explicit request.

Lock-screen text is visible to other people holding the phone. Messages must exclude secrets, authentication tokens, customer data, and full error stacks. Destination numbers remain in user-local environment settings or ignored files rather than committed configuration or CI logs.

Inputs include the task's outcome, verified destination contact, approved message format, and delivery pattern. Automated notifications also need an approved trigger and duration gate. Outputs are concise outbound phone alerts associated with discrete task results.

The CLI must be installed and authenticated. Check authentication with:

npx @sendblue/cli whoami        # confirms creds

The destination must be a verified contact. The free-plan workflow requires the contact to text the Sendblue number before outbound delivery works; check contact verification before unattended use. The destination can be cached per user or project using existing local configuration conventions.

Task success and notification delivery must be tracked separately. An if/else around the task result avoids sending a failure notice merely because the success notification failed. Hook notification errors should be logged without failing the parent workflow. Actual duration variable names need to be checked against the hook contract rather than copied blindly from an example.

The workflow uses @sendblue/cli and references sendblue-api as an HTTP alternative for service code. update-config handles local Stop-hook wiring. Loop and schedule routines supply discrete completion points.

textme provides the opposite direction: the user starts a conversation from the phone, while Notify sends from local work to the phone. Both can share a Sendblue account, with textme on a server and outbound notifications in the local workflow.

It serves users running unattended work who want a concise phone alert when a meaningful result arrives. It is useful when leaving the terminal should not mean repeatedly checking whether the task has finished.