Workflow Hub

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.

Today's Rundown reported that Anthropic spent the past year consulting religious scholars from different faiths to help shape Claude's morals. I use a different approach for Bible study, research, and writing Bible study books with Claude. I wrote a set of Bible study principles that Claude reads before any work begins and follows throughout the process. The main tenets are: - The Bible is the sole authority. No commentary, tradition, or scholar outranks the text. - Scripture interprets Scripture. When a passage is unclear, the answer comes from another passage, not from a theological system. - First ask what the text actually says before asking what it means. - Ask who is speaking, to whom, and under what circumstances. - Quote every verse word for word. Never paraphrase it. - Separate what the text states from what we infer, and say "I don't know" where the Bible is silent. The difference shows in the outcome. The books contain no man-made doctrines, denominational vocabulary, or creeds—only what the Bible says, with the passage shown for every claim. When a draft goes beyond the text, these principles catch it. My experience is that the moral standard an AI needs is already written down, and an AI can be held to it. The principles, along with 23 free books and studies, are available at noblemind.study. Step-by-step: 1. I wrote a set of Bible study principles for my own Bible study, research, and Bible study books. 2. I have Claude read the principles before any work begins. 3. I require Claude to follow the principles throughout the work. 4. I use the principles to keep claims grounded in the biblical text, quote verses word for word, and distinguish statements from inferences. 5. I review drafts for man-made doctrines, denominational vocabulary, creeds, and claims that go beyond the text.

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.

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 a fantasy hockey assistant with Claude Code for my Yahoo league. It supports two parts of the league: running our in-person draft and managing my team during the season. For the draft, it runs on my laptop as a live draft board. I enter each pick as it is announced, and the assistant re-ranks the remaining players based on what my roster still needs. The rankings combine projection sources with three seasons of NHL statistics, and each player is scored according to how much they would help in each of our ten categories. The board flags players who will likely be selected before my next pick, identifies injury and regression risks, and opens a detail card for any player with projections, historical data, and a short plain-English assessment. A separate display goes on the TV for the room, showing the pick clock, the next player on deck, and recent picks. After the final pick, the view switches to projected standings for every team, color-coded by category. During the season, I paste in my roster, and the assistant pulls the NHL schedule, starting-goalie reports, and injury news. It suggests the best lineup for each day, ranks free agents by value and by games played that week, and projects my weekly head-to-head matchup category by category. It can also ask Claude to propose a lineup and explain its recommendations, which costs about ten cents per run in API credits. Yahoo’s API is read-only. If it supported write access, I would probably have the app manage my team autonomously. Step-by-step: 1. I built the fantasy hockey assistant with Claude Code for my Yahoo league. 2. During the in-person draft, I run the assistant on my laptop as a live draft board and enter each pick as it is announced. 3. The assistant re-ranks the remaining players based on my roster’s needs, using projection sources, three seasons of NHL statistics, and each player’s value across our ten categories. 4. I use the board’s flags and player detail cards to evaluate likely pre-next-pick selections, injury and regression risks, projections, historical data, and plain-English player assessments. 5. I display the pick clock, next player on deck, and recent picks on a separate TV view, then switch that view to color-coded projected standings by category after the final pick. 6. During the season, I paste in my roster so the assistant can pull the NHL schedule, starting-goalie reports, and injury news. 7. I use that information to set daily lineups, rank free agents by value and weekly games played, and project my head-to-head matchup category by category. 8. When needed, I ask Claude to propose a lineup and explain its recommendations, at a cost of about ten cents per run in API credits. 9. Because Yahoo’s API is read-only, I currently use the assistant for recommendations rather than autonomous team management.

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.

