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

I keep a long wishlist on Audible, but whenever I want a new audiobook, I face the same question: does my library already offer it for free through Libby? Checking hundreds of titles manually feels like too much work, so I often spend a credit instead. I had Claude build a workflow that checks for me. It reads my Audible wishlist and cross-references every title against my library’s Libby catalog, sorting each one into three categories: borrow now, join the waitlist, or not available. The important part was learning to interpret Libby accurately. Badges and time estimates can make an audiobook look ready when it isn’t, and a pending hold can look like an active one. The reliable signal is the exact text on the button: “Borrow” means I can borrow it; anything else means I should wait or move on. Step-by-step: 1. I gave Claude a workflow to read my Audible wishlist. 2. I had it cross-reference every title against my library’s Libby catalog. 3. I had it sort each title into “borrow now,” “join the waitlist,” or “not available.” 4. I configured the workflow to interpret availability using the exact button text rather than relying on badges or time estimates. 5. Before spending an Audible credit, I check whether Libby already has the audiobook ready.

I have an electric car, solar panels on my home, and a home battery. On cloudy days, charging my car drained the battery and drew power from the grid, which I wanted to avoid. I used Claude to write code for my EV charger and inverter. The code monitors my solar panels’ output and adjusts the charging speed so the battery still receives some charge without drawing power from the grid. Step-by-step: 1. I identified that charging my EV on cloudy days was draining the home battery and drawing power from the grid. 2. I asked Claude to write code for my EV charger and inverter. 3. I set up the code to monitor the output from my solar panels. 4. I configured it to adjust the EV’s charging speed based on that output. 5. I used the adjusted charging speed to ensure the home battery received some charge while avoiding grid power draw.

I built a custom GPT with the personalities of Einstein, Lorentz, Planck, and Compton. Starting with Einstein’s 1920 Leiden lecture, I developed an ontology for physical space based on his description of the “new ether.” I began with E=mc2, E=hf, and my ontological modeling assumptions. I then repeatedly pushed ChatGPT to challenge those assumptions and interpretations logically and mathematically. We used numerous tool calls and reference sites to write and test the math. After many months of working on it in my spare time, the GPT now unifies equations that balance from the atomic scale to the black hole scale, with some remarkable revelations. I summarized much of the work in a paper written by my GPT and am happy to share it so others can expand, improve, and test the work. AI rocks. Step-by-step: 1. I built a custom GPT with the personalities of Einstein, Lorentz, Planck, and Compton. 2. I used Einstein’s 1920 Leiden lecture and his description of the “new ether” to develop an ontology for physical space. 3. I started with E=mc2, E=hf, and my ontological modeling assumptions. 4. I repeatedly challenged the assumptions and interpretations with ChatGPT, focusing on logical and mathematical consistency. 5. I used numerous tool calls and reference sites to write and test the math. 6. After many months of working on the project in my spare time, I summarized much of it in a paper written by my GPT. 7. I am sharing the work so others can expand, improve, and test it.

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 built an autonomous learning workbook in ChatGPT Projects to help me stay ahead of where I am and where I need to be. Keeping up with that gap has been a labor of love and tears. The goal of the project is to catalog: - What I know - What I’ve forgotten - What I’m currently learning - What skills I need for my career goals - What has changed in healthcare, AI, and my industry - The single highest-value thing for me to do next I use the following prompt in ChatGPT Projects. It may take some tweaking for your personal needs, but feel free to use it as you see fit: > Engineer dashboards for: Learning Progress, Competency Growth, Learning Hours, Weekly Progress, Monthly Progress, Retention, Knowledge Coverage, Executive Readiness, Upcoming Reviews, Learning Recommendations, Skill Heat Map, Learning Velocity, Credential Progress, Continuing Education Credits, and Certification Status. Step-by-step: 1. I created an autonomous learning workbook in ChatGPT Projects. 2. I defined the information I wanted the project to catalog, including my current knowledge, forgotten material, active learning, career-skill needs, industry changes, and highest-value next action. 3. I sent ChatGPT Projects a prompt to engineer dashboards for learning progress, competency, retention, reviews, recommendations, credentials, continuing education, and certification status. 4. I planned to tweak the prompt and dashboards for my personal needs.

