Sendblue Notify

Visão Geral

Notificações de saída, "dispare e esqueça", de uma sessão local do Claude Code, script ou tarefa agendada para o telefone do usuário via Sendblue. Este é o padrão "saia do terminal": inicie algo longo, receba um iMessage quando terminar. Esta habilidade é responsável por quando notificar e o que dizer. O envio real é feito através do [[sendblue-cli]]. A conexão de hooks (para que as notificações sejam disparadas automaticamente) é feita através do [[update-config]].

Quando Usar Esta Habilidade

• Use quando o usuário disser "me mande uma mensagem quando X terminar", "me avise no celular", "notifique-me na conclusão", "me avise quando a build/deploy/migração terminar" ou "me mande um iMessage quando…".
• Use quando o usuário pedir para conectar um hook que envie uma mensagem ao parar o agente, iteração /loop ou conclusão /schedule.
• Use quando um turno do agente for genuinamente demorado e o usuário estiver focado em outra coisa.
• Não use para tarefas curtas e interativas onde o usuário está observando o terminal — a notificação é ruído.

Pré-requisitos

O CLI deve estar instalado e autenticado:

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

O número de telefone do usuário deve ser um contato verificado na conta. No plano gratuito, o contato precisa enviar uma mensagem para o número do Sendblue uma vez antes que os envios de saída funcionem — confirme com sendblue contacts antes de confiar na notificação em um fluxo de trabalho não supervisionado.

Armazene o número de destino em cache uma vez por projeto em vez de perguntar novamente. Uma variável de ambiente NOTIFY_NUMBER ou um arquivo .notify-number de uma linha é suficiente; delegue a estratégia de armazenamento ao que o projeto circundante já faz.

Como Funciona

Etapa 1: Decida se a notificação é apropriada

A notificação é para trabalho longo e não supervisionado, não para conversas. Bons gatilhos:

• Turnos do agente de ~2 minutos (build, refatoração grande, migração, processamento de dataset).
• Tarefas /loop e /schedule que produzem um resultado discreto.
• Conclusão de CI/deploy quando observado do terminal.
• Playbooks de várias etapas onde o usuário está focado em outra coisa.

Gatilhos ruins (não conecte estes silenciosamente):

• Todo evento Stop, independentemente da duração — produz spam, treina o usuário a ignorar.
• Comandos somente leitura ou de subsegundo.
• Qualquer coisa dentro de um loop apertado.

Se o usuário pedir "me notifique quando terminar" em uma tarefa curta, faça o envio inline óbvio de um único tiro (Exemplo 1) e não instale um hook global.

Etapa 2: Escolha um padrão de entrega

• Envio inline de um único tiro — padrão para uma única tarefa ad hoc. Sem alterações de configuração.
• Hook Stop — opt-in, com escopo de projeto, para sessões que o usuário deseja explicitamente com notificação automática. Sempre limite pela duração.
• Ping de fim de /loop ou /schedule — anexe o envio ao corpo da rotina.

Etapa 3: Componha o texto da notificação

• Uma linha, com ~140 caracteres — cabe na prévia da tela de bloqueio.
• Comece com o resultado — ✅/❌, "concluído", "falhou", "precisa de revisão".
• Inclua algo acionável — nome do branch, cauda do erro, número do PR, duração.
• Sem emojis que o usuário não pediu além de um único glifo de status.
• Sem auto-narração do agente ("Concluí a tarefa conforme solicitado" — apenas diga o que aconteceu).

Exemplos

Exemplo 1: Envio inline de um único tiro

Para uma única tarefa, anexe o envio ao comando. Este é o padrão — sem alterações de configuração, sem comportamento surpreendente depois.

Ramifique o status de saída da tarefa com um if/else. Não use uma cadeia task && send-success || send-failure: se a tarefa for bem-sucedida, mas o próprio envio de sucesso retornar um valor diferente de zero, o || disparará a mensagem de falha — então o usuário verá ❌ mesmo que a tarefa tenha sido concluída. O if/else mantém o resultado vinculado exclusivamente à tarefa.

if long_running_thing; then
  npx @sendblue/cli send +15551234567 "✅ done: $(date +%H:%M)"
else
  npx @sendblue/cli send +15551234567 "❌ failed: $(date +%H:%M)"
fi

Ou, quando o resultado for interessante, inclua um resumo de uma linha:

RESULT=$(run-migration 2>&1 | tail -1)
npx @sendblue/cli send +15551234567 "migration done — $RESULT"

Exemplo 2: Hook Stop do Claude Code (opt-in, com escopo)

Registre um hook Stop em .claude/settings.json (com escopo de projeto) — nunca em configurações globais, a menos que solicitado. Delegue a edição real do arquivo para [[update-config]]. O próprio comando do hook deve:

1. Executar de forma barata (ele dispara em cada Stop).
2. Limitar pela duração — pular envios para turnos abaixo de um limite (por exemplo, 90s).
3. Nunca falhar o pai — canalize para || true para que um erro de notificação não apareça como uma falha do hook.

…