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

I built a workflow that converts landscape (16:9) footage into vertical (9:16) video without heavily cropping the original footage. Using AI tools and a simple node tree in Magnific, I generated the missing visual data outside the original frame so the final video looks as if it was captured vertically. Previously, this felt like too much trouble and too many steps to be worthwhile. Using Magnific Spaces, I extended the first frame of the video to fit a 9:16 frame with one prompt. Then I used a second prompt with the new frame and the original video as references in a video-generation node. I used Seedance 2.0 to save credits because I had low expectations that the workflow would work. To my surprise, the output was great immediately. It was not perfect, but the generated footage matched the original clip very well. Below are images of my node tree. Step-by-step: 1. I opened the original landscape (16:9) video in Magnific. 2. I used one prompt to extend the video's first frame into a 9:16 vertical frame. 3. I added the new frame and the original video as references in a video-generation node. 4. I used a second prompt to generate the expanded vertical footage with Seedance 2.0. 5. I reviewed the output and found that it matched the original clip well, although it was not perfect.

MinecraftEdu first launched nearly 15 years ago, but the classroom world we built with it is still growing. Years of students have contributed to the school and town-building project, creating a shared record of their creativity and learning. Getting it running on a modern Mac meant preserving that history and giving the next group of students a way to add their own chapter. Finding the right version of Java—the software MinecraftEdu needs to run—was central to the process. We used OpenAI’s Codex desktop app, powered by GPT-6, to examine the old setup, research compatibility issues, and test what would work. An older Java version launched the client, but resizing its window caused it to crash. ChatGPT read the crash reports and tested a newer Java 8 version, which gave us a setup that could launch the game and handle window resizing successfully. ChatGPT also repaired the server launcher and created standalone apps, using Apple’s Rosetta compatibility layer to run the older software on Apple Silicon. The result is a usable MinecraftEdu setup on modern hardware with the existing worlds preserved. We can now continue teaching and building in a place that successive classes of students have helped create. Step-by-step: 1. We examined the existing MinecraftEdu setup and researched its compatibility requirements on a modern Mac. 2. We used OpenAI’s Codex desktop app, powered by GPT-6, to investigate the old setup and test possible solutions. 3. We tested an older Java version, which launched the client but caused crashes when the window was resized. 4. We had ChatGPT read the crash reports and test a newer Java 8 version. 5. We used the working Java setup to launch MinecraftEdu and handle window resizing successfully. 6. We had ChatGPT repair the server launcher and create standalone apps. 7. We used Apple’s Rosetta compatibility layer to run the older software on Apple Silicon. 8. We preserved the existing worlds so future classes can continue building and learning in them.

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 built a playful GPT workflow called Prosperity Oracle, inspired by the astrology and mystical magazine columns I loved in the 1990s. It is deliberately not financial advice, forecasting, or decision support. It is a small ritual of fun: part horoscope, part creative prompt, and part retro-internet weirdness. Instead of asking GPT to optimize something useful, I wanted to recreate the slightly magical feeling of opening a magazine and finding a mysterious prediction written just for me. Sometimes AI does not need to increase productivity. Sometimes it can simply make the day a little stranger and more delightful—and, on some days, inspire my artwork. Step-by-step: 1. I drew inspiration from the astrology and mystical magazine columns I loved in the 1990s. 2. I built Prosperity Oracle as a playful GPT workflow that produces a horoscope-style experience. 3. I framed it as a ritual of fun, creative prompting, and retro-internet weirdness—not as financial advice, forecasting, or decision support. 4. I used the format to recreate the feeling of discovering a mysterious prediction written just for me. 5. I let the results serve as creative inspiration for my artwork.

