unified-notifications-ops

Operações de Notificações Unificadas

Use esta skill quando o problema real não for um ping perdido. O problema real é um sistema de notificações fragmentado.

A tarefa é transformar eventos dispersos em uma superfície de operador com:

• severidade clara
• propriedade clara
• roteamento claro
• ação de acompanhamento clara

Quando Usar

• o usuário deseja uma faixa de notificação unificada entre GitHub, Linear, hooks locais, alertas de desktop, chat ou e-mail
• falhas de CI, solicitações de revisão, atualizações de issues e eventos de operador chegam em locais desconectados
• a configuração atual cria ruído em vez de ação
• o usuário deseja consolidar ramificações de notificações sobrepostas ou propostas de backlog em uma faixa nativa do ECC
• o workspace já possui hooks, MCPs ou ferramentas conectadas, mas nenhuma política de notificação coerente

Superfície Preferida

Comece a partir do que já existe:

• Issues, PRs, revisões, comentários e CI do GitHub
• Movimentação de issues/projetos do Linear
• Eventos de hooks locais e sinais de ciclo de vida de sessão
• Primitivas de notificação de desktop
• Superfícies de chat/e-mail conectadas quando realmente existirem

Prefira a orquestração nativa do ECC em vez de dizer ao usuário para adotar um produto de notificação separado.

Regras Inegociáveis

• nunca exponha tokens, segredos, segredos de webhook ou identificadores internos
• separe:
  • fonte do evento
  • severidade
  • canal de roteamento
  • ação do operador
• o padrão é resumo primeiro quando o custo da interrupção não estiver claro
• não distribua todos os eventos para todos os canais
• se a correção real for melhor triagem de issues, política de hooks ou fluxo de projeto, diga isso explicitamente

Pipeline de Eventos

Trate a faixa como:

1. Capturar o evento
2. Classificar urgência e proprietário
3. Roteirizar para o canal correto
4. Colapsar duplicatas e volume de baixo sinal
5. Anexar a próxima ação do operador

O objetivo é menos notificações, mas melhores.

Modelo de Severidade Padrão

Classe	Exemplos	Tratamento padrão
Crítico	CI da branch padrão quebrada, issue de segurança, versão bloqueada, implantação falhada	interromper agora
Alto	Revisão solicitada, PR falhando, transferência que bloqueia proprietário	alerta no mesmo dia
Médio	Mudanças de estado de issue, comentários notáveis, movimentação de backlog	resumo ou fila
Baixo	Sucessos repetidos, volume rotineiro, marcadores de ciclo de vida redundantes	suprimir ou agrupar

Se o workspace não tiver um modelo de severidade, construa um antes de propor automação.

Fluxo de Trabalho

1. Inventariar a superfície atual

Liste:

• fontes de evento
• canais atuais
• hooks/scripts existentes que emitem alertas
• caminhos duplicados para o mesmo evento
• casos de falha silenciosa onde coisas importantes não estão sendo exibidas

Destaque o que o ECC já possui.

2. Decidir o que merece interrupção

Para cada família de evento, responda:

• quem precisa saber?
• com que rapidez eles precisam saber?
• isso deve interromper, agrupar ou apenas registrar?

Use estes padrões:

• interromper para eventos de versão, CI, segurança e que bloqueiam proprietário
• resumo para atualizações de sinal médio
• apenas registrar para telemetria e marcadores de ciclo de vida de sinal baixo

3. Colapsar duplicatas antes de adicionar canais

Procure por:

• o mesmo evento de PR aparecendo no GitHub, Linear e logs locais
• notificações de hook repetidas para a mesma falha
• comentários ou volume de status que deveriam ser resumidos em vez de encaminhados crus
• canais que duplicam uns aos outros sem adicionar um caminho de ação melhor

Prefira:

• um resumo canônico
• um proprietário
• um canal primário
• um caminho de fallback

4. Projetar o fluxo de trabalho nativo do ECC

Para cada necessidade real de notificação, defina:

• fonte
• portão
• forma: alerta imediato, resumo, fila ou apenas painel
• canal
• ação

Se o ECC já tiver a primitiva, prefira:

• uma skill para triagem do operador
• um hook para emissão/aplicação automática
• um agente para classificação delegada
• um MCP/conector somente quando uma ponte real estiver faltando

5. Retornar um design orientado a ação

Termine com:

• o que manter
• o que suprimir
• o que mesclar
• o que o ECC deve envolver a seguir

Formato de Saída

SUPERFÍCIE ATUAL
- fontes
- canais
- duplicatas
- lacunas

MODELO DE EVENTO
- crítico
- alto
- médio
- baixo

PLANO DE ROTEAMENTO
- fonte -> canal
- por quê
- proprietário operador

CONSOLIDAÇÃO
- suprimir
- mesclar
- resumos canônicos

PRÓXIMO MOVIMENTO ECC
- skill / hook / agente / MCP
- fluxo de trabalho exato para construir a seguir

Regras de Recomendação

• prefira uma faixa forte em vez de muitas fracas
• prefira resumos para atualizações de sinal médio e baixo
• prefira hooks quando o sinal deve ser emitido automaticamente
• prefira skills de operador quando o trabalho é triagem, roteamento e tomada de decisão baseada em revisão
• prefira project-flow-ops quando a causa raiz for coordenação de backlog/PR em vez de alertas
• prefira workspace-surface-audit quando o usuário primeiro precisar de um inventário de fontes
• se notificações de desktop forem suficientes, não invente uma ponte externa desnecessária

Bons Casos de Uso

• "Temos alertas de GitHub, Linear e hooks locais, mas nenhum fluxo de operador único"
• "Nossas falhas de CI são barulhentas e as pessoas as ignoram"
• "Quero uma política de notificação unificada entre superfícies Claude, OpenCode e Codex"
• "Descubra o que deve interromper versus o que deve ir para um resumo"
• "Colapse ideias sobrepostas de PR de notificação em uma faixa canônica do ECC"

Skills Relacionadas

• workspace-surface-audit
• project-flow-ops
• github-ops
• knowledge-ops
• customer-billing-ops quando a dor da notificação for operações de faturamento/cliente em vez de engenharia