Skill: ivangdavila/monitor (version 1.0.2)

--- 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 | Topic | File | |-------|------| | Monitor type examples | `templates.md` | | Alert configuration | `alerts.md` | | Analysis patterns | `insights.md` | ## 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: ```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): | Type | What it checks | Tool used | |------|---------------|-----------| | http | URL status + latency | curl | | ssl | Certificate expiry | openssl | | process | Process running | pgrep | | disk | Free space | df | | port | Port open | nc | | custom | User-defined command | user specifies | ### 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 - 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.


Security scan verdicts — ClawScan: suspicious | static analysis: clean | VirusTotal: suspicious | SkillSpector: suspicious (HIGH)