I have a lot of calls, and follow-ups were the first thing to get lost once my day filled up. Granola notes helped, but I still had to remember to go back and read them. I connected Granola, Claude, and Notion, then set up a scheduled task in Claude. Every day at 6 p.m., it reviews that day’s Granola meeting notes, finds any to-do items or commitments I made, and creates them as tasks in my Notion to-do list. Step-by-step: 1. I connected Granola and Notion to Claude through Settings > Connectors. 2. I created a scheduled task with a prompt like: "Read today's Granola meeting notes. For each action item assigned to me, create a task in my Notion to-do database with the meeting name and date." 3. I set the task to run daily at the end of the day.

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 built GlowNextDoor (glownextdoor.com), a map-based website for discovering nearby hair salons, barbers, nail studios, lash specialists, and other beauty services. I used ChatGPT/Codex and Claude to develop the idea, compare designs, and refine the experience. I then built and published the website with Base44. I connected Google Maps for live business listings and added location detection, distance and rating filters, reviews, directions, and links to salons’ existing booking systems. Through repeated testing on desktop and mobile, I improved the layout, added favorites without requiring a login, created realistic animated category icons, and included an option to add the website to a phone’s home screen. Finally, I connected a custom domain through Blacknight and configured Google Maps usage limits to control costs. My workflow was to describe each feature, review the AI-generated result, test it in the browser, and iterate before publishing. Step-by-step: 1. I described each GlowNextDoor feature to ChatGPT/Codex and Claude while developing the idea and comparing design options. 2. I built and published the website with Base44. 3. I connected Google Maps for live business listings and added location detection, distance and rating filters, reviews, directions, and links to existing booking systems. 4. I tested the website repeatedly on desktop and mobile, then refined the layout and added favorites without requiring users to log in. 5. I created realistic animated category icons and added an option to install the website on a phone’s home screen. 6. I connected the custom domain through Blacknight and configured Google Maps usage limits to control costs. 7. I reviewed each AI-generated result in the browser, iterated on it, and published the updated version.

AI can make a child’s drawing look more polished, but it can also erase exactly what made it interesting. A yellow tree, a rabbit larger than a person, a horse with impossible legs, or a tiny floating object may look like mistakes to a model—but they may be the whole point. I use the child’s drawing as art direction: preserve its visual logic, then build outward. The child supplies the invention; AI helps develop the surroundings. Step-by-step: 1. I read the drawing before transforming it by making a neutral description of what is visible: placement, relative sizes, colours, expressions, unusual shapes, and small details. For example: “A large yellow tree stands on the left. Two tiny figures sit near its trunk. A blue shape fills the lower right.” 2. I avoid deciding what an unclear shape represents. “An oval object with three legs” is more faithful than “a rocket” unless the child confirms it. If possible, I ask the child what is happening, since a strange proportion or colour may have a specific story behind it. 3. I separate essentials from flexible details in two short lists. Essentials might include the yellow tree, oversized rabbit, horse’s pose, characters’ arrangement, and red object in the corner. Flexible details might include lighting, textures, materials, environmental detail, and depth. 4. I make clear that the original is the structural source, not just a mood reference. This gives the model room to work while defining the boundaries. 5. I choose a target style, such as a storybook illustration, watercolour, digital painting, comic panel, or 3D scene. 6. I explicitly ask the model to preserve unusual proportions, unexpected colours, expressions, and relationships between characters. I identify details that must remain, even if they appear anatomically impossible or visually awkward. I avoid vague instructions such as “make it better,” because they leave the model to decide what counts as improvement. 7. I use a starting prompt such as: “Use this drawing as the structural blueprint for a storybook illustration. Preserve the composition, relative sizes, poses, expressions and original colour choices. Keep the yellow tree and the rabbit larger than the person. Do not normalize unusual anatomy or remove unexplained objects. Add texture, lighting and environmental depth around the existing scene.” 8. I treat comparison as part of the workflow because specific instructions do not guarantee a faithful result. I expand the world around the invention: a blank background can become a forest, a blue patch can become a pond if that interpretation fits, and two skiing figures can gain a mountain landscape. 9. I keep the original spatial relationships: who stands beside whom, what dominates the scene, which way characters face, and where empty space matters. I give colour the same care, so a yellow tree does not quietly become green because the model expects green trees. 10. I place the source and result side by side and check whether a character disappeared, the rabbit shrank, the palette changed, or the model invented a focal point, “fixed” an unusual shape, or altered the story. I also watch for generic cuteness—big eyes, pastel colours, and perfect symmetry—which can make very different drawings converge into the same image. I ask whether the result still feels like an expansion of this exact drawing. 11. If most of the result works, I request a targeted edit, such as: “Keep this version, but restore the original hair shape.” “Make the rabbit larger again.” “Return the tree to yellow.” 12. I check the whole image after each local edit because changes can affect other areas. I keep useful versions instead of repeatedly starting over. 13. I treat handwritten text separately. I do not guess unclear wording, correct spelling, or invent labels. If the tool cannot reproduce the text faithfully, I retain the original lettering through a separate editing step. 14. I save the original photo or scan alongside the result, instructions, and useful intermediate versions. I also keep a brief note about protected details to make future transformations easier. 15. Once I have a faithful version, I explore alternatives such as a space setting, surreal painting, or cinematic scene, keeping them as branches from the original. Across several drawings, I preserve recurring colours, shapes, and characters without forcing every image into one rigid style. The child has already decided who exists, what matters, how large things are, and what belongs together. Those decisions are creative direction. A drawing does not need to become less itself to become more finished. The impossible colour may be the atmosphere, and the awkward shape may be the character. The question I return to is: “How can I help this drawing become more fully what it already is?”

