Unified Notifications Ops
Usa este skill cuando el problema real no sea una notificación perdida. El problema real es un sistema de notificaciones fragmentado.
El trabajo consiste en convertir eventos dispersos en una única superficie de operador con:
- severidad clara
- propiedad clara
- enrutamiento claro
- acción de seguimiento clara
Cuándo usarlo
- el usuario quiere un carril de notificaciones unificado en GitHub, Linear, hooks locales, alertas de escritorio, chat o correo electrónico
- fallos de CI, solicitudes de revisión, actualizaciones de incidencias y eventos del operador llegan en lugares desconectados
- la configuración actual genera ruido en lugar de acción
- el usuario quiere consolidar ramas de notificación superpuestas o propuestas de backlog en un carril nativo de ECC
- el espacio de trabajo ya tiene hooks, MCPs o herramientas conectadas, pero no una política de notificaciones coherente
Superficie preferida
Comienza desde lo que ya existe:
- incidencias, PRs, revisiones, comentarios y CI de GitHub
- movimiento de incidencias/proyectos de Linear
- eventos de hooks locales y señales de ciclo de vida de sesión
- primitivas de notificaciones de escritorio
- superficies de correo electrónico/chat conectadas cuando realmente existan
Prefiere la orquestación nativa de ECC antes que decirle al usuario que adopte un producto de notificaciones separado.
Reglas no negociables
- nunca expongas tokens, secretos, secretos de webhook o identificadores internos
- separa:
- fuente del evento
- severidad
- canal de enrutamiento
- acción del operador
- por defecto, prioriza el resumen/digest cuando el costo de interrupción no esté claro
- no distribuyas cada evento a todos los canales
- si la solución real es mejorar el triaje de incidencias, la política de hooks o el flujo de proyecto, indícalo explícitamente
Pipeline de eventos
Trata el carril como:
- Capturar el evento
- Clasificar urgencia y propietario
- Enrutar al canal correcto
- Colapsar duplicados y rotación de baja señal
- Adjuntar la siguiente acción del operador
El objetivo son menos notificaciones, pero mejores.
Modelo de severidad predeterminado
| Clase | Ejemplos | Manejo predeterminado |
|---|---|---|
| Crítico | CI de rama principal rota, incidencia de seguridad, lanzamiento bloqueado, despliegue fallido | interrumpir ahora |
| Alto | revisión solicitada, PR fallido, traspaso que bloquea al propietario | alerta del mismo día |
| Medio | cambios de estado de incidencias, comentarios notables, movimiento de backlog | resumen/digest o cola |
| Bajo | éxitos repetidos, rotación rutinaria, marcadores de ciclo de vida redundantes | suprimir o plegar |
Si el espacio de trabajo no tiene un modelo de severidad, construye uno antes de proponer automatización.
Flujo de trabajo
1. Inventariar la superficie actual
Enumera:
- fuentes de eventos
- canales actuales
- hooks/scripts existentes que emiten alertas
- rutas duplicadas para el mismo evento
- casos de fallo silencioso donde cosas importantes no se están mostrando
Señala lo que ECC ya posee.
2. Decidir qué merece interrupción
Para cada familia de eventos, responde:
- ¿quién necesita saberlo?
- ¿qué tan rápido necesitan saberlo?
- ¿debería interrumpir, agrupar o solo registrar?
Usa estos valores predeterminados:
- interrumpir para eventos de lanzamiento, CI, seguridad y bloqueo de propietario
- resumir/digest para actualizaciones de señal media
- solo registro para telemetría y marcadores de ciclo de vida de baja señal
3. Colapsar duplicados antes de agregar canales
Busca:
- el mismo evento de PR apareciendo en GitHub, Linear y registros locales
- notificaciones de hook repetidas para el mismo fallo
- comentarios o rotación de estado que deberían resumirse en lugar de reenviarse en bruto
- canales que se duplican entre sí sin agregar una mejor ruta de acción
Prefiere:
- un resumen canónico
- un propietario
- un canal principal
- una ruta de respaldo
4. Diseñar el flujo de trabajo nativo de ECC
Para cada necesidad real de notificación, define:
- fuente
- puerta de acceso
- forma: alerta inmediata, resumen/digest, cola o solo panel
- canal
- acción
Si ECC ya tiene la primitiva, prefiere:
- un skill para triaje del operador
- un hook para emisión/aplicación automática
- un agente para clasificación delegada
- un MCP/conector solo cuando falte un puente real
5. Devolver un diseño orientado a la acción
Termina con:
- qué conservar
- qué suprimir
- qué fusionar
- qué debería envolver ECC a continuación
Formato de salida
SUPERFICIE ACTUAL
- fuentes
- canales
- duplicados
- brechas
MODELO DE EVENTOS
- crítico
- alto
- medio
- bajo
PLAN DE ENRUTAMIENTO
- fuente -> canal
- por qué
- propietario del operador
CONSOLIDACIÓN
- suprimir
- fusionar
- resúmenes canónicos
PRÓXIMO MOVIMIENTO DE ECC
- skill / hook / agente / MCP
- flujo de trabajo exacto a construir a continuación
Reglas de recomendación
- prefiere un carril fuerte sobre muchos débiles
- prefiere resúmenes/digests para actualizaciones de señal media y baja
- prefiere hooks cuando la señal deba emitirse automáticamente
- prefiere skills de operador cuando el trabajo sea triaje, enrutamiento y toma de decisiones basada en revisión
- prefiere
project-flow-opscuando la causa raíz sea la coordinación de backlog/PR en lugar de alertas - prefiere
workspace-surface-auditcuando el usuario primero necesite un inventario de fuentes - si las notificaciones de escritorio son suficientes, no inventes un puente externo innecesario
Casos de uso adecuados
- "Tenemos alertas de GitHub, Linear y hooks locales, pero ningún flujo de operador unificado"
- "Nuestros fallos de CI son ruidosos y la gente los ignora"
- "Quiero una política de notificaciones unificada en las superficies de Claude, OpenCode y Codex"
- "Determina qué debería interrumpir versus qué debería terminar en un resumen/digest"
- "Colapsa ideas de PR de notificaciones superpuestas en un carril canónico de ECC"
Skills relacionados
workspace-surface-auditproject-flow-opsgithub-opsknowledge-opscustomer-billing-opscuando el dolor de las notificaciones sea operaciones de facturación/clientes en lugar de ingeniería