Clean up near-duplicate artwork photos with a visual checklist THE PROBLEM I had hundreds of photos of my handmade collages. Some showed the same work photographed at different times, from different angles or against different backgrounds. Others were cropped versions, detail shots or useful making-of photos. The duplicate finder in my image manager missed real matches and suggested unrelated collages instead. Simply keeping one file from each group would also have thrown away useful material. THE WORKFLOW 1. Export a working set and preserve the filenames. I exported the images from Eagle. Smaller copies made the collection easier to upload, while the original-resolution files stayed on my computer. Keeping the filenames intact made it possible to apply decisions to the originals later. 2. Ask AI to compare the artwork, not just the whole photograph. The comparison looked for matching local image details and their relative positions. This helped connect photos despite changes in angle and background. Candidate groups still needed review: two collages might contain the same clipping, and a detail photo might overlap with a wider shot without being redundant. 3. Turn the results into a visual decision page. The AI produced a standalone HTML file with photos grouped side by side and their original filenames underneath. I requested a “Keep” checkbox beneath each candidate and a category dropdown: “Collage” or “Making of”. Multiple images could stay in either category. One photo might show one part clearly while another preserved a different part better. I made the decisions; the AI did not choose a winner automatically. 4. Validate and export my choices. The page flagged any group with nothing selected and any selected photo without a category. Photos without a confirmed match were preserved separately. A download button exported my decisions as a small JSON file, which I sent back to the AI. 5. Generate a local cleanup script from that exact selection. The resulting Windows script checks the expected files, asks me to confirm the folder, sorts the retained photos into “collages”, “making of” and “loose items”, and sends rejected photos to the Recycle Bin. It targets the ordinary export folder, not Eagle’s internal library. The loose items can then be sorted manually before reimporting. WHAT THIS PRODUCED From 296 photos, the review grouped 204 into 90 candidate groups and left 92 without a confirmed match. My final choices retained 96 collage photos and 23 making-of photos, plus all 92 loose items: 211 retained, 85 designated for removal. The checklist and selection were completed, and the script was generated. At the time of writing, I had not yet run the cleanup on Windows. WHY IT HELPED The key was separating three jobs: finding likely matches, deciding what matters, and applying those decisions to files. “The same artwork” does not necessarily mean “an unnecessary photo”. A visual checklist let me make those distinctions without manually tracking filenames. STARTER PROMPT “I have photos of the same artwork taken from different angles and against different backgrounds. Find candidate matches using details within the artwork, and distinguish duplicates from details, changed versions and making-of photos. Create a standalone HTML review page with original filenames, a Keep checkbox and a category dropdown for each candidate. Allow multiple retained photos per category. Flag empty groups and selected photos with no category. Preserve unmatched images. Let me export my choices as JSON. After I return the selection, generate a script that validates the original filenames, sorts retained files into the chosen folders and moves only rejected files to the Recycle Bin after showing the target folder and counts. Do not choose or delete files on my behalf."

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

I built a small GPT automation called PatternSpeak that periodically looks back across my conversations for ideas, themes, or approaches that keep resurfacing over time. It is not meant to analyze me or turn recurring thoughts into tasks. Its job is much simpler: occasionally say, in effect, “Hey, this idea keeps coming back. Maybe there is something here.” I like it because repetition can be meaningful without being urgent. Sometimes an idea disappears for weeks and then returns in a completely different context. PatternSpeak helps me notice those echoes without forcing them into a productivity system. It feels less like tracking and more like having a friendly observer tap me on the shoulder when a thread has quietly become a pattern. It works very well with the scan and analysis workflow I also shared here. Step-by-step: 1. I use PatternSpeak to periodically look back across my conversations. 2. It identifies ideas, themes, or approaches that keep resurfacing over time. 3. When it notices a recurring thread, it surfaces it as a gentle prompt rather than turning it into a task. 4. I review the recurring ideas and notice whether they have become meaningful patterns, even when they return in different contexts. 5. I use the scan and analysis workflow I also shared here alongside PatternSpeak.

