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

For the start of the new school year, I wanted to use the current eastern Washington wildfires near Spokane with my two sixth-grade science classes. I wanted an AI tool to create a website I could upload to my hosting service. The site needed to provide daily updates from verified news sources, along with air quality data comparing Spokane in eastern Washington, Kirkland near Seattle, and Chimacum, where we live, on the western side of the state. I also wanted to include a simulation where students could change different variables to see how they affect the direction of the smoke and air quality. I could not decide which AI service to use, so I entered the same prompt into my personal paid Claude and Gemini Spark accounts, as well as my free teacher ChatGPT and Claude accounts, to compare which one created the best site for students. Here is the prompt I used: "Create a dynamic website with information of the Spokane, WA 2026 wildfires. Information include only verified facts from credible news sources. Information needs to be updated from when the largest fire started until it is completely put out. At that point, this website is complete and done. Include a page with air quality data. Provide air quality data on a daily basis from the onset of the fire to the end of the fire. Include Spokane, Kirkland, and Chimacum to compare the air quality from eastern WA near the fire, mid WA, and western WA. Include factors that explain the air quality such as winds, inversion, altitude of smoke and any other relevant data that students can view to answer questions. Provide a way for students to click on different variables to see how different factors affect the fire, direction of smoke, and air quality. Use the /inversa-design skill to make the website." Here is a portal page with links to all four sites: https://educatoral.com/2026SpokaneFire/ Step-by-step: 1. I identified the eastern Washington wildfires near Spokane as a topic for my two sixth-grade science classes. 2. I defined the website requirements: verified news updates, daily air quality data, comparisons among Spokane, Kirkland, and Chimacum, and a student-facing smoke and air quality simulation. 3. I used the same prompt with my paid Claude and Gemini Spark accounts and my free teacher ChatGPT and Claude accounts. 4. I compared the sites created by the four AI accounts to determine which one would be best to use with students. 5. I collected links to all four sites on this portal page: https://educatoral.com/2026SpokaneFire/

I asked Claude to build me an artifact that works as my own personal book tracker. It includes separate sections for books I want to read, books I’m currently reading, and books I’ve read. I also asked Claude to collect specific data points about each book and create an insights tab that can gather information about my likes and dislikes over time, then make future recommendations. I personally dislike Goodreads’ UI and don’t use its social media features, so I wanted a personalized alternative housed within Claude alongside all my other workflows—a one-stop shop. Step-by-step: 1. I asked Claude to build an artifact for tracking my books. 2. I organized the tracker into books I want to read, books I’m currently reading, and books I’ve read. 3. I specified the data points I wanted to collect for each book. 4. I asked Claude to add an insights tab to gather data about my likes and dislikes. 5. I set it up to use those insights for future recommendations and keep the entire workflow within Claude.

After about 18 months of building software with AI, I realized that reliability wasn't primarily a model problem. Bigger context windows and more clever prompts didn't fix it. What did help was treating the AI like a developer joining an existing team instead of like a chatbot. Real developers don't work from memory. They inspect production, read the documentation, check the tickets, and use proven tools. I built an environment that lets the AI do the same. The workflow is tool-agnostic, so it can be rebuilt with whatever AI client and stack you already use. Step-by-step: 1. I gave the AI a persistent task and history store that it can read from and write to. This is the core of the workflow. Mine lives behind an MCP tool, but any queryable store can work. Every architectural decision, blocker, and progress note gets written there instead of being left in the chat. 2. I open every session with a stand-up. Before writing a single line of code, the AI pulls what was in progress, what's blocked, what changed since the last session, and which architectural decisions still hold. About 30 seconds later, we're both looking at the same project. Then we build. 3. I exposed real operations as MCP tools instead of relying on "write code" prompts. I wrapped specific, tested actions—such as creating a page, defining a data model, wiring an integration, and running a migration—as tools. The AI composes these known-good building blocks into larger solutions instead of regenerating infrastructure every session. I call this wave coding, and it's the biggest reason the output stays consistent. 4. I made verification a rule: before touching anything, the AI reads the live database, API state, logs, and files. It checks ground truth first instead of making assumptions. 5. I made the chat disposable and the log canonical. If it isn't logged, it didn't happen. The task store is the single source of truth, not the conversation. The payoff is that I can stop halfway through a feature, close my laptop, and come back days later. The AI reconstructs the project from its own history, so I don't spend 20 minutes re-explaining it. Full disclosure: I built this into my own platform, WebsitePublisher.ai, which currently has 43 MCP tools and 105 integration building blocks. It's delivered as an add-on that plugs into the AI client I already use over MCP, so there's no new app to learn. Nothing here is locked to that platform, though: the workflow itself works with any MCP client and any store the AI can query. I'm curious whether anyone else is running their AI this way or solving the amnesia problem from a different angle.

