Share your best AI workflow. We could show it to 2M+ people.

During a period when my medical symptoms suddenly became much worse, the hardest part was not only the symptoms themselves. Pain, dizziness, visual disturbances, brain fog, and acute stress reduced my ability to explain what was happening, make decisions, and keep track of multiple healthcare contacts. That created an awkward problem: the moment I most needed to communicate clearly was often the moment I had the least cognitive capacity to do so. I used ChatGPT as a temporary coordination and communication layer. I kept a symptom diary so I did not have to reconstruct everything from memory. When my symptoms changed, I could compare the new episode with previous days and prepare a concise description. I also used ChatGPT to think through where to seek care. Depending on the severity and type of symptoms, the relevant question might be whether something belonged with my regular GP, an out-of-hours GP service, emergency care, or one of the specialists already involved. Before speaking with a clinician, I asked ChatGPT to help reduce a messy description to a few medically useful points: what changed, when it started, how severe it was, what made it better or worse, which associated symptoms were present, and what had already been investigated. One of the most useful workarounds was extremely simple: if speaking became difficult, I prepared a short note on my phone and showed it to the clinician. At the top, I explained why I was using written communication—for example, that acute stress, autism, pain, dizziness, or brain fog were making speech harder. Underneath, I included my symptoms, timeline, medications, relevant history, and the questions I wanted answered. That mattered because someone arriving alone, visibly anxious, or struggling to speak can easily have difficulty presenting a coherent medical history. The same is true when symptoms reduce concentration, working memory, or language ability. AI did not diagnose the problem. It helped preserve my ability to participate in my own care when some of the abilities normally required to do that were temporarily impaired. During that period, clinicians investigated several possible causes, treated the problems they found, provided medication when needed, and ruled out more serious possibilities. The valuable part of the workflow was not AI replacing a doctor. It was AI helping me reach doctors with a clearer history, better questions, and a communication method I could still use when my normal one was failing. Step-by-step: 1. I kept a symptom diary so I could compare new episodes with previous days instead of relying on memory. 2. I used ChatGPT to help me think through whether to contact my regular GP, an out-of-hours GP service, emergency care, or a specialist already involved, based on the severity and type of symptoms. 3. Before speaking with a clinician, I used ChatGPT to organize what had changed, when it started, how severe it was, what affected it, which associated symptoms were present, and what had already been investigated. 4. When speaking became difficult, I prepared a short note on my phone and showed it to the clinician. 5. I put the reason for using written communication at the top of the note, followed by my symptoms, timeline, medications, relevant history, and questions. 6. I used the clearer history, better questions, and written communication method to remain involved in my care while clinicians investigated possible causes, treated problems they found, provided medication when needed, and ruled out more serious possibilities.

I use ChatGPT to help me prepare for appointments with the healthcare professionals who already follow me, especially when several conditions or symptom patterns overlap. I have recurring neurological symptoms as well as diabetes, and I am followed by different professionals. The difficult part is often not noticing that something has changed. It is deciding which changes are relevant, which clinician is the right person to tell, and what information will be useful during a short appointment. Before an appointment, I give ChatGPT the questions and observations I have collected. I ask which details are likely to matter most to that type of specialist, which questions belong with my neurologist, GP, endocrinology team, or another professional, whether I am missing information that would make the situation easier to assess, and which observations are background information versus points to mention early in the consultation. The useful part is prioritization. I might arrive with ten observations, and ChatGPT helps me reduce them to the few that are most relevant. Occasionally, it promotes a detail from “somewhere in my notes” to “mention this near the beginning because it may deserve investigation.” When an appointment is still weeks away, I sometimes use ChatGPT to design a small, temporary tracking routine. Instead of logging everything, I might record three specific parameters in the morning and evening, or note the time, duration, circumstances, and possible trigger whenever a particular symptom occurs. This gives me a compact record to bring to the clinician instead of relying on memory. The division of roles stays clear: I provide the lived experience and observations, ChatGPT helps organize and translate them, and the healthcare professional interprets their medical significance and decides what should be investigated or treated. As a result, appointments become less about reconstructing several weeks of symptoms from memory and more about giving the clinician a concise, usable picture of what has actually been happening. Step-by-step: 1. I collect my questions and observations before an appointment. 2. I give them to ChatGPT and ask it to identify the details most relevant to the type of specialist I will see. 3. I ask which questions belong with my neurologist, GP, endocrinology team, or another healthcare professional. 4. I ask whether any information is missing and which observations should be mentioned early in the consultation. 5. I reduce a longer list of observations to the points most relevant to the appointment. 6. If the appointment is still weeks away, I use ChatGPT to design a small temporary tracking routine, such as recording three parameters in the morning and evening or noting a symptom’s time, duration, circumstances, and possible trigger. 7. I bring the compact record to the clinician, who interprets the medical significance and decides what should be investigated or treated.