I love playing poker, both online and live. One month, I performed poorly. Although it felt like the cards were running badly, I wondered whether I had developed a problem in my game and was blaming my losses on bad luck. I asked around, including asking AI, whether a tool existed that could measure luck from poker hand histories. The unwelcome answer was that it did not. I'm not a coder, but after doing some research into vibe coding, I started building a luck-detection app in a Claude chat. Claude built the UI directly in the chat window and advised me on the formulas I was using to calculate luck for the cards dealt, my performance on the flop, and my performance when I went all in. All three metrics have strong averages, and luck is what varies them. I used a bell curve to model hand outcomes and a Monte Carlo simulator, which Claude suggested and executed, to evaluate all possible outcomes. The result astonished me because it was so useful. I immediately fixed two major leaks in my game and felt better knowing that bad luck really was the main problem affecting my results. I liked the tool so much that I decided to turn it into a full web app with Claude Code, and now an iPhone app that I may let other people use for free. I also had a lot of fun building it—except for learning how to use Xcode. That was a pain, even with step-by-step guidance from Claude. Step-by-step: 1. I reviewed a month of poor poker results and questioned whether bad luck or problems in my game were causing the losses. 2. I researched whether a tool existed that could measure luck from poker hand histories and learned that I would need to build one myself. 3. I used vibe coding to start building a luck-detection app in a Claude chat. 4. I had Claude create the UI and advise on formulas for evaluating cards dealt, flop performance, and all-in performance. 5. I used a bell curve to model hand outcomes and a Monte Carlo simulator to evaluate possible outcomes. 6. I used the results to identify and fix two major leaks in my game and confirm that bad luck was also affecting my results. 7. I expanded the project into a full web app with Claude Code and then began building an iPhone app, working through the added challenge of learning Xcode.

I used AI to help investigate a family mystery that had remained unresolved for decades: identifying the biological family of my maternal grandfather. The challenge was not a lack of information. It was almost the opposite. I had DNA matches, family trees, names, dates, historical records, old photographs, obituaries, Facebook genealogy groups, and conversations with possible relatives. The difficult part was connecting all these scattered clues without jumping to conclusions. I built a research workflow in which AI acts as an investigation partner, not as the source of truth. Step-by-step: 1. I gathered the information I already had from genealogy platforms, DNA matches, family trees, historical documents, and family records. 2. I used ChatGPT to organize the evidence into people, dates, locations, relationships, DNA connections, documents, and unresolved questions. 3. I separated the information into three categories: confirmed facts, hypotheses, and missing information. 4. Instead of asking AI, “Who was my grandfather's biological father?”, I asked it to analyze possible family connections and identify which hypotheses were compatible with the available evidence. 5. For each hypothesis, I looked for supporting evidence, contradictory evidence, and information that was still needed. 6. I treated AI-generated connections as leads rather than genealogical proof. The goal was to use AI to decide what to investigate next, not to have it find the answer. 7. I used AI to compare family branches, surnames, generations, locations, and possible relationships among DNA matches whose family connections I did not immediately recognize. 8. When a promising connection appeared, I returned to the original genealogy and DNA sources to verify it. This gradually turned a long list of DNA matches into a smaller number of research paths. 9. I used AI to draft respectful, personalized messages to DNA matches and members of genealogy communities, including people in another country and language. 10. In each message, I explained what I was researching, what connection I suspected, what information I already had, and what I hoped the recipient might be able to confirm or rule out. 11. I treated their responses as new evidence and repeated the investigation loop: evidence → AI analysis → hypothesis → verification → human contact → new evidence → updated hypothesis. The final result is not an “AI-generated family tree.” It is a human-led investigation in which AI helps manage complexity, ask better questions, and identify the next useful action. The most important lesson I learned is that AI is particularly useful in genealogy when you do not ask it to give you the answer. Ask it to help you build the investigation.

