Monitor

Create monitors for anything. User defines what to check, skill handles scheduling and alerts.

Security Scan

The skill's requested tools, storage, and behavior are consistent with a local monitoring/alerting utility, but it will create files under ~/monitor, execute the checks you ask for (including user-supplied commands), and can send alerts to endpoints you provide — review definitions and targets before use.

Purpose & Capability

Name/description match the declared requirements: only curl is required for HTTP checks, other tools are optional for specific check types. Storing monitors and logs under ~/monitor is consistent with a local monitor skill.

Instruction Scope

SKILL.md stays within monitoring scope but explicitly allows running user-provided commands (custom checks) and will post alert payloads to user-supplied webhooks or Pushover. These behaviors are expected for a monitor but grant the agent the ability to execute arbitrary commands you provide and to transmit alert data to external endpoints — review any custom commands and webhook targets.

Install Mechanism

Instruction-only skill with no install step and no code files; nothing is downloaded or written at install time beyond the runtime-created ~/monitor directory. Low install risk.

Credentials

No required credentials. Optional env vars (PUSHOVER_TOKEN, PUSHOVER_USER) are declared and used only for Pushover alerts. No unexpected secrets or unrelated credentials are requested.

Persistence & Privilege

Skill is not force-installed (always:false) but will create and write to ~/monitor/monitors.json, config.json, and logs. The agent may autonomously run scheduled checks (platform default); this is expected for a monitoring skill but increases the impact of any misconfiguration (e.g., a webhook that accepts sensitive data).

Assessment

Before installing, review and control these points: - Inspect monitor definitions (~/monitor/monitors.json) and avoid storing secrets (API keys, auth headers) in plain JSON. Use environment variables or secure stores where possible. - Be cautious with 'custom' checks: they run arbitrary commands you supply. Do not add untrusted commands that could access or transmit sensitive data. - Only provide webhook URLs or channels you trust. Alert payloads may include status, timestamps, and any logged output; a misconfigured webhook can leak information. - Limit granted access (SSH, Docker) to only the hosts/services you intend to monitor; the skill asks for explicit permission but will act on whatever is listed in 'requires'. - Set filesystem permissions on ~/monitor so only the intended user can read logs and configs (e.g., chmod 700 ~/monitor). - If you need stronger isolation, run this agent under a restricted user account or in an environment with limited network access, and review scheduled intervals to avoid resource or network abuse. Overall: the skill appears coherent for its stated purpose, but take care around custom commands, webhook targets, and any sensitive data that could be captured in logs or alert payloads.

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:

{
  "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.