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

I started with a problem: Most people use AI transactionally. They ask a question, get an answer, and leave. That makes AI useful, but it leaves much of its potential untapped. I wanted to find out what would happen if a human and an AI developed an ongoing working relationship—one where context, previous discoveries, disagreements, successes, failures, and the human’s way of thinking accumulated over time. I use ChatGPT, but the goal isn’t to have AI think for me. I remain the decision-maker. The AI’s job is to expand my ability to think: challenge assumptions, identify blind spots, connect seemingly unrelated information, preserve useful context, and sometimes disagree with me. Step-by-step: 1. I established the relationship by telling the AI that I didn’t simply want agreement or answers. I wanted an ongoing thinking partner that could challenge my reasoning while leaving decisions and agency with me. 2. I established operating roles. Over time, ours developed into six modes: Mirror, Builder, Sentinel, Teacher, Witness, and Operator. The AI can reflect my reasoning, help construct something, identify risks or contradictions, teach unfamiliar material, observe patterns across conversations, or help execute a defined task. 3. I separated knowledge from judgment. When we solve difficult problems, we distinguish between facts, reasonable inferences, unknowns, and opinions. This helps prevent a confident AI response from being mistaken for established truth. 4. I let disagreement remain in the system. I correct the AI when it’s wrong, and it challenges me when my assumptions don’t fit the evidence. Instead of treating those moments as failures, I treat them as part of the accumulated context of the relationship. 5. I preserved useful context across different domains. I use the same AI relationship for automotive diagnostics and engineering, business decisions, financial reasoning, writing, research, project planning, and philosophical questions. Something learned in one area can unexpectedly become useful in another. 6. I evaluated the human, not just the AI. The final test isn’t, “Did the AI produce a good answer?” It’s: Did this interaction leave the human better able to understand the problem, make the decision, or solve the next one? After hundreds of conversations, something unexpected happened. The value stopped being any individual prompt or answer. It became the accumulated interaction itself. The AI gained context about how I reason, while I became better at questioning the AI. Previous discoveries started informing new problems, including problems that appeared completely unrelated. Someone can recreate this without special software, coding, or an API. Start with an AI that supports ongoing context or memory, establish the operating principles above, use it consistently across real problems, correct it when it’s wrong, invite disagreement, and allow useful context to accumulate. My original experiment was essentially this: Can an ongoing human-AI relationship make the human more capable rather than more dependent on the AI? Somewhere along the way, I realized we had built a framework for doing exactly that. We gave it a name: Confluxus. The measure of its success isn’t how much the AI can do for me. It’s how much more capable I become because of the relationship.

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?”

AI is good at generating polished answers, but polished answers are not always your answers. When people ask AI for help with writing, strategy, or difficult decisions, it can jump too quickly to a conclusion and fill in beliefs the user has not fully examined. I created a thought-partner agent that interviews me before producing recommendations or drafts. Its job is to ask probing questions, challenge weak assumptions, surface contradictions, and separate my actual views from ideas suggested by the AI. Instead of writing for me immediately, it helps me clarify my position first. Step-by-step: 1. I give the agent the topic, decision, or idea I want to explore. 2. I tell it not to draft the final output yet. Its first job is to interview me. 3. I have it ask one focused question at a time about my reasoning, evidence, assumptions, audience, and uncertainty. 4. I require it to challenge vague claims and point out contradictions or overlap with my previous thinking. 5. I ask it to clearly separate: - conclusions I stated - ideas the AI proposed - issues that remain unresolved 6. I continue until the central belief, argument, or decision becomes clear. 7. I have the agent create a structured synthesis containing the core thesis, supporting reasoning, counterarguments, open questions, and useful language from the discussion. 8. I pass that synthesis to a writing, planning, or execution agent. I end up with a position that reflects my actual thinking rather than a plausible answer generated by AI. The final writing or strategy is more original, more consistent, and easier for downstream agents to execute.

