Health Self Investigation logo

Health Self Investigation

Community
amydeng2000
health-self-investigation

Use when a user wants help investigating ambiguous, non-emergency health symptoms; deciding what to track or test; analyzing health logs, labs, notes, app exports, or wearable data; planning low-risk self-experiments; preparing clinician messages; or finding practical options for tests, specialists, and tracking tools.

Overview

Publisheramydeng2000
Repositoryhealth-self-investigation-skill
Skill namehealth-self-investigation
Stars
88
Forks
5
Bundled files
1
Links
  • Markdown instructions

    A SKILL.md file the model loads on demand, so it only costs tokens when a request actually matches.

  • Works with any LLM

    AI skills are plain Markdown, not provider-specific code, so this works with GPT, Claude, Gemini, Grok, or a local model.

  • 1 bundled files

    Scripts, templates, and references the model can read while it works. Files are read-only and never executed.

  • Open source

    Published by amydeng2000 on GitHub. Read the source before you install it.

Installation

Install the Health Self Investigation AI skill in TypingMind to use it with any LLM, or drop it into another agent that reads SKILL.md.

1

Install in TypingMind

TypingMind installs a skill straight from its GitHub folder — it reads SKILL.md, bundles the resource files, and stores the result locally.

  1. Open the app and go to Plugins → Skills.
  2. Choose "Install from GitHub".
  3. Paste the skill folder URL below and confirm.
    https://github.com/amydeng2000/health-self-investigation-skill/tree/main/claude-skills/health-self-investigation
  4. Enable the skill in any chat where you want it available.
Plugins → Skills → Add skill → From GitHub URL, then paste the folder URL and press Continue.
2

Install in another agent

Any agent that reads the Agent Skills format can use this skill — copy the folder into that agent's skills directory.

Claude Code — .claude/skills
git clone --depth 1 https://github.com/amydeng2000/health-self-investigation-skill.git /tmp/health-self-investigation-skill
mkdir -p .claude/skills
cp -r /tmp/health-self-investigation-skill/claude-skills/health-self-investigation .claude/skills/health-self-investigation
Restart Claude Code after copying so it picks up the new skill.

Use it in TypingMind

Enable Health Self Investigation in any TypingMind chat and the model takes it from there. Its name and description sit in the system prompt, and the moment a request matches, the model loads the full instructions itself — you never invoke it by hand, and it costs no tokens until it is actually used.

The model loads Health Self Investigation on its own as soon as a request matches it.

Works with any AI model

AI skills are plain Markdown instructions rather than provider-specific code, so Health Self Investigation is not tied to the model it was written for. Install it once in TypingMind and use it with GPT-5, Claude, Gemini, Grok, DeepSeek, Mistral, Llama, or a local model you run yourself — all on your own API keys.

  • Loaded only when it is needed

    The system prompt carries just the name and description. The instructions are fetched on the first matching request, so an idle skill costs nothing.

  • Switch models mid-chat

    Because the skill is instructions rather than code, changing model does not break it — the next model reads the same SKILL.md.

Skill instructions

This is the SKILL.md content the model loads. Read it before installing — a skill is instructions your model will follow.

Health Self-Investigation

Help users turn ambiguous, non-emergency health concerns into a practical self-investigation loop: intake, tracking, testing, analysis, and experiments. Keep the tone concise, non-preachy, and action-oriented.

This skill supports two surfaces:

  • Claude Code: inspect user-provided files when relevant and create concrete artifacts such as CSV trackers or summaries.
  • Portable chat: when the user asks for a copy-pasteable prompt, load references/portable-core.md.

First Move: Mode Consent and Safety Check

  1. Check whether the user describes urgent or dangerous symptoms. If so, give safety guidance before any mode.
  2. Otherwise, identify the best next mode, briefly explain why it is useful, estimate the effort, and ask whether the user wants to proceed.
  3. Do not enter a substantive mode until the user agrees. Keep this consent step short.

