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

AI agents such as Claude Code, Codex, and Gemini can install skills, plugins, and CLI tools in seconds. That is convenient, but each add-on runs with access to files, passwords, and accounts. A malicious add-on could steal API keys, read private data, or quietly take control of the agent. I use `agent-guard` to make “check first, install after” the default. Before installation, it examines AI agent skills, MCP servers, and CLI tools for malware, prompt injection, and credential theft using professional, open-source security scanners from NVIDIA, Cisco, Datadog, and the Open Source Security Foundation. The tool returns a clear verdict: safe to install or blocked, with the exact reason. It then installs only the verified version, preventing a different version from being swapped in between. A single check can also cover multiple AI agents, installing the approved add-on into every agent on the machine. Free and open source: https://github.com/elliottwaves-20/agent-guard Step-by-step: 1. I select the AI agent skill, MCP server, or CLI tool I want to install. 2. I run `agent-guard` to scan it for malware, prompt injection, and credential theft. 3. I review the verdict and the reason if the add-on is blocked. 4. I install the exact version that was checked rather than an unverified replacement. 5. If I use several AI agents, I install the approved add-on into all of them at once.

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.

I spent twenty years producing documentary and nonfiction films, all of it the expensive way: crews, schedules, financing, and commissioners saying no. I'm proud of much of that work, and I still think about the films that never got made because the money wasn't there. Generative video pulled me in, but not for the reason people assume. It wasn't the speed or the cost. It was the fact that I could finally finish something without asking anyone for permission. No green light from a major platform. Nobody deciding that a story was too small to deserve a crew. A year later, I could produce this way. It turned out to be a different job rather than the same job with new tools. Then I ran into a problem I hadn't considered: how do you show the work? A finished shot doesn't prove much anymore. A client can look at a beautiful frame and have no way to tell whether it took three weeks or three minutes. If I'm honest, neither would I in their position. The thing every portfolio is built to display had stopped being evidence. I'm not a developer. I produce films. The site is bilingual, has seven sections, includes a case study for each film, plays video on hover, and has a comparison slider that works with a thumb as well as a mouse. I built all of it. I'd wanted this exact site for about fifteen years and had never managed to explain it properly to anyone I paid to make it. This time, I stopped explaining and built it myself. The middle of the page has a slider that you drag between the storyboard panel and the final shot. A basic before-and-after would prove nothing; you can fake that by generating twice. The storyboard is the proof because the framing, eyeline, and decision about what stays outside the frame all existed on paper before any model was asked to generate anything. You drag the handle and watch the intention survive. The rest of the site came from the same place. Video only plays on hover and is silent until you click for sound. Most video portfolios are unreadable because fifteen things start moving at once. The sections are organized by register rather than by client: epic, brand, animation, and lifestyle. A wall of logos answers who has hired you, which nobody is actually wondering. What they want to know is whether you can change tone. Nothing is cropped to fit the grid. A 5:33 film sits in 16:9 next to a 2:42 film in scope, and the layout is lopsided because of it. I nearly made them uniform because it looked tidier, then realized I was about to reformat my own films so a webpage would look neat. Anyone who cuts for a living spots that immediately. Concepts are labeled as concepts. Experiments have their own section instead of being scattered among the client work and hoping nobody asks which is which. Step-by-step: 1. I started from what my client couldn't verify: the craft behind a shot. 2. I found the artifact that proves it. It's usually the ugly thing nobody publishes: the storyboard, the reference sheet, or the version before the good version. 3. I put that artifact next to the finished piece inside one interaction, so nobody has to search for the proof. 4. I made playback deliberate. Video plays on hover, and sound requires a click. 5. I sorted the work by the question being asked rather than by the credentials I wanted to lead with. 6. I didn't reformat the work to fit the layout. I let the grid be uneven. 7. I labeled everything honestly: client, concept, or experiment. One word each can pay for the credibility of the whole page. 8. I wrote a brief for each section as a document first. Arguing with a paragraph is free; arguing with a built page is not. 9. I built the site with an AI coding tool. This was the least interesting step, even though it's the one everyone writes about. If your work can be mistaken for a lucky prompt, stop trying to prove it with the finished piece. The site is at www.termopilas.tv if you want to drag the handle yourself.

