Agent Bark Notify SKILL: añadir notificaciones Bark a tareas largas de Agent

Prefacio

Convertí una necesidad pequeña pero muy útil en un SKILL para Agents: agent bark notify.

Github Repo: Agent Bark Notify

El origen fue sencillo. Últimamente he usado el comando Goal de Codex para ejecutar una serie de tareas largas. Después de que el Agent empezaba a trabajar, yo salía de casa; una vez lejos del ordenador, no tenía una forma cómoda de saber cómo iba la tarea. Podía abrir la app de ChatGPT para conectarme a Codex y revisar el estado, pero eso era demasiado engorroso y poco directo. Así que hice este SKILL para que Codex, durante la ejecución, pudiera informarme por iniciativa propia.

Después de usarlo, la experiencia resultó mejor de lo esperado. Frente a la costumbre de volver cada cierto tiempo a mirar el estado del Agent, esto se parece más a sentir que “todo está bajo control”. También me hizo pensar que, sobre una infraestructura ya existente, unas pequeñas reparaciones hechas con Agents pueden elevar mucho la experiencia de uso.

Principios, instalación y funciones

Principios

Este SKILL lo escribí con Skill Creator, así que es un SKILL bastante estándar. Su lógica es simple y tiene varias capas:

1. El Agent carga primero SKILL.md: lee cuándo debe notificar, qué niveles de notificación usar, cómo cubrir parámetros y cómo tratar información sensible.

2. El Agent elige el nivel de notificación según el estado de la tarea: progreso ordinario usa passive; bloqueos y fallos usan timeSensitive; critical queda reservado para escenarios explícitamente urgentes.

3. El Agent llama al script incluido en el skill: ejecuta scripts/bark-notify.py desde la ruta relativa del directorio del skill, sin instalar paquetes globales.

4. El script lee la configuración privada local: la Bark key viene de ~/.config/bark-notify.env, y la agrupación e icono del Agent vienen de ~/.config/bark-notify-agents.json.

5. El script envía la solicitud al Bark server: por defecto usa el servicio oficial https://api.day.app, aunque también se puede cambiar a un Bark server propio.

6. El teléfono recibe la notificación: el usuario decide, según el contenido, si vuelve al lugar de trabajo para resolver un bloqueo, revisar un fallo o validar el resultado.

Instalación

Abre tu Agent y escribe lo siguiente:

阅读以下项目的 README，根据指引部署到本机：
https://github.com/Lumen01/agent-bark-notify

Después añade una línea de prompt en tu AGETNS.md global o de proyecto:

- Use the bark-notify SKILL to update the user on progress, especially when handling time-consuming tasks.

Reinicia el Agent. A partir de entonces informará de forma oportuna el estado o resultado de las tareas.

Funciones de detalle

Si quieres personalizar la configuración, estos son los puntos principales:

• Icono personalizado: cada Agent puede configurar su propia URL de icono, de modo que el origen se vea directamente en la notificación del móvil.
• Agrupación de mensajes: las notificaciones pueden agruparse por Agent, proyecto o tipo de tarea, facilitando el orden en la lista de Bark.
• Niveles de notificación: admite passive, active, timeSensitive y critical; cada estado de tarea usa un nivel de interrupción distinto.
• Sonido personalizado: permite pasar un nombre de sonido de Bark para que las tareas importantes sean más reconocibles.
• Salto al tocar: permite adjuntar una URL para entrar directamente en la página de la tarea, los logs o el proyecto.
• Texto para copiar: permite colocar texto en el campo copy de Bark, útil para comandos cortos, identificadores de tarea o pistas de diagnóstico.
• Número de badge: permite establecer un badge, apropiado para sincronizar tareas pendientes con el icono de iOS.
• Comprobación de conectividad: incluye --ping, para confirmar que el Bark server está disponible antes de enviar notificaciones reales.
• Guardado de configuración local: incluye --save-config, que escribe server y key en una configuración privada local y evita guardar secretos en el proyecto.

Mi sugerencia es dejar que el Agent gestione todo salvo la key.

Algunas notas de uso

Alcance de soporte para Agents