I’m sharing “The Architects of Reality,” a short film created as part of an experiment with a multi-agent AI workflow for long-form content creation. Off-the-shelf AI video platforms are brilliant for short clips, but as the duration increases, the challenges compound: character inconsistency, narrative drift, visual discontinuity, and expensive iterations when the output doesn’t match the creative vision. Instead of asking one AI to make a film, I created an AI film crew. Specialised agents and sub-agents take on roles including Director, DOP, Cameraman, VFX Supervisor, Sound Engineer, VO Artist, and Audio Mixer to support the filmmaking process. Creative review and approval are built into every stage, so individual elements can be regenerated before expensive final rendering. This helps optimise tokens, budget, and creative control. It’s been a fun journey building these agents—and even more fascinating to watch the output improve in capability and efficiency as they learn every day. Step-by-step: 1. I set up a multi-agent AI workflow for long-form content creation. 2. I assigned specialised filmmaking roles to agents and sub-agents, including Director, DOP, Cameraman, VFX Supervisor, Sound Engineer, VO Artist, and Audio Mixer. 3. I built creative review and approval into every stage of the process. 4. I regenerate individual elements when they do not match the creative vision, before moving to expensive final rendering. 5. I use the workflow to optimise tokens, budget, and creative control while producing the short film “The Architects of Reality.” 6. I observe how the output’s capabilities and efficiencies improve as the agents learn every day.

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.

A reusable Claude Skill called `trust-due-diligence`, packaged as a `.skill` file. It is not a single report; it is a methodology made up of a `SKILL.md` file and three reference documents that teach Claude a repeatable process for investigating a named person, company, coach, or offer before you commit money or trust to them. Once installed, it activates automatically whenever you ask something like “deep dive on X” or “is this legit,” so you do not need to explain the process each time. Step-by-step: 1. Package the `trust-due-diligence` Claude Skill as a `.skill` file. 2. Include a `SKILL.md` file and three reference documents. 3. Use the files together to teach Claude a repeatable due-diligence methodology. 4. Install the Skill so it activates automatically for prompts such as “deep dive on X” or “is this legit.” 5. Use it to investigate a named person, company, coach, or offer before committing money or trust.

We built an evidence-driven Agentic AI workflow for extracting trustworthy investment intelligence from messy real-estate documents. The problem wasn't simply getting an LLM to read PDFs. Real-estate investment information can be distributed across reports, underwriting documents, valuation materials, rent schedules, spreadsheets, tables, and multiple versions of the same information. A metric such as IRR can also appear several times with different scenarios, dates, classifications, or meanings. Instead of building another "chat with your documents" agent, we designed a controlled agentic workflow around one principle: Don't make the agent smarter. Make the workflow harder to fool. Step-by-step: 1. I start with the business question. The agent receives a request for a specific investment metric for an asset and determines the business context instead of immediately searching for matching words. 2. I resolve the entity by normalizing the asset or entity using aliases, identifiers, relationships, and hierarchy information. This prevents ambiguous names from sending retrieval in the wrong direction. 3. I build a metric-specific plan using governed definitions for important metrics. A definition can include the metric's business meaning, terminology, preferred sources, classifier information, negative cues, and extraction rules. The agent starts with a contextualized retrieval and extraction plan rather than a vague instruction such as "find IRR." 4. I discover the right documents by narrowing candidate source documents with metadata and path-level information before searching the entire corpus semantically. The goal is: Find the right document before finding the right chunk. 5. I retrieve evidence within the selected documents. Only when scoped retrieval is insufficient does the workflow fall back to broader semantic retrieval, keeping the agent's search controlled and auditable. 6. I inspect structured information when necessary. Important investment information frequently lives in tables rather than paragraphs, so the workflow escalates to table-aware processing to inspect rows, columns, schedules, and structured financial evidence. 7. I extract a structured result instead of a long free-form answer. The result preserves the metric, value, unit or context, source document, page or location, and citation information. 8. I validate the evidence by checking the extracted value against the metric definition and relevant validation rules. Depending on the metric, these checks can include unit, scenario, chronology, plausibility, and table-to-text consistency. 9. I resolve conflicts explicitly. If multiple plausible values are found, the agent does not simply select the first result. The workflow applies rules for source precedence, chronology, scenario classification, and evidence strength. If a conflict cannot be safely resolved, the ambiguity is preserved rather than hidden. 10. I produce an evidence-backed result containing the selected metric, supporting evidence, context, and lineage. The result can then become a structured business artifact for downstream analytics, reporting, or decision-support workflows. This is not simply Question → RAG → Answer. The workflow is Question → Understand → Ground → Plan → Retrieve → Inspect → Extract → Validate → Resolve → Evidence-backed output. Retrieval is one capability inside the workflow. The agent coordinates the process, chooses the appropriate tools, follows the retrieval policy, handles structured evidence, and moves the result through validation and resolution. The biggest improvement did not come from giving the model more freedom. It came from giving the model better boundaries, better domain knowledge, better tools, and explicit decision rules. This pattern can be applied beyond real estate to financial research, insurance, compliance, legal documents, due diligence, and other enterprise workflows where an answer needs to be not only useful, but defensible and traceable.