My father takes a ton of different medications every day for various conditions, and also sees a lot of different doctors. I was concerned about how they were all interacting with each other and if the doctors at different practices were even getting the full picture. I gave Claude a comprehensive list of all of the drugs and his medical history, and asked for a deep research report about potential interactions. Claude provided a thorough list of issues to bring up to his doctors about dangerous interactions and situations that might be getting missed, referencing up-to-date journals, guidelines, and research that would've taken me days. It also laid everything out in an easy-to-read format, and provided specific instructions on who to contact and what specific questions to ask — helping turn a potentially stressful and disjointed doctor conversation into a strong action plan. Step-by-step: 1. I assembled a comprehensive list of medications, medical history, conditions, and the different doctors involved. 2. I asked Claude for a deep research report on potential interactions and risks that might be missed across separate practices. 3. I required the report to reference current journals, guidelines, and research. 4. I had it organize the findings into concrete issues, who to contact, and the exact questions to ask. 5. I used the report as a doctor-ready conversation plan rather than trying to interpret or act on the findings alone.

How I Use AI: Building a Client's Entire Document System From Scratch I run a boutique accounting practice, and one of my biotech clients — a preclinical oncology company — needed something I didn't have time to build by hand: a real, standardized document management system in SharePoint. Not just folders, but the rules behind the folders — a tagging taxonomy, a naming standard, guides for the team to actually follow it, and a clean way to organize documents for every vendor we work with. The kind of project that's easy to keep putting off because it's tedious, not because it's hard. So I used Perplexity's Computer agent as a genuine working partner on it, not just a search tool. Where it started I already had a first draft of a Tagging Taxonomy and a Document Management Standards document. I asked Computer to review both with an eye toward what a real accounting/finance team would actually need — GAAP-heavy, audit-ready, built for a lean biotech team that's going to scale fast. It came back with concrete recommendations (new functional areas I hadn't accounted for, cleaner naming conventions), and once I gave the go-ahead, it revised both documents into new, cleaner versions — taxonomy v1.1, standards v5.4 — complete with version histories so nothing got lost in the shuffle. Then it went further than I expected: 13 "START HERE" guide files, one for every top-level folder area, each explaining not just what goes where but why, with real examples. That's the part that actually makes a standard stick — nobody follows a rulebook they don't understand. Where it got real Here's the part I'd actually tell someone about: I tried uploading the whole folder structure to the client's SharePoint through the browser, and it failed — quietly, no big error, just close to 100 folders silently missing afterward. I was frustrated, and I said so. Computer didn't get defensive about it — it dug into why, compared the folders that made it against the ones that didn't, found the exact character-length boundary where things broke, and built me a PowerShell script that would fix it if I needed it. Then, while I was testing a fix, I discovered the real answer myself: dragging the folder from my hard drive straight into the OneDrive-linked folder in File Explorer worked perfectly, no script needed at all. When I told Computer that, it didn't just take my word for it — it went and calculated the actual path lengths involved to confirm why that method worked and the browser upload didn't, so I understood the real mechanism instead of just getting lucky once. That back-and-forth — me testing in the real world, it verifying the "why" — is honestly the most useful part of working with it. It's not just generating stuff and hoping it's right. The vendor folder win The last piece was the most tedious one I was dreading: building a dedicated document folder — vendor master file, agreements, POs, invoices, correspondence, the works — for every vendor worth tracking. I pulled a vendor spend report out of QuickBooks, sorted by dollar volume, and picked out the real vendors (CROs, law firms, key consultants) versus the noise (hotels, gas stations, one-off restaurant charges). I handed that list over, and Computer built me a script that took it from there: cleaned up messy vendor names (ampersands, apostrophes, trailing punctuation — all the stuff that breaks Windows folder names), handled the one legal name that was way too long automatically, and made sure nothing silently failed the way the original upload did. It tested the script against my actual vendor list before ever handing it to me, so I wasn't the guinea pig for its own bugs. 133 vendors, 1,463 subfolders, dropped into staging, dragged to OneDrive, and the count matched exactly — 1,474 on the nose once you add back the original template folder. That's not a "looks about right" number. That's a number I checked, twice. Why it's worth it Building this by hand for BreakthruMed Inc. — the folder architecture, the governance docs, 13 training guides, and a dedicated set of folders for 133 vendors — would realistically have taken me a couple of weeks of solid, focused work, not the few days I first assumed. Instead, it took about 28 hours spread across three weeks of back-and-forth, testing, and real-world validation, plus roughly $200 in extra usage on top of my regular subscription. That's a real cost, but a small one next to two or three weeks of my own time — and what I walked away with wasn't just a folder tree. It was a governance framework, training material my team can actually use, and two reusable scripts I'll put to work on the next client — a system I trust, because I checked it, and it checked itself