I was tired of opening Spotlight every time I wanted to switch apps. The search results would move around, I would occasionally open the wrong app, and those few wasted seconds kept adding up throughout the day. Instead of memorizing a collection of unrelated hotkeys, I used ChatGPT Work to design and build a personalized shortcut system in Apple Shortcuts. The shortcuts can open individual apps, jump directly into specific Safari or Chrome profiles, or launch an entire work mode with one keystroke. For example, a recording shortcut could open your microphone, camera, recording software, and notes. An analytics shortcut could open all the dashboards you check each week. Step-by-step: 1. I opened the ChatGPT desktop app, started a new chat, and switched to Work mode. 2. I asked ChatGPT to plan shortcuts around my real workflow: Based on what you know about me and my workflow, suggest 10 time-saving hotkeys we can set up in Apple Shortcuts. I’m interested in opening specific apps and profiles based on what I need them for or what mode of work I’m going into. 3. I told it which apps, browser profiles, URLs, and work modes I use most. 4. I narrowed the list before making any changes by keeping the highest-frequency shortcuts and avoiding macOS or app conflicts. 5. In ChatGPT, I went to Settings → Computer Use and turned on Any App. 6. I gave ChatGPT the approved list and clearly limited its scope: Set these up in Apple Shortcuts. Do not change anything outside this list. Test each shortcut. 7. I opened All Shortcuts in Apple Shortcuts and ran each one manually. I used Quick Actions to add or change its keyboard shortcut. I like Control + Option because it is less likely to conflict with existing Mac commands. 8. I tested every shortcut while working in another app, checking that it opened the correct app, account, browser profile, or collection of tools before building more. 9. Once everything worked, I asked ChatGPT to create my reference: Write me a one-page cheat sheet of all the shortcuts you set up, where they live, and what’s left to do. The result is a personal shortcut system built around how I actually work, plus a one-page cheat sheet so I don’t have to memorize everything immediately. For the complete walkthrough, exact prompts, screenshots, and setup instructions, follow my full Rundown University guide: Use ChatGPT to Build a Custom Mac Shortcut System. Tools used: ChatGPT Work, Apple Shortcuts Industry: Cross-industry Tags: #chatgptwork #appleshortcuts #macautomation #productivity #workflowautomation

