# PushNotification

現在の Claude Code セッションからデスクトップ通知を送信します。リモートコントロールが接続されている場合は、ユーザーのスマートフォンにもプッシュ通知が届き、どこにいてもセッションへ注意を引き戻します。

## 使用タイミング

- ユーザーがおそらく端末を離れているときに、長時間かかるタスクが完了した場合
- ビルド、テスト、またはデプロイが完了し、結果が確認できる状態になった場合
- 作業が継続できない決断ポイントに到達し、ユーザーの判断が必要な場合
- 自律的に解決できないエラーやブロッカーが発生した場合
- ユーザーが特定のタスクや条件が満たされたときに通知するよう明示的に依頼した場合

## 使用しない場合

タスク中の通常の進捗更新には通知を送らないでください。ユーザーが直前に質問して明らかに待機中の場合も同様です。短いタスクが完了しても通知は不要です——ユーザーが送信してすぐ待っているなら、通知は無意味であり、今後の通知への信頼を損ないます。基本的には送らないことを強く推奨します。

## パラメータ

- `message`（文字列、必須）：通知の本文。200文字以内に収めてください。モバイルOSはそれ以上の文字列を切り捨てます。ユーザーが行動しやすい内容から始めてください："build failed: 2 auth tests" は "task complete" よりも有用です。
- `status`（文字列、必須）：常に `"proactive"` を設定します。これは固定マーカーであり、変更できません。

## 例

### 例 1：長時間の解析が完了したときの通知

リポジトリ全体の依存関係監査が要求され、実行に数分かかりました。ユーザーは席を外しています。レポートが準備できたとき：

```
message: "依存関係監査完了: lodash、axios、jsonwebtoken に高危険度 CVE が 3 件見つかりました。レポート: audit-report.txt"
status: "proactive"
```

### 例 2：自律作業中の決断ポイントのフラグ

複数ステップのリファクタリング中に、2 つのモジュールのインターフェイスが競合し、設計上の判断なしには統合できないことが判明した場合：

```
message: "リファクタリング停止: AuthService と UserService のトークンインターフェイスが競合。続行前にご判断が必要です。"
status: "proactive"
```

## 注意事項

- 基本的には**送らない**方向で判断してください。ユーザーが何をしていても、通知は割り込みになります。その情報価値によって正当化されるコストとして扱ってください。
- 行動可能な内容から始めてください。最初の数語で何が起きたか、ユーザーが何をすべきかを伝えてください——汎用的なステータスラベルではなく。
- `message` は 200 文字以内に収めてください。モバイル OS は超過した文字列を切り捨てるため、末尾の重要な情報が失われる可能性があります。
- リモートコントロールが接続されていないためにプッシュが送信されなかったと結果に表示された場合、それは期待される動作です。再試行や後続の対応は不要です。ローカルのデスクトップ通知は引き続き発火します。
- 通知の乱用を避けてください。些細な出来事で頻繁に通知を送ると、ユーザーは無視するようになります。ユーザーが席を外している可能性が高く、今すぐ結果を知る価値がある場合にのみ使用してください。