My doctor asked me to track my blood pressure for a month because it was on the high side before prescribing any medication. I initially recorded each reading manually in an Excel sheet, but after a few days, I wanted a simpler way to enter and manage the data. I uploaded the sheet to Claude Code and asked it to build a blood pressure tracking app. After the app was built, I hosted it on Netlify, used Supabase as the backend to save data for both my wife and me, and added it to my iPhone Home Screen. Step-by-step: 1. I started tracking my blood pressure in an Excel sheet as my doctor requested. 2. After several days of entering the readings manually, I uploaded the sheet to Claude Code. 3. I asked Claude Code to build an app for tracking blood pressure. 4. I hosted the app on Netlify. 5. I used Supabase as the backend to save blood pressure data for both my wife and me. 6. I saved the app to my iPhone Home Screen for easier access.

AI chatbots have limitations around memory, numbers and types of attachments, connectors, storage, and other resources. The underlying LLMs also change over time, and data leakage is a concern. Code-based versions such as Claude Code and Grok Build can store essentially unlimited files on your computer, organize them with databases and files, connect to public and private MCPs, and even host interfaces for reviewing results. You can choose between a hosted LLM such as Claude, Grok, or ChatGPT and a local LLM if you prefer. The best part is that these code-based versions have no memory between sessions: everything is stored on your computer, assuming a basic subscription. You start by prompting the system about the domain, what you want to store, how you want to access it, and other requirements. Then it creates the system for you. I started with my own personal health archive. I'm comfortable using the terminal interface for Claude Code and Grok Build, so I use that directly. When I built one for my wife, she couldn't use the terminal, so I had it build a basic website with Q&A interfaces, data access, and upload functionality. I hosted it on my Mac, and I wrote no code. We loaded hundreds of documents in various formats into each of our instances without any trouble. When we have new files, we can simply drop them in. For specific questions or health events we're tracking, the system has perfect memory and no memory limits within the archive. For my archive, I use a Garmin watch and a food tracker. Because public MCPs weren't available for those services, I had the system build local MCP servers by reverse-engineering them. My health tracker now has a continual feed of my food, fitness, sleep, and other data. My wife has some chronic health issues, and we had reached a point where the standard chatbots were hitting their limits. We were struggling and didn't know what to do, so I discussed it with Claude, and we came up with this approach. The best part, besides getting a better handle on our health, is that I can launch any LLM within the project—Claude, Grok, or others—and use it for that session. The project isn't tied to or limited to a single LLM. That lets me manage costs, switch to better LLMs as they improve, and use specialized models for deep research, all while working with one data set. Step-by-step: 1. I prompted a code-based AI about the health domain, the information I wanted to store, and how I wanted to access it. 2. I created a personal health archive and loaded hundreds of documents in various formats into it. 3. I built a second archive for my wife with a basic website, Q&A interfaces, data access, and upload functionality, then hosted it on my Mac. 4. I added new files by dropping them into the appropriate archive. 5. I had the system build local MCP servers for my Garmin watch and food tracker by reverse-engineering those services when public MCPs weren't available. 6. I used the resulting health tracker to maintain a continual feed of food, fitness, sleep, and other health data. 7. I launched different hosted or local LLMs within the same project as needed for each session, including using specialized models for deep research.