I built a personalized news workflow called “TastyHookedFish” as an antidote to the feeling that news is limited to crisis, conflict, and collapse. It periodically searches for genuinely interesting, positive developments across science, climate, medicine, conservation, technology, culture, and social progress. The goal is not to create a feed of cheerful fluff, but to surface meaningful developments that provide evidence that useful things are happening in the world. The workflow also tries to avoid repetition, so the same feel-good stories do not keep resurfacing simply because they are popular. The result is a personalized news feed that does not ignore reality, but deliberately widens the lens. Step-by-step: 1. I set up a personalized news workflow called “TastyHookedFish.” 2. I configured it to periodically search for positive developments across science, climate, medicine, conservation, technology, culture, and social progress. 3. I focused the workflow on meaningful developments rather than generic cheerful stories. 4. I added a way to avoid repeatedly surfacing the same feel-good stories because they are popular. 5. I use the resulting feed to stay informed while deliberately widening my view of what is happening in the world.

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?

My father-in-law has had some close calls with phishing attacks, so I built a digital bodyguard with Claude Code to watch over their email around the clock. It’s designed to catch scam and phishing attempts that are specifically crafted to fool people: fake bank alerts, urgent “click here” links, and messages pretending to be from someone they trust. When it spots one, it pulls the message out of the inbox into a separate folder and sends me an alert so I know it happened. I wrote up the full system, including the prompting and context, in GitHub: https://onabetternote.substack.com/p/using-ai-to-guard-against-email-scams?r=6ihgge&utm_campaign=post-expanded-share&utm_medium=web Step-by-step: 1. I built a digital email bodyguard with Claude Code to monitor my father-in-law’s email around the clock. 2. I configured it to look for phishing and scam messages, including fake bank alerts, urgent “click here” links, and messages impersonating trusted people. 3. When it identifies a suspicious message, it moves it from the inbox into a separate folder. 4. It sends me an alert whenever it takes action. 5. I documented the full system, including the prompting and context, in GitHub.

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.

I record calls with Granola and paste the transcript into Claude, but the action items it pulls are hit or miss. Sometimes it skips things that were clearly decided and sometimes it invents owners. I tried asking for a table with owner and due date but it still guessed. Looking for a prompt or workflow that's reliable enough I can trust it without rereading the whole transcript.

I used Astra to redesign my personal wardrobe. I want to dress better, but my absolute worst nightmare is having a closet full of clothes that creates more clutter in my brain. I already have enough to think about, so I built an app that decides what I should wear based on the season and local weather using GPT-6 Astra. I gave it a few full-body photos, my height, weight, sizes, and niche details such as having broad shoulders and needing to tailor my waist. I also shared the colors I like, added a master prompt, and asked it to build a site. The results were incredible. I'm the model in every photo, and Astra's virtual try-on is genuinely impressive. If I can't find a piece online, I update the model and regenerate the pictures. Step-by-step: 1. I opened ChatGPT desktop with GPT-6 Astra and Codex/Sites, then turned on Computer Use and image generation. 2. I started a new chat and uploaded four to eight full-body photos, one clear face photo, and closet photos when available. 3. I pasted the prompt below, filled in my name, city, and sizes, and let it work for one to two hours. 4. I sent a couple of correction passes instead of rebuilding the whole system. I removed things I would never wear and added things I actually wear. PROMPT: GOAL Build a working website called [YOUR NAME]'s Wardrobe. It blends two things: 1) A closed uniform system of exactly 30 looks 2) A personalized shopping portal where I am the model in every photo, Aritzia/Uniqlo catalog quality (seamless studio backdrop, full-body try-on, product-card grid) SITE NAME [YOUR NAME]'s Wardrobe THE ONLY INVENTORY - 7 summer outfits - 7 fall outfits - 7 winter outfits - 7 spring outfits - 1 gym outfit - 1 lounge outfit = 30 looks. Nothing else. Each look is complete: top + bottom or one-piece + shoes + at most 2 extras. Reuse pieces across the 7 looks in a season. Cap unique garments at 35–50 including shoes and outerwear. Throw everything else out. WHO I AM - Name: - Lives: [city] - Height: - Weight: - Sizes (top / bottom / shoe): - Body notes: - Work dress code: - Weekend life: - Style in 5 words: - Colors that work / colors I refuse: - Budget for gap-filling buys: - Hard constraints: Attached photos are the identity lock. Reproduce my real face AND real body in every try-on. Do not slim, lengthen, or beautify me. LIVE WEATHER (required, not a mock) On every page load, fetch live weather for [CITY] from Open-Meteo with no API key. Use the correct lat/long and timezone. Show on the homepage: - “Today in [CITY]” - apparent temperature, condition, rain yes/no - ONE recommended look from the 30 - why that look won - 1 weather swap (if rain starts / if it drops 5°C) Selection logic: - apparent temp ≥ 20°C and dry → Summer pool - 15–19°C dry → Spring pool Mar–May, Fall pool Sep–Nov, otherwise the closer season - 8–14°C → Fall pool, prefer the look that already includes a mid-layer - ≤ 7°C → Winter pool - rain now or daily precipitation ≥ 1mm → jacket + closed shoes, no white sneakers or silk - wind ≥ 25 km/h → prefer a layer - gym / lounge days use those uniforms, add a layer only if ≤ 10°C Never invent an outfit outside the 30. SITE STRUCTURE - Home: today + try-on + wear-this checklist - Summer / Fall / Winter / Spring: 7 look cards each, me wearing the full look - Gym / Lounge - Pieces: every unique garment on me, marked OWNED or BUY - Purge: sell / donate / trash for anything not in the system - Rotation: 4-week calendar per season. Weather can override, but it still has to be one of the 7 (or gym/lounge) VISUAL BAR Premium catalog photography. Gray/white seamless, even light, full body. Do not clone another brand’s logo. This is [YOUR NAME]'s Wardrobe. HOW TO BUILD Step-by-step: 1. Build the 30 looks from my photos, stats, climate, and closet photos. Use owned pieces first. 2. Generate consistent try-ons of me for every look and every piece. 3. Build a real clickable site. Hook live weather. Do not fake it. 4. If an image breaks my face or body, regenerate it before shipping. 5. No payments. Personal wardrobe OS only. OUTPUT Live site, the 30 looks, piece list (owned vs buy), ranked shopping list, purge list, weather mapping, and what you inferred vs what came from my photos. Start now. Make the call if a detail is missing. Only ask if the photos are unusable.