I’m designing a publishing system that keeps producing value without requiring constant output. This workflow started with frustration about the usual content model: publish constantly, stay visible, feed the algorithm, and repeat. That model works poorly when my energy varies, my interests shift, and forcing output quickly turns creativity into maintenance. Instead of asking, “How do I post more?” I’m asking: “How can content keep moving without requiring me to keep producing at the same pace?” The system is built around uneven energy. During high-energy periods, I can generate ideas, draft pieces, collect fragments, or prepare several posts at once. During low-energy periods, existing material does not become a failure state. It can sit, mature, be lightly edited, be reused, or simply wait. Ideas can exist in different stages: a note, a half-developed thought, a finished piece, something worth revisiting later, or something that can be repurposed in another format. Older material is not automatically “used up” after publication. A long-form idea can become a short post. A workflow can become a case study. A conversation fragment can become an essay seed. A previous post can return later from a different angle. The goal is not to build a machine that constantly demands feeding. It is to create a content reservoir I can draw from when I have the capacity. This workflow has not been fully implemented yet, but the design principle is useful: > Build around energy reality, not around imaginary consistency. Content should fit into life. Life should not be reorganized to serve the content treadmill. Step-by-step: 1. I design the publishing system around variable energy rather than a constant production schedule. 2. During high-energy periods, I generate ideas, draft pieces, collect fragments, and prepare several posts at once. 3. During low-energy periods, I let existing material sit, mature, receive light edits, be reused, or wait. 4. I allow ideas to remain in different stages, from notes and half-developed thoughts to finished pieces and material worth revisiting later. 5. I repurpose older material across formats, such as turning a long-form idea into a short post, a workflow into a case study, a conversation fragment into an essay seed, or a previous post into a new angle. 6. I draw from the resulting content reservoir when I have the capacity instead of constantly feeding a content treadmill.

I built a workflow called PeopleSparkles for researching people connected to creative fields, schools, collectives, residencies, local art scenes, and cultural networks. The workflow starts from a defined group of people, for example teachers, alumni, artists, current or former members of an association, residents, or associates connected to a specific academy, organization, or cultural scene. A typical research request can be as simple as: “Look at this art website and identify all current and former residents and associates. Build a list. Then research them in batches of ten, checking their websites and other relevant sources, and write a short description of their work. Deliver the results in a format that can be imported into my local database.” Before each new research run, I provide GPT with a ZIP containing the current state of the PeopleSparkles database. This means the research starts from the existing corpus rather than from scratch. New people can be added, existing entries can be expanded, and previously researched people can be recognized before new material is prepared for import. The actual database lives locally on my computer. Apart from the initial development of the code and the research needed to create new lists of people, the database itself runs locally. Once a new batch has been researched and imported, browsing, organizing, scoring, annotating, and using the material does not require the whole corpus to be sent back for analysis. The database also generates a human-readable HTML version with a designed layout, so the research is not trapped inside raw data or spreadsheets. I can browse the people and their notes visually as a small personal research publication, while the underlying structured data remains available for future additions and processing. The “Sparkles” part is personal. I can add my own notes and scores to each person to capture whether their work sparked something in me, and if so, how. That might be curiosity, recognition, inspiration, aesthetic attraction, a strong question, a surprising association, or simply the desire to look again. This means the database does not only record who someone is and what they make. It also records my evolving relationship to their work. Over time, that creates a second layer on top of the research corpus: not just a map of creative people, but a map of resonance. The database also includes a “Surprise me” function that brings up a person from the collection without me choosing them deliberately. This helps break habitual search patterns and allows older, less obvious, or previously overlooked entries to resurface. Someone I barely noticed months ago can suddenly become relevant in a completely different creative context. The purpose is not to create conventional biographies. I am interested in the sparks around a person: what they make, the media and themes they work with, the organizations or people they connect to, and which traces may lead somewhere unexpected. This is particularly useful for creative ecosystems where information is fragmented across artist websites, academy pages, exhibition archives, old posters, association websites, interviews, catalogues, and small cultural organizations. The workflow gathers those fragments into a cumulative research corpus. It also allows the research to grow organically. One artist may lead to a collective, a teacher to a former student, an exhibition to another maker, or an old membership list to someone whose work would never have appeared in a conventional search. In simple terms: existing local database → new source or people list → GPT-assisted discovery and research in batches → import-ready structured data → local database → HTML browsing, notes and scores → surprise rediscovery → new creative connections The result is a living creative research database that combines external research with personal resonance, so I can not only discover people, but also trace which work actually sparks something in me over time.

