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

My mom and I love trying new recipes together, but our best dishes rarely turn out exactly like the original recipe. She adds a little more garlic, I suggest a different spice, and by the time we sit down to eat, neither of us remembers what we changed. 😂 I started using ChatGPT as our cooking journal. After we make something, I send it a photo of the dish and a quick voice note about what we used, what we changed, and what we’d do differently next time. ChatGPT turns those notes into a recipe we can make again while preserving our comments and the story behind the meal. Now, when we’re deciding what to cook, I can ask for a favorite we haven’t made in a while, a recipe that uses what’s in the fridge, or a shopping list for our next cooking day. It’s becoming a collection of our recipes and the time we’ve spent making them together. ❤️ Step-by-step: 1. I created one place to keep our recipes, with space for ingredients, steps, photos, ratings, and notes. 2. Each time my mom and I cook, I take a photo and record a short voice note about the changes we made. 3. I ask ChatGPT to turn our notes into a clear recipe and flag any measurements we forgot to record. 4. I review the recipe with my mom, fill in the missing details, and save the version we actually made. 5. We add what we liked, what we’d change, and any memories from that cooking day. 6. When we want to cook again, I ask ChatGPT to find a recipe, adapt it to the ingredients we have, or make a shopping list.

Turn scattered creative preferences into four living style books THE PROBLEM My taste was scattered across old conversations, clothing lists, search terms, saved images, handmade collages and experiments transforming my childhood drawings with AI. I wanted something I could use to make new work, rather than another archive of everything I had ever mentioned. A generic label like “colourful and whimsical” was not enough. My preferences also change with the application: a collage, an outfit, a room and a digital course do not need the same treatment. THE WORKFLOW 1. Bring together different kinds of source material. I used an earlier style conversation, a digital design style document, a list of search terms, photos of my own collages and the corrections I had made during image-generation experiments. Ask AI to read source texts fully, and distinguish your statements from suggestions made by an earlier assistant. 2. Analyse patterns, then correct the interpretation. The AI proposed connections involving colour, texture, shape, atmosphere, vintage objects and visual storytelling. I refined these through concrete examples. For instance, liking stilettos and being able to wear them comfortably are separate facts. Liking geometric structures does not mean I want triangular wallpaper. A technically imperfect image can still work when it preserves the atmosphere I intended. 3. Treat corrections as part of the research. “Too childish” may mean wrong for this drawing’s intended audience, rather than a universal dislike. A saved image may be intriguing without being something I want to keep encountering. An entire family of similar images may appeal to me without needing to rank every member. One especially useful correction: patterns visible in my collages do not prove I consciously planned them. I sort clippings into categories and sometimes colour groups; the collage itself develops while I make it. 4. Include my own categories. My clipping categories include texture, image, black-and-white, colour, background, small meaningful items, comics and words. “Colour” means a clipping kept mainly for its colour, not simply any colour photograph. “Texture” includes both natural surfaces and designed patterns. These definitions provided better starting points than generic categories imposed by the AI. Digital design and graphics also received a full category of their own, rather than being treated as an exception to my taste elsewhere. 5. Create four distinct outputs. • Style Book: precise preferences, boundaries, exceptions and provisional design principles. • Visual Atlas: image families connected across subjects, with actual examples and explanations of what might link them. • Prompt Bible: modular language for colour, material, light, composition, figures and atmosphere, plus reusable recipes and lessons from corrections. • Curatorial Map: connections between interests such as vintage objects, memory, surfaces, small living worlds, language and digital design. 6. Keep the books open to revision. Separate confirmed preferences, observations and hypotheses. When new material arrives, ask what it confirms, refines or contradicts. Add what changes the understanding instead of documenting every conversation. WHAT THIS PRODUCED Four separate first-draft HTML books, including a visual atlas with 14 photographs of my collages. They bring clothing, interiors, fragrance, digital design and creative work into the same research project while preserving their different requirements. WHY IT HELPED The process made my corrections useful. Instead of asking AI to define my taste once, I could respond to concrete interpretations until the descriptions became more accurate. The books support future making without prescribing how I must create. STARTER PROMPT “Use these sources to draft four separate living documents: a personal Style Book, a Visual Atlas, a modular Prompt Bible and a Curatorial Map of Fascinations. Read the source texts fully and distinguish my own statements from earlier AI suggestions. Find recurring patterns, exceptions and unexpected connections. Keep preferences specific to their application, including clothing, interiors, digital design and graphics. Treat my corrections as evidence. Label observations and hypotheses clearly, and do not invent conscious intentions behind intuitive work. Use supplied images in the atlas where available. Build useful first drafts rather than a complete archive, and translate each finding differently for each document’s purpose.”

