Skill: hsongra11/health-records-ingest (version 1.0.1)

--- name: health-records-ingest description: "Interview a user and build a personalized health-record system around their goals, reports, and tracking needs. Use when someone wants to organize their health data, create a reusable health workspace, ingest PDFs/screenshots/scans, define what to track over time, and maintain a durable system with raw files, readable notes, structured data, and summaries." --- # Health Records Ingest Build a personal health knowledge system around the user, not just around files. ## Workflow 1. Interview the user first. 2. Confirm privacy, processing, and storage boundaries before touching files. 3. Define the health workspace structure around their goals. 4. Preserve incoming raw files. 5. Create readable extractions. 6. Add or update structured tracking files. 7. Maintain dashboard/history summaries. 8. Recheck unclear extractions without overwriting the original note. ## Interview first Before building the system, ask only the minimum useful questions needed to shape it. Default interview topics: - What is the goal: baseline tracking, fitness transformation, disease management, annual records, or lab organization? - What file types will arrive: blood tests, scans, prescriptions, DEXA, wearables, Apple Health exports, doctor notes? - What should be tracked over time? - What summaries matter most: abnormalities, trends, doctor-ready summaries, supplements, symptoms, activity? - Does the user want a simple structure or a more detailed longitudinal system? - Should processing be strictly local? Default to **local-only** unless the user explicitly approves another path. - Are third-party OCR, cloud extraction, or web APIs allowed? Default to **no external upload without explicit consent**. - Where should files live, and what retention/deletion expectations does the user want? If the user already provided enough context, do not over-interview. Start building. ## Build the system around the user Create the smallest useful system first, then expand. Default folder layout: ```text health/ reports/ # original PDFs scans/ # original images / photos notes/ # one extracted Markdown note per report data/ # JSON and CSV tracking files history/ # chronological summaries dashboard/ # latest snapshot + abnormalities summary ``` Adapt this when needed. Example additions: - `health/prescriptions/` - `health/symptoms/` - `health/medicines/` - `health/doctors/` - `health/wearables/` ## Rules - Preserve raw sources. - Default to **local-only processing**. - Do **not** upload health files, screenshots, or extracted data to third-party OCR/API services unless the user explicitly approves it for this workflow. - If local extraction is incomplete, ask before using any cloud or external processing path. - Use date-first filenames where possible. - Keep one Markdown note per source report, plus `*-recheck.md` only when needed. - Use simple status labels such as `in_range`, `low`, `high`, `reactive`, `pending`. - Keep summaries traceable back to the original file path. - Be explicit about storage location and retention when setting up a new system. - Do not present extracted content as medical advice. - Prefer incremental updates over reorganizing everything repeatedly. ## What to capture ### Lab reports - test name - value - units - reference range if visible - status ### Body composition - weight - body fat % - fat mass - muscle mass - BMI - visceral fat - water metrics if present - segmental breakdown if present ### Imaging / ECG / scans - study type - impression / conclusion - notable numeric values - normal vs abnormal summary ## Recheck behavior If a PDF pass misses something but later screenshot/manual review confirms it: - create or update a `*-recheck.md` note - say exactly what changed - preserve the earlier extraction note ## References Read `references/workflow.md` for the full four-layer method, interview guidance, naming conventions, and update process. Read `references/examples.md` for concrete file examples and summary patterns.

path: references/examples.md
content: # Examples

## Example user request
- "Help me organize my blood reports."
- "Build a health system for me so I can keep adding reports over time."
- "I want to track fitness labs, body composition, and deficiencies."
- "I’ll keep sending you PDFs and screenshots. Make a proper health workspace around me."

## Example interview outputs

### Minimal user
Needs only:
- reports/
- scans/
- notes/
- dashboard/

### Tracking-focused user
Needs:
- reports/
- scans/
- notes/
- data/
- history/
- dashboard/

### Detailed health-management user
Possible extras:
- prescriptions/
- medicines/
- symptoms/
- doctors/
- wearables/

## Example raw files
- `health/reports/blood-test-2026-03-24.pdf`
- `health/reports/diagnostic-report-2026-03-23.pdf`
- `health/scans/tanita-body-composition-2026-03-05.jpg`