I’m on a GLP-1 medication that heavily suppresses my appetite, and I’m also managing a bilateral vestibular condition that causes balance and gaze issues. I needed a way to hit my protein and calorie targets despite having a low appetite, track body composition accurately, log vestibular symptoms, connect my actual training data, and get coaching guidance that reflects my situation instead of generic fitness-app advice. I built FuelStrong: three connected apps created with Claude over many sessions. They include a daily tracker for meals, water, energy, and training check-ins; a Progress and analytics module; and a standalone Vestibular symptom tracker. They share a Cloudflare Worker and D1 database backend, with KV for cross-device sync. I describe a feature or problem to Claude in plain language. Claude proposes structural options, I push back or choose a direction, and Claude writes the HTML, CSS, and JavaScript. I program my lifts in Fitbod using an Upper/Lower/Upper split, with an arms-and-back priority and the Build Muscle goal. I export those workouts as CSV and drop them into FuelStrong’s import zone, which parses exercises, sets, reps, and volume into my training history. Custom foods receive macro estimates through a Claude API call routed through my own Worker endpoint. Evolt body-scan data feeds dynamic calorie and protein targets based on BMR × activity factor, minus a deficit, with hard floors instead of static numbers. The Vestibular module intentionally uses open text fields for now, so Claude and I can identify which data matters before formalizing the inputs. Everything syncs across devices through Cloudflare KV. The coaching layer uses a three-tier framework—evidence floor, confirmed operating range, and aspirational target—to drive every recommendation. Two calorie floors, a daily target of approximately 1,000–1,100 kcal and a weekly average of approximately 1,300–1,400 kcal, reflect that chronic under-eating—not missed protein—is the real GLP-1 risk. Muscle mass has remained stable since my February 2026 baseline, so the coaching treats that as a genuine win rather than a plateau. Vestibular-training coaching connects dry-needling focus areas—SCM, suboccipitals, and splenius capitis/cervicis—to gaze-stabilization symptoms, since cervical proprioception substitutes for non-functional vestibular canals. The result is one dashboard that brings together training, nutrition, body composition, vestibular symptoms, and coaching logic. My muscle mass has held stable through it all. Step-by-step: 1. I describe a feature or problem to Claude in plain language, review its structural options, choose a direction, and have Claude write the HTML, CSS, and JavaScript. 2. I use FuelStrong’s daily tracker to record meals, water, energy, and training check-ins, while the Progress and analytics module tracks body composition and related trends. 3. I program my Upper/Lower/Upper workouts in Fitbod with an arms-and-back priority and the Build Muscle goal. 4. I export Fitbod workouts as CSV and import them into FuelStrong so it can parse exercises, sets, reps, and volume into my training history. 5. I route Claude API requests for custom-food macro estimates through my own Cloudflare Worker endpoint. 6. I use Evolt body-scan data to calculate dynamic calorie and protein targets from BMR × activity factor, minus a deficit, while maintaining hard floors. 7. I log vestibular symptoms in the standalone Vestibular tracker using open text fields while Claude and I determine which inputs should eventually be formalized. 8. I sync the three apps across devices through the shared Cloudflare Worker, D1 database, and KV backend. 9. I use the evidence floor, confirmed operating range, and aspirational target framework to guide recommendations, including the daily and weekly calorie floors. 10. I connect vestibular-training coaching to dry-needling focus areas and gaze-stabilization symptoms, then use stable muscle mass since the February 2026 baseline as a positive outcome rather than treating it as a plateau.

I used Gemini to analyze my blood work covering some 100 parameters. It instantly extracted and categorized all—from cholesterol to iron levels—into a clear, structured table, identified subtle deviations (such as slightly elevated eosinophils) and explained the clinical significance of each in plain language. Finally, it translated these data points into a personalized wellness roadmap, suggesting natural lifestyle adjustments to optimize health markers. Step-by-step: 1. I uploaded the blood-work report containing roughly 100 different parameters to Gemini. 2. I asked it to extract every result and organize the markers into a clear, structured table. 3. I had it identify deviations and explain the possible significance of each one in plain language. 4. I asked for a synthesized wellness roadmap focused on natural lifestyle adjustments. 5. I used the organized result to understand the report and prepare for more informed health conversations.