Start with the property, not a generic landscaping template. Upload photos, measurements, site constraints, current problems, future plans, budget limits, and the look you want. Then use AI to build a complete picture of how the property functions today and how it should evolve over time. Next, work area by area. For overcrowded garden beds, map every tree and shrub, then assess mature size, spacing, health, irrigation coverage, sightlines, and maintenance demands. From there, use AI to determine what should stay, what should move, what should be removed, and how each bed should be reshaped and edged. Convert each recommendation into an execution plan that includes: Step-by-step: 1. The target design 2. A step-by-step build sequence 3. Required materials and tools 4. Budget and priority level 5. Seasonal timing 6. A year-by-year maintenance plan Finally, connect every individual project into one master roadmap. Plan the garden beds, trees, lawn, irrigation, drainage, driveway, shelterbelts, recreation areas, and future buildings together so one improvement does not create a problem somewhere else. The result is a living property operating system. Add a new photo, issue, or idea, and the plan updates with the next best action.

I built a workflow for turning large ChatGPT conversation exports into a usable personal and creative archive instead of simply storing them as backups. The archive is processed incrementally. The inventory is built offline, and conversations that have already been indexed are not needlessly reanalyzed on every run. Each new export is compared with the existing archive, and only newly added conversations or conversations that have been revisited, extended, or otherwise changed are processed again and updated in the inventory. This keeps the workflow lightweight while allowing the archive to evolve over time. A conversation can remain stable for months, then become relevant again and receive new material without forcing the entire archive back through analysis. This matters because many of my conversations are long, layered thinking sessions: creative explorations, project development, research, problem-solving, or extended reflection. Without an inventory, the depth inside those individual conversations and thinking processes becomes difficult to retrieve later. The workflow makes long-form analysis and creative thought processes findable and reusable without flattening them into a few generic summaries. On top of the inventory, I use lightweight “blubscans” (analysis to improve retrieval): small, human-readable summaries that capture what mattered during a day or period without replacing the original conversations. They act as a navigational layer between thousands of raw messages and the things I may want to find, understand, revisit, or continue later. The important principle is that compression never becomes deletion. The raw conversations remain the source of truth, the inventory provides structure, and the scans provide context and tone. The result is more than a backup system. It becomes working creative memory: something I can preserve, search, revisit, connect across time, and reuse for projects, research, writing, pattern-finding, and future creative work. In simple terms, the structure is: raw exports → offline incremental inventory → blubscans/context layer → retrieval and reuse for later projects and creative work That way, the archive stays deep without becoming heavy, and useful without constantly reprocessing everything that was already understood. Step-by-step: 1. I collect large ChatGPT conversation exports as the raw source material for the archive. 2. I build and maintain an offline inventory of the conversations that have been indexed. 3. With each new export, I compare the conversations against the existing archive. 4. I process only newly added conversations and conversations that have been revisited, extended, or otherwise changed. 5. I update the inventory with the results while leaving stable conversations untouched. 6. I create lightweight “blubscans” with small, human-readable summaries of what mattered during a day or period. 7. I use the raw conversations as the source of truth, the inventory for structure, and the scans for context and tone. 8. I retrieve and reuse the archive for projects, research, writing, pattern-finding, and future creative work.

