Philips Hue Thinking Indicator
Analysis
The skill mostly matches its Hue-light indicator purpose, but the core `hue` executable is missing and points to placeholder or unknown sources, so users would need to trust unreviewed code to install it.
Findings (4)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
Checks for instructions or behavior that redirect the agent, misuse tools, execute unexpected code, cascade across systems, exploit user trust, or continue outside the intended task.
"homepage": "https://github.com/yourusername/philips-hue-thinking", ... "bin": { "hue": "./hue" }, ... "files": [ "hue", "SKILL.md", "README.md", "LICENSE" ]The package declares a central `hue` executable and placeholder repository metadata, but the provided manifest does not include the `hue` binary. The user would have to obtain the device-controlling executable from an unverified or placeholder source.
The assistant will automatically use `hue thinking` and `hue done` during long tasks.
The skill intentionally lets the agent invoke commands that change Philips Hue lights. This is aligned with the stated purpose, but it is still physical device control.
Background process keeps pulsing ... `pkill -f "hue-pulse-loop"`
The pulse effect is implemented as a background process that may keep running until explicitly stopped. This is documented and purpose-aligned, but it is persistent behavior.
Checks whether tool use, credentials, dependencies, identity, account access, or inter-agent boundaries are broader than the stated purpose.
Config stored in: `~/.config/philips-hue/config.json` ... "username": "your-api-key"
The skill documents storing a Hue bridge API username/key locally. This credential is expected for Hue Bridge access and no artifact shows it being exfiltrated.