I use ChatGPT to turn a physical trading card collection into a structured digital inventory. I start by photographing the collection and uploading the images to Google Drive. I divide the cards into logical groups and store them in separate subfolders, creating a clear structure before identification begins. ChatGPT then works through the folders in manageable batches, using OCR and visual recognition to extract information from the cards. This avoids manually uploading and describing every card one by one. I use consistent processing rules to reduce mistakes: I limit the number of cards per batch, make sure every source image is accounted for, and use one central card per photo when identification could otherwise be ambiguous. For each card, ChatGPT helps identify and organize the information I want to keep: card name, set code, set or series, edition, rarity, language, quantity, approximate year or period, condition notes, confidence level, and the source image. The useful part is not just OCR or card recognition. It is the combination of a structured Google Drive archive, visual identification, consistency checks, and systematic data extraction across a large physical collection. When identification is uncertain, I record that uncertainty rather than silently guessing. Damaged or unusual cards can also receive specific notes, such as foil scratches, edge wear, folds, or other condition issues. Once all folders have been processed, I consolidate the separate batches into one central inventory so I can check duplicates, quantities, and inconsistencies more easily. I first used this workflow for a Yu-Gi-Oh! collection and plan to reuse the same process for a Harry Potter trading card collection. The result is a searchable, structured overview of a physical collection that can later be used for valuation, selling, insurance, cataloguing, or simply knowing what is actually in the boxes. Step-by-step: 1. I photograph the physical trading card collection. 2. I upload the images to Google Drive and divide them into logical groups stored in separate subfolders. 3. I process the folders with ChatGPT in manageable batches using OCR and visual recognition. 4. I limit the number of cards per batch, account for every source image, and use one central card per photo when needed to reduce ambiguity. 5. I extract each card’s name, set code, set or series, edition, rarity, language, quantity, approximate year or period, condition notes, confidence level, and source image. 6. I record uncertainty instead of silently guessing and add specific notes for damaged or unusual cards, such as foil scratches, edge wear, and folds. 7. I consolidate the processed batches into one central inventory to check duplicates, quantities, and inconsistencies. 8. I reuse the process for additional collections, including my planned Harry Potter trading card collection.

I’m a nurse with no tech experience, but I’m curious and have many creative ideas. I used Claude to build a website that helps people plan which vegetables to grow based on their location, available space, and the time they have. Veggiegrowguide.com Step-by-step: 1. I identified an idea for helping people choose vegetables to grow based on their location, available space, and available time. 2. I used Claude to help me build a website for the idea. 3. I created Veggiegrowguide.com as a resource for people planning their vegetable gardens.

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

I 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 named `IMG_8834.JPG`. Renaming and filing them took about an hour per visit, when it happened at all. When it didn’t, the photos sat unnamed and unfindable. For an architecture firm, that creates a professional liability gap because the photos 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 eye of a residential architect, describe what the image actually shows using our professional vocabulary, and rename the file in a consistent format. `IMG_8834.JPG` becomes `2026-07-17_03_side-elevation-porch-brick-piers.JPG`—searchable, legible, and filed. 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 identical 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. This is the safety practice I’d urge anyone to follow: the skill can see and touch only what you connect, so connect the narrowest folder that does the job. 3. I created a skill that tells Claude to read each photo, identify what it shows using the industry’s vocabulary, and rename each file in a standard format. I wrote mine for residential architecture, but the approach also works for real estate, inspections, insurance, and other field work. My format is `date_sequence_description`. 4. I ran the skill with one command, and Claude worked through the folder photo by photo. 5. The renamed photos were filed into a dated site-visit folder, ready to reference by number in reports. 6. I handed the skill file to teammates so they could run it on their 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