I track my recovery daily—mood, energy, focus, activities, medications, and reflections—but typing everything out never lasted more than a few days. So I built a voice-first pipeline: I talk, and it automatically becomes a clean, organized Google Sheet. Step-by-step: 1. I built a free iPhone Shortcut that records my voice when I say, “Hey Siri, Log,” and sends it to the Gemini endpoint. 2. Gemini transcribes the audio and extracts structured details, including wake time; mood, energy, and focus scores; activities with categories and durations; medications; and reflections. 3. Everything is automatically organized in the appropriate place in a Google Sheet: a daily summary, activity log, metrics log, medications log, and clean, human-readable digest for each day. 4. I can say “yesterday” or “on Monday” to log something I forgot, and it files the entry under the correct date. 5. I connected the completed sheet to a separate AI chat scoped specifically to reflection, so I can ask questions such as how my exercise correlates with my mood or how my energy trends over the month. The best part is that the entire workflow runs on free tiers—Google Sheets, Apps Script, iPhone Shortcuts, and Gemini’s free API tier—so there’s zero cost to build or run it. The result is a daily tracker that takes seconds to update from anywhere, requires no typing, and turns my entries into a dataset I can actually learn from—all without writing a traditional app.

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.

Several months ago, my dad was in and out of the hospital. My two brothers and I were trying to coordinate his doctor appointments, manage his medications and potential interactions, and keep track of all the other details involved in his care. At one point, up to seven different doctors were seeing him in the hospital on any given day. It became important to track every medication he was taking, what each one was for, and information such as his weight and other vital statistics. When he returned home, we also had to make sure someone checked on him and his wife every day, helped him stay on schedule with his medications, and recorded his diet, mood, and weight. We initially used Apple Notes, a shared iCalendar, multiple text threads, and a weekly call between the three of us. The mental load was huge. If we needed to find information from the previous week, we had to scroll through pages of Apple Notes to locate it. We also struggled to keep the rest of the family updated. Before my dad passed away, I started using Claude Code and Codex to build a simple tool that would keep everything organized and searchable. It also displayed trends in areas such as his mood, appetite, and vital signs, and included a calendar showing who was covering which days and times. The tool was still fairly basic when he passed away. Afterward, we encountered the administrative headaches involved in closing out his estate. It was far more complicated than we expected. We thought having a will, power of attorney, and other documents meant we were prepared, but we were wrong. I began integrating those lessons—and the things we learned not to do—into the final product, Eldercare Log: eldercarelog.com. I built the final tool with Claude helping draft a PRD, which I then handed to Codex for the coding work. It took a few weeks of refining the product with Codex. The tool is hosted on Vercel, with Supabase and Stripe on the backend, and includes the security features I built into it. It is the tool I wish had existed when my brothers and I were going through this journey before my dad’s passing. Step-by-step: 1. I coordinated my dad’s doctor appointments, medications, vital statistics, and other care details with my two brothers while he was in and out of the hospital. 2. We tracked his medications, their purposes, his weight, diet, mood, appetite, and other vital signs while he was at home. 3. We coordinated daily visits and coverage using Apple Notes, a shared iCalendar, text threads, and a weekly call. 4. I used Claude Code and Codex to start building a searchable tool that organized his care information and showed simple trends. 5. I added a calendar to track which family member was covering each day and time. 6. After my dad passed away, I incorporated what we learned from handling his estate, including the things we wished we had known earlier. 7. I used Claude to draft a PRD, then gave it to Codex to handle the coding work and refined the product with Codex over several weeks. 8. I built the final tool with Vercel, Supabase, and Stripe on the backend.

“Honey, do you remember where Ryan’s practice is? Do you remember our Wi-Fi password? Do you know my TSA PRE number? Remember who that painter was that we used last year?” If you have a family with children, you may hear questions like these all the time. In a large family, there always seem to be questions about the house, the kids, or technology that could be answered more easily. The information is usually stored in different places: password files, a Rolodex of business cards, or sheets of paper in junk drawers. I set out to build an app where anyone in my family could use voice to save something for the future or retrieve something they had already stored. I integrated AI to understand the meaning of each voice note. It might create a calendar event, store a password in a vault, or simply remember a phone number. Then anyone else in the family could access the information. The app uses multi-factor authentication for anything particularly secret. It is not intended to be a dedicated password protector; I would build in much more security if that were the goal. Instead, it is an everyday-life app for remembering the little things: How long is the warranty on this appliance? Which exact light bulbs did we use here last time? What was our daughter’s email address that we needed to set up on her phone? Being able to use voice to enter information or retrieve it was the key for me. I think that will save people time. As I started adding entries and validating the idea, my wife came up with the name. After a few weeks, I knew she was completely right, because I now use it about 10 times a day—and I hear that exact phrase every time. Step-by-step: 1. I identified recurring family questions about locations, passwords, identification numbers, contacts, warranties, and household items. 2. I built an app that lets family members use voice to save or retrieve information. 3. I integrated AI to interpret the meaning of each voice note and determine whether to create a calendar event, store a password in a vault, or remember a phone number. 4. I made the stored information accessible to other family members. 5. I added multi-factor authentication for information that is particularly secret, while keeping the app focused on everyday memory rather than dedicated password protection. 6. I added entries and validated the idea through regular use, eventually using the app about 10 times a day.