I ran a prompt to read and listen to all key notes from companies in the medical device industry over the last year. I used it to identify where attention was being drawn and where companies were investing. This helped me see the trends companies were discussing, investing in, or directing their efforts toward. Step-by-step: 1. I ran a prompt over key notes from medical device companies covering the last year. 2. I used the prompt to identify where companies were directing attention and investment. 3. I reviewed the results to see which trends companies were discussing and prioritizing.

My pool water looks great, and I’ve taken over the weekly water-care routine myself after years of using a pool service. I first gave Claude the relevant information about my in-ground pool setup. Now, each week, I check the water’s chlorine, pH, alkalinity, and other chemical levels, then enter the results into Claude. I often take a water sample to a local pool store, where they provide a printed analysis. I snap a photo of the analysis with my phone and upload it to the Claude chat. Claude tells me which chemicals to add and when. Over time, the water has stayed balanced and looks great, while I’ve saved a lot of money on pool service and avoided wasting chemicals. This workflow has paid for itself many times over through this one use case. Step-by-step: 1. I gave Claude the relevant information about my in-ground pool setup. 2. I checked the pool water weekly, including chlorine, pH, alkalinity, and other chemical levels. 3. I either entered the results into Claude or took a water sample to a local pool store for a printed analysis. 4. I photographed the printed analysis with my phone and uploaded it to the Claude chat. 5. I followed Claude’s guidance on which chemicals to add and when. 6. I repeated the process over time to keep the water balanced and avoid wasting chemicals.

I fed Claude my sweat-test data, and it formulated a DIY high-carb cycling mix tuned to my sweat chemistry. It also scaled the batch to match my available supplies and generated print-ready labels and batch sheets. Step-by-step: 1. I provided Claude with my sweat-test data. 2. I used Claude to formulate a DIY high-carb cycling mix tuned to my sweat chemistry. 3. I had Claude scale the batch to match my available supplies. 4. I had Claude generate print-ready labels and batch sheets.

I’ve automated 90% of my payroll work at an engineering firm. I use Claude Code to write Python scripts that pull timesheets from our ERP, Deltek Ajera. I check the data for oddities and, once everything looks right, push the timesheets into our HRIS, Paycom, through its API. I also have a script that parses and compares the preliminary payroll register with the timesheet data. Once I’m satisfied with the results, I can submit payroll. After payroll, my scripts create all the benefits upload files I used to create by hand. The spreadsheets I relied on for years are no longer necessary. Do I even need a spreadsheet anymore? Step-by-step: 1. I use Claude Code to write Python scripts for the payroll process. 2. I pull timesheets from Deltek Ajera, our ERP. 3. I check the timesheets for oddities. 4. Once the data looks right, I push the timesheets into Paycom, our HRIS, through its API. 5. I parse and compare the preliminary payroll register with the timesheet data. 6. Once I’m satisfied with the comparison, I submit payroll. 7. After payroll, I run scripts that create the benefits upload files I previously created by hand.

I used ChatGPT + Button to understand my dog’s blood work in language I could follow. Every couple of weeks, I uploaded all of my dog’s blood work PDF files and provided the information verbally that wasn’t included on the forms. It helped me understand which markers were important and compare the results from week to week, including where values were changing. That gave me a better foundation for conversations during veterinary appointments. During a difficult time, it also gave me peace of mind in a way nothing else could. It feels strange to say that, but it’s true. Step-by-step: 1. I uploaded all of my dog’s blood work PDF files to ChatGPT + Button every couple of weeks. 2. I provided the relevant information verbally when it wasn’t included on the forms. 3. I used it to identify which markers were important. 4. I compared the results from week to week and reviewed where the values were changing. 5. I used that understanding to have better conversations with the veterinarian.

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

