Proactive health monitoring for AI agents. Apple Health integration, pattern detection, anomaly alerts. Built for agents caring for humans with chronic conditions.
Security Analysis
medium confidenceThe skill's stated purpose (local Apple Health import + anomaly detection) is plausible, but the runtime instructions, configuration, and the two included scripts do not line up — files referenced by the docs are missing or use different paths/formats, so the bundle is incoherent and should be treated with caution.
The high-level purpose (import Apple Health exports, run pattern detection, produce alerts) matches the included Python scripts at a surface level, and the code operates on local files only (no network calls). However there are several mismatches: SKILL.md and config.example.json point at an iCloud path like '~/Library/Mobile Documents/com~apple~CloudDocs/Health Auto Export', while scripts/import_health.py uses a different hard-coded HEALTH_EXPORT_PATH ('~/Library/Mobile Documents/iCloud~com~ifunography~HealthExport/Documents') and an AUTOSYNC_PATH of 'AutoSync/HealthMetrics'. The skill claims support for a 'summary' script (scripts/summary.py) but that file is not present. These inconsistencies indicate the components may be from different versions or authors and reduce confidence that the skill actually implements its claimed behavior.
SKILL.md instructs creating config.json with data_source and scheduling an hourly cron import, but import_health.py does not read config.json (it uses hard-coded HEALTH_EXPORT_PATH). The SKILL.md and config.example.json describe storing data in files like 'readings.json', 'baselines.json', 'alerts.json', etc., whereas import_health.py writes 'vitals.json' with a 'readings' list and analyze.py expects a different structure (it looks for 'readings.json' in data_dir and expects metric keys mapping to lists with 'timestamp' fields). Thus the runtime instructions grant the agent broad discretion to read iCloud paths and write local data, but the scripts and instructions are inconsistent about which files/paths/formats are used. There are no instructions or code that transmit data off-machine (consistent with the privacy claim), but the inconsistent scope and missing scripts are a significant functional problem.
No install spec is provided (instruction-only with two scripts). This is the lowest install risk: nothing in the skill attempts to download or install external binaries. The code writes to local directories (data/ and /tmp), which is expected for a local importer.
The skill declares no required environment variables, credentials, or config paths. The scripts read user files under the user's iCloud Documents path and write to a local data directory — these are proportionate to the stated purpose of importing Apple Health exports. There are no network calls or credentials requested by the code.
The skill does not request 'always: true' and has no install actions that modify other skills or global agent configuration. It writes its own data files under its directory and /tmp, which is normal for this type of tool.
Guidance
The skill appears to be intended for local Apple Health import and anomaly detection, and it does not contain obvious networking/exfiltration code — that's good. However there are multiple coherence problems that make this bundle unreliable and risky to use on a real person's health data until fixed: - Path mismatches: SKILL.md/config.example point to one iCloud path, but import_health.py uses a different hard-coded iCloud export path and AutoSync folder. You may need to edit import_health.py to match your actual export location. - Data-format mismatches: import_health.py writes a 'vitals.json' with a 'readings' list, but analyze.py expects a different file ('readings.json') and structure (a dict keyed by metric containing timestamped entries). The scripts as shipped will not interoperate correctly. - Missing pieces: SKILL.md references scripts/summary.py, but that file is not included. There may be other versioning or packaging gaps. - Behavior differences: SKILL.md instructs you to create config.json, but import_health.py ignores config.json and uses hard-coded constants. That implies the documentation and code are out of sync. Before installing or running this skill on real patient data, consider these steps: 1) Don't run it on sensitive/production data yet. Test in a sandbox or throwaway account. 2) Review and reconcile the paths and filenames: either adapt import_health.py to read your configured data_source, or modify config.json usage. Align the producer (import) and consumer (analyze) formats or write a conversion step. 3) Add or restore missing scripts (summary.py) if you need them, or update the docs to reflect actual capabilities. 4) Verify the code runs on your platform (import_health.py uses signal.alarm which only works on Unix-like systems) and that file locks/timeouts behave as expected. 5) If you are not comfortable making these fixes yourself, prefer a maintained project with a verifiable repository, clear versioning, and a homepage/origin. Because these inconsistencies could be innocent (version skew, sloppy packaging) but also hide unintentional data-handling bugs, treat the package as untrusted until the author provides a coherent, complete release or you validate and fix the code yourself.
Latest Release
v1.0.0
Initial release. Proactive health monitoring with Apple Health integration, pattern detection, and anomaly alerts. Built for agents caring for humans with chronic conditions.
More by @CTsolutionsdev
Published by @CTsolutionsdev on ClawHub
