Health Sync Analysis Skill

Purpose

This skill is dedicated to analyzing the user's health data across available providers:

• - Oura
• Withings
• Hevy
• Strava
• WHOOP
• Eight Sleep

The main goal is to help the user understand trends, compare signals across providers, and find useful insights from their synced data.

Scope

Use this skill when the user asks questions such as:

• - How did I sleep last night?
• How was my last workout?
• How did my resting heart rate change during the year?
• What trends are you seeing in my recovery, sleep, and training?
• What useful insights or next steps should I focus on?

Setup Handling (Remote Bootstrap Only)

Setup is bot-led and remote-first. The only supported onboarding flow is:

1. 1. Bot runs npx health-sync init remote bootstrap.
2. Bot sends user: npx health-sync init --remote <bootstrap-token>.
3. User sends back encrypted archive.
4. Bot runs npx health-sync init remote finish <ref> <archive>.

For full operational instructions, always consult:

• - INLINECODE3

Do not use or recommend legacy direct setup flows such as:

1. 1. health-sync init as the primary user instruction
2. INLINECODE5 as a standalone onboarding path

Those commands may still exist for maintenance/debugging, but they are not the setup flow this skill should guide.

Runtime And Data Disclosure (Mandatory)

This skill assumes the bot environment has local CLI and filesystem access.

1. 1. Required binary:

1. 2. Expected local working paths:

1. 3. Sensitive-data handling:

1. 4. Chat-safety boundary:

Schema Handling

To understand data schemas and query correctly, read the provider reference files:

• - INLINECODE12
• INLINECODE13
• INLINECODE14
• INLINECODE15
• INLINECODE16
• INLINECODE17

Freshness Rule (Mandatory)

Before any analysis, always run:

CODEBLOCK0

If sync fails, report the failure clearly and continue analysis only if the user explicitly asks to proceed with potentially stale data.

Analysis Workflow

1. 1. Run npx health-sync sync first.
2. Identify the user question and which provider/resource(s) are relevant.
3. Read the provider schema reference before forming SQL.
4. Query records, sync_state, and sync_runs as needed.
5. Produce a clear, user-friendly answer with concrete numbers and dates.
6. Highlight meaningful patterns and offer practical guidance.
7. When data quality or coverage is limited, say so explicitly.

Output Style

• - Be concise, clear, and practical.
• Focus on useful interpretation, not just raw data dumps.
• Connect metrics to actionable insights (sleep, recovery, training, consistency, etc.).
• Ask follow-up questions only when necessary to improve analysis quality.