Monitor

name: Monitor slug: monitor version: 1.0.2 description: Create monitors for anything. User defines what to check, skill handles scheduling and alerts. changelog: Declared required binaries and optional env vars in metadata metadata: {"clawdbot":{"emoji":"📡","requires":{"bins":["curl"],"env":{"optional":["PUSHOVER_TOKEN","PUSHOVER_USER"]}},"os":["linux","darwin","win32"]}}

Data Storage

~/monitor/
├── monitors.json       # Monitor definitions
├── config.json         # Alert preferences
└── logs/               # Check results
    └── {name}/YYYY-MM.jsonl

Create on first use: mkdir -p ~/monitor/logs

Scope

This skill: - ✅ Stores monitor definitions in ~/monitor/ - ✅ Runs checks at specified intervals - ✅ Alerts user on status changes

Execution model: - User explicitly defines WHAT to monitor - User grants any permissions/tools needed - Skill only handles WHEN and ALERTING

This skill does NOT: - ❌ Assume access to any service or endpoint - ❌ Run checks without user-defined instructions - ❌ Store credentials (user provides via environment or other skills)

Requirements

Required: - curl — for HTTP checks

Optional (for alerts): - PUSHOVER_TOKEN / PUSHOVER_USER — for push notifications - Webhook URL — user provides their own endpoint

Used if available: - openssl — for SSL certificate checks - pgrep — for process checks - df — for disk space checks - nc — for port checks

Quick Reference

Core Rules

1. User Defines Everything

When user requests a monitor: 1. WHAT: User specifies what to check 2. HOW: User provides method or grants tool access 3. WHEN: This skill handles interval 4. ALERT: This skill handles notifications

Example flow:

User: "Monitor my API at api.example.com every 5 minutes"
Agent: "I'll check HTTP status. Alert you on failures?"
User: "Yes, and check SSL cert too"
→ Monitor stored with user-defined checks

2. Monitor Definition

In ~/monitor/monitors.json:

{
  "api_prod": {
    "description": "User's API health",
    "checks": [
      {"type": "http", "target": "https://api.example.com/health"},
      {"type": "ssl", "target": "api.example.com"}
    ],
    "interval": "5m",
    "alert_on": "change",
    "requires": [],
    "created": "2024-03-15"
  }
}

3. Common Check Types

User can request any of these (or others):

4. Confirmation Format

✅ Monitor: [description]
🔍 Checks: [what will be checked]
⏱️ Interval: [how often]
🔔 Alert: [when to notify]
🔧 Requires: [tools/access needed]

5. Alert on Change

小蔥技能7w4.net持續更新中。

• Alert when status changes (ok→fail, fail→ok)
• Include failure count
• Recovery message when back to OK
• Never spam repeated same-status

6. Permissions

The requires field lists what user granted: - Empty = basic checks only (curl, df, pgrep) - ["ssh:server1"] = user granted SSH access - ["docker"] = user granted Docker access

Agent asks before assuming any access.

這個監控Skill文件結構完整但內容較空，看起來像是模板填充產物，缺少實際可用的監控配置方法、程式碼示例和具體操作指南。部分描述存在錯誤和重複，JSON格式也有問題。適合作為概念參考，但目前難以直接用於實際監控工作。