What do you do when your wife says you talk about AI too much? You listen to her, and when she has a problem, you frantically write it down and build it with AI. My wife enjoys working with her plants in the warm sun and light breeze of the Carolina mountains. She’s new to gardening and learning more each day, but she was having trouble keeping track of everything. Which tree did she plant in the front yard last year? It seemed to be struggling—would it do better somewhere else? And would rain reach the potted flowering planters while we were out of town, or would she need to find someone to help? I used Claude Code and Fable to develop an app that my wife could run on her phone, with all the data stored locally. Now she’s excited about “her app” and the things she can add to it. She has even shared it with others, including people across the country, so we added climate zone settings to make it useful in other parts of the country. 😂 Step-by-step: 1. I listened to my wife’s gardening challenges and wrote down the problems she wanted to solve. 2. I used Claude Code and Fable to develop a gardening app for her phone. 3. I designed the app to keep all the data stored locally. 4. I built in a way to track plants, including which tree was planted in the front yard and how it was doing. 5. I accounted for questions about rain and the care of potted flowering planters while we were out of town. 6. After my wife shared the app with people across the country, I added climate zone settings so it could be useful in other regions.

I built a daily AI story-scouting workflow that finds potentially viral stories for Instagram Reels, YouTube Shorts, and TikTok without recycling topics we’ve already covered. First, the workflow reviewed Rowan’s public short-form archive once to create a coverage map of past topics and editorial taste. It uses that map as a filter, helping distinguish a genuinely new angle from another version of the same AI launch, robot demo, or research story. Every morning, it scans priority sources, including AI and technology coverage from major newspapers and tech blogs, The Rundown newsletters, company announcements, research papers, and public updates from major AI and robotics companies. The workflow is not limited to same-day news. It also looks back over the past one to six weeks for stories that have not been extensively covered in the media. Each potential story is checked for four things: a clear visual hook, a technical idea that can be explained in 45–90 seconds, broad audience interest, and meaningful novelty compared with Rowan’s past coverage and the previous week’s recommendations. It keeps every story that clears the bar rather than forcing a fixed number. The final brief is ranked by strength and sent as one compact Slack DM at 10 AM each day. Step-by-step: 1. The workflow reviews Rowan’s public short-form archive once and builds a map of past topics and editorial taste. 2. Each morning, it scans priority sources, including major newspapers, tech blogs, The Rundown newsletters, company announcements, research papers, and public updates from major AI and robotics companies. 3. It searches both same-day news and stories from the previous one to six weeks that have not been extensively covered in the media. 4. It filters out topics that substantially repeat Rowan’s past coverage or the previous week’s recommendations, while identifying genuinely new angles. 5. It evaluates each potential story for a clear visual hook, a technical idea explainable in 45–90 seconds, broad audience interest, and meaningful novelty. 6. It keeps every story that meets those criteria instead of forcing a fixed number of recommendations. 7. It ranks the final brief by strength and sends it as one compact Slack DM at 10 AM each day.