My car recently lost a small part near the bonnet. I didn’t know what it was called, and even the official workshop couldn’t help because the model was no longer in production. I gave ChatGPT my car details and a photo showing where the part was missing. It identified the part, helped me cross-check the specifications and compatible part numbers, and found sellers that had it available. I found the right part and had it delivered within a week. Step-by-step: 1. I shared my car model and a photo of where the part was missing. 2. I used ChatGPT to identify the part and its specifications. 3. I cross-checked compatible part numbers and alternatives. 4. I searched for sellers carrying the correct part. 5. I compared the options and ordered the right one.

This mobile app organizes a field service technician’s entire workday in one place. It records departure and arrival times, on-site work, parts purchases, reports, return travel, and mileage. The app automatically identifies missing details, saves unfinished jobs, and allows them to be edited later. Filters make it easy to find a task by store, job number, date, or month. Data can be safely exported, transferred to another device, and downloaded as Excel or PDF files. Step-by-step: 1. Record the technician’s departure and arrival times. 2. Log on-site work, parts purchases, reports, return travel, and mileage. 3. Review the app’s indicators for missing details and complete any unfinished information. 4. Save unfinished jobs and edit them later when needed. 5. Use filters to find tasks by store, job number, date, or month. 6. Export the data safely, transfer it to another device, or download it as an Excel or PDF file.

I used AI to develop a simple daily care plan for my above-ground pool. I copied the links to the pool I bought online and asked which chemicals would be best and whether I should make any upgrades right away. Then I asked AI to create a daily routine to keep the pool sparkling throughout the summer. When the water started looking cloudy, I took pictures of the water tests I was running and shared them so AI could help me get the pool back where it needed to be. Step-by-step: 1. I copied the online links for the above-ground pool I bought. 2. I asked AI which chemicals would be best for the pool and whether I should make any upgrades. 3. I asked AI to create a daily pool-care routine for the summer months. 4. When the water became cloudy, I took pictures of the tests I was running on the water. 5. I shared the pictures with AI to get guidance on bringing the water back to the right condition.

I used Claude Cowork to replace a weekly analysis of closed-end funds for a weekly newsletter. I created a project that uses Claude for Chrome to scrape and download all closed-end pricing information from a CEF website. It adds that information to a weekly dated spreadsheet and calculates changes from the prior week, month, and year. It also updates other data points, including graphs, Top 10 and Bottom 10 rankings, and our own portfolio of funds. Step-by-step: 1. I created a Claude Cowork project for the weekly closed-end fund analysis. 2. I used Claude for Chrome to scrape and download all closed-end pricing information from a CEF website. 3. I added the information to a weekly dated spreadsheet. 4. I calculated changes from the prior week, month, and year. 5. I updated the graphs, Top 10 and Bottom 10 rankings, and our own portfolio of funds. 6. I used the resulting analysis for a weekly newsletter.

I built an interactive AI recommender for Medium publications and packaged it as a Gemini Gem. Medium writers who want their articles to be discovered can submit their pieces to a publication, which is like a digital magazine focused on a specific topic. However, there are hundreds of publications, so it can be difficult to find the right one for a particular article. A key resource is "Medium's Huge List of Publications Accepting Submissions." It contains basic information about each publication, but the list is difficult to navigate because of its size. My solution was to organize that information and use it as the source for an AI recommender. I packaged the system as a Gem because the interface is cleaner, and users do not need to see the sources I used. Step-by-step: 1. I asked Gemini to compile and format basic information for each publication, including its topic, size by number of followers, and a short description. 2. I consolidated that information in a Google Sheet. 3. I used the spreadsheet as a source for a Google Notebook (formerly NotebookLM). 4. I added instructions for the AI, like the following: "You are an expert guiding the user to find the ideal publications for their articles in Medium. Ask the user to write down what their interests, topics, etc., are; whether they are beginner writers; whether they want to start with a small publication (less than 1,000 followers), mid-size (a few thousand), or only the biggest (tens or hundreds of thousands). Ask them for any other personal information and details about their writing, and take that into account." 5. I packaged the system as a Gemini Gem instead of distributing it as a Notebook so users could access it through a cleaner interface without seeing the sources. It can be accessed at the following link: https://gemini.google.com/gem/1HDPzcE6Jls76V4I2tFZhIn-SbeeDe-_-?usp=sharing