Este proyecto puede compartirse entre varios Agents. Uso Codex con más frecuencia, seguido por Claude Code y OpenCode, y todos funcionan perfectamente con él. Si tu escenario se parece al mío, puedes seguir el uso predeterminado y dejarlo en el directorio compartido:

~/.agents/skills/bark-notify

Después, cada Agent lo referencia según sus propias reglas de directorio. Por ejemplo, Codex puede enlazarlo a ~/.codex/skills/bark-notify, mientras Claude, OpenCode u otros Agents pueden usar sus respectivos directorios de skills.

El directorio compartido tiene dos ventajas: las reglas de notificación se mantienen en un solo lugar; y distintos Agents pueden enviar notificaciones con su propia identidad. Por ejemplo, las notificaciones de Codex entran en el grupo Codex, las de Claude en Claude, y con una mirada al teléfono se sabe quién está informando.

Otros Agents deberían funcionar de forma similar, siempre que respeten las reglas del archivo de skill.

¿Servicio oficial de Bark o servidor propio?

Bark ofrece un servicio oficial y también admite servidor propio. Este SKILL soporta ambas formas: por defecto usa https://api.day.app, pero puedes configurar BARK_SERVER para apuntar a tu propio servicio.

La ventaja del servicio oficial es la simplicidad. Solo necesitas instalar la app Bark, obtener la key del dispositivo, configurarla para el script y empezar. Para uso personal, notificaciones de baja frecuencia y contenido no sensible, es el camino de menor coste.

La razón para usar un servidor propio es principalmente privacidad y control.

La solicitud de notificación de Bark puede incluir título, cuerpo, grupo, URL de salto, texto de copia, URL de icono, nivel de notificación y otros datos. Con el servicio oficial, esas solicitudes pasan por el Bark server oficial y luego se entregan al Apple Push Notification service. Para recordatorios ordinarios este camino es aceptable; contenidos como entorno de despliegue, nombres de servicios internos, resúmenes de errores o información de máquinas son más adecuados para un servidor propio.

Un Bark server propio reduce esa superficie de exposición: la solicitud llega primero a tu servicio y luego entra en la cadena de push de Apple. Las notificaciones de iOS siguen dependiendo de APNs, y el contenido todavía entra en la cadena de push de Apple; el valor principal del servidor propio es evitar el Bark server oficial.

Mi recomendación:

• Tareas personales ordinarias, notificaciones de prueba y progreso no sensible: el servicio oficial es suficientemente cómodo
• Proyectos de empresa, servicios internos, estados de despliegue y mantenimiento de dispositivos: considerar primero un servidor propio
• Si el cuerpo de la notificación puede incluir tokens, claves o logs completos: no lo envíes, aunque tengas servidor propio

Por eso este SKILL subraya una regla: el Agent no debe meter configuraciones sensibles ni salidas completas de comandos en la notificación. La notificación debe resumir el estado, no volcar logs.

Tipos de tarea adecuados

Principalmente lo uso en estos tipos de tarea:

• Tareas largas y de varios pasos como Codex Goal
• Build, test, despliegue y rollback
• Mantenimiento de servidores o dispositivos remotos
• Verificación continua tras cambios en varios repositorios
• Diagnóstico que requiere juicio humano a mitad de camino
• Trabajo en segundo plano que debe recordarme volver a revisar el resultado

No es adecuado notificar cada paso. El estado ideal es enviar mensajes solo en límites de etapa:

开始执行耗时构建
测试通过
构建失败，需要修复
远程服务恢复
任务完成
等待用户确认下一步

Su objetivo es pequeño pero útil: reducir la cantidad de veces que tengo que comprobar activamente el estado de una tarea.

Cierre

agent-bark-notify es un SKILL muy pequeño, pero cubre una pieza clave del flujo de trabajo con Agents: la retroalimentación de estado.

Antes, cuando un Agent ejecutaba una tarea larga, tenía que quedarme delante del ordenador o volver cada cierto tiempo a mirar. Ahora puede avisarme de forma proactiva en los momentos importantes: progreso, resultado y causa de bloqueo.

Lo realmente valioso es que el Agent empieza a adquirir un hábito de trabajo más parecido al de un colaborador: ejecuta en silencio, informa por etapas, interrumpe cuando hay riesgo y mantiene la información sensible dentro de la máquina local.