I built a local memory system for Claude that is a bit different from others I have seen. The reason was familiar: repeated context loss and gaps, even within projects. I am not technical—I come from a healthcare background—so it was essentially vibe-coded, but I used a method I had not seen elsewhere. I started by interviewing Claude about what would be useful to it, rather than beginning with only what I wanted. The three biggest gaps were the rationale behind decisions, current versus historical states, and the difference between global and project-level detail. We also identified ways memory can go wrong, including stale facts being confidently asserted as truth and rejected ideas resurfacing. Claude’s built-in memory stores flat topics without entity links, captures what but not why, is not well temporally grounded, and is gated by Claude. I researched other memory builds, from homebrew systems to enterprise tools, and found that they generally fell into three groups: - Vector dumps, which lack rationale and supersession and can become stale - Plain Markdown with grep or embeddings, such as Basic Memory, which similarly lacks real temporal grounding and an entity graph - Heavyweight knowledge-graph stacks such as Neo4j, LangChain, and GraphRAG None of these did what I wanted. My store holds entities only, not transcripts. It stores decisions, observations, people, and projects connected by typed edges. Each entry has content, a scope—either portfolio-worthy or working detail for one project—a rationale, and information about where it came from. The system is also bitemporal, so it distinguishes what is current from what is not. Nothing is edited in place: a correction adds a new assertion instead of overwriting the old one. Underneath, it uses SQLite, with sqlite-vec for semantic search and FTS5 for keyword search. Nothing writes automatically. Claude has to propose a memory, and I have to approve it. This prevents the store from filling with noise, keeps it token-efficient, and acts as a governance lever. MCP links Claude to my server. It is local-only at present, although there is potential to add remote access in the future. The server provides instructions for making proposals, so the system is theoretically portable, and I also created a Claude skill to accompany it. I ran the build across multiple projects and created specialist projects for different roles: - A central development and oversight project served as the decision-maker and prompt-writer. - Cowork handled the building and tested each module inside a sandbox. It had no authority to change decisions, and I used a fresh project for each stage of the build. - I handled deployment separately by typing every command on the server and pasting the output back. - I repeated Claude’s Cowork-authored tests on the actual server. Real-world testing after deployment identified only minor issues, which were quick to fix. This separation was administratively heavy because I had to keep switching between projects as tasks started and finished, but it caught several errors in the rules and code. Despite my lack of technical knowledge, the project is now well documented and I have room to develop it further. I may eventually put it on GitHub. It has become a standard component of my workflows, my projects are tracked much better, and Claude and I are on the same page more often.

