Bluetooth
v1.0.0Discover, connect, and control Bluetooth devices with automatic profile learning, cross-platform tools, and device management.
⭐ 2· 801·1 current·1 all-time
byIván@ivangdavila
MIT-0
Download zip
LicenseMIT-0 · Free to use, modify, and redistribute. No attribution required.
Security Scan
OpenClaw
Suspicious
medium confidencePurpose & Capability
Name and description (discover/connect/control Bluetooth devices) align with the provided instructions and supporting docs. The SKILL.md and tools.md reference expected platform tools (bluetoothctl, blueutil, Bleak, Noble) and workflows for profiling, scanning, and GATT interactions; nothing requested is unrelated to Bluetooth management.
Instruction Scope
Instructions explicitly direct reading/writing files under ~/bluetooth (profiles, history, pending), running local platform Bluetooth tools, and optionally capturing HCI traffic with btmon (root). They also instruct logging 'everything' and allow storing device identifiers and pairing info in profile files. Security guidance is internally contradictory (e.g., 'NEVER store pairing keys in plain text' vs. 'Document PIN/passkey in profile (if static)'). Use-cases mention syncing data to external services (Strava/Garmin) but provide no mechanism or credential handling — this could lead to accidental leakage if a user or agent follows through. Overall the instruction scope stays within Bluetooth functionality but contains risky and inconsistent privacy/security directives.
Install Mechanism
There is no install spec and no code files to write/execute; the skill is instruction-only. This is the lowest install risk (nothing is downloaded or installed by the skill itself).
Credentials
The skill declares no required environment variables or credentials, which is proportionate for a local Bluetooth helper. However, several workflows (sync to external services, pushing to Health/Strava/Garmin) imply the later need for third-party credentials; those are not declared or documented. The skill also encourages storing MAC addresses and possibly PINs in local files — sensitive data that should be handled deliberately. No direct credential exfiltration is requested, but the documentation places responsibility on the user to avoid insecure storage.
Persistence & Privilege
always:false and user-invocable:true. The skill's persistent footprint is limited to user-land files under ~/bluetooth (profiles, history). It does not request system-wide config changes or permanent elevated privileges. Packet capture guidance explicitly requires root but does not instruct the skill to obtain or store elevated tokens.
What to consider before installing
This skill is mostly coherent for managing Bluetooth devices, but review and tighten before installing.
- Contradictory security guidance: the docs both forbid storing pairing keys in plain text and instruct documenting PIN/passkeys in profiles. Decide on a single secure policy (prefer not storing secrets; if you must, encrypt them).
- Local sensitive data: profiles/history will contain MAC addresses, device names, timestamps, and possibly pairing info. Protect ~/bluetooth with restrictive file permissions (chmod 700) or avoid storing persistent secrets.
- Packet capture requires root: btmon/packet capture needs elevated privileges; only run captures in a controlled environment and delete captures when done.
- External syncs: use-cases reference pushing data to Strava/Garmin/Health but no credential handling is provided. Do not enter third-party credentials unless you understand where and how they will be stored/transmitted; prefer manual, explicit auth flows.
- Logging/privacy: 'log everything' can create a privacy risk (location tracking via MACs). If you install, configure what is logged and avoid exporting logs off-device.
- Agent autonomy: the skill is user-invocable and can be followed by the agent at runtime; if you allow autonomous agent actions, consider restricting its permissions or asking for confirmations for pairing/first connections.
What would change this assessment: if the skill included executable code or an install script that performed network calls, uploaded profiles, or requested credentials automatically, it would be higher risk. If the author supplied clear encrypted-storage guidance for secrets and an explicit, secure mechanism for external syncs (OAuth flows, scoped tokens), that would reduce concerns.Like a lobster shell, security has layers — review code before you run it.
latestvk972fg6jzdpcqx97va2xqfp92n810985
License
MIT-0
Free to use, modify, and redistribute. No attribution required.
