Unified Notifications Ops (Vereinheitlichte Benachrichtigungsverwaltung)
Verwenden Sie diesen Skill, wenn das eigentliche Problem nicht ein fehlender Ping ist. Das eigentliche Problem ist ein fragmentiertes Benachrichtigungssystem.
Die Aufgabe besteht darin, verstreute Ereignisse in eine einzige Betreiberoberfläche zu verwandeln, mit:
- klarer Schweregrad
- klarem Besitzer
- klarer Weiterleitung
- klarer Folgeaktion
Wann verwenden
- Der Benutzer möchte eine einheitliche Benachrichtigungsspur über GitHub, Linear, lokale Hooks, Desktop-Benachrichtigungen, Chat oder E-Mail hinweg
- CI-Fehler, Überprüfungsanfragen, Issue-Updates und Betreiberereignisse treffen an voneinander getrennten Orten ein
- Das aktuelle Setup erzeugt Lärm anstatt Aktion
- Der Benutzer möchte überlappende Benachrichtigungszweige oder Backlog-Vorschläge zu einer ECC-nativen Spur konsolidieren
- Der Arbeitsbereich verfügt bereits über Hooks, MCPs oder verbundene Tools, aber keine kohärente Benachrichtigungsrichtlinie
Bevorzugte Oberfläche
Beginnen Sie mit dem, was bereits vorhanden ist:
- GitHub Issues, PRs, Reviews, Kommentare und CI
- Lineare Issue-/Projektbewegungen
- Lokale Hook-Ereignisse und Sitzungslebenszyklussignale
- Desktop-Benachrichtigungsprimitiven
- Verbundene E-Mail-/Chat-Oberflächen, wenn sie tatsächlich existieren
Bevorzugen Sie ECC-native Orchestrierung gegenüber dem Vorschlag, ein separates Benachrichtigungsprodukt einzuführen.
Unverhandelbare Regeln
- Niemals Tokens, Geheimnisse, Webhook-Geheimnisse oder interne Kennungen offenlegen
- Trennen:
- Ereignisquelle
- Schweregrad
- Weiterleitungskanal
- Betreiberaktion
- Standardmäßig digest-first (zuerst zusammenfassen), wenn die Unterbrechungskosten unklar sind
- Nicht jedes Ereignis an jeden Kanal senden
- Wenn die eigentliche Lösung eine bessere Issue-Triage, Hook-Richtlinie oder Projektablauf ist, dies explizit sagen
Ereignispipeline
Behandeln Sie die Spur als:
- Erfassen des Ereignisses
- Klassifizieren von Dringlichkeit und Besitzer
- Weiterleiten an den richtigen Kanal
- Zusammenführen von Duplikaten und Signalen mit geringer Relevanz
- Anhängen der nächsten Betreiberaktion
Das Ziel sind weniger, bessere Benachrichtigungen.
Standard-Schweregradmodell
| Klasse | Beispiele | Standardbehandlung |
|---|---|---|
| Kritisch | Fehlerhafter default-branch CI, Sicherheitsproblem, blockierte Freigabe, fehlgeschlagener Deploy | Sofort unterbrechen |
| Hoch | Überprüfung angefordert, fehlgeschlagener PR, blockierende Übergabe | Tagesaktuelle Warnung |
| Mittel | Issue-Statusänderungen, bemerkenswerte Kommentare, Backlog-Bewegung | Digest oder Warteschlange |
| Niedrig | Wiederholte Erfolge, Routine-Churn, redundante Lebenszyklusmarkierungen | Unterdrücken oder zusammenfassen |
Wenn der Arbeitsbereich kein Schweregradmodell hat, erstellen Sie eines, bevor Sie Automatisierung vorschlagen.
Workflow
1. Bestandsaufnahme der aktuellen Oberfläche
Auflisten:
- Ereignisquellen
- Aktuelle Kanäle
- Vorhandene Hooks/Skripte, die Warnungen ausgeben
- Doppelte Pfade für dasselbe Ereignis
- Stille Fehlerfälle, bei denen wichtige Dinge nicht angezeigt werden
Benennen, was ECC bereits besitzt.
2. Entscheiden, was eine Unterbrechung verdient
Für jede Ereignisfamilie beantworten:
- Wer muss es wissen?
- Wie schnell müssen sie es wissen?
- Sollte dies unterbrechen, bündeln oder nur protokollieren?
Diese Standardeinstellungen verwenden:
- Unterbrechen für Release-, CI-, Sicherheits- und blockierende Besitzer-Ereignisse
- Digest für Aktualisierungen mit mittlerem Signal
- Nur protokollieren für Telemetrie und Lebenszyklusmarkierungen mit geringem Signal
3. Duplikate vor dem Hinzufügen von Kanälen beseitigen
Ausschau halten nach:
- Dem gleichen PR-Ereignis, das in GitHub, Linear und lokalen Logs erscheint
- Wiederholten Hook-Benachrichtigungen für denselben Fehler
- Kommentaren oder Statusänderungen, die zusammengefasst werden sollten, anstatt roh weitergeleitet zu werden
- Kanälen, die sich duplizieren, ohne eine bessere Aktionspfad hinzuzufügen
Bevorzugen:
- Eine kanonische Zusammenfassung
- Einen Besitzer
- Einen primären Kanal
- Einen Fallback-Pfad
4. Den ECC-nativen Workflow entwerfen
Für jeden echten Benachrichtigungsbedarf definieren:
- Quelle
- Schwelle
- Form: Sofortige Warnung, Digest, Warteschlange oder nur Dashboard
- Kanal
- Aktion
Wenn ECC bereits die Grundfunktion hat, bevorzugen:
- Einen Skill für Betreiber-Triage
- Einen Hook für automatische Ausgabe/Durchsetzung
- Einen Agenten für delegierte Klassifizierung
- Einen MCP/Connector nur, wenn eine echte Brücke fehlt
5. Einen action-bewerteten Entwurf zurückgeben
Enden mit:
- Was behalten werden soll
- Was unterdrückt werden soll
- Was zusammengeführt werden soll
- Was ECC als nächstes umschließen soll
Ausgabeformat
AKTUELLE OBERFLÄCHE
- Quellen
- Kanäle
- Duplikate
- Lücken
EREIGNISMODELL
- kritisch
- hoch
- mittel
- niedrig
WEITERLEITUNGSPLAN
- Quelle -> Kanal
- Warum
- Betreiberbesitzer
KONSOLIDIERUNG
- Unterdrücken
- Zusammenführen
- Kanonische Zusammenfassungen
NÄCHSTER ECC-SCHRITT
- Skill / Hook / Agent / MCP
- Genaue Workflow, der als nächstes gebaut werden soll
Empfehlungsregeln
- Eine starke Spur ist besser als viele schwache
- Digests für Aktualisierungen mit mittlerem und niedrigem Signal bevorzugen
- Hooks bevorzugen, wenn das Signal automatisch ausgegeben werden soll
- Betreibers Skills bevorzugen, wenn die Arbeit Triage, Weiterleitung und entscheidungsbasierte Überprüfung ist
project-flow-opsbevorzugen, wenn die Ursache Backlog-/PR-Koordination ist, nicht Warnungenworkspace-surface-auditbevorzugen, wenn der Benutzer zuerst eine Quellenbestandsaufnahme benötigt- Wenn Desktop-Benachrichtigungen ausreichen, keine unnötige externe Brücke erfinden
Gute Anwendungsfälle
- "Wir haben GitHub, Linear und lokale Hook-Warnungen, aber keinen einheitlichen Betreiber-Workflow"
- "Unsere CI-Fehler sind laut und die Leute ignorieren sie"
- "Ich möchte eine Benachrichtigungsrichtlinie über Claude, OpenCode und Codex-Oberflächen hinweg"
- "Herausfinden, was unterbrechen und was in einem Digest landen soll"
- "Überlappende PR-Ideen zu Benachrichtigungen in eine kanonische ECC-Spur konsolidieren"
Verwandte Skills
workspace-surface-auditproject-flow-opsgithub-opsknowledge-opscustomer-billing-ops, wenn der Benachrichtigungsschmerz eher Abrechnungs-/Kundenvorgänge als Engineering betrifft