Every RSVP tool I found wanted a monthly subscription to collect a few hundred yes-or-no answers, and none would return my data in a format I could use. So I built my own with Claude Code. The RSVP system is small: a form deployed on Vercel and embedded into our wedding website. We also emailed the direct link because plenty of guests might never visit the site. The form asks for more than a yes-or-no response. It collects meal choices, dietary restrictions, and plus-ones. Every submission adds a row to a Google Sheet through the Sheets API. That sheet ended up mattering more than the app. Months later, when it was time to create the seating chart, every guest was already represented in clean, structured rows that I could give to a completely different tool. For seating, I opened the same sheet in Claude and wrote out the rules in plain English: who had to sit together, who could not sit anywhere near each other, which relatives needed a quiet corner, and which friends could anchor a table of people who did not know anyone else. Claude produced a first draft that respected those constraints, along with an interactive board where I could drag people between tables. Step-by-step: 1. Tell Claude Code which fields you want on the RSVP form and have it build the front end and back end. Have Claude deploy it to Vercel. 2. Set up a Google Cloud service account, enable the Google Sheets API, and share the sheet with the service account’s email address. Configure each submission to append a row. 3. Embed the form on your wedding website and email the direct link separately. Some people will never open the website. 4. Ask for everything you will eventually need, not just attendance. Your caterer and venue will want meal counts and dietary restrictions, and going back to collect that information later is miserable. 5. When it is time to seat people, point Claude at the same sheet and write your rules in plain language: who must sit together, who cannot sit together, who needs a quiet table, and who can anchor a table of strangers. 6. Have Claude generate a first draft based on those rules, then move people yourself. This works anywhere you have a public form collecting data and a private tool that needs to reason about it. Put a spreadsheet between them instead of building one app that tries to do both. The form stays simple, and whatever you build six months later can read from the same place.

I built WarrantKit, an open-source (Apache-2.0) kill switch for AI agents. Each agent run receives a Warrant: a typed contract that specifies what the agent may do, for how long, and under which policy. A gateway checks every action before it reaches the outside world. When containment triggers, the runtime’s epoch advances, immediately invalidating every Warrant issued under the old epoch instead of allowing it to linger until a timer expires. Evidence of what happened remains separate from authority, and receipts can be verified offline with a standalone Python script. I designed the architecture and threat model, then used AI coding assistants for most of the implementation. I reviewed everything against an adversarial test suite and a real-host enforcement demo that others can run themselves. Before writing the mechanisms, I wrote tests for the attacks: replayed runtime reports, tampered event sequences, evidence attempting to upgrade itself into authority, and authority carried across execution boundaries. The suite has 202 passing tests, and several core behaviors exist because a test caught the system trusting too much. One example is a recovered runtime carrying a stale report into a new epoch. I then proved enforcement on a real Linux host with a cgroup-v2 real-kill demo before claiming it. The no-root demo is simulated, and the README says so. It also lists what WarrantKit is not. The architecture is layered: WarrantKit owns the authority lifecycle and verification; AgentContainment owns the enforcement boundary; and Warden, DProvenanceKit, and ClaimProofKit record evidence independently. Step-by-step: 1. I defined a Warrant as a typed contract specifying an agent’s permitted actions, duration, and governing policy. 2. I placed a gateway in front of the outside world so it checks every agent action before allowing it through. 3. I made containment advance the runtime’s epoch, invalidating every Warrant issued under the previous epoch immediately. 4. I kept evidence separate from authority and made receipts verifiable offline with a standalone Python script. 5. I wrote adversarial tests for replayed runtime reports, tampered event sequences, evidence attempting to become authority, authority crossing execution boundaries, and stale reports carried into a new epoch. 6. I implemented the system with help from AI coding assistants and reviewed the implementation against the test suite and a real-host enforcement demo. 7. I validated enforcement on a real Linux host with a cgroup-v2 real-kill demo, while clearly labeling the no-root demo as simulated in the README. 8. I kept authority lifecycle, enforcement, and evidence recording in separate architectural layers using WarrantKit, AgentContainment, Warden, DProvenanceKit, and ClaimProofKit.