I used to open calls by asking people to remind me where we left off. The notes existed, but they were scattered across transcripts that nobody reviewed. I built two scheduled tasks that work together: one files every meeting at the end of the day, and the other sends me a prep brief every morning. At the end of each day, the first task pulls the verbatim transcript of every meeting I had into a shared Notion database. I use the transcript rather than the AI summary because summaries may be useful that afternoon but are less useful three weeks later when I need the exact thing somebody said. Each meeting becomes a page with the date, client, and attendees stored as real relations rather than text, so everything is filterable later. My business partner has access to the same database, so neither of us has to recap our calls for the other. At 7 a.m., the second task reads my Outlook calendar, finds the email thread or threads tied to each meeting, reads the associated transcripts in Notion, and writes a short prep brief for each one: what we said last time, what I owe them, and what is still open. The part that took the most thought was deciding what should not be filed in the main database. Personal meetings are skipped by keyword. Small internal meetings are screened for topics such as pay, hiring, legal matters, or client-confidential material. Those meetings are routed to a separate database with different permissions. When a meeting is ambiguous, it defaults to the restricted database. Failing toward privacy is the right default when a robot is making the decision. Step-by-step: 1. I turned on Zoom AI Companion so every meeting produces a transcript, then connected Zoom, Notion, and Outlook. 2. I built a Notion database for meeting notes with Date, Client, and Attendees as relation properties connected to existing Clients and People databases. These relations make the notes findable later. 3. I wrote the end-of-day task to pull each transcript verbatim, create a page, match the client by keyword against my client list, and add attendees based on the transcript speakers. 4. I filtered the speaker list because notetaker bots appear as attendees. I removed Fireflies, Otter, Fathom, and the other notetaker bots, and automatically created a person page for anyone who was genuinely new. 5. I deduplicated meetings using the title and date. If a page already existed as a placeholder, I updated it in place instead of creating a second one. 6. I added a skip list for personal meetings and a confidentiality screen that routes sensitive internal meetings to a separate, permission-restricted database. When the classification is unclear, it defaults to restricted. 7. I wrote the morning task to read that day’s calendar, search email and transcripts for each attendee and company, and produce one short brief per meeting covering the last contact, open commitments, and what I owe them. 8. I scheduled both tasks: the filing task for the end of the day and the briefing task for early morning.

I regularly use ChatGPT for lesson planning and materials development with students ranging from EFL learners to UK undergraduates. I keep a separate anonymous thread for each student, so GPT can track the context and suggest the best direction for the next session. I also contribute my experience as a tutor while using AI to create fresh worksheets based on typical materials from various UK exam boards. Today, I had a successful interview for a lecturer role. Gemini helped me design and plan my demo seminar, and it looks like I’ve landed the job. Step-by-step: 1. I create a separate anonymous thread for each student. 2. I use ChatGPT to track each student’s context and suggest the best direction for the next session. 3. I combine AI-generated ideas with my experience as a tutor when planning lessons and developing materials. 4. I use typical materials from various UK exam boards as the basis for creating fresh worksheets. 5. For my lecturer interview, I used Gemini to design and plan my demo seminar. 6. I had a successful interview, and it looks like I’ve landed the job.

