통합 알림 운영(Unified Notifications Ops)
이 스킬은 실제 문제가 누락된 핑(ping)이 아닐 때 사용하세요. 실제 문제는 파편화된 알림 시스템입니다.
작업은 흩어진 이벤트를 하나의 운영자 표면으로 전환하여 다음을 명확히 하는 것입니다.
- 명확한 심각도
- 명확한 소유권
- 명확한 라우팅
- 명확한 후속 조치
사용 시기
- 사용자가 GitHub, Linear, 로컬 훅, 데스크톱 알림, 채팅 또는 이메일 전반에 걸친 통합 알림 레인을 원할 때
- CI 실패, 검토 요청, 이슈 업데이트 및 운영자 이벤트가 분리된 장소에 도착할 때
- 현재 설정이 조치 대신 소음을 만들어낼 때
- 사용자가 중복되는 알림 브랜치나 백로그 제안을 하나의 ECC 네이티브 레인으로 통합하려고 할 때
- 워크스페이스에 이미 훅, MCP 또는 연결된 도구가 있지만 일관된 알림 정책이 없을 때
선호 표면
이미 존재하는 것에서 시작하세요:
- GitHub 이슈, PR, 리뷰, 댓글 및 CI
- Linear 이슈/프로젝트 이동
- 로컬 훅 이벤트 및 세션 수명 주기 신호
- 데스크톱 알림 기본 요소
- 실제로 존재하는 경우 연결된 이메일/채팅 표면
사용자에게 별도의 알림 제품을 채택하라고 말하는 것보다 ECC 네이티브 오케스트레이션을 선호하세요.
절대 타협하지 않는 규칙
- 토큰, 시크릿, 웹훅 시크릿 또는 내부 식별자를 절대 노출하지 마세요.
- 다음을 분리하세요:
- 이벤트 소스
- 심각도
- 라우팅 채널
- 운영자 조치
- 중단 비용이 불분명할 때는 기본적으로 디지스트 우선으로 하세요.
- 모든 이벤트를 모든 채널로 전송하지 마세요.
- 실제 해결책이 더 나은 이슈 분류, 훅 정책 또는 프로젝트 흐름이라면 명시적으로 말하세요.
이벤트 파이프라인
레인을 다음과 같이 처리하세요:
- 이벤트 캡처
- 긴급도 및 소유자 분류
- 올바른 채널로 라우팅
- 중복 및 낮은 신호 변화 제거
- 다음 운영자 조치 첨부
목표는 더 적고 더 나은 알림입니다.
기본 심각도 모델
| 클래스 | 예시 | 기본 처리 |
|---|---|---|
| 치명적(Critical) | 손상된 기본 브랜치 CI, 보안 이슈, 차단된 릴리스, 실패한 배포 | 지금 중단 |
| 높음(High) | 검토 요청, 실패한 PR, 소유자 차단 핸드오프 | 당일 알림 |
| 중간(Medium) | 이슈 상태 변경, 주목할 만한 댓글, 백로그 이동 | 디지스트 또는 대기열 |
| 낮음(Low) | 반복적 성공, 일상적인 변화, 중복된 수명 주기 표시자 | 억제 또는 접기 |
워크스페이스에 심각도 모델이 없으면 자동화를 제안하기 전에 먼저 구축하세요.
워크플로
1. 현재 표면 인벤토리
다음을 나열하세요:
- 이벤트 소스
- 현재 채널
- 알림을 내보내는 기존 훅/스크립트
- 동일한 이벤트에 대한 중복 경로
- 중요한 사항이 표면화되지 않는 무음 실패 사례
ECC가 이미 소유하고 있는 것을 명시하세요.
2. 중단할 가치가 있는 것 결정
각 이벤트 패밀리에 대해 다음 질문에 답하세요:
- 누가 알아야 합니까?
- 얼마나 빨리 알아야 합니까?
- 이것이 중단, 일괄 처리 또는 기록만 해야 합니까?
다음 기본값을 사용하세요:
- 릴리스, CI, 보안 및 소유자 차단 이벤트의 경우 중단
- 중간 신호 업데이트의 경우 디지스트
- 원격 측정 및 낮은 신호 수명 주기 표시자의 경우 기록 전용
3. 채널을 추가하기 전에 중복 제거
다음을 찾으세요:
- GitHub, Linear 및 로컬 로그에 나타나는 동일한 PR 이벤트
- 동일한 실패에 대해 반복되는 훅 알림
- 원시 전달 대신 요약되어야 하는 댓글 또는 상태 변화
- 더 나은 조치 경로를 추가하지 않으면서 서로를 중복하는 채널
다음을 선호하세요:
- 하나의 표준 요약
- 한 명의 소유자
- 하나의 기본 채널
- 하나의 대체 경로
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