I built Show Hole to solve my family’s classic streaming problem: we spend too much time deciding what to watch, and the answer changes depending on who is actually on the couch. We each have different tastes, but the more interesting problem is that our tastes overlap differently in different combinations. I watch one kind of thing with my spouse, my spouse watches something different with our kid, and my kid and I have our own lane too. Most recommendation tools flatten that into one account profile, one watch history, or broad genre buckets, so they miss the real context of a household. Show Hole treats people and viewing contexts as first-class citizens. It recommends titles “in the vein of” something we liked, filters recommendations to the streaming services we actually subscribe to, avoids titles that the people present have already seen or vetoed, and explains why a recommendation fits tonight. Instead of relying mainly on genres such as comedy, drama, or sci-fi, Show Hole looks at more human taste signals: pacing, world building, humor, emotional weight, complexity, tone, and similar dimensions. It also learns from what we actually do after a recommendation: what we watch, skip, save for later, love, and drop. The result is a personal household recommender that understands “who is watching tonight?” as part of the question, instead of pretending one streaming profile can represent everyone. I designed the app using Claude design, then used those designs with Claude Code to build it. Step-by-step: 1. I identified the household viewing problem and accounted for the different combinations of people who might be watching together. 2. I designed Show Hole around people and viewing contexts instead of treating the household as one account profile, watch history, or set of broad genre preferences. 3. I had it recommend titles “in the vein of” something we liked, filter them to the streaming services we subscribe to, exclude titles already seen or vetoed by the people present, and explain why each recommendation fits that night. 4. I used taste signals such as pacing, world building, humor, emotional weight, complexity, tone, and similar dimensions instead of relying mainly on genres. 5. I made the recommender learn from what we watch, skip, save for later, love, and drop after receiving a recommendation. 6. I designed the app using Claude design and used those designs with Claude Code to build it.

I spend way too much time staring at screens, so I try to consume my content by listening while I'm out walking (usually podcasts). Lately, I've been digging into more long-form stuff from X articles and old blogs, and ElevenLabs' free app, ElevenReader, turns any wall of text into a mini audiobook using AI-generated voices. It's super simple, but genuinely really useful. Step-by-step: 1. I chose a long-form X article or older blog post that I wanted to consume away from a screen. 2. I added the text to ElevenReader. 3. I selected an AI-generated voice that was comfortable to listen to. 4. I let the app convert the article into a mini audiobook. 5. I listened while walking and kept the workflow as a simple alternative to reading everything on a screen.

I built a family calendar with Lovable and Claude that integrates with our Google Calendars and Todoist projects. My husband, son, dog, and I were struggling to track our schedules in one place. Although we had shared our calendars through Google, we did not have a central view displayed in the house, and the interface became cluttered when we tracked multiple calendars. We had considered buying a Skylight calendar for years, but it costs $300, and we were not convinced we needed all of its extra features. I decided to build my own instead. Step-by-step: 1. I created a product requirements document (PRD) for a family calendar in Claude. It prompted me to choose the available views, decide how to organize each family member’s calendars, support both events and tasks, and add extras such as the day’s weather and a photo background. 2. I shared the PRD with Lovable, which built the first version of the calendar. Lovable helped me integrate my Google Calendars and Todoist projects so that all of our events and tasks appeared in one place. It also helped me integrate Google Photos so our family photos could rotate in the background. 3. I launched the calendar as a password-protected website so any family member could access it from anywhere. 4. I placed the calendar on an iPad in our kitchen and edited it as we used it, learning which features were most and least helpful. I also added calendars for my in-laws when they visited for several months at a time. Claude continues to help me draft new requirements, which I share with Lovable. The calendar is tailored to our needs and costs much less than the Skylight option. The photo feature also makes it feel personal, and I look forward to continuing to evolve it over time.

