Opérations de Notifications Unifiées
Utilisez cette compétence lorsque le vrai problème n'est pas un signal manquant. Le vrai problème est un système de notifications fragmenté.
Le travail consiste à transformer des événements épars en une surface opérateur unique avec :
- une sévérité claire
- une propriété claire
- un routage clair
- une action de suivi claire
Quand l'utiliser
- l'utilisateur souhaite un couloir de notification unifié sur GitHub, Linear, hooks locaux, alertes bureau, chat ou e-mail
- les échecs CI, les demandes de révision, les mises à jour de problèmes 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 veut consolider des branches de notification ou des propositions de backlog qui se chevauchent en un seul couloir natif ECC
- l'espace de travail a déjà des hooks, des MCP ou des outils connectés, mais aucune politique de notification cohérente
Surface Préférée
Partez de ce qui existe déjà :
- Problèmes GitHub, PR, révisions, commentaires et CI
- Mouvements de problèmes/projets Linear
- Événements de hooks locaux et signaux de cycle de vie de session
- Primitives de notification de bureau
- Surfaces e-mail/chat connectées lorsqu'elles existent réellement
Préférez l'orchestration native ECC plutôt que de dire à l'utilisateur d'adopter un produit de notification séparé.
Règles Non-Négociables
- ne jamais exposer de jetons, secrets, secrets de webhook ou identifiants internes
- séparez :
- la source de l'événement
- la sévérité
- le canal de routage
- l'action opérateur
- par défaut, optez pour le digest en premier lorsque le coût d'interruption est incertain
- ne diffusez pas chaque événement sur chaque canal
- si la vraie solution est un meilleur triage des problèmes, une politique de hook ou un flux de projet, dites-le explicitement
Pipeline d'Événements
Traitez le couloir comme :
- Capturer l'événement
- Classifier 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 | Gestion par défaut |
|---|---|---|
| Critique | CI de branche principale cassé, problème de sécurité, version bloquée, déploiement échoué | interrompre maintenant |
| Haute | révision demandée, PR en échec, transfert bloquant le propriétaire | alerte dans la journée |
| Moyenne | changements d'état de problème, commentaires notables, mouvement du backlog | digest ou file d'attente |
| Basse | succès répétés, bruit de routine, marqueurs de cycle de vie 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.
Flux de Travail
1. Inventorier la surface actuelle
Listez :
- les sources d'événements
- les canaux actuels
- les hooks/scripts existants qui émettent des alertes
- les chemins en double pour le même événement
- les cas d'échec silencieux où des éléments importants ne sont pas remontés
Indiquez ce qu'ECC possède déjà.
2. Décider ce qui mérite une interruption
Pour chaque famille d'événements, répondez :
- qui doit savoir ?
- à quelle vitesse doivent-ils savoir ?
- cela devrait-il interrompre, être regroupé par lots, ou simplement être journalisé ?
Utilisez ces valeurs par défaut :
- interrompre pour les événements de version, CI, sécurité et blocage du propriétaire
- digest pour les mises à jour à signal moyen
- journalisation uniquement pour la télémétrie et les marqueurs de cycle de vie à faible signal
3. Effondrer les doublons avant d'ajouter des canaux
Recherchez :
- le même événement PR apparaissant dans GitHub, Linear et les journaux locaux
- des notifications de hook répétées pour le même échec
- des commentaires ou des changements d'état qui devraient être résumés plutôt que transmis bruts
- des canaux qui se dupliquent sans ajouter un meilleur chemin d'action
Préférez :
- un résumé canonique
- un propriétaire
- un canal principal
- un chemin de repli
4. Concevoir le flux de travail 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/application automatique
- un agent pour la classification déléguée
- un MCP/connecteur uniquement lorsqu'un véritable pont manque
5. Retourner une conception orientée action
Terminez avec :
- quoi conserver
- quoi supprimer
- quoi fusionner
- ce qu'ECC devrait encapsuler ensuite
Format de Sortie
SURFACE ACTUELLE
- sources
- canaux
- doublons
- lacunes
MODÈLE D'ÉVÉNEMENT
- critique
- haute
- moyenne
- basse
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
- flux de travail exact à construire ensuite
Règles de Recommandation
- préférez un couloir fort à plusieurs couloirs faibles
- préférez les digests 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 orientée révision
- préférez
project-flow-opslorsque la cause racine est la coordination du backlog/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 Idéaux
- "Nous avons des alertes GitHub, Linear et de 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 devrait interrompre versus atterrir dans un digest"
- "Effondrez les idées de PR de notification qui se chevauchent en un seul couloir ECC canonique"
Compétences Associées
workspace-surface-auditproject-flow-opsgithub-opsknowledge-opscustomer-billing-opslorsque la douleur de notification est liée aux opérations de facturation/client plutôt qu'à l'ingénierie