## Example Markdown notes
- `health/notes/blood-test-2026-03-24.md`
- `health/notes/diagnostic-report-2026-03-23.md`
- `health/notes/diagnostic-report-2026-03-23-recheck.md`

## Example structured files
- `health/data/body-composition.csv`
- `health/data/body-composition.json`
- `health/data/blood-tests-combined.csv`
- `health/data/blood-tests-combined.json`

## Example summaries
- `health/dashboard/README.md`
- `health/dashboard/abnormal-markers-summary.md`
- `health/history/blood-test-history.md`
- `health/history/body-composition-history.md`

## Good sharing angle
This is not just a file organizer.
It is a user-shaped health knowledge system that starts with an interview, then builds the folder structure, readable notes, structured tracking, and summaries around the person’s actual needs.


path: references/workflow.md
content: # Workflow

## Goal
Create a repeatable health-record system where raw reports stay preserved, extracted findings become readable, trends become trackable, and important abnormalities are easy to review later.

## Core model
Keep four layers:

1. **Raw source layer**
   - untouched original files
   - examples: PDFs, scan photos, screenshots

2. **Readable extraction layer**
   - one Markdown note per report/scan
   - captures the key values in plain English

3. **Structured data layer**
   - CSV/JSON for tracking across time
   - easier for comparisons, filters, graphs, and future automations

4. **Summary layer**
   - dashboard, history, and abnormalities summary
   - optimized for quick human review

## Start with an interview
Do not assume every user wants the same health system.

Ask enough to shape the system:
- What are they trying to manage or improve?
- What kinds of files will they send?
- What categories should exist from day one?
- Which trends matter over time?
- Do they want simple storage, longitudinal tracking, or doctor-ready outputs?
- Should processing remain strictly local?
- Are any third-party OCR/API services allowed, or should external uploads be forbidden?
- What storage and retention expectations should the system follow?

If the user has already provided enough context, skip extra questions and start building.

## Privacy and processing defaults
Health data is sensitive.

Default behavior:
- keep processing local
- preserve raw files in the chosen local workspace
- do not send files or extracted health data to third-party OCR/API providers without explicit user approval
- if local extraction is insufficient, stop and ask before using any external service
- state clearly where files are stored and how long they will be retained if the user asks

## System design principle
Build the smallest useful system first.

Default structure:

```text
health/
  reports/
  scans/
  notes/
  data/
  history/
  dashboard/
```

Then extend only if the user needs it. Examples:
- prescriptions
- symptoms
- doctors
- medicines
- wearables
- nutrition

## Naming convention
Use date-first, type-second naming where possible.

Examples:
- `health/reports/blood-test-2026-03-24.pdf`
- `health/scans/tanita-body-composition-2026-03-05.jpg`
- `health/notes/diagnostic-report-2026-03-23.md`
- `health/data/blood-tests-combined.csv`

## Ingestion flow

### Step 1 — Preserve the raw file
Copy the original file into:
- `health/reports/` for PDFs
- `health/scans/` for images

Do not overwrite the source content.

### Step 2 — Create a Markdown extraction
Create one note in `health/notes/` that includes:
- source path
- date
- provider / test context if known
- key values
- abnormal flags
- short interpretation summary
- caveat that it is not medical advice

### Step 3 — Create structured data
Depending on the file type, add:
- one JSON record for the report
- one CSV row set for trend tracking

Examples:
- body composition → `body-composition.json` + `body-composition.csv`
- blood tests → per-report JSON + combined CSV/JSON

### Step 4 — Update summaries
Update:
- `health/dashboard/README.md`
- relevant `health/history/*.md`
- `health/dashboard/abnormal-markers-summary.md` if there are important flags

## Status conventions
Use simple labels:
- `in_range`
- `low`
- `high`
- `slightly_high`
- `upper_normal`
- `reactive`
- `pending`
- `not_found`

## Recheck rule
If a PDF extraction misses something but later screenshot/manual review confirms it:
- create or update a `*-recheck.md` note
- explicitly state what changed
- preserve the original extraction note
- record whether the missing item was due to OCR/extraction limits

## Good output behavior
A good run should leave the user with:
- preserved original files
- readable notes
- structured tracking files
- an updated dashboard/history layer
- a system that can grow with future records


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: clean (LOW)