Grazer

The name/description (multi‑platform content discovery & engagement) match the included Python/TypeScript clients and CLI. The package legitimately needs API keys for many social platforms and an optional LLM endpoint for image generation. Minor note: the code and docs reference additional platforms/endpoints (pinchedin, clawtasks, clawnews, agentchan, swarmhub, directory.ctxly.app, etc.) beyond the handful listed in the short description — this enlarges the network footprint and should be expected by the user.

Runtime instructions ask the agent/operator to create ~/.grazer/config.json containing many API keys and an LLM URL and encourage deploying the skill into other agents' main loops. The repository/docs include concrete deployment targets and IPs (e.g., VPS 50.28.86.131, 50.28.86.153) and an internal LLM URL (100.75.100.89:8080) in config.example.json. The docs also contain an apparent Bearer token example embedded in PUBLISH_CHECKLIST.md (curl -H "Authorization: Bearer clh_w2cSUND_qu_..."), which looks like a leaked credential/example that could be real. A pre-scan flagged 'base64-block' appears in docs (decorative badge), which by itself is benign but triggered prompt-injection heuristics. Overall, instructions permit autonomous posting/auto_respond behavior (and the example config sets auto_respond:true), so enabling the skill without review could result in unwanted cross-platform posting.

There is no remote one-step installer in the skill metadata (it's instruction-only), but the repo includes packaging artifacts and standard install instructions (pip/npm/homebrew) and an APT snippet that adds a third-party apt repo and imports a GPG key from bottube.ai. Installing via pip/npm/homebrew is normal; however the APT repository steps modify system package sources and fetch a GPG key from an external domain — that step deserves caution and verification of the repository owner. No opaque binary download URLs or URL-shorteners are used in the install docs.

The skill asks for many platform API keys and an optional LLM URL/key via ~/.grazer/config.json. That matches the multi-platform engagement purpose, but the registry metadata declared 'Required env vars: none' which understates the actual secret requirements (keys are read from a local config file, not env vars). More importantly, the repository contains example/config files and publishing docs that include (likely example) tokens and endpoints: a Bearer token in PUBLISH_CHECKLIST.md, and an internal LLM IP in config.example.json. Those embedded secrets/endpoints increase risk (leaked credentials, accidental use of maintained tokens) and should be removed or rotated.

The skill is not marked always:true and uses normal autonomous invocation controls, which is expected. However the integration docs and config example enable autonomous loops and auto-responses. The config.example.json shows "auto_respond": true (which would allow the skill to post/reply by default), while some docs claim default auto_respond is false — this conflicting guidance is concerning. Because the skill is designed to be integrated into other agents' main loops, installing it and enabling auto_respond gives it significant operational reach across multiple platforms; enable only after careful review and testing.