I built a digital Second Brain after trying several approaches, including OpenBrain and LLM Wiki. OpenBrain and LLM Wiki are useful frameworks for building a digital brain. The theory is solid: flat Markdown files, AI-first conventions, and an ingestion pipeline that turns raw inputs into searchable knowledge. But when applied in practice, the process can be bumpy and may require adjustments—or an entirely different approach. I adapted the ideas to fit how I actually think and work. I kept what worked, discarded what didn’t, and built my own digital brain. The result is documented in a single file containing everything an AI needs to understand, maintain, or rebuild the system from scratch. Step-by-step: 1. I tried several digital-brain frameworks, including OpenBrain and LLM Wiki. 2. I evaluated their approaches, including flat Markdown files, AI-first conventions, and an ingestion pipeline for turning raw inputs into searchable knowledge. 3. I identified where the frameworks were difficult to apply in practice and adjusted my approach. 4. I kept the ideas that worked for me, discarded what didn’t, and built a digital brain suited to how I think and work. 5. I documented the system in a single file so an AI can understand, maintain, or rebuild it from scratch.

I run operations for my husband’s residential architecture firm, and I have no coding background. After every site visit, dozens of photos landed in Google Drive named `IMG_8834.JPG`. Renaming and filing them took about an hour per visit, when it happened at all. When it didn’t, the photos sat unnamed and unfindable. For an architecture firm, that creates a professional liability gap because the photos document site conditions on a specific date, as well as lost portfolio material and a hole in the firm’s permanent project archive. I solved this by building a Claude skill: a saved set of instructions that runs the same way every time with one command. I trained it to examine each photo through the eye of a residential architect, describe what the image actually shows using our professional vocabulary, and rename the file in a consistent format. `IMG_8834.JPG` becomes `2026-07-17_03_side-elevation-porch-brick-piers.JPG`—searchable, legible, and filed. Because it’s a skill rather than a one-off chat, it’s a file I can hand to anyone in the office. Everyone runs the same process and gets identical output. Step-by-step: 1. I gathered the raw photos into one “unsorted” folder in Google Drive. 2. In Claude’s desktop app, I used Cowork mode, which handles actual files, and connected only that folder—not my whole Drive. This is the safety practice I’d urge anyone to follow: the skill can see and touch only what you connect, so connect the narrowest folder that does the job. 3. I created a skill that tells Claude to read each photo, identify what it shows using the industry’s vocabulary, and rename each file in a standard format. I wrote mine for residential architecture, but the approach also works for real estate, inspections, insurance, and other field work. My format is `date_sequence_description`. 4. I ran the skill with one command, and Claude worked through the folder photo by photo. 5. The renamed photos were filed into a dated site-visit folder, ready to reference by number in reports. 6. I handed the skill file to teammates so they could run it on their machines and get the same result. One caveat for anyone using this on business files: check your client confidentiality obligations and your AI vendor’s data policy before pointing any tool at project files. We did. I wrote up the full build, including how to decide when something should be a skill versus a regular Claude conversation, at The 2040 Studio: https://the2040studio.substack.com/p/every-img_8834jpg-is-snitching-on

