통합 알림 운영(Unified Notifications Ops)
이 스킬은 놓친 핑이 진짜 문제가 아닐 때 사용하세요. 진짜 문제는 단편화된 알림 시스템에 있습니다.
목표는 분산된 이벤트를 하나의 운영자 표면으로 전환하는 것입니다:
- 명확한 심각도
- 명확한 소유권
- 명확한 라우팅
- 명확한 후속 조치
사용 시기
- 사용자가 GitHub, Linear, 로컬 훅, 데스크탑 알림, 채팅 또는 이메일 전반에 걸친 통합 알림 레인을 원할 때
- CI 실패, 검토 요청, 이슈 업데이트, 운영자 이벤트가 분산된 장소에 도착할 때
- 현재 설정이 행동 대신 소음만 생성할 때
- 사용자가 중복되는 알림 브랜치나 백로그 제안을 하나의 ECC 네이티브 레인으로 통합하려고 할 때
- 워크스페이스에 이미 훅, MCP 또는 연결된 도구가 있지만 일관된 알림 정책이 없을 때
선호 표면
이미 존재하는 것부터 시작하세요:
- GitHub 이슈, PR, 리뷰, 코멘트, CI
- Linear 이슈/프로젝트 이동
- 로컬 훅 이벤트 및 세션 생애주기 신호
- 데스크탑 알림 프리미티브
- 실제로 존재하는 연결된 이메일/채팅 표면
사용자에게 별도의 알림 제품을 도입하라고 요청하는 대신 ECC 네이티브 오케스트레이션을 선호합니다.
준수해야 할 규칙
- 토큰, 비밀, 웹훅 시크릿, 내부 식별자를 절대 노출하지 마세요
- 다음을 분리하세요:
- 이벤트 소스
- 심각도
- 라우팅 채널
- 운영자 작업
- 중단 비용이 불분명할 때는 기본적으로 다이제스트 우선 방식을 사용하세요
- 모든 이벤트를 모든 채널로 전파하지 마세요
- 진짜 해결책이 더 나은 이슈 트리아지, 훅 정책 또는 프로젝트 흐름이라면 명시적으로 말하세요
이벤트 파이프라인
레인을 다음과 같이 취급하세요:
- 캡처 이벤트
- 분류 긴급도와 소유자
- 라우팅 올바른 채널로
- 중복 제거 및 저신호 변동 억제
- 첨부 다음 운영자 작업
목표는 더 적고 더 나은 알림입니다.
기본 심각도 모델
| 클래스 | 예시 | 기본 처리 |
|---|---|---|
| 심각 | default-branch CI 손상, 보안 이슈, 릴리스 차단, 배포 실패 | 즉시 중단 |
| 높음 | 검토 요청, 실패한 PR, 소유자 차단 핸드오프 | 당일 알림 |
| 중간 | 이슈 상태 변경, 중요한 코멘트, 백로그 이동 | 다이제스트 또는 큐 |
| 낮음 | 반복 성공, 일상 변동, 중복 생애주기 표시 | 억제 또는 접기 |
워크스페이스에 심각도 모델이 없으면 자동화를 제안하기 전에 먼저 구축하세요.
워크플로우
1. 현재 표면 인벤토리 작성
다음을 나열하세요:
- 이벤트 소스
- 현재 채널
- 알림을 내보내는 기존 훅/스크립트
- 동일한 이벤트에 대한 중복 경로
- 중요한 사항이 드러나지 않는 무음 실패 사례
ECC가 이미 소유한 것을 밝히세요.
2. 중단할 가치가 있는 것 결정
각 이벤트 패밀리에 대해 다음 질문에 답하세요:
- 누가 알아야 하나요?
- 얼마나 빨리 알아야 하나요?
- 중단, 배치, 또는 단순 기록만 해야 하나요?
다음 기본값을 사용하세요:
- 릴리스, CI, 보안 및 소유자 차단 이벤트는 중단
- 중간 신호 업데이트는 다이제스트
- 낮은 신호 생애주기 표시는 기록 전용
3. 채널 추가 전에 중복 제거
다음을 찾으세요:
- 동일한 PR 이벤트가 GitHub, Linear, 로컬 로그에 모두 나타나는 경우
- 동일한 실패에 대해 반복되는 훅 알림
- 요약 대신 원시 전달되어야 하는 코멘트 또는 상태 변동
- 더 나은 작업 경로를 제공하지 않으면서 서로 중복되는 채널
다음을 선호하세요:
- 하나의 표준 요약
- 한 명의 소유자
- 하나의 기본 채널
- 하나의 대체 경로
4. ECC 네이티브 워크플로우 설계
각 실제 알림 요구사항에 대해 다음을 정의하세요:
- 소스
- 게이트
- 형태: 즉각 알림, 다이제스트, 큐 또는 대시보드 전용
- 채널
- 작업
ECC가 이미 기본 요소를 가지고 있다면 다음을 선호하세요:
- 운영자 트리아지를 위한 스킬
- 자동 방출/강제 실행을 위한 훅
- 위임 분류를 위한 에이전트
- 실제 브릿지가 누락된 경우에만 MCP/커넥터
5. 실행 중심 설계 반환
다음으로 끝맺으세요:
- 유지할 것
- 억제할 것
- 병합할 것
- ECC가 다음에 감싸야 할 것
출력 형식
현재 표면(CURRENT SURFACE)
- 소스
- 채널
- 중복
- 갭
이벤트 모델(EVENT MODEL)
- 심각
- 높음
- 중간
- 낮음
라우팅 계획(ROUTING PLAN)
- 소스 -> 채널
- 이유
- 운영자 소유자
통합(CONSOLIDATION)
- 억제
- 병합
- 표준 요약
다음 ECC 작업(NEXT ECC MOVE)
- 스킬 / 훅 / 에이전트 / MCP
- 구축할 정확한 워크플로우
권장 규칙
- 많은 약한 레인보다 하나의 강력한 레인을 선호하세요
- 중간 및 낮은 신호 업데이트에는 다이제스트를 선호하세요
- 신호가 자동으로 방출되어야 할 때는 훅을 선호하세요
- 작업이 트리아지, 라우팅 및 리뷰 우선 의사 결정일 때는 운영자 스킬을 선호하세요
- 근본 원인이 알림보다 백로그/PR 조정일 때는
project-flow-ops를 선호하세요 - 사용자가 먼저 소스 인벤토리가 필요할 때는
workspace-surface-audit을 선호하세요 - 데스크탑 알림으로 충분하다면 불필요한 외부 브릿지를 만들지 마세요
적합한 사용 사례
- "GitHub, Linear 및 로컬 훅 알림이 있지만 단일 운영자 흐름이 없습니다"
- "CI 실패가 시끄럽고 사람들이 무시합니다"
- "Claude, OpenCode 및 Codex 표면 전반에 걸친 하나의 알림 정책을 원합니다"
- "무엇이 중단되어야 하고 무엇이 다이제스트에 들어가야 하는지 파악하세요"
- "중복되는 알림 PR 아이디어를 하나의 표준 ECC 레인으로 통합하세요"
관련 스킬
workspace-surface-auditproject-flow-opsgithub-opsknowledge-ops- 알림 문제가 엔지니어링보다 결제/고객 운영과 관련된 경우
customer-billing-ops