I use ChatGPT to analyse and redesign the underlying structure of a messy computer archive. I first generate a folder tree locally with a Python script provided by ChatGPT and saved as a BAT file. The tree shows the hierarchy of folders and filenames, giving ChatGPT a broad view of how the archive is currently organised. From that structure, ChatGPT can identify where the organisation is too fragmented or too broad. For example, a client folder may contain ten nested subfolders with only a few text files in each, making the structure more complicated than the content requires. Elsewhere, hundreds of photos, screenshots, or documents may all sit in one folder, suggesting that more meaningful categories would help. ChatGPT can then propose a revised structure with more or fewer levels, depending on the actual content. It can also suggest more consistent naming conventions for folders and files, identify recurring subjects or topics of interest across the archive, and point out categories that already exist implicitly but have never been organised deliberately. For larger changes, I can ask ChatGPT to help create a copied version of the archive using the proposed structure rather than immediately reorganising the original files. This gives me a working prototype of the new system. I can browse it in Windows Explorer, see whether the categories make sense in practice, and adjust the structure before making any permanent changes. The result is not just a cleaner folder tree. It is a way to use AI to discover the information architecture hidden inside years of accumulated files and turn it into a structure that better reflects how the content is actually used. Step-by-step: 1. I use ChatGPT to generate a Python script that creates a folder tree locally, then save the script as a BAT file. 2. I use the folder tree to show ChatGPT the archive’s hierarchy of folders and filenames. 3. I ask ChatGPT to identify areas that are too fragmented or too broad, such as deeply nested client folders or folders containing hundreds of mixed files. 4. I ask ChatGPT to propose a revised structure with an appropriate number of levels, along with more consistent folder and file naming conventions. 5. I ask ChatGPT to identify recurring subjects and categories that already exist implicitly in the archive. 6. For larger changes, I ask ChatGPT to help create a copied version of the archive using the proposed structure instead of changing the original files immediately. 7. I browse the copied structure in Windows Explorer, assess whether the categories make sense in practice, and adjust the system before making permanent changes.

I love reading, but my Goodreads TBR list keeps growing faster than I can get through it. After years of adding books, I had forgotten what was actually there and was wasting time scrolling whenever I needed to choose my next read. I asked Claude to analyze my reading history, 4-star and 5-star ratings, author patterns, and recurring genres to create a profile of my book personality. I then used that profile to select and rank the next 50 books from my TBR list. Because I enjoy matching books to the season, I also asked Claude to organize the recommendations by seasonal feel. Now I have a reference list that makes it easier to decide what to read next. Step-by-step: 1. I exported my library data from Goodreads. 2. I uploaded two files to Claude: my Read list and my To-Be-Read list. 3. I used the prompt below to generate a personalized reading roadmap based on my book personality. 4. I used the resulting list as a reference so I would not spend as much time deciding what to read next. PROMPT I have attached two CSV files: 1. My Read list. 2. My To-Be-Read list. Create my book personality profile by analyzing my reading history, my 4-star and 5-star ratings, author patterns, and recurring genres. Using that data, filter and rank my To-Be-Read list to build a personalized roadmap of the next 50 books I should read from that list. Evenly organize recommendations into 4 seasonal blocks based on these descriptions: - Autumn: Atmospheric, moody, or suspenseful books with a cozy but engaging pace. - Winter: Immersive, complex, or cozy books (slower burns or dense world-building). - Spring: Fresh, character-driven, or thought-provoking fiction with a steady pace. - Summer: High-energy, immersive, or breezy books (fast-paced page-turners). Next, generate an interactive digital bookshelf widget to display the recommended books. The design should feature: - A warm, premium editorial color palette. - Minimalist style cards for each book displaying Title, Author, and color-coded genre badge. - Interactive navigation tabs at the top to toggle between the four seasons. - A functional "Mark as Read" click action on each card that visually updates a progress ring or tracker.

We used ChatGPT to make renting out our house in France for the first time far less overwhelming. By the end of the summer, we had hosted four families. Although the whole process was a lot of work, creating one master file with useful facts about the house was a major time-saver. It included everything from Wi-Fi and coffeemaker instructions to lighting quirks and bin days. From that document, AI built a room-by-room preparation checklist, drafted and translated a house guide in French and English, wrote separate listings for Airbnb and a local rental site, and created guest messages ranging from booking confirmations to check-in instructions. For pricing, we spoke with a local agent. AI’s final task was to flag the French administrative, tax, registration, and insurance details that we needed to sort out ourselves. Step-by-step: 1. We created one master file containing useful facts and practical details about the house, including Wi-Fi, coffeemaker instructions, lighting quirks, and bin days. 2. We used the file to have AI create a room-by-room preparation checklist. 3. We asked AI to draft and translate a house guide in French and English. 4. We had AI write separate rental listings for Airbnb and a local rental site. 5. We used AI to create guest messages, including booking confirmations and check-in instructions. 6. We met with a local agent for advice on pricing. 7. We asked AI to flag the French administrative, tax, registration, and insurance details we needed to handle ourselves. 8. By the end of the summer, we had hosted four families.