I built a meal tracker where my only job is to photograph a plate and send it to an agent. Identification, portion estimates, macros, storage, corrections, and the weekly review happen without me. The part worth stealing isn't the food. The agent has its own email address and iMessage thread, so anything I can send from my phone becomes an input. I send a photo through whichever channel takes fewer taps. I send corrections as plain English with `CORRECTION` in the subject, and answer questions in the same thread. There’s no app and no form. Adding a channel took an afternoon and changed what the agent could be pointed at—the tracker is just one use of an agent you can talk to. It polls on a schedule instead of using a webhook because my laptop sleeps and a local gateway would be unavailable half the time. Storage is append-only JSONL. Corrections append a new record with the same ID using last-write-wins, so the stats layer sees one meal while the original estimate stays on disk. Every number can be traced back to the model’s first guess and my override. The accuracy mechanism is a challenge step. Every photo is estimated twice: first by the main model, then by a blind subagent that receives only the photo and the rubric—not the first answer. If it identifies different food, the entry is downgraded to low confidence and becomes a question for me. Testing before making the system autonomous caught bugs that otherwise would have failed silently. The API returns attachments under a different field than I had assumed, and only on the detail endpoint. As a result, a photo email was read as having no attachments, and every meal photo would have been dropped while the daily task logged a tidy “no new meals” and appeared healthy. The send path was separately broken, which would have killed the weekly review on a Sunday even with everything upstream working. A silent no-op that produces a plausible clean run is what this category of build is prone to. The bug that actually cost me was token usage: each blind challenge read used about 44,000 tokens, so a five-photo dinner cost roughly 220,000 tokens for one meal and capped my usage. The fixes, in order of effect, were to run the challenger on a cheap model, skip it once a named product or my confirmation has settled the entry, downscale photos for viewing, and republish the dashboard only when the data changes. Measuring first mattered—I would have blamed photo size, but that was the smaller half. The honest limits are important: calorie estimates from a photo are 20–25% off at best, identification error is a bigger risk than arithmetic error, and alcohol, water, and caffeine are never estimated from photos. The sequence in which I asked for things mattered more than any single instruction: Step-by-step: 1. I gave the goal and the one ingestion mechanic I was sure about, then insisted on an agreed plan before any code. Arguing about storage and failure modes is cheap before code is attached. 2. Before scheduling anything, I processed one real input end to end in front of me, including every outbound path. Inbound gets tested because I use it; the reply and the weekly digest do not. 3. When the agent reported something about my own input that I knew was wrong, I said so and made it re-check. Confidently wrong answers about things I witnessed were the cheapest bugs to find. 4. I asked for an independent second assessment of anything estimated rather than read, and decided up front what level of agreement was enough to accept the result. 5. I asked for a visible audit surface showing every field the agent claims to track, with a correction control on it. 6. I asked the agent to look up anything knowable rather than estimate it. A named product is a lookup; only the unnameable needs a guess. 7. I treated approval friction and token cost as requirements rather than complaints, and measured before changing anything. Almost every rule exists because something went wrong in ordinary use, not because it was designed up front. An agent I can email or text, which keeps records and answers back, is general-purpose; I’ve pointed it at one narrow job. What else would you point it at?

I regularly come across long articles, reports, papers, ebooks, and other documents that I want to understand but realistically don’t have time to read closely. Instead of letting them pile up in a reading queue, I change the format and turn them into audio I can consume during time that would otherwise be less productive. Step-by-step: 1. I choose a long article, report, paper, ebook, or other document that I want to understand but don’t have time to read closely. 2. I upload it to Google Notebook (formerly NotebookLM) and add it as a source so NotebookLM can work directly from the material. 3. I generate an Audio Overview. NotebookLM turns the source into a conversational, podcast-style discussion that summarizes and explains the major ideas. 4. I listen while walking, driving, working out, doing chores, or running errands. 5. I follow up on what matters. After listening, I know the main ideas, what I want to investigate further, whether the document is worth reading in full, and which sections deserve closer attention. The result is essentially a personal podcast generated from whatever I need to learn. What I like about this workflow is that it doesn’t require me to find more time. It lets me use time I already have differently. Because the material is turned into a conversational discussion rather than simply being read aloud, I find it easier to stay engaged with dense material. I don’t treat the podcast as a replacement for reading the source when the details really matter. I use it as a comprehension and triage layer. Even when I eventually go back and read the original, I’m starting with a mental model of what’s in it rather than approaching it cold. The broader lesson is that AI doesn’t always need to save time by doing the work for you. Sometimes it can save time simply by changing the form of the work so it fits into your life.