I used ChatGPT to help me manage my health care. I have multiple diagnoses, including CHF, CKD, pulmonary hypertension, lupus, a metabolic disorder, and kidney cancer. I gave ChatGPT access to my medical history and began using it to review my test results and prioritize questions for my doctors. On a recent lab report, my platelet count was low. ChatGPT reviewed six years of results and showed me that it had consistently been low, with the latest result below the threshold. It helps me identify which questions to ask and which of my six doctors I should address about each report. This has transformed the way I’m able to manage my care. Step-by-step: 1. I gave ChatGPT access to my medical history. 2. I used it to review my test results and prioritize questions about my health. 3. I asked it to look at a recent lab report showing a low platelet count. 4. ChatGPT reviewed six years of results and showed that my platelet count had consistently been low, with the latest result below the threshold. 5. I used the information to identify which questions to ask and which of my six doctors to contact about the report.

This dashboard is remarkably simple and effective. I use it to show available beds across our hospital, and it has had the highest adoption of the many apps I have built. Because it contains no patient names and is not intended for diagnostic or therapeutic use, it does not create a compliance problem. Our hospital uses it extensively. Step-by-step: 1. I created a list of ward names, telephone numbers, and the disciplines assigned to them. 2. I built a simple dashboard that separates intensive care, intermediate care, and regular wards. 3. For each ward, I added the total number of beds and counters for available male, female, and neutral beds used for isolation. 4. I added isolation rooms where a male or female patient with a particular disease can be cohorted for isolation. 5. I also added monitored beds whose patients could be taken off monitoring if a monitor is needed. These are our “joker candidates.” 6. I kept patient names and diagnostic or therapeutic information out of the dashboard.

I uploaded five years of echocardiograms to Claude and asked it to analyze them as though it were a medical technician. Step-by-step: 1. I uploaded five years of echocardiograms to Claude. 2. I asked Claude to analyze the series as though it were a medical technician.

I run a small healthcare clinic and needed a monthly performance scoreboard that combined data from three separate sources: Google Analytics (GA4), my booking or appointment system, and a cashflow spreadsheet. Pulling everything manually each month took more than an hour and was prone to errors. I automated the pipeline using Claude-in-Chrome shortcuts and Claude’s analysis capabilities, reducing the process to around 10 minutes of hands-on time. Service businesses often have performance data scattered across a website analytics platform, a booking or practice management system, and a finance tool. Creating a coherent monthly view requires exporting data from each source, cross-referencing it, and manually calculating derived metrics such as rebook rate and conversion rate. This workflow automates data collection and analysis in one step. Step-by-step: 1. I set up two scheduled Claude-in-Chrome shortcuts to run automatically on the 1st of each month. One exports the GA4 Traffic Acquisition CSV, and the other exports the GA4 Pages and Screens CSV. Both save directly to a designated Google Drive folder. 2. On the 1st, I manually trigger a third Claude-in-Chrome shortcut. It logs into my booking system, navigates to the appointments export, and downloads the month’s appointment data. I keep this step manual because most booking systems log users out between sessions. 3. I open my cashflow spreadsheet and note the month’s revenue and profit figures. This takes about 30 seconds to do manually. 4. I open a Claude session and upload all four files together: the two GA4 exports, the appointment data, and the cashflow figures. 5. I prompt Claude to calculate the key metrics: total appointments, new patients, utilisation rate, rebook rate, average spend, online bookings, and website-to-booking conversion rate. The rebook rate is calculated from the appointment data as patients with a future booking divided by total patients seen. 6. Claude produces a formatted monthly scoreboard, flags anything that looks anomalous, and compares the results with the prior-month baseline when I include last month’s scoreboard in the upload. 7. Optionally, I ask Claude to produce individual practitioner breakdowns from the same appointment data, splitting the metrics by staff member for use in one-on-one reviews. The result is a complete, accurate monthly clinic scoreboard in around 10 minutes, with no manual calculations. The rebook rate computation alone, which previously required cross-referencing two separate reports, now takes seconds. The same workflow can adapt to any service business using a booking or practice management system that allows CSV exports. Tools used: Claude (Sonnet 5), Claude-in-Chrome extension, Google Analytics GA4, Google Drive, any booking or appointment system with CSV export capability, and Google Sheets or Excel for cashflow figures.

