Generate a daily health brief from Oura, Whoop, and Withings. Unified re-auth script, local token persistence, Green/Yellow/Red morning summary.
Security Analysis
medium confidenceThe skill mostly does what its name/description claim (fetch and normalize Oura/Whoop/Withings data and persist rotated tokens), but there are documentation vs. implementation inconsistencies and a few operational choices that deserve attention before installation.
Name/description match the code: connectors for Oura, WHOOP, Withings; normalization and Markdown rendering; token rotation and local persistence. Network calls, OAuth refresh flows, and local token storage are all expected for this purpose.
SKILL.md and README claim tokens are saved to both 1Password and ~/.openclaw/secrets/health_tokens.json 'automatically'. The implementation will persist tokens locally, but 1Password writeback only happens when OPENCLAW_1P_WRITEBACK=1 and the op CLI is available. The docs don't call out that writeback is opt‑in, which is an important behavioral difference. The cron example also sources ~/.openclaw/secrets/gateway.env — that file may contain unrelated automation/gateway credentials (the docs don't explain its contents), so the example could cause broader credential exposure if blindly copied.
There is no external installer or remote download; the repository is instruction + local Python code. No install spec (no arbitrary URL downloads) — lower install risk. All network interactions are standard HTTPS requests to provider APIs.
The skill uses many environment variables (OP_SERVICE_ACCOUNT_TOKEN, OPENCLAW_1P_VAULT, OPENCLAW_1P_WRITEBACK, OPENCLAW_LOCAL_SECRETS_PATH, WHOOP_*, OURA_*, WITHINGS_*, OPENCLAW_FORCE_SAMPLE, etc.). Those are reasonable for OAuth access and optional 1Password integration, but the registry metadata lists 'Required env vars: none' which is misleading. OP_SERVICE_ACCOUNT_TOKEN in particular grants the skill access to 1Password items (via the op CLI) and should be treated as highly sensitive.
The skill persists rotated tokens to a local JSON file (~/.openclaw/secrets/health_tokens.json) with an atomic write and attempts to chmod 0600 — this is expected for token rotation. It can also write back to 1Password (via op) when enabled. The skill does not request system-wide privileges or modify other skills. However, the provided cron example sources an external gateway.env file (potentially containing other secrets) — copying that example without review could expose unrelated credentials to the automation.
Guidance
What to check before installing: - Behavior is broadly consistent with the stated purpose (fetching from providers, normalizing, persisting tokens), but the docs slightly overstate behavior: 1Password writeback is NOT automatic unless you set OPENCLAW_1P_WRITEBACK=1 and have the op CLI and appropriate OP credentials available. - Review and decide where rotated tokens should live: by default the skill writes tokens to ~/.openclaw/secrets/health_tokens.json (attempts chmod 600). If you prefer not to keep local tokens, don't enable writeback or change OPENCLAW_LOCAL_SECRETS_PATH. - If you will enable 1Password writeback, treat OP_SERVICE_ACCOUNT_TOKEN as highly sensitive and ensure the service-account/vault have minimal scope. Confirm the 'op' CLI is installed and you understand the vault that will be targeted (OPENCLAW_1P_VAULT). - The registry metadata says no required env vars, but the skill will need credentials (either in 1Password or env vars) to fetch live data. Use OPENCLAW_FORCE_SAMPLE=1 to run smoke tests without credentials. - Inspect the cron example before copying: it sources ~/.openclaw/secrets/gateway.env — verify that file doesn't contain unrelated high-value credentials you don't want the periodic job to source. - If you can't inspect code yourself, run tests/smoke mode first, and consider running the skill in an isolated environment (container or VM) until you are comfortable with where tokens are stored and how writeback behaves.
Latest Release
v1.0.0
Initial release: WHOOP, Oura, Withings connectors with unified reauth, local token persistence, and OpenClaw cron integration
More by @NathanielWeiner
Published by @NathanielWeiner on ClawHub