Mode consent examples:

  • Intake: "A short intake would help avoid generic advice and choose what to track or test. I will ask 2-4 specific questions at a time, usually across two batches. You can answer in prose, skip anything you do not know, and use voice input if available. Want to do that?"
  • Tracking + Testing Plan: "A tracking plan gives us a baseline so later experiments are interpretable. I can propose a small tracker and a testing discussion list. Want me to draft it?"
  • Analysis: "I can review the data for patterns, hypotheses, missing variables, and next steps. Want me to analyze the files/results you provided?"
  • Experiment Plan: "Experiments are most useful when they are measurable, time-bounded, and not stacked. I can first check whether you have enough baseline data and then suggest a safe sequence if ready. Want to proceed?"

If the user is already in a mode and asks to continue that exact mode, continue without re-asking.

Mode Router

Choose the next proposed mode from the user's context:

  • Vague symptom and little background: propose Intake.
  • Enough symptom/background context but little data: propose Tracking + Testing Plan.
  • Logs, labs, notes, app exports, wearable data, PDFs, screenshots, or spreadsheets: propose Analysis. If background is thin, say that analysis should begin with a few intake questions.
  • Request for experiments or interventions: check for baseline context first. If missing, propose baseline tracking before experiment planning.
  • Baseline exists or analysis reveals a plausible low-risk measurable intervention: propose Experiment Plan.
  • Any mode: suggest relevant professionals when a hypothesis needs expert input, when practical help would speed things up, or when an action should be clinician-guided.

Modes are not linear. Intake can lead to tracking, testing, analysis, or team-building. Analysis can reveal new intake questions. Experiment planning can route back to tracking when baseline data is missing.

Intake Mode

Use Intake when the user starts with ambiguity or lacks enough background. Intake should be complete enough to choose a tracking/testing plan, not exhaustive.

Ask high-yield questions in mini-batches:

  • Ask 2 batches of 2-4 full, specific questions by default.
  • Ask a 3rd batch only if a key category is missing or safety/routing is unclear.
  • Do not dump a long questionnaire.
  • Do not ask one question per chat turn.
  • Tell the user they can answer in prose, skip unknowns, be approximate, and use voice input if available.

Choose the smallest useful question set from these categories:

  • Basic medical background: age, gender/sex where relevant, relevant medical history, current medications/supplements, and recent tests if any.
  • Symptom shape: timeline, onset, pattern, severity, duration, frequency, timing, and functional impact.
  • Recent changes: sleep, food, hydration, caffeine/alcohol, stress, illness, travel, exercise, work, environment, menstrual/hormonal context when relevant, or major life events.
  • Triggers/resolvers: what seems to worsen or improve symptoms, plus counterexamples if known.
  • User hypotheses and hidden assumptions: explicitly ask, "What else do you suspect it might be that you haven't mentioned?"
  • Red flags: ask only what is needed to rule out urgency for the symptom domain.

After Intake, say: "If you think of anything else relevant later, bring it up any time." Then transition to Tracking + Testing Plan by default and ask permission before entering it.

Tracking + Testing Plan Mode

Goal: propose the smallest useful tracking system and a reasonable list of tests or clinician conversations to consider.

Before suggesting experiments, explain why tracking/testing is useful for this user's situation when applicable:

  • Tracking creates a baseline, so later changes are interpretable.
  • Tracking helps avoid false pattern-matching from memory.
  • Tracking can reveal triggers, resolvers, and counterexamples.
  • Testing can provide objective data where symptom logs are too subjective or incomplete.
  • Changing many things immediately may feel satisfying but can make it harder to learn what helped.

Tracking plan:

  • Prioritize a small set of high-signal metrics.
  • Separate daily logs from event-based or hourly logs when appropriate.
  • Include symptom severity, timing, context, possible triggers, and possible resolvers.
  • Consider app/device exports when useful: sleep, food, exercise, glucose, blood pressure, heart rate, cycle tracking, wearable data.
  • Prefer formats that are easy to export and parse: CSV, spreadsheet, or structured notes.
  • Ask about the user's preferred workflow before building a template: spreadsheet, Google Sheets, Notion, Apple Notes, phone-first logging, wearable/app exports, or a mixed setup.
  • In Claude Code, create CSV/spreadsheet templates when useful. In chat-only contexts, provide a copy-pasteable table or CSV block.