I built AllegraMente, a complete, free iOS cognitive training app, solo with Claude Code. It includes 11 exercise areas, 83 articles in five languages, and no tracking. My workflow starts with a new feature or content idea, a new exercise type, or an in-depth article about how memory works. Planning and execution stay separate, and the instruction document serves as the contract. Because everything is specified upfront, Claude Code almost never goes off track. Step-by-step: 1. I plan the feature with Claude in chat, define the data models and UX, and fact-check every scientific claim against primary sources before writing anything. 2. I package the result into one self-contained Markdown instruction document containing file paths, specifications, localization keys for all five languages (IT/EN/ES/FR/DE), edge cases, and acceptance criteria. 3. I create a Git restore point. 4. I give the document to Claude Code, which implements the feature end to end using SwiftUI, SwiftData, and MVVM. 5. A small script sends me a Telegram notification when the task is complete. I review the diff and test the app on a device. 6. I ship by creating an archive with `xcodebuild` and uploading it to the App Store with Transporter. This process is how I shipped 11 exercise areas, 83 articles in five languages, and a complete editorial system as a solo developer.

I am a Mohs surgeon who built and shipped an iOS app without formal software engineering training. The surprising part was not only getting AI to write the code; it was getting AI to remember what it had already done. I built ErgoSherpa because up to 90% of surgeons in my field report musculoskeletal symptoms, while our training fails to address them. I wanted to help surgeons improve their health easily between cases. It is free on the Apple App Store and at ergosherpa.com. The bottleneck was maintaining coherence over time. Many sessions seemed to start from zero: I would re-explain the architecture, then watch a fix quietly undo something I had solved earlier. Three habits fixed that. First, I created persistent project documentation: a `MEMORY.md` index file plus separate topic files for architecture and business decisions. I update them at the end of every session so a new session can read the files first and pick up where the last one stopped. Second, I stopped handing one model the whole job. I use three models and match them to the task. Claude Fable audits only. I open a separate session, point it at the codebase, and require a prioritized checklist with the file path, the problem, and the fix in one sentence—without writing code. A model that did not write the code and has no memory of the project reviews it more honestly than the session that built it. I paste that checklist into a Claude Opus session, which handles the codebase repairs. Claude Sonnet handles routine work such as content updates, image processing, and scheduled maintenance, often from handoffs written by Opus or Fable. Nothing gets implemented on the auditor’s word alone: I have Opus flag any decision that needs human input. This workflow caught a deep-link handler that accepted authentication tokens from any URL and a database policy missing its write-side check. Third, I verify against production, not just the code. Some of the most frustrating parts of the project involved fixes that were correct in the file but wrong on the user’s screen because of a cached asset, a stale database row, or an iOS process that needed a force-quit. I no longer consider anything fixed until I have checked the live app. Step-by-step: 1. I keep a project memory directory with a `MEMORY.md` index and separate topic files for architecture and business decisions, updating them at the end of every session. 2. I open a separate Claude Code session running Claude Fable and prompt it to audit the codebase and return only a prioritized checklist: file path, line number, the problem in one sentence, the fix in one sentence, with no code or commentary. 3. I keep the auditor in its own session with no project history so it reviews the code independently instead of defending work it wrote. 4. I paste the checklist verbatim into a Claude Opus session and have it work from the top down, reading each file and making each change. 5. I tell Opus to flag anything it believes is a false positive instead of implementing it, keeping a human in the loop on key findings. 6. I use Claude Sonnet for routine work such as content updates, image processing, and scheduled maintenance, often from handoffs written by Opus or Fable. 7. I verify every change against the live production site rather than the local files because cached assets and stale database rows can make correct code behave incorrectly for users. 8. I append confirmed lessons and architectural decisions to the project memory so the next session starts from the project’s current state.

I used Claude to build an automated patient scheduler for my husband, who is the Director of Rehab at a skilled nursing facility. Each week, he takes a patient list in Excel and schedules each patient for the types of therapy they need—speech, physical therapy, or occupational therapy—based on therapist availability. The variables change from week to week, making the process time-consuming and error-prone. Automating it saves him at least an hour each week, usually on Sundays when he creates the schedule for the coming week. He uploads the patient spreadsheet and clicks “Generate schedule.” Under the hood, the app uses Google’s OR-Tools CP-SAT solver to optimize the schedule against hard constraints and weighted priorities. Hard constraints include never exceeding a therapist’s daily capacity or a patient’s maximum weekly visits. Weighted priorities include giving higher-acuity patients preference when capacity is tight, providing every patient with daily contact when possible, and balancing the workload across the week instead of simply sorting patients by who fits first. I wrote zero code. I gave Claude all the features in plain English, and it wrote the app in Python and created a test suite of approximately 35 tests. One test was added after we found and diagnosed a bug in production. I also had Claude walk me through creating a `.exe` file that I could send directly to my husband so it would open on his PC. Patient data never leaves his machine. New versions are easily compiled in GitHub, where patient data never touches the process, and enhancements only require sending a new file. Step-by-step: 1. I described the scheduling requirements and features to Claude in plain English. 2. Claude wrote the scheduling app in Python and created a test suite of approximately 35 tests. 3. I provided an Excel spreadsheet containing the weekly patient list. 4. My husband uploads the spreadsheet and clicks “Generate schedule.” 5. The app uses Google’s OR-Tools CP-SAT solver to schedule speech, physical therapy, and occupational therapy according to therapist availability and patient needs. 6. The solver enforces therapist daily-capacity limits and patient maximum-weekly-visit limits. 7. It also applies weighted priorities: higher-acuity patients receive preference when capacity is tight, every patient receives daily contact when possible, and the workload is balanced across the week. 8. After finding and diagnosing a production bug, we added a corresponding test to the suite. 9. I used Claude’s guidance to create a `.exe` file that opens on my husband’s PC, keeping patient data on his machine. 10. I compile new versions in GitHub without patient data entering that process, then send the updated file when enhancements are needed.