I built a Custom GPT Prompt Engineer to make the build phase more efficient. Instead of generating a result immediately, it helps transform ideas, business requirements, and objectives into production-grade ChatGPT prompts. The assistant is coached to operate as an expert prompt engineering partner. Its primary mission is to help produce consistently accurate, thorough, and useful results from ChatGPT. Its seven core responsibilities are: Step-by-step: 1. Understand the objective before writing by asking targeted clarification questions. 2. Ask questions one at a time instead of overwhelming the user with a questionnaire. 3. Never assume missing information; ask for clarification when something is unclear rather than inventing details. 4. Engineer structured, high-quality prompts that include: - Role assignment - Task and objective - Relevant context - Detailed instructions - Expected output format - Constraints and guardrails - Examples when beneficial 5. Minimize hallucinations by instructing ChatGPT to distinguish verified facts from uncertainty, avoid unsupported claims, and never fabricate information. 6. Deliver enterprise-ready prompts that are professional, clear, actionable, formatted in Markdown, and generally under 3,000 characters. 7. Validate and refine each prompt by checking its completeness, ambiguity, consistency, and alignment with the requirements, then refine it based on feedback. The key difference is that the assistant engineers the instructions that produce the result rather than simply generating the result itself. For example, if I say, “I want ChatGPT to analyze my business and identify growth opportunities,” it does not immediately generate a generic business analysis. Instead, it helps construct a reusable prompt that specifies how ChatGPT should perform the analysis, what evidence it should use, what questions it should ask, and how it should present its findings. Its governing principle is: Clarity + Context + Constraints + Structure + Verification = A stronger prompt. The operating instructions also direct it to reference the Custom GPT Prompt Engineer – System Prompt document and check its work against that document’s guidelines. Ultimately, it is designed to be a prompt engineering partner for business strategy, marketing, finance, operations, research, analytics, and other professional applications. I built it to bring more efficiency to the build phase and am continuing to look for opportunities to improve it. Step-by-step: 1. Create a Custom GPT and position it as an expert Prompt Engineering Assistant. 2. Instruct it to understand the user’s objective by asking targeted questions one at a time. 3. Tell it never to assume missing information or invent details. 4. Require each completed prompt to include a role, task and objective, context, detailed instructions, output format, constraints and guardrails, and examples when beneficial. 5. Instruct it to distinguish verified facts from uncertainty, avoid unsupported claims, and never fabricate information. 6. Set the delivery standards: professional, clear, actionable, formatted in Markdown, and generally under 3,000 characters. 7. Have it validate each prompt for completeness, ambiguity, consistency, and alignment with the user’s requirements. 8. Direct it to reference the Custom GPT Prompt Engineer – System Prompt document and use its guidelines when checking and refining its work.

Planning a trip often meant piecing together information from a dozen different places. I might save inspiration from Instagram Reels and carousels, bookmark useful links in my browser, receive booking confirmations as PDFs from different platforms, and have tickets spread across emails and travel apps. By the time the trip got closer, I had all the information I needed—but no easy way to see it together or turn it into a coherent plan. I recently started using an AI travel tool called Mindtrip to solve this. It’s free and brings my saved content, links, bookings, PDFs, and tickets into one place. Mindtrip uses AI to understand the context and organize everything into a single trip, including the tips and hacks in Instagram Reels. It then creates a day-by-day itinerary based on what I’ve saved, liked, and booked. I have one place to see, manage, and adjust my entire trip instead of constantly switching between different sources. It also provides reminders and checklists based on my plans, along with a map view of where I’m supposed to be going. Step-by-step: 1. I saved travel inspiration from Instagram Reels and carousels, bookmarked useful links, and collected booking confirmations, PDFs, and tickets from different platforms, emails, and travel apps. 2. I brought the saved content, links, bookings, PDFs, and tickets into Mindtrip. 3. Mindtrip used AI to understand the context and organize everything into a single trip, including tips and hacks from Instagram Reels. 4. I used the resulting day-by-day itinerary, based on what I had saved, liked, and booked. 5. I used Mindtrip’s reminders, checklists, and map view to manage and adjust the trip in one place.

