Unified Notifications Ops (Vereinheitlichter Benachrichtigungsbetrieb)
Verwenden Sie diesen Skill, wenn das eigentliche Problem nicht eine fehlende Benachrichtigung ist. Das eigentliche Problem ist ein fragmentiertes Benachrichtigungssystem.
Die Aufgabe besteht darin, verstreute Ereignisse in eine einzige Bedieneroberfläche zu verwandeln mit:
- klarem Schweregrad
- klarem Besitzer
- klarer Weiterleitung
- klarer Folgeaktion
Wann verwenden
- Der Benutzer möchte einen einheitlichen Benachrichtigungskanal über GitHub, Linear, lokale Hooks, Desktop-Benachrichtigungen, Chat oder E-Mail hinweg
- CI-Fehler, Überprüfungsanfragen, Issue-Updates und Betreiberereignisse treffen an getrennten Orten ein
- Die aktuelle Einrichtung erzeugt Lärm anstatt Aktionen
- Der Benutzer möchte überlappende Benachrichtigungszweige oder Backlog-Vorschläge zu einem einzigen nativen ECC-Kanal konsolidieren
- Der Workspace hat bereits Hooks, MCPs oder verbundene Tools, aber keine kohärente Benachrichtigungsrichtlinie
Bevorzugte Oberfläche
Beginnen Sie mit dem, was bereits existiert:
- GitHub Issues, PRs, Reviews, Kommentare und CI
- Linear Issue/Projektbewegungen
- Lokale Hook-Ereignisse und Sitzungslebenszyklus-Signale
- Desktop-Benachrichtigungs-Primitiven
- Verbundene E-Mail/Chat-Oberflächen, wenn sie tatsächlich existieren
Bevorzugen Sie die ECC-native Orchestrierung gegenüber der Aufforderung an den Benutzer, ein separates Benachrichtigungsprodukt zu verwenden.
Unverhandelbare Regeln
- Niemals Tokens, Geheimnisse, Webhook-Geheimnisse oder interne Kennungen preisgeben
- Trennen:
- Ereignisquelle
- Schweregrad
- Weiterleitungskanal
- Betreiberaktion
- Standardmäßig zuerst Digest verwenden, wenn die Unterbrechungskosten unklar sind
- Nicht jedes Ereignis an jeden Kanal weiterleiten
- Wenn die echte Lösung eine bessere Issue-Triage, Hook-Richtlinie oder ein besserer Projektablauf ist, sagen Sie dies explizit
Ereignis-Pipeline
Behandeln Sie den Kanal wie folgt:
- Erfassen des Ereignisses
- Klassifizieren von Dringlichkeit und Besitzer
- Weiterleiten an den richtigen Kanal
- Zusammenführen von Dubletten und unwichtigem Rauschen
- Anhängen der nächsten Betreiberaktion
Das Ziel ist weniger, aber bessere Benachrichtigungen.
Standard-Schweregrad-Modell
| Klasse | Beispiele | Standardbehandlung |
|---|---|---|
| Kritisch | defekte default-branch CI, Sicherheitsproblem, blockiertes Release, fehlgeschlagenes Deployment | sofort unterbrechen |
| Hoch | Überprüfung angefordert, fehlschlagender PR, blockierende Übergabe an Besitzer | am selben Tag alarmieren |
| Mittel | Issue-Statusänderungen, bemerkenswerte Kommentare, Backlog-Bewegungen | Digest oder Warteschlange |
| Niedrig | wiederholte Erfolge, Routine-Rauschen, redundante Lebenszyklus-Marker | unterdrücken oder zusammenführen |
Wenn der Workspace kein Schweregrad-Modell hat, bauen Sie eines, bevor Sie Automatisierung vorschlagen.
Workflow
1. Bestandsaufnahme der aktuellen Oberfläche
Liste:
- Ereignisquellen
- aktuelle Kanäle
- bestehende Hooks/Skripte, die Alarme ausgeben
- doppelte Pfade für dasselbe Ereignis
- stille Fehlerfälle, bei denen wichtige Dinge nicht aufgedeckt werden
Zeigen Sie auf, was ECC bereits besitzt.
2. Entscheiden, was eine Unterbrechung rechtfertigt
Für jede Ereignisfamilie beantworten:
- Wer muss es wissen?
- Wie schnell müssen sie es wissen?
- Soll dies unterbrechen, bündeln oder nur protokollieren?
Verwenden Sie diese Standards:
- unterbrechen bei Release-, CI-, Sicherheits- und blockierenden Ereignissen
- Digest für Nachrichten mittlerer Signifikanz
- nur protokollieren für Telemetrie und geringwertige Lebenszyklus-Marker
3. Dubletten zusammenführen, bevor Kanäle hinzugefügt werden
Suchen nach:
- demselben PR-Ereignis, das in GitHub, Linear und lokalen Logs erscheint
- wiederholten Hook-Benachrichtigungen für denselben Fehler
- Kommentaren oder Status-Rauschen, das zusammengefasst statt unverarbeitet weitergeleitet werden sollte
- Kanälen, die sich gegenseitig duplizieren, ohne einen besseren Aktionspfad zu bieten
Bevorzugen:
- eine kanonische Zusammenfassung
- einen Besitzer
- einen primären Kanal
- einen Rückfallpfad
4. Den ECC-nativen Workflow entwerfen
Für jeden echten Benachrichtigungsbedarf definieren:
- Quelle
- Tor
- Form: sofortiger Alarm, Digest, Warteschlange oder nur Dashboard
- Kanal
- Aktion
Wenn ECC bereits die Primitive hat, bevorzugen:
- einen Skill für die Betreiber-Triage
- einen Hook für die automatische Emission/Durchsetzung
- einen Agenten für die delegierte Klassifizierung
- einen MCP/Connector nur, wenn eine echte Brücke fehlt
5. Ein Aktionsorientiertes Design zurückgeben
Enden mit:
- was behalten
- was unterdrücken
- was zusammenführen
- was ECC als nächstes umschließen sollte
Ausgabeformat
AKTUELLE OBERFLÄCHE
- Quellen
- Kanäle
- Dubletten
- Lücken
EREIGNISMODELL
- kritisch
- hoch
- mittel
- niedrig
WEITERLEITUNGSPLAN
- Quelle -> Kanal
- warum
- Betreiber-Besitzer
KONSOLIDIERUNG
- unterdrücken
- zusammenführen
- kanonische Zusammenfassungen
NÄCHSTER ECC-SCHRITT
- Skill / Hook / Agent / MCP
- exakter Workflow, der als nächstes zu bauen ist
Empfehlungsregeln
- einen starken Kanal vielen schwachen vorziehen
- Digest für Nachrichten mittlerer und niedriger Signifikanz bevorzugen
- Hooks bevorzugen, wenn das Signal automatisch emittiert werden soll
- Betreiber-Skills bevorzugen, wenn die Arbeit Triage, Weiterleitung und entscheidungsfindung zuerst umfasst
project-flow-opsbevorzugen, wenn die Ursache eher Backlog/PR-Koordination als Alarme istworkspace-surface-auditbevorzugen, wenn der Benutzer zuerst eine Quelleninventur benötigt- Wenn Desktop-Benachrichtigungen ausreichen, erfinden Sie keine unnötige externe Brücke
Gute Anwendungsfälle
- „Wir haben GitHub, Linear und lokale Hook-Alarme, aber keinen einzigen Betreiberablauf“
- „Unsere CI-Fehler sind laut und die Leute ignorieren sie“
- „Ich möchte eine einheitliche Benachrichtigungsrichtlinie über Claude, OpenCode und Codex-Oberflächen“
- „Finde heraus, was unterbrechen sollte, was in einem Digest landen sollte“
- „Überlappende PR-Ideen zu Benachrichtigungen in einen kanonischen ECC-Kanal zusammenführen“
Verwandte Skills
workspace-surface-auditproject-flow-opsgithub-opsknowledge-opscustomer-billing-ops, wenn der Benachrichtigungsschmerz eher Abrechnungs-/Kundenbetrieb ist als Entwicklung