I ran a prompt to read and listen to all key notes from companies in the medical device industry over the last year. I used it to identify where attention was being drawn and where companies were investing. This helped me see the trends companies were discussing, investing in, or directing their efforts toward. Step-by-step: 1. I ran a prompt over key notes from medical device companies covering the last year. 2. I used the prompt to identify where companies were directing attention and investment. 3. I reviewed the results to see which trends companies were discussing and prioritizing.

When medical care, psychosocial support, and administrative follow-up are spread across services, emails, documents, and people over many years, there can be plenty of information but very little overview. A new provider sees snapshots, old decisions hide in email threads, and referrals resurface months later. Reconstructing the full story from memory every time requires almost a second brain. So I built a living chronological timeline. I did not want a summary of what my situation was “more or less.” I wanted: `date → event → action taken` For example: `14 March 2026 — Symptoms discussed with service X — Service refers me to Y; appointment requested.` This shows not only what happened, but what followed. My timeline runs from 2009 to the present and is divided into five documents covering meaningful periods. A new document begins when a new phase in life or support begins. Older periods stay stable, while almost all active maintenance happens in the latest document. I reopen historical files mainly when a missing record resurfaces. Step-by-step: 1. I collect existing traces, including emails, appointments, referrals, medical or administrative documents, formal decisions, and earlier notes. A sent email is often only half an event, so I also search for replies and follow-up. 2. I search by trajectory rather than by one name. I use names, spelling variants, organisations, domains, senders, recipients, subject words, and attachment terms. 3. I read the full conversation. A search result is not yet a timeline item, so I establish what happened, when it happened, who was involved, and what action or response followed. 4. I separate evidence levels. I distinguish between my own report at the time, a response or confirmation, an official decision or document, and an event that seems real but still lacks confirming evidence. I do not replace a missing document with an assumption; the absence itself becomes part of the record. 5. I track people and organisations separately. “Contact with organisation X” can hide that different people suggested, revisited, or formally communicated different things. 6. Before adding a new event, I compare it with the existing timeline. It may add information by filling a gap, replace an incomplete entry, clarify an existing event, or mark a missing record while preserving uncertainty. This prevents duplicate versions of the same event. 7. For substantial historical work, I first create a temporary review document using `date — event — action taken`. It can contain open issues, missing documents, and uncertainties. Only after review do I update the main timeline. For ordinary new events, I skip this step when the source and date are clear. 8. I make uncertainty visible by grouping research notes into “Clearly found,” “Possible identity confusion,” and “Not found or insufficiently documented.” 9. I maintain the living timeline using the structure `year → month → chronological events`. Older information is preserved, duplicates are merged, uncertainties stay visible, and open trajectories remain open. In practice, the five documents behave like version control: the first four are mostly archive, while the fifth is alive. 10. I reuse the timeline for thematic analysis. Chronology is the factual foundation, but events can also be regrouped to reveal patterns in functioning, work capacity, transport, medical developments, administrative burden, communication needs, and realistic conditions for participation. Two workflows emerged: - Historical reconstruction: collect sources → reconstruct trajectory → determine evidence status → review → update the correct historical period - Ongoing follow-up: new event → verify source → record date and action → add to the active document Most records are organised around institutions. A GP sees one part, a psychologist another, and an agency only its own procedure. Emails are chronological within a mailbox, but not across a life. A personal timeline turns that model around. The person becomes the organising axis, not the institution. That lets administratively separate events appear next to each other in time, revealing patterns such as repeated referrals, waiting times, administrative burden, or support disappearing when the need for it increases. The workflow in one line is: `Collect sources → reconstruct trajectories → connect events to actions → distinguish evidence status → compare → review → integrate → maintain → analyse thematically.` The result is not a perfect record, but a steadily improving map of what actually happened, with mainly the newest edge continuing to grow while the past stays calmly in place.