I’m pregnant with my second child. For my first, we had a doula, so my husband and I didn’t spend much time learning about labor positions or what can help during labor because we knew she would guide us. This time, we don’t have a doula, and we didn’t want to spend a lot of money on an online course or take the time to attend an in-person one. I asked ChatGPT to scour free resources from leading experts and create a mini-course we could work through, along with a cheat sheet for my husband to use during labor. It saved me hours of research and gave us an incredibly useful resource. Step-by-step: 1. I explained that I’m pregnant with my second child and that we had relied on a doula during my first labor. 2. I identified the information we needed to learn, including labor positions and what can help during labor. 3. I asked ChatGPT to scour free resources from leading experts and use them to develop a mini-course. 4. I also asked it to create a cheat sheet for my husband to use during labor. 5. We used the mini-course and cheat sheet as a more affordable and convenient alternative to an online or in-person course.

The Rundown recently held our first in-person retreat in Portugal, which was also my first time traveling to Europe. Claude and ChatGPT were amazing resources throughout the trip, from helping me navigate a chaotic international airport to providing personalized advice on cultural differences, tipping, translating menus, and using public transportation. My wife accompanied me and had plenty of time for solo exploration during the day. She is already a big planner, but a ChatGPT project containing our trip information helped her create a detailed plan, including a packing list, pre-trip checklist, and well-structured day-by-day itinerary for seeing as much of Lisbon as possible. As someone who gets stressed by travel, having an expert with context about my life available in my pocket to answer questions whenever I needed it is something I can’t imagine taking trips without. Step-by-step: 1. I used Claude and ChatGPT for personalized travel guidance during my first trip to Europe. 2. I asked for help navigating a chaotic international airport and handling cultural differences, including tipping, translating menus, and using public transportation. 3. My wife created a ChatGPT project with our trip information to support her planning. 4. She used it to create a packing list, pre-trip checklist, and day-by-day plan for exploring Lisbon during her solo time. 5. I used the tools throughout the trip to answer questions with context about my life and reduce the stress of traveling.

I use ChatGPT to support a hobby that combines research, negotiation, history, craftsmanship, and family legacy: collecting mechanical watches. The workflow usually begins when I discover a watch that interests me. Rather than simply asking whether it is a good watch, I use ChatGPT as a research analyst. We investigate the exact reference, movement, production history, complications, materials, rarity, manufacturer history, comparable watches, secondary-market pricing, previous sales, and any known weaknesses or servicing concerns. With unusual independent watches, this can become surprisingly deep research. The goal is to answer two separate questions: Is the watch genuinely interesting? And is this particular example worth buying at this price? If I decide to pursue a watch, ChatGPT shifts into the role of negotiation adviser. I share dealer listings, asking prices, trade proposals, emails or text messages, previous offers, comparable sales, and my own walk-away price. We discuss likely dealer economics, negotiating leverage, possible counteroffers, and how aggressively or patiently I should approach the transaction. ChatGPT also helps draft correspondence, but the final decision remains mine. I find the greatest value in having an analytical partner that remembers the research and can challenge my enthusiasm before I spend money. After acquiring a watch, I create an entry in a private document I call my Horological Codex. Each entry includes the technical specifications and historical information, along with why I chose that particular watch, how I acquired it, its price, its appraised value, what was happening in my life at the time, and why it deserves a place in the collection. One early watch commemorates an educational milestone. Another is a one-of-one piece commissioned directly with an independent watchmaker. Other watches connect to family events, travel, my cars, personal interests, or particular periods of my life. The Codex preserves those stories and memories alongside the watches themselves. My original Codex eventually became a large, 70-page formatted document, and maintaining it manually became cumbersome as watches entered and left my collection. My next version will separate the structured information from the presentation layer: I will maintain a master record for each watch, then use AI to generate or update the polished Codex from that underlying data. That way, the collection can evolve without requiring me to rebuild an entire book every time something changes. I keep the full Codex private because it contains family and financial information, but the system itself has become a meaningful way to preserve the history behind the collection. Step-by-step: 1. I identify a watch that interests me and describe the exact reference and available listing information to ChatGPT. 2. I research the watch’s movement, production history, complications, materials, rarity, manufacturer, comparable watches, secondary-market pricing, previous sales, and known weaknesses or servicing concerns. 3. I evaluate both whether the watch is genuinely interesting and whether the specific example is worth buying at the asking price. 4. If I decide to pursue it, I share the dealer’s listing, asking price, trade proposals, correspondence, previous offers, comparable sales, and my walk-away price with ChatGPT. 5. I use that information to discuss dealer economics, negotiating leverage, counteroffers, and the right negotiation approach, then make the final decision myself. 6. After acquiring the watch, I record its technical details, history, acquisition story, price, appraised value, personal significance, and place in the collection in the Horological Codex. 7. I maintain a master record for each watch so AI can eventually generate or update the polished Codex without requiring me to rebuild the entire 70-page document whenever the collection changes.