I built an episode with the wrong voice. It was not a bad take; it was the voice of a different project entirely—a narrator I had cloned for another series months earlier. Nothing in my files identified which voice belonged to which show, so the assistant picked the one it had seen most recently. I did not catch the mistake until the mix. That is what working with agents on anything long actually costs you: not bad output, but amnesia. Every session starts cold, so settled decisions get reopened, undocumented rules get broken, and the same argument returns every week wearing a different hat. I run several short-form historical and science-fiction series at once, and they all survive on one file each. It is not documentation or a spec. It is what film crews have used for a century: a series bible combined with a daily production report, pointed at an agent instead of a hundred people. I use one Markdown file, read at the start of every session and updated when the session closes rather than when it opens. Four sections do the work: Step-by-step: 1. Closed canon: Each decision includes its reason. Mine says the opening shot is never a contemplative establishing shot. It opens mid-action, with the text hook on screen by the first second, and the beautiful wide shot comes second as the breather. I write the reason next to the decision because the plan for the current episode came back with that wide shot opening the sequence, and I had to reorder it again. The decision alone stops nothing; the reason keeps the rejected version from returning. 2. Rejected list: I record what was already tried and exactly why it was dropped. The wrong voice lives here now as one line: never reuse assets across projects without confirming. This is half the value of the document, and it is the half almost nobody writes. 3. State table: I track each item, its known defects, and the decision already made about it. Mine currently reads: lips at 62.5 to 63.5 seconds, native voice at 64.1 to 65.6, voice moved forward and the original position ducked. A defect written down with its fix is an instruction. A defect nobody records is work you pay for twice. 4. Next three actions: I list concrete next steps, each naming the file it touches. Never “keep going.” Step-by-step: 1. Create `HANDOFF.md` at the root of the project before any real work starts. 2. Write the goal, deadline, and delivery constraints. Anything external that forces your hand goes here instead of staying in your head. 3. Add every consequential decision to the canon, along with its reason and what broke with the alternative. 4. Whenever something is tried and rejected, add a row to the rejected table. It takes fifteen seconds and can save an afternoon. 5. Maintain a state table of the real items, including their defects and agreed fixes. 6. Close every session by updating only three things: the state, the new rejections, and the next three actions. 7. Open every session with: “Read `HANDOFF.md` in full before proposing anything. The canon and rejected list are not up for discussion. Verify the real state against the files, then tell me where we are in two lines.” The discipline that makes this work is updating the file when you close a session, not when you open one. At the end of a session, you still remember why you made the decisions. The next morning, you do not—and neither does the agent. The template is at the bottom. It costs nothing and it is a text file.

I developed a platform that helps users learn dimensional modeling and create entity-relationship (ER) diagrams through a drag-and-drop interface tailored to specific use cases. I noticed that many people struggle with visualization and face a significant gap between understanding database concepts and creating tables. This can make it difficult to work independently or determine which type of table to use and when, including whether to create a dimension or fact table. Step-by-step: 1. I identified the difficulty many people have visualizing dimensional modeling concepts. 2. I created a platform focused on learning dimensional modeling and ER diagrams. 3. I built a drag-and-drop interface tailored to specific use cases. 4. I designed it to help users understand how to create tables and determine whether to use a dimension table or a fact table.

I created a website lead workflow that researches each company, scores the opportunity, updates my CRM, drafts a personalized reply, and notifies me on WhatsApp. I had previously built similar workflows with Claude Code, but connecting external applications was often the hardest part. I had to manage OAuth setup, credentials, APIs, and different integration requirements for every app. I also found it difficult to monitor and control completed automations from WhatsApp without building additional infrastructure. To solve this, I created Awish, a tool focused on AI-powered automation. Instead of manually designing every workflow, I describe the result I want in chat. Awish’s agents understand the request, plan the automation in the background, determine which applications and steps are required, and prepare the complete workflow for me. When a new lead submits my website form, the workflow researches the company, evaluates the lead against my criteria, assigns a score, and adds the contact and research results to my CRM. It then drafts a personalized response based on the lead’s company and needs before sending me a WhatsApp notification for review. The application connections are handled through a simple sign-in flow. I connect my personal accounts with a click instead of manually working with OAuth code, API keys, or custom authentication logic. Once the workflow is active, I can monitor it, receive updates, and manage its actions directly from WhatsApp without opening the Awish application. Step-by-step: 1. I open the Awish chat and describe the workflow I want: when someone submits my website form, research the company, score the lead, add it to my CRM, draft a personalized response, and notify me on WhatsApp. 2. Awish’s agents analyze the request and create the application and automation plan on my behalf, including the trigger, research steps, lead-scoring logic, CRM fields, response draft, and notification. 3. I review the proposed plan and sign in to the required applications with my personal accounts to connect them to the workflow. 4. Awish builds the automation so each new website submission triggers company research and collects the information needed to evaluate the opportunity. 5. The workflow scores the lead, creates or updates the CRM record, and stores the contact details, company research, and lead score in the appropriate fields. 6. It drafts a personalized response using the information submitted by the lead and the additional company research. 7. I connect WhatsApp from the Awish chat, and the workflow sends me the lead details, score, CRM update, and response draft there. 8. I review and manage the automation directly from WhatsApp without needing to open Awish or build a separate messaging integration. The result is a lead-management workflow I can create through a conversation, connect to my existing applications without manually implementing OAuth, and control from WhatsApp while the agents handle the planning and execution in the background.

