Use the Health Data AI Analyzer Mac app read-only localhost API on macOS to generate a concise Apple Health daily brief and 3 practical suggestions. Only run...
Design & media
Health Metrics
Try itIngest Apple Health Auto Export JSON (HealthMetrics + Workouts) into a local DuckDB database and render offline HTML dashboards plus a Markdown daily summary...
What it does
Ingest Apple Health Auto Export JSON (HealthMetrics + Workouts) into a local DuckDB database and render offline HTML dashboards plus a Markdown daily summary (activity rings, training load, sleep, vitals, per-workout maps). Use when the user wants to process Apple Health exports, refresh their health dashboards, or get a training-load / rings / sleep / vitals report from their exported data.
The skill document
Health Metrics
A self-contained pipeline that ingests Apple Health Auto Export JSON feeds into a local
DuckDB database and renders static, offline-first HTML dashboards plus an AI-oriented Markdown
digest. No web server, no scheduler, no pip packages — just Python stdlib and the duckdb CLI.
You run it on demand whenever new export files land.
Prerequisites
python3and theduckdbCLI binary onPATH(no Pythonduckdbpackage needed).- Apple Health Auto Export daily JSON files available on disk (see Configuration).
- Internet is needed only to view workout route maps (Leaflet + satellite tiles from a CDN). Everything else renders fully offline.
Normal workflow
Regenerate everything after new exports arrive:
python3 {baseDir}/scripts/ingest.py && python3 {baseDir}/scripts/report.py -o
ingest.pyreads the source JSON and upserts into the DuckDB file (idempotent — safe to re-run; unchanged files are skipped).report.py -owrites all dashboards into a directory you choose. Pick a working or output directory the user controls; do not write inside the skill folder.
One-command runner (scripts/run.sh) — recommended
scripts/run.sh wraps the pipeline and handles two things the raw scripts do not:
- Materializes iCloud placeholder files before ingest (see the gotcha below).
- Always ingests before rendering, so reports never show stale data.
bash {baseDir}/scripts/run.sh daily-md [YYYY-MM-DD] [OUT_DIR] # ingest -> flat /YYYY-MM-DD.md (default date = today)
bash {baseDir}/scripts/run.sh html [OUT_DIR] # ingest -> full HTML dashboard set in OUT_DIR
bash {baseDir}/scripts/run.sh ingest # materialize + ingest only
Output dirs: daily-md defaults to $HEALTH_MD_DIR (else reports/summary); html defaults
to $HEALTH_HTML_DIR (else a timestamped reports/html-*). html prints HTML_OUT_DIR=
on the last lines. Exits non-zero on failure so schedulers surface it.
Use daily-md from a scheduler to keep a per-day Markdown log current (e.g. a nightly cron
that writes into a knowledge/notes folder), and html on demand for shareable dashboards.
⚠️ iCloud "dataless placeholder" gotcha (macOS)
Apple Health Auto Export writes into an iCloud Drive folder. With "Optimize Mac Storage"
enabled, macOS evicts file contents to placeholders — the files still appear in ls (with a
size!) but their bytes are not on disk until something opens them. DuckDB and Python then fail
to read them with:
IO Error: Could not read from file "…HealthMetrics-YYYY-MM-DD.json": Resource deadlock avoided
(EDEADLK). run.sh handles this by running brctl download on each source file and waiting
until the bytes are present before ingesting (no-op on Linux / non-iCloud dirs).
Permanent fix (do once): in Finder, right-click each source folder
(iCloud Drive HealthMetrics and iCloud Drive Workouts) → "Keep Downloaded". This pins the
folders so iCloud never evicts them; there is no CLI equivalent. After pinning, the brctl
step in run.sh becomes a harmless safety net.
Configuration (all optional — sensible defaults)
| Env var | Purpose | Default |
|---|---|---|
HEALTH_METRICS_DIR | Folder of HealthMetrics-YYYY-MM-DD.json files | Apple Health Auto Export iCloud …/iCloud Drive HealthMetrics under $HOME |
HEALTH_WORKOUTS_DIR | Folder of Workouts-YYYY-MM-DD.json files | Apple Health Auto Export iCloud …/iCloud Drive Workouts under $HOME |
HEALTH_DB_PATH | Where the DuckDB file lives | ~/.local/state/health-metrics/health.duckdb |
--db PATH on ingest.py / report.py overrides HEALTH_DB_PATH for that run.
⚠️ The DuckDB database is personal, sensitive health data. It is created on first ingest, lives outside this skill, and must never be committed, published, or shared. It is not part of the skill bundle.
Choosing where reports go
report.py -o mirrors this layout beneath ``:
- HTML dashboards →
/(daily-*.html,weekly-*.html,monthly-*.html,rings.html,training-load.html) - Per-workout pages + index →
/workouts/ - Markdown daily summaries →
/summary/
Individual stages (targeted re-runs)
Each script is independently runnable and honors HEALTH_DB_PATH. A single script's --out-dir
is the literal, flat directory it writes into (no subfolder appended).
| Script | What it produces | Key flags |
|---|---|---|
scripts/ingest_health_metrics.py | samples_qty / samples_hr / sleep_sessions | — |
scripts/ingest_workouts.py | workouts + workout_route/hr/hr_recovery | — |
scripts/report_health_metrics.py | activity / sleep / vitals summaries | --period daily|weekly|monthly|all --date YYYY-MM-DD -o DIR |
scripts/report_workouts.py | one page per workout + index | --force (re-render all) -o DIR |
scripts/report_rings.py | Apple-style activity rings | -o DIR |
scripts/report_training_load.py | TRIMP training load trend | -o DIR |
scripts/report_daily_summary.py | Markdown digest for AI readers | --date YYYY-MM-DD -o DIR |
Ad-hoc analysis
Query the database directly — the tables in references/schema.md are the full analysis surface:
duckdb "$HEALTH_DB_PATH" -json -c "SELECT * FROM workouts ORDER BY date DESC LIMIT 5"
Or from Python via scripts/lib/query.py's query(sql) helper (shells out to the duckdb CLI,
returns parsed JSON rows).
Internals
See {baseDir}/references/architecture.md (data flow, ingestion pattern, report conventions,
lib/ helpers) and {baseDir}/references/schema.md (DuckDB table reference) before modifying
the scripts or adding a new report/metric.
Related skills
Fetch health and fitness data from Garmin Connect -- 40+ metrics including sleep, HRV, stress, body battery, SpO2, VO2 Max, training status, and activities. Stores data locally as JSON and SQLite.
Access the user's biohub — WHOOP, Oura, Fitbit, Apple Health, and Garmin biometrics (recovery, sleep, strain, HRV, SpO₂); FreeStyle Libre continuous glucose...
Read your Google Health data from any agent. Lists data points for every Google Health data type (heart rate, resting heart rate, sleep, steps, distance, weight, blood oxygen, VO2 max, exercise, and more), returns server-side daily roll-ups (one reconciled total per day), gives a parsed view of exercise sessions, and can GET any read-only v4 API path. A self-contained, read-only client for the Google Health v4 API: authenticates via OAuth2 (token cached locally and auto-refreshed) and emits JSON. It does NO filtering, merging, or writing — the caller decides what to do with the data. Single static binary, no Python or other runtime. NOTE: needs your own Google Cloud OAuth client and a one-time interactive browser login; runs headless afterward.
Plan daily meals and workouts from a user's age and health profile with customizable ingredients, then schedule localized plans via OpenClaw automations.
More granular and few more features than the original one that is based on and seems to be abandoned. I will be fine to merge with original one but I have got not reply for MRs.