I built a predictive maintenance workflow in Awish for one of my manufacturing clients. The client had machine telemetry, production data, and maintenance history spread across different systems. The problem wasn’t collecting the data—it was spotting failure risk early enough to act. I built a custom Awish workflow that continuously checks machine telemetry and production signals in Snowflake alongside asset, meter, and maintenance history from MaintainX. When it detects abnormal performance or increasing failure risk, it identifies the affected equipment, estimates the likely operational impact, and prepares a recommended maintenance action. Nothing is scheduled automatically at that point. The recommendation first goes to the maintenance manager in Microsoft Teams for approval. Once approved, Awish creates and assigns the work order in MaintainX, then keeps tracking and updating its status until the maintenance is completed. The useful part is that the system does not wait for a machine to fail before maintenance starts, but it also does not let AI make the maintenance decision on its own. The analysis is automated, while the actual intervention still requires human approval. Step-by-step: 1. I described the maintenance process I wanted in the Awish chat. 2. Awish planned the workflow and selected Snowflake, MaintainX, and Microsoft Teams for the required steps. 3. I connected the client’s accounts and approved the automation plan. 4. Awish continuously analyzed production and telemetry data in Snowflake together with MaintainX asset, meter, and maintenance history. 5. When it detected abnormal behavior or increasing failure risk, it identified the affected equipment and estimated the likely operational impact. 6. It prepared a recommended maintenance action and sent it to the maintenance manager in Microsoft Teams. 7. Once the manager approved the recommendation, Awish created and assigned the work order in MaintainX. 8. The workflow continued tracking the work order and updating its status until the maintenance was completed. Trigger → Analyze → Approval → Action Machine signals → Failure-risk analysis → Teams approval → MaintainX work order

I asked ChatGPT to create a graphic for my company. I provided our company colors, logo, brand guide, the objective of the graphic, and information about our audience. ChatGPT then created the graphic based on those details. Step-by-step: 1. I asked ChatGPT to create a graphic for my company. 2. I provided our company colors, logo, and brand guide. 3. I explained the objective of the graphic. 4. I described the intended audience. 5. ChatGPT created the graphic using the information I provided.

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.

For years, my family has run a shared birthday fund: five of us contribute a fixed amount for each birthday, while the person whose immediate family is celebrating that month is exempt from paying. Tracking everything in a payment app and a chat thread meant nobody knew the balance, who was behind, or what the next gift would cost. I rebuilt the fund as a small web app with Claude. The app itself isn't the only reason I'm writing this up. The same build is also the demo I use to teach clients and students how AI-assisted product development actually works, including the parts that go wrong. Step-by-step: 1. I described the real rules instead of presenting Claude with a generic app idea: the contributors, the fixed amount per person, the family-exemption rule, and birthdays with birth years so ages could be calculated automatically. Claude built the app as a single, self-contained HTML file with no build step or server, so it opens in any browser. 2. I worked in phases and asked Claude to explain its reasoning at each stage. Instead of using one giant prompt, I added one layer per session: the calculation engine, the setup screen, then reports and CSV export. The explanations made the sessions reusable as teaching material. 3. I required the app to be configured through its own interface rather than by editing code. This was the turning point. Claude removed the hardcoded demo family and added a full setup screen for the group name, contributors, deposits, birthdays, amounts, and alerts. I can now build a family from scratch live in front of a class in about [X] minutes without showing a line of code. 4. I let a data-loss incident shape the next phase. I entered the real family data, then the browser tab closed and the download link I had been using to open the file broke. The data was stored in browser storage tied to that exact URL, and I had no backup. Nothing was recoverable at the time. 5. I turned that failure into features. Claude added CSV export for both reports, CSV import that automatically detects which file it is reading, and a backup reminder that appears in the app's alert banner when the data has never been backed up or has not been backed up for seven days. We also discovered that birth year was missing from the export, which meant a re-import would have silently lost everyone's age. 6. I had Claude test its own work. Before each handoff, it ran a jsdom test suite in a sandbox. By the end, the suite had 46 tests covering the exemption math, empty states, CSV round-trips, and backup logic. Several real bugs surfaced there instead of in front of a class. 7. I made a second version for a different audience. One prompt produced a fully English, left-to-right translation with flipped directional CSS, Latin typography, US date formatting, dollars instead of shekels, and Venmo and Zelle instead of local payment apps. It was a genuinely different build, not a find-and-replace translation. The project took 14 sessions over one week and six hours total. It had no hosting cost, dependencies, or accounts. The data still lives in the browser's local storage on each device. Opening the file on my phone and laptop creates two unrelated pools, so CSV import is the manual bridge between them. There is no authentication or sync; this is a personal record-keeper, not shared infrastructure. The data-loss incident was not a Claude failure. I failed to build a backup path before entering real data. If I did it again, I would add export before adding a single feature. The highest-leverage prompt in the whole project was not a feature request. It was: "let me configure this through the interface instead of the code." That shift turned a static demo into something my family actually uses and my students can watch being built from an empty screen. The broader point is that the failure was the most useful part of the project. A polished demo teaches people that AI makes building easy. Losing the data and rebuilding the safety net around it teaches them what building actually involves—and that is the lesson that survives the workshop.

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.