My AI digest looked perfect and was quietly wrong. What actually fixed it. Every run succeeded. Every dashboard was green. And the content was still wrong. My digest invented "AI Moat Brief", a newsletter that does not exist. It reported scan counts nobody measured. It resurfaced week-old stories as fresh headlines. Here is what broke, and what fixed it. The sorting used to happen in my head: skimmed subject lines, unopened tabs, quiet guilt. The Signal is one email at 08:00: a single Make scenario calling Claude Sonnet through OpenRouter. It reads the last 24 hours of my RSS feeds and newsletters, keeps what touches what I am actively building plus the domains I need to stay current in, and arrives in the language I actually think in. Core items end with what it means for my work. Five to ten minutes, and I know where to go deep today. Structurally it looks like this, minus the content, rendered in English for this post (Image 1). No real edition is shown; section names and sample lines are illustrative. The dangerous failures were never pipeline failures. They were content failures, and the cause is structural: an LLM summarizing newsletters that already summarize primary sources is third hand by construction. Every hop strips attribution and adds confidence, and when data goes missing the model fills the gap the way LLMs do: fluently. Valid HTML, confident tone, green pipeline, wrong content. Image 2 is that whole failure class in one frame. Three rules closed the gaps I caught, all live in production: Step-by-step: 1. Verbatim or nothing. A source name is copied character for character, and a link exists only if that exact URL is in the input. The model copies; it never composes. 2. The model never generates metrics. Every count the report shows is injected by the pipeline after the model returns. 3. Recycled news gets demoted. A recap of recaps gets one line at most, and is dropped when the underlying story falls outside the collection window. Rules 1 and 3 lean on the prompt, and that is why the counters exist. The pipeline writes a hidden HTML comment into every email it sends: items, links, urls, cost, finish status. That line caught what I could not see. In one run, the published-links counter and the leftover-urls counter read 45 and 435: the only sign a new cleanup step was a silent no-op. Another morning the model stopped at 15,999 tokens against a 16,000 cap, one token from an email cut off mid-sentence. On the morning I wrote this they agreed, 21 links and 21 urls, and boring is the goal. Image 3 is that morning's actual comment, with the same two counters from the no-op run. The run itself has a dead man's switch on Healthchecks.io, so a missing 08:00 email reaches me before I notice. Honest limits: the $0.31 per report is a fresh measurement I am still validating, and I have not proven these rules hold as the source set scales. There is more behind every part of this; I would rather share it where it is wanted. Ask and I will put it in the comments: the three rules in full, the exact cost and what drives it, what this replaced in my day, how it compares to what is on the market, or the ugliest of the 15 documented bugs. I am sharing this because I doubt I am the only one building fragile things behind the scenes, and monitoring text is harder than monitoring uptime. What content-level checks do you run on LLM output, the kind pipeline monitoring cannot see? Real thresholds and embarrassing failures especially welcome.

