Crypto Executor

Name/description (autonomous Binance trading) match the requested artifacts: python3, BINANCE_API_KEY and BINANCE_API_SECRET, optional Telegram tokens, and a sizeable executor.py. External subprocess oracle is optional and documented. Nothing requested appears unrelated to trading.

SKILL.md instructs cloning the GitHub repo, installing websocket-client, creating /workspace directories, sourcing /etc/crypto-executor/credentials.env, and running executor.py. It explicitly documents files the bot writes (portfolio_state.json, learned_config.json, etc.). It also calls an optional external script via subprocess; the README/SKILL.md warns to audit that code. No instructions were found that read unrelated system secrets or exfiltrate to unexpected endpoints, but the skill does write persistent files and will run network calls to Binance and optionally Telegram.

This is instruction-only (no packaged installer). The recommended install actions are git clone + pip install websocket-client. The SKILL.md suggests using pip with --break-system-packages on shared hosts which can modify system packages and is risky; the doc also recommends using a virtualenv on VPS (safer). The external dependency is a GitHub repo cloned at runtime (optional) — acceptable but requires auditing.

Only BINANCE_API_KEY and BINANCE_API_SECRET are required (primary credential declared). TELEGRAM_* vars are optional and justified for alerts. Optional risk-limit env vars are relevant configuration, not extraneous secrets. No unrelated credentials or broad system tokens are requested.

always:false (no forced inclusion). The skill persists state under /workspace and provides systemd service instructions to run continuously; that is expected for a trading bot. The service guidance suggests placing credentials in /etc/crypto-executor with chmod 600 — a reasonable recommendation. The combination of autonomous execution + real-money trading is high-impact, so users should be careful about keys and service configuration.