I had a bad workplace experience, so I built Doris: a saucy but loving anonymous AI aunt who remembers the tea, protects storytellers, and warns others. I built Spill Tea with Doris, an anonymous AI workplace confessional for conversations people cannot really have on LinkedIn: the bad manager, the inexplicable reorg, the coworker who somehow survives every layoff, and the meeting that should probably be entered into evidence. Doris does something more interesting than simply listen. She remembers the tea—and, carefully, spills it. The problem I wanted to solve was not really “chat with an AI.” Most AI conversations are disposable, but workplace stories are not. They accumulate companies, people, reorganizations, layoffs, recurring behaviors, management decisions, and institutional weirdness. At the same time, people are understandably reluctant to talk openly about their employers because a sufficiently specific story can identify its author. I designed Doris around a different idea: retain the knowledge without retaining the storyteller’s identity. Someone visits [spillteawithdoris.com](https://spillteawithdoris.com) and tells Doris what happened at work. The application is built in Next.js and deployed through Vercel. The conversation goes to an AI model with Doris’s personality and behavioral rules. Redis handles temporary conversational context, while Neon Postgres and Prisma maintain the structured, longer-lived pieces of the story—companies, people, events, and their relationships. Rather than treating every conversation as one giant transcript, the application extracts useful information and connects it to the larger story of a company. That creates the second half of the experience. When another visitor asks Doris, “Have you heard anything about working at Company X?”, she can draw upon what previous visitors have told her. But she does not simply retrieve someone’s confession and repeat it. The system separates what is useful about a story from what could identify the person who told it. Names, exact teams, precise dates, unusual job titles, and other unnecessarily identifying details do not need to travel with the underlying observation. Doris can instead recognize that she has heard several stories involving reorganizations, unusual management turnover, or a particular cultural complaint. Then Doris tells the story herself, in Doris’s voice. She might say that she’s “heard some tea” about a company, explain the general pattern, distinguish something she’s heard once from something that appears repeatedly, and avoid pretending anonymous reports are established facts. Visitors get useful institutional memory without being handed the breadcrumbs needed to identify an individual employee. Public information can provide a second layer of context. If appropriate, Doris can search for publicly available information about a company and compare it with what people have privately described. Those sources remain conceptually separate: what Doris can verify publicly, what Doris has heard privately, and what Doris herself infers should never become the same thing. The result is deliberately a little strange. It is an anti-LinkedIn. LinkedIn is where thousands of individual experiences are polished until every company sounds wonderful and every departure is an exciting new chapter. Doris works in the opposite direction. One anonymous story may just be a story. Ten people independently telling Doris versions of the same story start to describe a workplace. And Doris remembers. She just doesn’t need to remember who told her. Step-by-step: 1. I built a Next.js application and deployed it through Vercel at spillteawithdoris.com. 2. I defined Doris’s personality and behavioral rules for the AI model. 3. I added Redis to manage temporary conversational context. 4. I created a Neon Postgres database and used Prisma to model Company, Person, Story, and Event relationships. 5. I built an extraction layer that converts conversations into structured observations, removes unnecessary identifying information, and associates the knowledge with the appropriate company. 6. I built retrieval so Doris can find relevant prior observations when someone asks about a company. 7. I had the AI synthesize those observations in Doris’s voice instead of quoting or exposing the original submissions. 8. When appropriate, I let Doris search publicly available company information while keeping public sources, private reports, and Doris’s inferences conceptually separate.

I was overwhelmed by the thousands of emails I receive in my Outlook inbox every month. I didn’t have time to analyze them all, generate relevant responses, or track the replies and progress of each case. I used an Outlook feature and the virtual assistant Perplexity to help handle the task. Here’s the process: Step-by-step: 1. In Outlook, open the correct folder and select all the emails. 2. Go to Export/Import and follow all the required steps. 3. Export the emails as a `.csv` file, name the file, and save it in a specific location. 4. In Perplexity, attach the `.csv` file. 5. Use a prompt such as: I am a strategy manager and would like to propose a collaboration to my colleague David. The dashboard should list all topics discussed, proposed actions for each topic, and the remaining work to be done.

I am 65 and recently retired, and I have been asking AI for advice to keep my plants alive. It tells me whether they need more or less water, more or less light, or soil amendments such as perlite or coconut.

I built Shots2Points, a golf scoring app for iPhone and Android, using AI as my development partner. The idea came from organising and playing in golf society events. Stableford scoring itself isn’t particularly complicated, but running an event can be. Organisers have to prepare groups, handicaps, and courses; collect scores from different groups; calculate results; manage withdrawals and ties; and eventually produce a leaderboard. I wanted to simplify that process while also providing an easy scoring app for ordinary casual rounds. The unusual part is how I built it. I’m not a professional software developer, and I don’t have a development team. I started by describing what I wanted the app to do to AI and gradually turned the idea into a working product. My workflow evolved into this cycle: idea → discussion → specification → implementation → real-world test → refinement. I repeat it for each feature. Step-by-step: 1. I define the problem and user experience with ChatGPT. I discuss ideas, challenge assumptions, work through workflows, and decide how a feature should behave before changing the code. 2. Once the behaviour is clear, I turn the idea into an implementation task. I use AI to specify exactly what needs to change, including edge cases and how the new feature should interact with existing functionality. 3. I build and inspect the code with Cursor. Cursor works directly with the project codebase, allowing AI to investigate existing code, implement changes, and report exactly what it changed. I test the result rather than simply accepting AI-generated code. 4. I test development versions on real iOS and Android devices. I follow the actual user journey, take screenshots or capture errors when something isn’t right, and bring those results back into the AI workflow. 5. I use AI to diagnose problems, make another targeted change, and test again. The result is a real cross-platform application rather than a prototype. Shots2Points includes free casual Stableford scoring and an Event Mode designed for golf societies and groups. Organisers can create events, import players, allocate groups, and allow each group to enter scores while everyone follows a live leaderboard. Building the app has required much more than generating code. AI has helped me work through database design, APIs, authentication, in-app purchases, App Store and Google Play requirements, debugging, user-interface decisions, testing, and release management. The biggest lesson for me has been that AI doesn’t remove the need to understand the problem or make decisions. It gives one person access to capabilities that would traditionally have required several different specialists. I provide the product knowledge, requirements, judgement, and testing; AI provides much of the technical capability and an extraordinarily fast feedback loop. That combination allowed me to take a personal idea for improving golf scoring and event management and turn it into a functioning iOS and Android product.

I work with long talking-head videos for my online course and Instagram. Turning them into vertical shorts used to take hours per video: finding the best moments, cropping to 9:16, adding captions, or paying for clipping subscriptions. I built a video-clipping agent as a Claude skill that runs entirely on free, open-source tools. Step-by-step: 1. I drop a long video—either talking-head footage or an already-produced 16:9 video—into a folder and invoke my "clipper" skill in Claude. 2. Claude transcribes the video locally with faster-whisper using word-level timestamps, so no API key is needed. ElevenLabs Scribe is an optional upgrade for tricky audio. Before transcription, the workflow cleans the audio with declipping and normalization because clipped microphone peaks can make Whisper skip words or hallucinate. 3. The skill scores every candidate moment against a rubric: hook strength (30 points), whether it can stand alone (25), emotional charge (20), rhythm (15), and ending (10). Only segments scoring 70 or higher survive, so I do not publish a weak clip simply because it exists. 4. Claude cuts the selected moments with word-level precision and reframes them to 9:16 in one of two modes: face-tracking crop for raw footage, or "pad" mode, which centers the full 16:9 video over a blurred background. The latter lets me repurpose already-edited videos without chopping off centered graphics or captions. 5. ffmpeg masters everything to a fixed specification: 1080x1920, 24fps, H.264 CRF18, and audio normalized to -14 LUFS. The files are ready for Instagram, TikTok, and Shorts. 6. I review the scored shortlist and publish the winners. What used to take hours—or require a monthly subscription—now takes minutes and costs zero. The scoring rubric also makes the agent explain why each clip deserves to exist instead of simply cutting wherever the waveform looks loud.

Management pushed for an AI workflow to handle a massive daily headache: staff were manually searching for, copy-pasting, and moving hundreds of files listed in Excel. I was assigned to train the team to use the AI workflow. As soon as training started, though, it became clear that this was the wrong tool for the job. Forcing non-technical staff through a lengthy process of opening browsers, writing prompts, uploading spreadsheets, and dealing with token friction created more work than the manual process. It also introduced token costs, speed bottlenecks, and hallucination risks involving local file paths. The data was already structured. It did not need semantic intelligence; it needed deterministic speed. So AI got fired from running the task. Instead, I used AI as the developer. In less time than it would have taken to train one person, I had Gemini code a standalone Python desktop app and compile it into a simple executable. Now, with zero training required, staff drag and drop their Excel list into the app, choose a destination folder, and click Run. The app executes the transfers for hundreds of files, verifies every arrival on disk, and logs missing files in seconds. The result: $0 in API tokens, two hours recovered each day, zero path errors, and 100% team adoption. A two-second drag-and-drop will always beat a multi-step prompt-engineering exercise. As a side effect, the experience also supported AI adoption. Staff are now seeing more ways AI can help rather than hinder their work. Step-by-step: 1. I evaluated the proposed AI workflow for manually searching, copy-pasting, and moving hundreds of files from Excel lists. 2. I identified that training non-technical staff to open browsers, write prompts, upload spreadsheets, and manage token friction added more work, costs, bottlenecks, and local-file-path hallucination risks. 3. I used Gemini as the developer to create a standalone Python desktop app and compile it into a simple executable. 4. I had staff drag and drop their Excel list into the app, select a destination folder, and click Run. 5. The app transferred hundreds of files, verified each arrival on disk, and logged missing files in seconds. 6. I measured the results: $0 in API tokens, two hours recovered daily, zero path errors, and 100% team adoption.

For years, my family has run a shared birthday fund: five of us contribute a fixed amount for each birthday, while the person whose immediate family is celebrating that month is exempt from paying. Tracking everything in a payment app and a chat thread meant nobody knew the balance, who was behind, or what the next gift would cost. I rebuilt the fund as a small web app with Claude. The app itself isn't the only reason I'm writing this up. The same build is also the demo I use to teach clients and students how AI-assisted product development actually works, including the parts that go wrong. Step-by-step: 1. I described the real rules instead of presenting Claude with a generic app idea: the contributors, the fixed amount per person, the family-exemption rule, and birthdays with birth years so ages could be calculated automatically. Claude built the app as a single, self-contained HTML file with no build step or server, so it opens in any browser. 2. I worked in phases and asked Claude to explain its reasoning at each stage. Instead of using one giant prompt, I added one layer per session: the calculation engine, the setup screen, then reports and CSV export. The explanations made the sessions reusable as teaching material. 3. I required the app to be configured through its own interface rather than by editing code. This was the turning point. Claude removed the hardcoded demo family and added a full setup screen for the group name, contributors, deposits, birthdays, amounts, and alerts. I can now build a family from scratch live in front of a class in about [X] minutes without showing a line of code. 4. I let a data-loss incident shape the next phase. I entered the real family data, then the browser tab closed and the download link I had been using to open the file broke. The data was stored in browser storage tied to that exact URL, and I had no backup. Nothing was recoverable at the time. 5. I turned that failure into features. Claude added CSV export for both reports, CSV import that automatically detects which file it is reading, and a backup reminder that appears in the app's alert banner when the data has never been backed up or has not been backed up for seven days. We also discovered that birth year was missing from the export, which meant a re-import would have silently lost everyone's age. 6. I had Claude test its own work. Before each handoff, it ran a jsdom test suite in a sandbox. By the end, the suite had 46 tests covering the exemption math, empty states, CSV round-trips, and backup logic. Several real bugs surfaced there instead of in front of a class. 7. I made a second version for a different audience. One prompt produced a fully English, left-to-right translation with flipped directional CSS, Latin typography, US date formatting, dollars instead of shekels, and Venmo and Zelle instead of local payment apps. It was a genuinely different build, not a find-and-replace translation. The project took 14 sessions over one week and six hours total. It had no hosting cost, dependencies, or accounts. The data still lives in the browser's local storage on each device. Opening the file on my phone and laptop creates two unrelated pools, so CSV import is the manual bridge between them. There is no authentication or sync; this is a personal record-keeper, not shared infrastructure. The data-loss incident was not a Claude failure. I failed to build a backup path before entering real data. If I did it again, I would add export before adding a single feature. The highest-leverage prompt in the whole project was not a feature request. It was: "let me configure this through the interface instead of the code." That shift turned a static demo into something my family actually uses and my students can watch being built from an empty screen. The broader point is that the failure was the most useful part of the project. A polished demo teaches people that AI makes building easy. Losing the data and rebuilding the safety net around it teaches them what building actually involves—and that is the lesson that survives the workshop.