unified-notifications-ops

name	unified-notifications-ops
description	GitHub, Linear, 데스크톱 알림, 훅, 연결된 커뮤니케이션 채널 전반의 알림을 하나의 ECC 네이티브 워크플로로 운영합니다. 실제 문제가 알림 라우팅, 중복 제거, 에스컬레이션, 받은편지함 붕괴일 때 사용합니다.
origin	ECC

통합 알림 운영

문제가 단순히 빠진 알림 하나가 아닐 때 이 스킬을 사용합니다. 실제 문제는 파편화된 알림 시스템입니다.

목표는 흩어진 이벤트를 다음 특성을 가진 하나의 운영자 표면으로 바꾸는 것입니다.

• clear severity
• clear ownership
• clear routing
• clear follow-up action

사용 시점

• 사용자가 GitHub, Linear, 로컬 훅, 데스크톱 알림, 채팅, 이메일 전반에서 하나의 통합 알림 경로를 원할 때
• CI 실패, 리뷰 요청, 이슈 업데이트, 운영 이벤트가 서로 다른 곳으로 흩어져 들어올 때
• 현재 구성이 행동보다 노이즈를 만들 때
• 겹치는 알림 브랜치나 백로그 제안을 하나의 ECC 네이티브 경로로 통합하고 싶을 때
• 워크스페이스에 훅, MCP, 연결 도구는 있지만 일관된 알림 정책이 없을 때

우선 표면

이미 존재하는 것부터 시작합니다.

• GitHub issues, PRs, reviews, comments, and CI
• Linear issue/project movement
• local hook events and session lifecycle signals
• desktop notification primitives
• connected email/chat surfaces when they actually exist

사용자에게 별도 알림 제품을 도입하라고 하기보다 ECC 네이티브 오케스트레이션을 우선합니다.

필수 규칙

• 토큰, 시크릿, 웹훅 시크릿, 내부 식별자를 절대 노출하지 않습니다.
• 다음 요소를 분리해서 다룹니다.
  • 이벤트 소스
  • 심각도
  • 라우팅 채널
  • 운영자 액션
• 중단 비용이 불명확하면 기본은 digest-first입니다.
• 모든 이벤트를 모든 채널로 퍼뜨리지 않습니다.
• 진짜 해결책이 더 나은 이슈 트리아지, 훅 정책, 프로젝트 흐름이라면 그 점을 명시합니다.

이벤트 파이프라인

알림 경로를 다음 단계로 취급합니다.

1. Capture the event
2. Classify urgency and owner
3. Route to the correct channel
4. Collapse duplicates and low-signal churn
5. Attach the next operator action

목표는 더 적지만 더 좋은 알림입니다.

기본 심각도 모델

Class	Examples	Default handling
Critical	broken default-branch CI, security issue, blocked release, failed deploy	interrupt now
High	review requested, failing PR, owner-blocking handoff	same-day alert
Medium	issue state changes, notable comments, backlog movement	digest or queue
Low	repeat successes, routine churn, redundant lifecycle markers	suppress or fold

워크스페이스에 심각도 모델이 없다면 자동화를 제안하기 전에 먼저 만듭니다.

워크플로

1. 현재 표면 인벤토리 작성

다음을 나열합니다.

• event sources
• current channels
• existing hooks/scripts that emit alerts
• duplicate paths for the same event
• silent failure cases where important things are not being surfaced

ECC가 이미 소유하고 있는 표면을 명확히 표시합니다.

2. 어떤 이벤트가 인터럽트를 유발할지 결정

각 이벤트 군마다 다음 질문에 답합니다.

• who needs to know?
• how fast do they need to know?
• should this interrupt, batch, or just log?

기본값은 다음과 같습니다.

• 릴리스, CI, 보안, 담당자 차단 이벤트는 즉시 인터럽트
• 중간 신호 업데이트는 digest
• 텔레메트리와 저신호 생명주기 마커는 로그만 남김

3. 채널을 늘리기 전에 중복부터 접기

다음을 찾습니다.

• the same PR event appearing in GitHub, Linear, and local logs
• repeated hook notifications for the same failure
• comments or status churn that should be summarized instead of forwarded raw
• channels that duplicate each other without adding a better action path

다음 원칙을 우선합니다.

• one canonical summary
• one owner
• one primary channel
• one fallback path

4. ECC 네이티브 워크플로 설계

실제 알림 요구마다 다음을 정의합니다.

• source
• gate
• shape: immediate alert, digest, queue, or dashboard-only
• channel
• action

ECC에 이미 해당 원시 기능이 있다면 다음을 우선합니다.

• 운영자 트리아지를 위한 스킬
• 자동 발행/강제를 위한 훅
• 위임 분류를 위한 에이전트
• 실제 브리지가 부족할 때만 MCP/커넥터

5. 액션 중심 설계안 반환

최종 결과에는 다음을 포함합니다.

• what to keep
• what to suppress
• what to merge
• what ECC should wrap next

출력 형식

CURRENT SURFACE
- sources
- channels
- duplicates
- gaps

EVENT MODEL
- critical
- high
- medium
- low

ROUTING PLAN
- source -> channel
- why
- operator owner

CONSOLIDATION
- suppress
- merge
- canonical summaries

NEXT ECC MOVE
- skill / hook / agent / MCP
- exact workflow to build next

권고 규칙

• 약한 경로 여러 개보다 강한 경로 하나를 우선합니다.
• 중간/저신호 업데이트는 digest를 우선합니다.
• 신호가 자동 발행돼야 한다면 훅을 우선합니다.
• 작업이 트리아지, 라우팅, 리뷰 우선 의사결정이라면 운영자 스킬을 우선합니다.
• 근본 원인이 알림이 아니라 백로그/PR 조정이라면 project-flow-ops를 우선합니다.
• 먼저 소스 인벤토리가 필요하다면 workspace-surface-audit를 우선합니다.
• 데스크톱 알림만으로 충분하다면 불필요한 외부 브리지를 만들지 않습니다.

좋은 사용 사례

• "We have GitHub, Linear, and local hook alerts, but no single operator flow"
• "Our CI failures are noisy and people ignore them"
• "I want one notification policy across Claude, OpenCode, and Codex surfaces"
• "Figure out what should interrupt versus land in a digest"
• "Collapse overlapping notification PR ideas into one canonical ECC lane"

관련 스킬

• workspace-surface-audit
• project-flow-ops
• github-ops
• knowledge-ops
• customer-billing-ops when the notification pain is billing/customer operations rather than engineering