- 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.jsonlCreate 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 checkspgrep— for process checksdf— for disk space checksnc— 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:
- WHAT: User specifies what to check
- HOW: User provides method or grants tool access
- WHEN: This skill handles interval
- 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 checks2. 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):
| 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.