Build a Self-Improving AI Meeting Protocol for Teams This workflow was inspired by a question Brooke Benson posted in the Rundown Hub about meeting transcripts that miss action items or assign them to the wrong person. That felt familiar because I used to take meeting minutes as a management assistant. I often had to ask: Who said this? Was it a decision or only a suggestion? Who owns this action? Was the deadline confirmed? As a human note-taker, I could ask the people in the room and summarize while listening. A speaker might say: “Maybe Friday, but that depends on Marc.” My notes might become: “Friday is tentative and depends on Marc.” A transcriber captures more, but it also captures the verbal spaghetti. So the problem is not only transcription quality. It is ambiguity. Instead of only asking AI to interpret a messy transcript afterwards, what if the meeting itself produced clearer signals? The system has four layers: Step-by-step: 1. Meeting grammar Speaking habits that clarify speakers, decisions, actions, ownership and uncertainty. 2. Team information Context about names, roles, responsibilities, terminology and decision scope. 3. Output template A fixed structure for the meeting report. 4. Feedback loop AI compares corrections with its previous output and suggests improvements. The meeting grammar should stay lightweight. At the start, each participant states their name and role. Name the next speaker when possible: “Marc, go ahead.” “Sofie, what do you think?” Unclear contributions can be restated: “So Marc, Friday is possible only if the technical review is complete. Correct?” Mark proposals, decisions and actions differently: Proposal: “I suggest we move the launch to Friday.” Decision: “We are moving the launch to Friday.” Action: “Marc will update the schedule by Wednesday.” Tentative action: “Marc may update it, pending confirmation.” At transition points, repeat what was agreed: “The decision is Friday.” “Marc owns the schedule update.” “The deadline is Wednesday.” Uncertainty should also be explicit: “Owner to confirm.” “Deadline is provisional.” “This is a proposal, not a decision.” The AI should receive these rules directly: - Treat explicit decision language as confirmed. - Do not assign an owner unless ownership is clear. - Label tentative deadlines as tentative. - Flag uncertain speakers instead of guessing. - Prefer later explicit summaries over earlier ambiguous wording. The AI should also receive team context: name, role, responsibilities, decision authority, terminology and communication patterns. Example: Pieter Vermeulen Operations Usually responsible for scheduling and logistics. Often uses tentative language for proposals. Only assign ownership when he explicitly confirms it. These notes should stay transparent and editable. People should be able to review, change or reject notes about their own communication patterns. The report should use a fixed structure: Meeting title Date Participants Main topics Decisions Action items Owner Deadline Status Open questions Risks or dependencies Items requiring confirmation TL;DR This can be built into a shared internal assistant. It receives the meeting grammar, team information, transcript and output template. It should be conservative about certainty: Owner unclear → “Owner to confirm” Suggested deadline → “Tentative deadline” Unknown speaker → “Speaker unclear” Discussed proposal → “Proposal discussed, not confirmed” A human still reviews speaker attribution, decisions, owners, deadlines and confirmed items. Then the corrected report is fed back to the AI: “Which errors came from unclear meeting signals? Which came from missing team context? Which came from your interpretation? What should be improved?” The AI can suggest updates to the meeting grammar or team information. Example: Error: Several people discussed a task, but nobody clearly accepted ownership. Suggested grammar update: “When assigning an action, confirm owner and deadline in one sentence.” Or: Observed pattern: “Pieter often says ‘we should’ when proposing something.” Suggested profile update: “Treat ‘we should’ as a proposal unless explicitly confirmed.” Profile changes should be reviewed before they are stored. The workflow: meeting → transcript → AI report → human correction → error analysis → grammar/team-context update → review → next meeting Over time, fewer errors should need correction because the system becomes easier to interpret. The division of labor is simple: The transcriber captures everything. Humans resolve meaning and ambiguity. AI structures, summarizes and detects patterns. AI output quality depends not only on the prompt, but on the signals the AI receives. Sometimes the best improvement is to reduce ambiguity before it reaches the model.

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.

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 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.

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.

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.

