Que fait Opérations de notifications unifiées ?
Utilisez cette compétence lorsque le vrai problème n'est pas un ping manquant. Le vrai problème est un système de notifications fragmenté.
Le travail consiste à transformer des événements dispersés en une seule surface opérateur avec :
- une sévérité claire
- une propriété claire
- un routage clair
- une action de suivi claire
Quand l'utiliser
- l'utilisateur souhaite une voie de notification unifiée sur GitHub, Linear, hooks locaux, alertes bureau, chat ou email
- les échecs CI, les demandes de revue, les mises à jour de tickets et les événements opérateur arrivent dans des endroits déconnectés
- la configuration actuelle crée du bruit au lieu de l'action
- l'utilisateur souhaite consolider des branches de notification chevauchantes ou des propositions de backlog en une seule voie native ECC
- l'espace de travail possède déjà des hooks, des MCP ou des outils connectés, mais aucune politique de notification cohérente
Surface privilégiée
Partez de ce qui existe déjà :
- GitHub : tickets, PR, revues, commentaires et CI
- Linear : déplacements de tickets/projets
- événements de hooks locaux et signaux de cycle de session
- primitives de notification bureau
- surfaces email/chat connectées lorsqu'elles existent réellement
Préférez une orchestration native ECC plutôt que de demander à l'utilisateur d'adopter un produit de notification séparé.
Règles non négociables
- ne jamais exposer de tokens, secrets, secrets de webhook ou identifiants internes
- séparer :
- source de l'événement
- sévérité
- canal de routage
- action opérateur
- par défaut, privilégier le digest lorsque le coût de l'interruption est incertain
- ne pas diffuser chaque événement sur tous les canaux
- si la vraie solution est un meilleur triage des tickets, une politique de hooks ou un flux de projet, le dire explicitement
Pipeline d'événements
Traitez la voie comme :
- Capturer l'événement
- Classer l'urgence et le propriétaire
- Router vers le bon canal
- Effondrer les doublons et le bruit à faible signal
- Attacher la prochaine action opérateur
L'objectif est d'avoir moins de notifications, mais de meilleure qualité.
Modèle de sévérité par défaut
| Classe | Exemples | Traitement par défaut |
|---|---|---|
| Critique | CI de branche principale cassée, problème de sécurité, release bloquée, déploiement échoué | interrompre maintenant |
| Haute | revue demandée, PR en échec, transfert bloquant pour le propriétaire | alerte le jour même |
| Moyenne | changements d'état de ticket, commentaires notables, mouvement du backlog | digest ou file d'attente |
| Faible | succès répétés, bruit de routine, marqueurs de cycle redondants | supprimer ou plier |
Si l'espace de travail n'a pas de modèle de sévérité, construisez-en un avant de proposer de l'automatisation.
Workflow
1. Inventorier la surface actuelle
Listez :
- sources d'événements
- canaux actuels
- hooks/scripts existants qui émettent des alertes
- chemins dupliqués pour le même événement
- cas d'échec silencieux où des éléments importants ne sont pas remontés
Soulignez ce que ECC possède déjà.
2. Décider ce qui mérite une interruption
Pour chaque famille d'événements, répondez :
- qui doit être informé ?
- à quelle vitesse doivent-ils être informés ?
- cela doit-il interrompre, être regroupé en digest, ou simplement journalisé ?
Utilisez ces valeurs par défaut :
- interrompre pour les événements de release, CI, sécurité et bloquants pour le propriétaire
- digest pour les mises à jour à signal moyen
- journalisation seule pour les données de télémétrie et les marqueurs de cycle à faible signal
3. Effondrer les doublons avant d'ajouter des canaux
Cherchez :
- le même événement PR apparaissant dans GitHub, Linear et les logs locaux
- des notifications de hook répétées pour le même échec
- des commentaires ou du bruit de statut qui devraient être résumés plutôt que transférés bruts
- des canaux qui se dupliquent sans apporter de meilleure action
Préférez :
- un résumé canonique
- un propriétaire
- un canal principal
- un chemin de repli
4. Concevoir le workflow natif ECC
Pour chaque besoin de notification réel, définissez :
- source
- porte
- forme : alerte immédiate, digest, file d'attente ou tableau de bord uniquement
- canal
- action
Si ECC possède déjà la primitive, préférez :
- une compétence pour le triage opérateur
- un hook pour l'émission/l'application automatique
- un agent pour la classification déléguée
- un MCP/connecteur uniquement lorsqu'un pont réel manque
5. Retourner une conception orientée action
Terminez par :
- ce qu'il faut conserver
- ce qu'il faut supprimer
- ce qu'il faut fusionner
- ce que ECC devrait encapsuler ensuite
Format de sortie
SURFACE ACTUELLE
- sources
- canaux
- doublons
- lacunes
MODÈLE D'ÉVÉNEMENTS
- critique
- haute
- moyenne
- faible
PLAN DE ROUTAGE
- source -> canal
- pourquoi
- propriétaire opérateur
CONSOLIDATION
- supprimer
- fusionner
- résumés canoniques
PROCHAINE ACTION ECC
- compétence / hook / agent / MCP
- workflow exact à construire ensuite
Règles de recommandation
- préférez une voie forte à de nombreuses voies faibles
- préférez les digest pour les mises à jour à signal moyen et faible
- préférez les hooks lorsque le signal doit être émis automatiquement
- préférez les compétences opérateur lorsque le travail est du triage, du routage et de la prise de décision par revue
- préférez
project-flow-opslorsque la cause racine est la coordination du backlog / des PR plutôt que les alertes - préférez
workspace-surface-auditlorsque l'utilisateur a d'abord besoin d'un inventaire des sources - si les notifications de bureau suffisent, n'inventez pas un pont externe inutile
Cas d'utilisation appropriés
- « Nous avons des alertes GitHub, Linear et hooks locaux, mais aucun flux opérateur unique »
- « Nos échecs CI sont bruyants et les gens les ignorent »
- « Je veux une politique de notification unique sur les surfaces Claude, OpenCode et Codex »
- « Déterminez ce qui doit interrompre plutôt que d'atterrir dans un digest »
- « Effondrez les idées de PR de notification qui se chevauchent en une seule voie ECC canonique »
Compétences associées
workspace-surface-auditproject-flow-opsgithub-opsknowledge-opscustomer-billing-opslorsque la douleur de notification concerne les opérations de facturation/client plutôt que l'ingénierie