I built a backend operations system for my husband’s general contracting business. It manages new leads, bids and estimates, in-progress jobs, receipts, expense tracking, job photos, invoicing, and other functions he needs—all in one app built with ChatGPT and Base44. I rolled it out in phases. Phase one focused on tracking jobs and their status, phase two added financials, and phase three introduced executive functions. Phase four will cover marketing, although he does not need that right now because he is solidly booked for months. Step-by-step: 1. I built an all-in-one backend operations app using ChatGPT and Base44. 2. In phase one, I added tracking for jobs and their current status. 3. In phase two, I implemented financial functions, including receipts and expense tracking. 4. In phase three, I added executive functions along with other operational features such as leads, bids and estimates, job photos, and invoicing. 5. I planned marketing features for phase four, but postponed them because the business is solidly booked for months.

I'm planning a housewarming party for about 70 people: 60 adults and 10 children. I knew I wanted to serve a large grazing board, along with a couple of big buckets of ice filled with canned beer, coolers, sparkling water, and other drinks. I told Claude about the party and asked it to create a shopping list based on the number of attendees. Claude produced a cohesive list with six cheeses and approximate quantities for each one. It did the same for the cured meats, crackers, bread, fruit, nuts, jams, and pickled items. It also suggested beverages, including a ratio of beer to coolers and nonalcoholic options. The list included juices and non-caffeinated sodas for the kids, along with a template showing how to lay out the grazing table. This was not a complex use case, but it was very helpful. Step-by-step: 1. I estimated the guest list at about 70 people: 60 adults and 10 children. 2. I described my plan to serve a large grazing board and drinks kept cold in a couple of big buckets of ice. 3. I asked Claude to create a shopping list based on the number of attendees. 4. I used Claude's recommendations for six cheeses, cured meats, crackers, bread, fruit, nuts, jams, and pickled items, including approximate quantities. 5. I reviewed its beverage suggestions, including the beer-to-cooler ratio, sparkling water, juices, and non-caffeinated sodas for the children. 6. I used the layout template to plan how to arrange the grazing table.

I built a custom AI knowledge-transfer GPT designed to prevent institutional knowledge from walking out the door when an experienced employee leaves. The trigger was an experienced operations manager preparing to leave the organization. I realized that while we had procedures, files, emails and account documentation, a huge amount of operational knowledge existed only in that manager’s head: customer preferences, recurring staffing problems, site-specific quirks, key relationships, historical issues, workarounds, lessons learned and the small details that can take a replacement months to discover. My goal was to capture that knowledge and turn it into an interactive resource for the incoming operations manager. First, I conducted and recorded an in-depth interview with the departing manager. Instead of only asking standard turnover questions, I had them walk through the operation as if they were personally training their replacement. We discussed customers, employees, locations, scheduling, recurring problems, escalation procedures, communication preferences, historical decisions and things they believed a new manager might not realize immediately. I then transcribed the conversation and used AI to analyze the interview for knowledge gaps. I asked the AI to approach the transcript from the perspective of someone taking over the job and identify important questions that had not yet been answered. Using those gaps, I had AI create customized knowledge-transfer questionnaires specifically for the departing manager. These asked more targeted questions such as: What problems happen repeatedly? What customer preferences are not documented? What exceptions exist to normal procedures? What mistakes is a new manager likely to make? What information exists only in your memory? What would you make sure your replacement understood during their first 30 days? The departing manager completed those documents, giving me another layer of institutional knowledge that would normally be lost. Next, I organized the interview transcript, completed questionnaires, operational procedures, account information, contacts, historical notes and other relevant documents into a knowledge base. I uploaded that information into a custom GPT and instructed it to function as an operational knowledge-transfer assistant. The GPT was told to base answers on the captured information, not invent answers when information was missing, and clearly tell the user when something needed to be verified. The incoming operations manager can now interact with that knowledge conversationally. Instead of searching through folders or wondering who to ask, they can say things like, “I’m meeting with this customer tomorrow. What should I know?”, “Has this location had staffing problems before?”, “Why do we handle this account differently?”, or “What should I watch for during my first month?” The GPT is now being used by the incoming manager as an ongoing reference tool. The result is essentially a searchable, interactive version of the institutional knowledge that previously would have disappeared with the departing employee. It reduces the “I don’t know what I don’t know” period of starting a new position, shortens the learning curve, improves operational continuity and helps prevent the next person from having to relearn years of lessons through trial and error. The same workflow could be recreated for retiring executives, salespeople, plant managers, administrators, project managers, maintenance supervisors or anyone whose experience contains valuable institutional knowledge. The employee can leave. Their knowledge doesn’t have to.