I built a repeatable, human-directed AI workflow for turning an original emotion, memory, or story into a finished WazWorld song, complete with cover artwork and release content. It addresses one of the biggest problems with AI music: a simple prompt can produce something technically impressive but generic, overproduced, or disconnected from the creator’s real intention. The workflow begins with a human trigger—an experience, relationship, place, mood, or musical idea that I genuinely want to express. WazWorld generally moves between dark alternative/electronic music and California coastal country-rock. Step-by-step: 1. I create a detailed artistic brief describing the song’s emotional core, story, genre, energy, vocal character, instrumentation, arrangement, dynamics, and intended listener experience. 2. I work with ChatGPT to develop and challenge the concept, write and rewrite lyrics, remove clichés, and design the full arrangement. This includes the intro, verses, choruses, instrumental passages, transitions, musical peaks, and outro. ChatGPT also helps translate my direction into precise production language and exclusions that Suno can understand. 3. I generate versions in Suno, treating each result as a demo rather than a finished song. I evaluate the vocal delivery, lyrics, bass, guitars, synths, drums, tempo, arrangement, and emotional impact. Then I make targeted prompt changes and generate new versions. A song may go through dozens of iterations before it sounds the way I originally heard it in my head. 4. After selecting the final music, I use ChatGPT and AI image generation to develop cover artwork that matches the song’s emotional identity. I adapt the artwork for streaming, YouTube, Instagram, Stories, and Shorts, then create the metadata, descriptions, captions, and promotional material needed for release. 5. I distribute the finished music through services such as DistroKid and publish it across streaming and social platforms. The final result is not a one-click AI song. AI provides creative and production tools, but I direct every major decision—from the original emotion and lyrics to the arrangement, instrumentation, vocals, artwork, and release strategy. Someone can recreate this workflow by starting with a clear human idea, documenting the desired sound, generating multiple versions, evaluating each one like a producer, and iterating until the finished work communicates the original intention.

Ten days ago, I posted about keeping a `HANDOFF.md` so an AI film project doesn't lose the decisions it has already made. This is the other half, and it turned out to be the expensive one: the decisions that haven't been made yet. Credit where it belongs: Tony Ojeda posted a spec-generator agent that sits between an idea and implementation. The rule I borrowed is his: the agent inspects what already exists before proposing anything. I applied it to film production instead of code. I pointed an agent at my production documents for a short film I hadn't started generating and asked it to identify what was still undecided, what each item affected, and what would break if it were decided late. It came back with ten open decisions. One of them was worth the whole exercise. My environment description is locked verbatim across all 40 shots so the world stays identical. The film is called *The Thaw*. Whether the ice visibly melts during the film is written down nowhere. If I decide that in week three, all 40 keyframes get regenerated at once. I would have found out around shot 12. The counterintuitive part is who writes the list: not me. Asking the person who already has the whole film in their head what's missing gets you very little, because they have all of it—and that's exactly why they can't see the hole. The list has to come from something that only knows what's written down. Step-by-step: 1. I put the open questions in section 0 of the handoff, above everything else, so it's the first thing read and the first thing emptied. 2. I have the agent write that list, not me. It reads every existing document for the project and returns only what it cannot know from them. 3. I have it return three things for each item: what's undecided, which shots it affects, and what breaks if it's decided late. The third column sets the priority. 4. I have it sort by what costs the most to change afterward, not by what's easiest to answer. 5. I keep one hard rule: while an open question affects a shot, that shot doesn't get generated. The question gets decided, or deferred in writing with the cost of being wrong stated. 6. Every answered item leaves section 0 through one of two doors: into the closed canon or into the rejected list. Nothing is simply deleted. 7. I ask specifically about the things that go missing every time: the rule of the world; the physical scale of anything impossible, such as whether the character can touch or climb it; any object appearing in more than one shot; screen direction; how it ends; who speaks and in what voice; and the delivery format. 8. When it finds nothing real, it says so. A list padded to look thorough is worse than an empty one. The version I'd used for a year ran at the end of a session and recorded what got decided. Running it at the start, focused on what hasn't been decided, is the same document pointed the other way—and it's the direction that saves money.

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.