Server Maintenance

This skill largely implements its stated maintenance tasks, but has a few red flags you should address before running it on production systems: 1) Inspect and edit servers.json and maintain-all.sh: both contain hard-coded remote IPs. Remove or replace them with only servers you control. The bundled maintain-all.sh currently will attempt SSH to those addresses. 2) Root SSH & host-key checking: scripts use ssh root@host and maintain-all.sh sets StrictHostKeyChecking=no. That bypasses host authenticity checks; change this and avoid automatic root access unless you intentionally want it. Prefer connecting as a non-root user with sudo where possible. 3) Verify backup behavior: SKILL.md claims automatic backups of key configs, but the scripts do not perform backups. Add an explicit backup step (and test it) before any destructive operations. 4) Use dry-run and test in an isolated environment: cleanup.sh has a dry-run mode — use it first. Test everything on a disposable VM to confirm effects before running on production. 5) Code review: the scripts run rm -rf on cached directories and perform remote commands. Read and understand each command, and lock down who/what can invoke the skill (do not enable autonomous scheduled runs until you trust it). 6) Source verification: the skill's source is 'unknown' and the package.json points to a GitHub repo — if you plan to use this, verify the upstream repository and its history. If you want, I can produce a hardened version of these scripts that: - reads servers from a user-managed config and refuses to run against unknown hosts, - enforces StrictHostKeyChecking and key-based auth only, - performs safe backups before changes, - runs cleanup actions under a non-root account with sudo prompts. Confidence: high — the scripts are readable and the risky elements (hard-coded IPs, root SSH, disabled host-key checking, missing backups) are concrete and observable.