통합 알림 운영
문제가 단순히 빠진 알림 하나가 아닐 때 이 스킬을 사용합니다. 실제 문제는 파편화된 알림 시스템입니다.
목표는 흩어진 이벤트를 다음 특성을 가진 하나의 운영자 표면으로 바꾸는 것입니다.
- 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입니다.
- 모든 이벤트를 모든 채널로 퍼뜨리지 않습니다.
- 진짜 해결책이 더 나은 이슈 트리아지, 훅 정책, 프로젝트 흐름이라면 그 점을 명시합니다.
이벤트 파이프라인
알림 경로를 다음 단계로 취급합니다.
- Capture the event
- Classify urgency and owner
- Route to the correct channel
- Collapse duplicates and low-signal churn
- 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-auditproject-flow-opsgithub-opsknowledge-opscustomer-billing-ops when the notification pain is billing/customer operations rather than engineering