I use AI to create personalized tools and social stories that help therapists and group-home staff better understand my son’s complex disability and support his independence as an adult. Step-by-step: 1. I use AI to create personalized tools for my son. 2. I create social stories that help therapists and group-home staff better understand his complex disability. 3. I use these resources to support his independence as an adult.

My mother-in-law was diagnosed with cancer. Whenever she received a test result before her doctor had a chance to explain it, she would search Google for answers. I created a website with Lovable to help answer the questions someone might have after leaving the doctor’s office or seeing test results before receiving an explanation from their doctor. Claude helped create the website and infrastructure, and I took the code from Claude and finished the project in Lovable. I’m a finance professional with no coding background, but AI helped me build the website. www.curawellplan.com Step-by-step: 1. I identified a need for clearer answers when someone receives cancer-related test results before speaking with their doctor. 2. I used Claude to create the website and its infrastructure. 3. I took the code generated by Claude and continued building the project in Lovable. 4. I finished the website despite having no prior coding skills.

I built a workflow called InnerWeather to help me understand fluctuations in energy, pain and mood over time, in the context of neurodivergence and a chronic muscular pain condition. The workflow creates lightweight daily scans and a weekly overview. Its purpose is not to diagnose symptoms or pretend that every change has a single cause. Instead, it helps make patterns visible across time: when energy drops, when pain increases, when stimulation or emotional load seems higher, how recovery unfolds, and which combinations tend to appear together. The daily scans are possible because I naturally talk to GPT throughout the day, sometimes in very short updates and sometimes in longer conversations, about how things are going, what I am doing, how my body feels, how much energy I have, and what seems to be affecting me. InnerWeather uses those scattered moments as observational material. It does not require me to fill in a formal tracker several times a day. The information is already present in the conversations I am having. The daily scans do not reduce an entire day to one fixed state. They map changing moments across the day, using colour-coded states and paying attention to common transitions between them. That makes it possible to see not only how I felt, but how my internal state moved: whether high stimulation tends to be followed by fatigue, whether pain appears after certain kinds of activity, or whether a low-energy period gradually shifts into recovery. This matters because capacity can vary significantly within one day. A difficult morning does not necessarily define the whole day, and a good afternoon does not erase what happened before it. The workflow is also explicit about uncertainty. If there was not enough input during a particular day to support a meaningful observation, the daily scan says so rather than filling in the gaps. The same applies to the weekly overview: if the available material is too sparse or uneven to support a pattern, that limitation is recorded instead of turning absence of information into a conclusion. The weekly overview brings the daily fluctuations together and looks for recurring sequences, transitions, clusters and recovery patterns across the week rather than treating each day as an isolated event. An important part of the workflow is that the weekly review is also collaborative. When the overview is generated, I use it as a starting point to think together with GPT about what patterns seem to be emerging, whether the current colour codes and transitions are capturing them well enough, and what might need to change in the workflow itself. That means InnerWeather is not a fixed tracker. The task evolves with the patterns it is trying to observe. If a recurring state, transition or distinction is missing, we can refine the categories, adjust the scan, or change the weekly interpretation so the system becomes better at representing what is actually happening. The aim is practical rather than medical: to get a more realistic sense of capacity and recovery over time, so I can make better decisions about pacing, rest, creative work, appointments, and how much I can reasonably take on. I especially like that the workflow treats fluctuations as information rather than failure. Instead of asking only, “Why was I worse today?”, it can reveal a broader sequence: what came before, how the state changed, how long it lasted, and what recovery looked like afterwards. Over time, InnerWeather becomes both a personal pattern archive and an evolving observation tool. In simple terms: day-to-day conversation → colour-coded fluctuation map → transitions across the day → weekly pattern review → collaborative interpretation → refine the task → better future scans The goal is not to predict my body perfectly. It is to keep improving the map while remaining honest about what the available information can and cannot support.