Radarr+

This package appears to implement a legitimate Radarr integration, but there are a few red flags to address before installing: - Metadata vs runtime mismatch: The registry entry claims no required environment variables, yet the scripts require RADARR_URL and RADARR_API_KEY (plus optional TMDB/OMDB/PLEX creds). Treat the latter as required and do not rely on the registry metadata. Ensure you only provide the Radarr API key to skills you trust. - Secrets handling: The SKILL.md tells you to place secrets in ~/.openclaw/.env. Confirm your OpenClaw setup actually sources that file into the environment for the runtime. Store secrets securely and avoid committing .env files. - Hardcoded paths: Several scripts call absolute paths such as /home/vishix/.openclaw/workspace or run bash -lc with a concatenated command. Update those paths to your actual OpenClaw workspace before enabling the skill, or run the skill in a controlled test environment first. - Shell invocation risk: resolve_defaults uses bash -lc and builds a command by joining args into a string. Although current calls appear safe, avoid passing untrusted user input through that code path; consider patching it to use a direct exec (no shell) if you will feed user-supplied values into it. - Test before trusting: Run ./skills/radarr/scripts/check_env.py and the ping/profile/root commands against a non-production Radarr instance, inspect the state directory (workspace/state/radarr) to see what the skill writes, and confirm outbound network calls are only to your Radarr instance and the optional add-ins (TMDB, OMDb, Plex) you expect. If you can get the skill's source repository or contact the author, ask them to (1) correct the registry metadata to list required env vars, (2) remove hardcoded /home/vishix paths or make them configurable, and (3) avoid constructing shell commands with unescaped user data. Those changes would raise confidence that the skill is safe to deploy.