Operações de Notificações Unificadas
Use esta habilidade quando o problema real não é um ping perdido. O problema real é um sistema de notificações fragmentado.
O trabalho é 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 quer 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 estão chegando em lugares desconectados
- a configuração atual cria ruído em vez de ação
- o usuário quer consolidar ramificações de notificação 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 pelo que já existe:
- Issues, PRs, revisões, comentários e CI do GitHub
- Movimentação de issues/projetos do Linear
- Eventos de hook locais e sinais de ciclo de vida de sessão
- Primitivos de notificação desktop
- Superfícies de chat/e-mail conectadas quando realmente existirem
Prefira orquestração nativa do ECC a 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
- por padrão, use 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 hook ou fluxo de projeto, diga isso explicitamente
Pipeline de Eventos
Trate a faixa como:
- Capturar o evento
- Classificar urgência e proprietário
- Roteir para o canal correto
- Colapsar duplicatas e ruído de baixo sinal
- Anexar a próxima ação do operador
O objetivo é menos notificações, melhores.
Modelo de Severidade Padrão
| Classe | Exemplos | Tratamento padrão |
|---|---|---|
| Crítico | CI da branch padrão quebrada, issue de segurança, lançamento bloqueado, deploy falhou | Interromper agora |
| Alto | Revisão solicitada, PR com falha, handoff bloqueando proprietário | Alerta no mesmo dia |
| Médio | Mudanças de estado de issues, comentários notáveis, movimentação de backlog | Resumo ou fila |
| Baixo | Sucessos repetidos, rotina, 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 em lote ou apenas registrar?
Use estes padrões:
- interromper para eventos de lançamento, CI, segurança e bloqueio de proprietário
- resumo para atualizações de sinal médio
- apenas registro para telemetria e marcadores de ciclo de vida de baixo sinal
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 rotina de status que deveriam ser resumidos em vez de encaminhados em bruto
- canais que se duplicam sem adicionar um melhor caminho de ação
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
- gate
- forma: alerta imediato, resumo, fila ou apenas painel
- canal
- ação
Se o ECC já tiver o primitivo, prefira:
- uma habilidade para triagem do operador
- um hook para emissão/aplicação automática
- um agente para classificação delegada
- um MCP/conector apenas 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 em seguida
Formato de Saída
SUPERFÍCIE ATUAL
- fontes
- canais
- duplicatas
- lacunas
MODELO DE EVENTOS
- crítico
- alto
- médio
- baixo
PLANO DE ROTEAMENTO
- fonte -> canal
- por quê
- proprietário operador
CONSOLIDAÇÃO
- suprimir
- mesclar
- resumos canônicos
PRÓXIMA AÇÃO DO ECC
- habilidade / hook / agente / MCP
- fluxo de trabalho exato a construir em seguida
Regras de Recomendação
- prefira uma faixa forte a muitas faixas fracas
- prefira resumos para atualizações de sinal médio e baixo
- prefira hooks quando o sinal deve ser emitido automaticamente
- prefira habilidades de operador quando o trabalho é triagem, roteamento e tomada de decisão baseada em revisão
- prefira
project-flow-opsquando a causa raiz for coordenação de backlog/PR em vez de alertas - prefira
workspace-surface-auditquando 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 do GitHub, Linear e hooks locais, mas nenhum fluxo de operador único"
- "Nossas falhas de CI são ruidosas e as pessoas as ignoram"
- "Quero uma política de notificação unificada nas superfícies Claude, OpenCode e Codex"
- "Descobrir o que deve interromper versus o que deve ir para um resumo"
- "Colapsar ideias de PR de notificação sobrepostas em uma faixa canônica do ECC"
Habilidades Relacionadas
workspace-surface-auditproject-flow-opsgithub-opsknowledge-opscustomer-billing-opsquando a dor de notificação for operações de faturamento/cliente em vez de engenharia