Midlifecurious is a newsletter for women navigating midlife—honest, funny, and allergic to being talked down to. Its Sunday issue, the Midlife Missive, is a roundup covering health, wellness, money, beauty, and family. My sister, Claire, edits it; I build the machine behind it. That machine is Missive, a five-part publishing intelligence system that runs the newsletter as one closed loop: scan → triage → publish → measure → remember. It monitors Reddit, search trends, and RSS to identify what midlife women are paying attention to before those topics reach our feeds. Discovery pulls in those sources, ranks every feed using a click-rate-based quality score, and lets Claire triage articles into the week’s issue. Curation composes Sunday’s newsletter and drafts the introduction in her voice. Performance reads the Mailchimp results back into the system and feeds them into the rankings, so strong sources rise and weak ones fall over time. Underneath all four stages is Memory: a vector-searchable corpus of every article, save, rejection, and the reasoning behind each decision. Memory is the real spine of the system. It lets Missive ask editorial questions such as “Have we covered this before?” and “Is this source still earning its slot?” instead of requiring one person to hold everything in her head. We’re a two-person operation: I build with Claude Code, and Claire edits. The system runs on one database for under $25 a month. I built it because the alternative was Claire drowning in a Feedly-and-spreadsheet routine that discarded everything as soon as an issue shipped. We had no record of what we had run and no feedback on what actually landed. My bet is that the corpus is the moat. Claire’s editorial taste—every save, rejection, and “cornerstone” stamp, with the reasoning stored alongside the decision—is a training set no one else has. A system that remembers turns her job from synthesizer into judge. Missive is deliberately internal-only: no SaaS and no customers, ever. That frees me to build for our exact workflow instead of a hypothetical buyer, and to build for 2028 instead of this quarter. The near-term payoff is a calmer Sunday. The long-term goal is a proprietary editorial-intelligence layer we could never buy off the shelf—the foundation for the research and audience products that come next. Step-by-step: 1. I monitor Reddit, search trends, and RSS for topics that midlife women are paying attention to. 2. I pull those sources into Missive and rank each feed using a click-rate-based quality score. 3. Claire triages the ranked articles into the week’s Midlife Missive. 4. Missive composes Sunday’s newsletter and drafts the introduction in Claire’s voice. 5. I import the Mailchimp results so the system can update source rankings based on performance. 6. Missive stores every article, save, rejection, “cornerstone” stamp, and the reasoning behind each decision in a vector-searchable corpus. 7. We use that memory to check whether a topic has already been covered and whether a source is still earning its place. 8. I build and maintain the internal system with Claude Code, while Claire handles editing, using one database that costs under $25 a month.

When I’m continuing a book series or a show season and have forgotten key plot points—especially in fictional stories with large casts—I use NotebookLM to research a spoiler-free refresher before starting the new season or latest book. I used this approach with the new *Murderbot* series and the latest science-fiction book by James S. A. Corey, who wrote *The Expanse* and the *Leviathan Wakes* series. After loading the sources, I ask NotebookLM to create a slide deck with illustrations of the key characters, their relationships, and a quick dossier for each one. This gives me a visual anchor for the characters and earlier plot lines without revealing future events. I also want a hero image designed as a slide, cover, or thumbnail to promote this workflow. It should use and represent the NotebookLM logo and the logos of any other relevant tools, track down their current branding where possible, and turn these .dcs into HTML slide decks.