¿Qué hace Operaciones Unificadas de Notificaciones?
Usa este skill cuando el problema real no sea la falta de un ping. El problema real es un sistema de notificaciones fragmentado.
El trabajo consiste en convertir eventos dispersos en una única superficie de operación que incluya:
- severidad clara
- propiedad clara
- enrutamiento claro
- acción de seguimiento clara
Cuándo Usarlo
- el usuario desea un carril de notificaciones unificado entre 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 notificaciones superpuestas o propuestas de backlog en un carril nativo de ECC
- el espacio de trabajo ya tiene hooks, MCPs o herramientas conectadas, pero carece de una política de notificaciones coherente
Superficie Preferida
Comienza desde lo que ya existe:
- incidencias, PRs, revisiones, comentarios y CI de GitHub
- movimientos de incidencias/proyectos de Linear
- eventos de hooks locales y señales del ciclo de vida de la sesión
- primitivas de notificaciones de escritorio
- superficies de chat/correo electrónico conectadas cuando realmente existan
Prefiere la orquestación nativa de ECC sobre indicarle 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 periódico cuando el costo de interrupción no esté claro
- no distribuyas cada evento a cada canal
- si la solución real es un mejor triaje de incidencias, una política de hooks o un flujo de proyecto, dilo explícitamente
Pipeline de Eventos
Trata el carril como:
- Capturar el evento
- Clasificar urgencia y propietario
- Enrutar al canal correcto
- Colapsar duplicados y ruido de baja señal
- Adjuntar la próxima acción del operador
El objetivo es tener menos notificaciones, pero mejores.
Modelo de Severidad por Defecto
| Clase | Ejemplos | Manejo por defecto |
|---|---|---|
| Crítica | CI de rama principal rota, incidencia de seguridad, lanzamiento bloqueado, despliegue fallido | interrumpir ahora |
| Alta | revisión solicitada, PR fallido, traspaso que bloquea al propietario | alerta el mismo día |
| Media | cambios de estado de incidencias, comentarios notables, movimiento del backlog | resumen periódico o cola |
| Baja | éxitos repetidos, ruido rutinario, marcadores de ciclo de vida redundantes | suprimir o plegar |
Si el espacio de trabajo no tiene un modelo de severidad, constrúyelo 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 fallos silenciosos donde no se están mostrando cosas importantes
Señala qué es propiedad de ECC.
2. Decidir qué merece interrupción
Para cada familia de eventos, responde:
- ¿quién necesita saberlo?
- ¿qué tan rápido necesitan saberlo?
- ¿esto debe interrumpir, agruparse o simplemente registrarse?
Usa estos valores por defecto:
- interrumpir para eventos de lanzamiento, CI, seguridad y bloqueo del propietario
- resumen periódico 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 cambios de estado que deberían resumirse en lugar de reenviarse en crudo
- canales que se duplican entre sí sin agregar una mejor ruta de acción
Prefiere:
- un resumen canónico
- un propietario
- un canal primario
- una ruta de respaldo
4. Diseñar el flujo de trabajo nativo de ECC
Para cada necesidad real de notificación, define:
- fuente
- puerta
- forma: alerta inmediata, resumen periódico, cola o solo panel
- canal
- acción
Si ECC ya tiene la primitiva, prefiere:
- un skill para el triaje del operador
- un hook para la emisión/aplicación automática
- un agente para la clasificación delegada
- un MCP/conector solo cuando falte un puente real
5. Devolver un diseño sesgado a la acción
Termina con:
- qué mantener
- 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 periódicos para actualizaciones de señal media y baja
- prefiere hooks cuando la señal deba emitirse automáticamente
- prefiere skills del 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 del backlog/PR en lugar de las alertas - prefiere
workspace-surface-auditcuando el usuario necesite primero 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 única para las superficies de Claude, OpenCode y Codex"
- "Determina qué debería interrumpir versus qué debería ir a un resumen periódico"
- "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/atención al cliente en lugar de ingeniería