sendblue-sendblue-notify

name	sendblue-sendblue-notify
description	Text the user's phone when a long-running task, agent turn, or scheduled job finishes — via @sendblue/cli for outbound, optionally wired to a Claude Code Stop hook for automatic fire.
category	automation
risk	critical
source	community
source_type	official
date_added	2026-05-22
author	AnthonyFirth
tags	["sendblue","imessage","sms","notifications","hooks","claude-code","automation"]
tools	["claude","cursor","gemini"]
plugin	{"targets":{"codex":"blocked","claude":"blocked"}}

Sendblue Notify

Overview

Outbound, fire-and-forget notifications from a local Claude Code session, script, or scheduled job to the user's phone via Sendblue. This is the "walk away from the terminal" pattern: kick off something long, get an iMessage when it lands. This skill owns when to notify and what to say. Actual sending goes through [[sendblue-cli]]. Hook wiring (so notifications fire automatically) goes through [[update-config]].

When to Use This Skill

• Use when the user says "text me when X is done", "ping my phone", "notify me on completion", "let me know when the build/deploy/migration finishes", or "send me an iMessage when…".
• Use when the user asks to wire a hook that texts on agent stop, /loop iteration, or /schedule completion.
• Use when an agent turn is genuinely long-running and the user has gone heads-down on something else.
• Do not use for short, interactive tasks where the user is watching the terminal — the notify is noise.

Prerequisites

The CLI must be installed and authenticated:

npx @sendblue/cli whoami        # confirms creds
# or, if first run:
npx @sendblue/cli setup

The user's phone number must be a verified contact on the account. On the free plan, the contact has to text the Sendblue number once before outbound sends work — confirm with sendblue contacts before relying on notify in an unattended workflow.

Cache the destination number once per project rather than re-asking. A NOTIFY_NUMBER env var or a one-line .notify-number file is fine; defer storage strategy to whatever the surrounding project already does.

How It Works

Step 1: Decide whether notify is appropriate

Notify is for long, unattended work — not chatter. Good triggers:

• Agent turns over ~2 minutes (build, large refactor, migration, dataset crunch).
• /loop and /schedule jobs that produce a discrete result.
• CI / deploy completion when watched from the terminal.
• Multi-step playbooks where the user has gone heads-down on something else.

Bad triggers (do not silently wire these):

• Every Stop event, regardless of duration — produces spam, trains the user to ignore.
• Read-only or sub-second commands.
• Anything inside a tight loop.