A finished video can be wrong in ways you cannot see—not because of the edit, but because of the delivery file itself. That is what gets work sent back, and it is rarely the craft. I built a delivery check for this. I give it a finished file, tell it where the file is going and what kind of piece it is, and it measures the things that cause rejections: sample rate, mono audio, integrated loudness against the destination target, true peak, dynamic range against a band rather than a single number, A/V drift, whether the shots cut together, and whether the file can stream before it has finished downloading. Most of those checks are for sound, because most of what gets sent back is sound. Picture problems are visible on a screen. A file that is 2 dB too quiet or peaks at -0.7 dBFS can look perfect and still come back. For everything it can fix, the checker gives me the exact `ffmpeg` command, with the numbers already calculated for that file. It does not merely describe the fix, and it does not hand me a corrected file. That was the decision that mattered. A fixer is a black box. You never learn that you had a problem, so you make it again the following week. Then, when your editing tool adds an “optimize on export” button, you have nothing. An inspector that explains the problem in one sentence and gives you the command teaches you the standard once and remains useful when the tools change. Three things determined whether I would actually use it, and none of them are checks. “Two severities, never one.” Something either bounces, or it needs your eyes. A tool that only says “bad” gets ignored on the third run, because half of what it flags is a decision you made on purpose. Sample rate, mono, and true peak bounce without argument, and they get a command. Loudness and dynamic range need to be reviewed first. My dynamic-range check says in plain words that the result is often deliberate and should be fixed at the source rather than in the master. “A check that refuses to give a verdict.” On vertical video, the platform interface covers the bottom 26 percent and the top 12 percent. I flag high-contrast elements in those zones but deliberately do not fail them, because the detector cannot tell a caption from a bright patch of sky. The report explains that limitation. A check admitting what it cannot know is what makes the checks that do commit worth trusting. “The thresholds are mine; the code only applies them.” They live in a table: destination crossed with content. Social wants -14 LUFS, a festival master wants -18 with a wider tolerance because festivals provide a band rather than a number, and broadcast wants -23. A scripted short is allowed to be denser than a screencast. That table is the whole product. For example, to catch shots that do not cut together, I measure the luminance range across the piece. The first version used average brightness per frame and kept flagging legitimate night photography. A fade to black has nothing bright in it; a night scene does—a streetlight, a moon, or a face. Changing the discriminant to the brightest pixel in the frame instead of the average eliminated the false positives. That took ten minutes of thinking, and no amount of better code would have found it. Step-by-step: 1. I wrote down what had actually gotten my work sent back over twenty years before writing any code. I captured the scars rather than making a spec sheet; that list became the product. 2. I gave every check a severity: it bounces, or look before you send. Anything I could not confidently put in one bucket became informational, with no verdict at all. 3. I made every check return four things: the measured value, pass or fail, why it matters in one plain sentence, and, where possible, the command that fixes it. 4. I put the thresholds in a profile table instead of hardcoding one standard, because -14 LUFS is right for social and wrong for a festival. 5. I added a parameter for whether the file is my own master or a copy pulled from a platform. On a downloaded copy, half the container checks measure someone else’s transcode rather than my work, so they are skipped and the report explains why. 6. When two fixes would collide, I output only one command. If loudness already needs a gain change, the limiter goes inside that command instead of being offered separately; otherwise, I would run two instructions that fight each other. 7. I tuned the checker against real files until the false positives stopped. Ignoring the top and bottom five percent of frames eliminated the ones caused by a single stray frame. 8. I made the output a report. I read it, decide, and run the command myself. The functions are an afternoon of work, and anyone can copy them. What is not written down is the list of what to check, at what threshold, and why.