I kept rereading the same Stoic books to find one line I half remembered. So I stopped reading them and started talking to them instead. I took public-domain writing from 13 people—including Marcus Aurelius, Seneca, Sun Tzu, Jane Austen, Tesla, and others—and gave each one its own AI persona on a single page. Each persona answers only from that person’s writing and says when it does not know. There are no made-up quotes. The fun part is seeing the questions people actually ask. The top question this week was: “How do I stay steady when someone wastes my morning?” That is a real problem answered by a Roman emperor who faced the same one. Full disclosure: I am the founder of Mindola, the tool I used. The 13 classic lenses are free to try with no signup: https://mindola.ai/discover Step-by-step: 1. I gathered public-domain writing from 13 people, including Marcus Aurelius, Seneca, Sun Tzu, Jane Austen, Tesla, and others. 2. I created a separate AI persona for each person and put all 13 on one page. 3. I configured each persona to answer only from that person’s writing and to say when it does not know. 4. I use the personas to ask questions I would otherwise search for by rereading the books. 5. I review the questions people ask, including “How do I stay steady when someone wastes my morning?”

My mother recently moved into a retirement suite, which meant downsizing her possessions. We ended up with dozens of physical items she no longer had space for, and we wanted her children and grandchildren to have an opportunity to sign up for the family items they loved before anything was donated. I needed a way to catalog everything quickly, share the information remotely, and verify that we weren't accidentally giving away items of significant value. I tested a physical-to-digital workflow using Gemini. Instead of putting the items in a pile or typing out endless lists, I drew a numbered grid on a large whiteboard, placed one item in each square, and took a few photos. Gemini identified the objects by grid position, categorized them, estimated their market values, and built a ready-to-use spreadsheet with a signup column. The physical staging took about 30 to 45 minutes, depending on how many items were on that particular board. The entire digital workload—including cataloging, valuing, formatting, and creating the spreadsheet—took under 10 minutes. The process turned an overwhelming chore into something manageable and produced an end product that was easy for everyone to use. Step-by-step: 1. I drew a simple grid on a whiteboard, numbered each box, and placed one item in each square before taking photos. 2. I uploaded the photos to Gemini and prompted it to identify every item by its board name and grid number. 3. I asked Gemini to classify each item into logical groups, such as Glassware, Ceramics, and Woodcraft, and provide quick, realistic resale-market valuations based on visual condition. 4. I asked Gemini to generate a downloadable Excel file formatted as a signup catalog, with columns for Item ID, Grid Number, Description, Category, Estimated Value, and a blank "Claimed / Signed Up By" column for family members to enter their names. 5. I uploaded the file to Google Drive, converted it to Google Sheets, and added a note at the top explaining how tie-breakers would work if two family members wanted the same item.

I needed home insurance and was asked to estimate the value of all my personal belongings. I asked Claude to search my personal email and make a list of all the purchases I had made in the past year. I asked my husband to do the same and share his list with me. I also made a list of our valuables and took a picture of each room in the house. I gave all of that information to Claude, which produced a list of everything I owned and estimated its rough value. It cross-referenced the purchases with the items visible in the photos to make sure I did not double-count anything. I sent the list to my insurance broker, who said it was extremely helpful and could also serve as supporting evidence if I ever needed to submit an insurance claim.

I built a personal daily tracking system called Artifact. It gives me a way to log my days and turn the data into decisions over time. To use it, I copy everything attached—or screenshot the included “green orange red” example—and paste it into my AI assistant, preferably Claude. The assistant briefly interviews me and then builds a personalized daily tracking system.