I'm not a professional developer, but I built Sujido, a live word puzzle, with multiple AI agents. For months, they gave me bloat, lost context, and slop, and neither I nor the models could untangle what had been decided or why. I eventually settled on two agents: one Claude instance that plans and reviews, and another that builds. I imposed rules on both, one failure at a time. None of these rules would surprise a professional engineering team, but nobody handed them to me. That's the key lesson I learned: agents won't bring the discipline for you. You have to impose it. When I showed the first game revision to strangers, their verdict was that the first half was "boring" and the second half was novel. It was hard news to hear about my baby, but I took the feedback to heart and cut the game in half. That required surgery on code tangled across both halves, followed by a rebuild under the rules below. Before the rebuild, a separate AI audit graded the codebase B−. Afterward, it graded it A−. The deployed site shrank by 97.5%, and every serious finding was fixed and locked in by an automated test. The models didn't change drastically, but my operating rules did. Step-by-step: 1. I wrote a constitution before the first prompt. The repo holds what every agent must read before working: `CLAUDE.md` files for the project as a whole and for each major part of the code, a collaboration protocol for how the agents and I work together, a spec for the core data format, and a decision log. The data format is changed there first and then in code. Nothing is remembered unless it is written down. That's my life as well. :) 2. I split the work by role, not by task. One Claude instance is the strategist: it writes briefs, reviews reports, and never commits code. Claude Code in VS Code is the builder: it executes the brief, writes the tests, reports back, and never releases. Neither agent can approve its own work. 3. I made every job start from a written brief, and I never edit briefs. Each brief is committed to the repo with an exact scope, such as "do X only, do not begin Y." If plans change, a dated amendment states what it supersedes. The builder may skip a risky item with a written reason; skipping is better than forcing it. 4. I used mock-ups with real data instead of descriptions. Anything I will look at gets a mock-up, and I approve it before any code is written. I learned this when a status report described only in words arrived on my phone formatted as a wall of text. The approved mock became the spec, and the tests pin the output to it. 5. I proved that every test could fail. No test is trusted until it has been run against deliberately broken code and caught the bug. A test suite that has never failed hasn't proven anything. 6. I verified reports against the real repo. Agent reports drift. One summary said players rated a puzzle "just right" when the log said "too easy." An audit said there were about 25 unused functions; a recount found 29. The strategist spot-checks load-bearing claims against the actual files and data before anything ships. 7. I built gates the agents can't talk their way past. All work lands on a branch that auto-deploys to a test site. GitHub Actions lints and runs the Python and headless-browser tests on every push. A git hook refuses direct pushes to production. Releases are fast-forward merges that only I perform, after CI is green and I've tested the build personally. The live site shows the release's commit ID, and I check it before calling it shipped. Nothing merges automatically. An agent's "looks good" is just another report, and reports drift. 8. I gave the system a memory. Every session ends by updating the decision log and a "resume here" document, so the next session—a fresh model with no recollection—picks up exactly where the last one stopped. Without this, every session starts by relitigating old decisions. 9. I let the data and end users overrule me. A scheduled GitHub Action turns player telemetry into a daily report. It showed that the difficulty dials I assumed mattered did not predict what players found hard; what mattered was how misleading the starting arrangement was. When testers were confused by the tutorial, I rebuilt it even though I had already approved it. Player feedback about their own experience outranks my earlier rulings. AI agents are velocity multipliers, but they multiply bad structure as quickly as good code. The rules came from me, not the models: the AI writes the code, while the rules, gates, and written record keep the process honest. See the result at Sujido.com. Finding the anagram is the easy part; sliding it into place is the hard part. One board took me 902 moves. My S.O. solved it in 242, and I haven't heard the end of it. Try to break it!

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.

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

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

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.