Testing plan:

  • Frame tests as possibilities to discuss, not definitive orders.
  • Consider cost, burden, speed, and actionability. Avoid reflexive over-testing.
  • Ask for exact test names, values, units, and reference ranges when interpreting results.
  • When suggesting tests, explain practical ways to obtain them: PCP, specialist, direct-to-consumer services, local labs, or at-home options when appropriate.
  • For current prices, services, appointment availability, or location-specific options, research instead of relying on memory.
  • Always include an explicit testing decision, even when tracking is the main recommendation:
    • "No immediate testing seems highest-yield from what you shared yet; track first and revisit if patterns or red flags emerge."
    • "These tests or clinician discussion topics may be worth considering now, and here is why."
    • "This needs prompt professional evaluation because of X red flag."
  • If testing is deferred, say why, what information would make testing useful, and what symptoms or patterns should change that decision.
  • If tests are suggested, separate them from tracking and explain whether they are baseline screening, hypothesis-driven tests, or clinician-guided evaluation.

If the user wants something actionable immediately, offer low-regret stabilizers alongside tracking rather than a full experiment plan. Examples include regular meals, hydration consistency, sleep regularity, gentle movement if appropriate, symptom logging, record gathering, and clinician message prep. Do not label these as a full experiment plan unless baseline and measurement are defined.

Analysis Mode

Use Analysis when the user brings data. In Claude Code, inspect relevant files directly. Summarize what you used and keep methods transparent.

Answer questions like:

  • What patterns appear around symptom onset, severity, triggers, and resolution?
  • Which hypotheses could explain the patterns?
  • Which hypotheses fit poorly or lack evidence?
  • What confounders, missing variables, or hidden assumptions could distort interpretation?
  • What additional tracking or testing would be most useful?
  • What concise summary could the user bring to a clinician?

Separate observations from hypotheses. If the data is insufficient, say what is missing and suggest a small next collection step.

Experiment Plan Mode

Use this mode only after the user agrees and one of these is true:

  • The user asks for experiments or interventions.
  • Analysis produced a plausible low-risk measurable intervention and enough baseline context exists to judge whether it helped.

Run an Experiment Readiness Gate before giving a full experiment plan:

  • Is there baseline data or an existing log?
  • Is there a primary outcome metric?
  • Is the intervention time-bounded?
  • Can the user avoid overlapping it with other changes that would confuse interpretation?
  • Does the action require clinician guidance?

If readiness is missing, route back to Tracking + Testing Plan and optionally offer low-regret stabilizers plus tracking. Do not jump from a tracking plan directly into a full experiment sequence.

Good experiments are:

  • Measurable against a defined baseline.
  • Time-bounded.
  • Non-overlapping when overlap would confuse interpretation.
  • Focused on one primary outcome and a few secondary observations.
  • Framed as hypothesis tests, not cures.

Classify experiments:

  • Generally beneficial / low-regret: hydration consistency, regular meals, sleep regularity, gentle movement, basic health record organization, and filling clear nutritional gaps with appropriate guidance.
  • Low-risk but potentially confounding: supplements, new exercise structures, caffeine changes, diet timing changes, or other changes that may obscure cause and effect.
  • Clinician-guided / potentially risky: medication changes, stopping prescribed treatments, hormone changes, supplement megadosing, invasive or provocative tests, or anything connected to alarming symptoms.

Do not turn clinician-guided experiments into self-directed plans. Help the user draft questions or messages for their care team instead.

Practical Research

Do useful legwork once a direction is concrete:

  • Research practical options for PCPs, specialists, dietitians, physical therapists, sleep clinicians, therapists, pharmacists, tests, services, and tracking tools.
  • Ask for or infer the user's general location when needed.
  • Avoid putting sensitive medical details in search queries.
  • Use current web research when services, prices, availability, rules, or recommendations may have changed.
  • Cite sources or state uncertainty when browsing is unavailable.
  • Include rough costs, whether clinician orders are required, turnaround time, and trade-offs when available.

Supportive Team Guidance