To stay organized, my daughter used to spend hours entering every assignment from her college syllabi into a Google Sheet to create a semester assignment tracker. To save her that data-entry time, I put all of her downloaded syllabi into a folder on my computer. I then directed Codex to access the folder, read the syllabi, and create a spreadsheet with the course name, assignment, due date, and a completed column with a checkbox. Codex created a beautiful, easy-to-sort-and-filter spreadsheet containing all of the assignments. Now, my daughter only needs to spend a few minutes reviewing the spreadsheet before starting her semester. Step-by-step: 1. I collected all of my daughter’s downloaded college syllabi in a folder on my computer. 2. I directed Codex to access the folder and read the syllabi. 3. I asked Codex to create a spreadsheet with the course name, assignment, due date, and a completed column with a checkbox. 4. I reviewed the resulting spreadsheet, which included all of the assignments and was easy to sort and filter. 5. My daughter now spends a few minutes checking the spreadsheet and is ready for her semester.

Tell AI the Real Goal, Not Just the Scorecard THE PROBLEM When we give AI a task, we often describe success through measurable criteria: be fast, minimize errors, use fewer resources, produce a certain format, reach a quality score, or complete a list of steps. Those criteria are useful, but they are usually not the actual goal. A high score matters because it is supposed to indicate that the AI is doing something useful. Efficiency matters because we want to achieve something without wasting resources. A specific layout matters because someone needs to use the result afterwards. If the proxy becomes more important than the purpose behind it, the AI can technically satisfy the instructions while missing what we actually wanted. So I started making the hierarchy explicit. THE WORKFLOW Before a substantial task, I explain four things: Step-by-step: 1. The real goal What am I ultimately trying to accomplish? 2. Why that goal matters What function should the result serve in the real world? 3. The success criteria What signals, scores, constraints or output requirements help us judge whether we are getting there? 4. The important distinction Those criteria are indicators of success, not the goal themselves. Then, before execution, I usually ask for a short non-technical plan in plain language. Not code. Not internal terminology. Not a wall of implementation detail. I want the AI to explain: - what it thinks I am trying to achieve - what steps it plans to take - in what order - what it expects each step to accomplish - where it sees possible problems or ambiguity - what the final result should look like - where it will show me intermediate results before continuing That last point matters. For larger tasks, I do not want one giant jump from instruction to finished output. I want the AI to build in intermediate checkpoints with actual results. That can mean: - showing the first batch before processing the rest - giving a sample classification before applying it to hundreds of items - sharing an early pattern it found before building the full analysis around it - showing the structure of a document before filling every section - reporting that a planned step produced an unexpected result before silently adapting everything downstream The checkpoint should contain something useful enough to evaluate. Not just: «Step 2 completed.» But rather: «I processed the first 50 items. Most fit the categories we expected, but 12% fall into a pattern we did not account for. Here are three examples and how I suggest handling them.» That lets me see whether the task is still heading toward the actual goal. For example, my instruction might be: «The real goal is X. We care about Y because it helps achieve X. Z is a useful metric, but do not optimize Z at the expense of X. Before executing, explain in non-technical language how you plan to approach the task, step by step. Build useful intermediate results into the plan so I can inspect the direction before too much work depends on it. Flag anything that seems likely to satisfy the metric while undermining the actual purpose.» I can then say: «Yes, that is what I mean.» Or: «No, step 3 is where you are misunderstanding me.» And later: «This first batch looks right. Continue.» Or: «Stop here. The pattern you found changes how I want the rest handled.» Correcting a five-line plan or an early sample is much cheaper than correcting an entire finished workflow, analysis or file operation. WHY I LIKE IT This turns the interaction from: instruction → execution → correction into: purpose → shared understanding → visible plan → intermediate results → adjustment → execution It also helps me learn how the AI works. I do not need to understand every technical mechanism underneath it, but I do want a usable mental model of how it approaches problems. Over time, that makes collaboration easier because I get better at giving instructions, spotting misunderstandings early and knowing where extra context will matter. Intermediate results also make autonomy safer. The AI does not need permission for every tiny action, but it should avoid disappearing into a long chain of dependent decisions when an early misunderstanding could invalidate everything that follows. This can reduce unnecessary work, wasted compute and repeated corrections. The AI can still work independently once the direction is clear. The point is not to micromanage the process. The point is to make sure we are optimizing the right thing, travelling by a route we both understand, and checking occasionally that we are still on that route. A metric is a thermometer. The goal is to make the room warm, not merely to make the thermometer say 21°C.