# PushNotification

현재 Claude Code 세션에서 데스크톱 알림을 전송합니다. 원격 제어가 연결된 경우 사용자의 휴대폰으로도 푸시되어, 어디에 있든 세션으로 주의를 끌어옵니다.

## 사용 시점

- 사용자가 터미널을 떠나 있을 가능성이 높은 상황에서 오래 걸리는 작업이 완료된 경우
- 빌드, 테스트 또는 배포가 완료되어 결과를 검토할 수 있는 경우
- 작업을 계속하기 위해 사용자의 입력이 필요한 결정 지점에 도달한 경우
- 자율적으로 해결할 수 없는 오류나 차단 요소가 발생한 경우
- 사용자가 특정 작업 또는 조건이 충족되었을 때 알림을 보내달라고 명시적으로 요청한 경우

## 사용하지 말아야 할 경우

작업 중 일상적인 진행 상황 업데이트에는 알림을 보내지 마십시오. 사용자가 방금 질문하고 명백히 기다리고 있는 경우에도 마찬가지입니다. 짧은 작업이 완료되었을 때도 알림은 불필요합니다. 사용자가 제출 직후 기다리고 있다면 알림은 아무 가치가 없고, 이후 알림에 대한 신뢰만 떨어뜨립니다. 기본적으로 보내지 않는 방향으로 강하게 권장합니다.

## 매개변수

- `message` (문자열, 필수): 알림 본문. 200자 이내로 유지하십시오. 모바일 운영체제는 긴 문자열을 잘라냅니다. 사용자가 행동을 취할 수 있는 내용으로 시작하십시오: "build failed: 2 auth tests"는 "task complete"보다 훨씬 유용합니다.
- `status` (문자열, 필수): 항상 `"proactive"`로 설정합니다. 이것은 고정 마커로 변경할 수 없습니다.

## 예시

### 예시 1: 오래 걸리는 분석이 완료되었을 때 알림 보내기

저장소 전체 의존성 감사가 요청되어 실행에 몇 분이 걸렸습니다. 사용자는 자리를 비웠습니다. 보고서가 준비되면:

```
message: "의존성 감사 완료: lodash, axios, jsonwebtoken에서 고위험 CVE 3건 발견. 보고서: audit-report.txt"
status: "proactive"
```

### 예시 2: 자율 작업 중 결정 지점 표시

다단계 리팩토링 도중 두 모듈의 인터페이스가 충돌하여 설계 결정 없이는 병합할 수 없음을 발견한 경우:

```
message: "리팩토링 중단: AuthService와 UserService의 토큰 인터페이스 충돌. 계속하려면 결정이 필요합니다."
status: "proactive"
```

## 참고사항

- 기본적으로 **보내지 않는** 방향으로 판단하십시오. 사용자가 무엇을 하고 있든 알림은 방해가 됩니다. 정보 가치로 정당화되어야 하는 비용으로 취급하십시오.
- 행동 가능한 내용으로 시작하십시오. 처음 몇 단어에서 무슨 일이 있었는지, 사용자가 무엇을 해야 하는지 알려주십시오. 일반적인 상태 레이블이 아니라요.
- `message`는 200자 이내로 유지하십시오. 모바일 운영체제는 초과하는 문자열을 잘라내어 끝부분의 중요한 내용이 손실될 수 있습니다.
- 원격 제어가 연결되지 않아 푸시가 전송되지 않았다고 결과에 표시되면, 이는 예상된 동작입니다. 재시도나 후속 조치는 필요 없습니다. 로컬 데스크톱 알림은 정상적으로 실행됩니다.
- 알림 남발을 피하십시오. 사소한 일에 자주 알림을 보내면 사용자가 무시하기 시작합니다. 사용자가 자리를 비웠을 가능성이 높고, 지금 바로 결과를 알 가치가 있는 경우에만 이 도구를 사용하십시오.