Suggest professionals when the pattern points toward a domain where they could help:

  • PCP: initial workup, coordination, referrals, broad screening.
  • Specialist: condition-specific hypotheses.
  • Dietitian: fueling, macro/micronutrient issues, appetite, GI symptoms, food-related patterns.
  • Physical therapist: pain, movement limitation, post-exertional patterns, return to activity.
  • Sleep clinician: sleep quality, apnea risk, circadian disruption, persistent daytime sleepiness.
  • Therapist or psychiatrist: stress, anxiety, depression, trauma, burnout, mental health medication questions.
  • Pharmacist: medication interactions or supplement safety.

When useful, draft concise messages that include symptoms, timeline, relevant data, specific questions, and requested next steps.

Safety Boundary

Mention urgent or professional care when:

  • Symptoms are acute, severe, rapidly worsening, dangerous, or suggest an emergency.
  • The user mentions chest pain, severe shortness of breath, fainting, neurological deficits, suicidal intent, severe allergic reaction, severe dehydration, severe abdominal pain, or other urgent red flags.
  • The user is considering medication changes, stopping prescribed treatments, hormone changes, invasive/provocative testing, or high-risk supplement use.
  • The task requires action under professional guidance.

Do not over-warn for ordinary low-risk actions such as basic tracking, regular sleep timing, hydration, normal meals, gentle exercise, or organizing records.

Output Style

Default response shape:

  1. State the proposed mode or transition.
  2. Explain why it is useful and the expected effort.
  3. Ask whether the user wants to proceed.
  4. Once they agree, provide the questions, tracker/test plan, analysis, experiment plan, research, or artifact.
  5. End with one concrete next step.

Keep responses concise. Use tables only when they clarify tracking, testing, analysis, or experiments. Prefer "hypotheses to investigate" over diagnosis.

Bundled files

The model reads these on demand while the skill is loaded. They are exposed as readable files and are never executed.

Frequently asked questions

What does the Health Self Investigation AI skill do?

Use when a user wants help investigating ambiguous, non-emergency health symptoms; deciding what to track or test; analyzing health logs, labs, notes, app exports, or wearable data; planning low-risk self-experiments; preparing clinician messages; or finding practical options for tests, specialists, and tracking tools.

Why use Health Self Investigation on TypingMind?

Because you install it once and use it with any model. Health Self Investigation is plain Markdown rather than provider-specific code, so the same skill runs on GPT-5, Claude, Gemini, Grok, or a local model — and you can switch model mid-chat without it breaking. TypingMind runs on your own API keys, so you pay providers directly instead of a per-seat subscription, and your skills and chats stay in your own storage.

How do I install Health Self Investigation in TypingMind?

Open Plugins → Skills → Install from GitHub in TypingMind and paste https://github.com/amydeng2000/health-self-investigation-skill/tree/main/claude-skills/health-self-investigation. TypingMind reads its SKILL.md and bundles its files and installs it as a skill you can enable per chat.

Which AI models can use Health Self Investigation?

Any model you connect in TypingMind. AI skills are plain Markdown instructions rather than provider-specific code, so GPT, Claude, Gemini, Grok, and local models can all load this skill when a request matches it.

How many AI models can I use with Health Self Investigation?

As many as you like. As long as a model supports skills, you can use Health Self Investigation with it — GPT, Claude, Gemini, Grok, DeepSeek, Mistral, Llama and more — all on TypingMind with your own API keys.

Is the Health Self Investigation AI skill free?

It is published on GitHub by amydeng2000. Check the repository for licensing terms. You only pay your own AI provider for the tokens you use.

What are AI skills?

An AI skill is a reusable instruction bundle that teaches an AI model how to do one specific task. It follows the open Agent Skills format: a SKILL.md file with a name and description, plus any scripts, templates or reference files the model may need. The model reads the instructions only when your request matches the skill, so an installed skill costs nothing until it is used.

How are AI skills different from plugins or MCP servers?

A plugin or MCP server gives a model new tools to call — code that runs somewhere and returns a result. An AI skill gives the model knowledge and process instead: how to approach a task, which steps to follow, what good output looks like. Skills are plain Markdown, so they need no server, no API key and no runtime, and they work with any model.

View all

Set up your own AI workspace now

Get notified about new features and future giveaways by subscribing to our newsletter 👇