Workflow Hub

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.

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.

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

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

Build a Tiny HTML Research Logger Instead of Fighting a Spreadsheet Turn repeated research measurements into a simple phone-friendly interface instead of making participants wrestle with spreadsheets. Some research data is simple. Collecting it often isn't. Imagine recording pain, energy, mood and a few additional variables several times during a study. A spreadsheet can technically do this. But on a phone? Open the file, find the right row, locate the columns, enter values without accidentally changing something, save and close. That's a ridiculous amount of interface for a tiny measurement. If recording how you feel takes ten seconds mentally but two minutes administratively, the tool has become part of the research burden. So I asked: What is the smallest interface someone actually needs when logging an observation? My answer was a tiny HTML page that works on both phone and desktop. 1. Separate the interface from the dataset Participants shouldn't need to interact with rows, columns or database structures. They should see a few simple fields: Pain, Energy, Mood, Optional Note and Save. Behind the interface, each submission becomes a structured record containing the measurements, a timestamp and any optional context. The researcher gets organised data. The participant gets simple controls. 2. Define the research measures first Before asking AI to build anything, establish what you're measuring. Which variables matter? What does each scale mean? Which values are allowed? Should measurements remain comparable over time? These are research decisions, not interface-design decisions. AI can help implement your measurement system, but shouldn't quietly invent the methodology. 3. Design for repeated use A questionnaire completed once can tolerate some friction. A logger used several times a day cannot. Make controls large enough to tap comfortably. Use readable labels, vertical layouts and obvious actions. Avoid unnecessary navigation, tiny cells and repeated setup. Design for the phone first, then let the interface adapt to larger screens. And test the fifth entry, not just the first. Something that looks elegant during development can become irritating when you're tired, distracted or recording yet another observation. The ideal repeated action is almost boring. That's a compliment. 4. Automate the invisible work Participants shouldn't have to enter information the system already knows. A logger can automatically generate timestamps, record identifiers and technical metadata. Each submission should become one coherent record. Show a clear confirmation when saving succeeds and prevent accidental duplicates. Keep optional notes available without turning every measurement into a diary assignment. Don't make participants do the database's job. 5. Keep the interface neutral A research logger is a measurement instrument. Its colours, labels, ordering and controls shouldn't subtly suggest which answers are desirable. Likewise, the logger doesn't need to interpret someone's measurements or announce that their mood seems lower on Tuesdays. That's analysis, not collection. First gather observations reliably. Interpret them later using appropriate research methods. 6. Decide where the data lives A single HTML file can provide the interface without requiring a full application. But HTML alone doesn't provide persistent storage or synchronisation. Browser storage may work for a local prototype, although it has limitations. For research involving several devices, participants or longer periods, you'll need suitable storage and export options. A phone and laptop displaying the same interface don't automatically share observations. Keep the dataset consistent and exportable, for example as CSV. For sensitive information, include appropriate privacy and security safeguards. 7. Build only what's necessary It's tempting to expand a tiny logger into an entire platform. Dashboards! Charts! Profiles! Notifications! Accounts! Perhaps later. Start with Open → Measure → Save. Test the process repeatedly on phone and desktop. Improve whatever causes genuine friction. You can enlarge buttons or rearrange the layout without changing the study. But changing a measurement scale is a research-design decision, not a cosmetic update. The workflow Define the variables and scales → ask AI to build a responsive HTML logger → add automatic timestamps and structured records → choose suitable storage and export methods → test repeated logging → refine usability without changing the measurements. Why this works A spreadsheet is excellent at displaying a dataset. That doesn't make it the best place to create one. Researchers think in variables, records and analysis. Participants simply need to answer the question in front of them. Those shouldn't have to be the same interface. Sometimes the best research tool isn't a sophisticated platform. It's a tiny page that gets the spreadsheet out of the participant's way.

I built a model dispatcher to avoid paying premium usage for simple tasks. In Claude, every task runs on the model used by the current session, so a two-line formatting fix can consume the same level of model capacity as a difficult strategic problem. I had Claude build a scoring system that evaluates each task across six dimensions: required reasoning, the amount of context, the importance of craft or nuance, whether speed is the priority, the number of agentic parts involved, and the potential consequences if something goes wrong. Based on the score, it recommends a model—from a light, fast option for rote work to the most capable option for genuinely difficult tasks—and suggests how much effort that model should apply. The key design choice is that the dispatcher never spends anything automatically. Scoring is free and instant, while sending the task to a model through the API costs real money. Dispatching therefore requires an explicit confirmation flag every time. Nothing runs without me saying go. The payoff is not dramatic from day to day. It comes from many small savings that add up, along with a habit shift: I check the router before sending a task instead of wondering afterward why a simple request cost more than it should have. Step-by-step: 1. I identified the problem: every task in a Claude session uses the current model, even when the task is simple. 2. I had Claude build a scoring system that evaluates each task across six dimensions: reasoning, context, craft or nuance, speed, agentic complexity, and the potential consequences of failure. 3. I used the score to recommend an appropriate model, from a light and fast model for rote work to the heaviest model for genuinely difficult tasks. 4. I included a recommendation for how much effort the selected model should apply. 5. I kept scoring free and separate from dispatching, since sending a task through the API costs money. 6. I required an explicit confirmation flag before dispatching any task, so nothing runs automatically. 7. I check the router before sending tasks and benefit from small savings that accumulate over time.

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.

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.

GeneTrust AI — Asistente Genético Virtual (AGV) es una plataforma tecnológica concebida bajo una arquitectura basada en evidencia (Evidence-First), asistida por IA y gobernada por humanos. Está diseñada para facilitar el acceso, la estructuración, la exploración, la clasificación, la priorización y la síntesis trazable de evidencia genética y biomédica. Su diseño busca prevenir riesgos críticos de la IA en biomedicina, como las alucinaciones, las referencias no resolubles, la pérdida de procedencia, el ocultamiento de contradicciones y la atribución indebida de autoridad clínica. Aplica operaciones aditivas y no destructivas: filtrar, clasificar o priorizar los datos nunca modifica ni reescribe la evidencia fuente original. Además, preserva la ambigüedad y los elementos no clasificables en lugar de forzar conclusiones artificiales. El stack tecnológico incluye React, TypeScript, Node.js y servicios en la nube. La plataforma integra un enfoque de múltiples proveedores y agentes de IA, con modelos generativos desacoplados, junto con una clasificación multidimensional de la evidencia mediante la abstracción de un Structured Decision Provider (SDP, Proveedor de Decisión Estructurada). Utiliza específicamente TypeSafe AI, con su modelo Jev, como proveedor de decisiones estructuradas bajo estrictas políticas de activación y gobernanza por dimensión. La IA y sus agentes asisten en la organización, exploración y síntesis de información compleja, pero no actúan como una autoridad diagnóstica ni determinan por sí mismos la verdad clínica. Sus salidas se manejan como inferencias computacionales controladas, separadas estrictamente de la evidencia fuente y sujetas a validación humana explícita. Step-by-step: 1. Accedo y estructuro la evidencia genética y biomédica dentro de una arquitectura basada en evidencia. 2. Exploro, clasifico y priorizo la información mediante operaciones aditivas y no destructivas, sin modificar ni reescribir la evidencia fuente original. 3. Mantengo la procedencia, las contradicciones, la ambigüedad y los elementos no clasificables, evitando forzar conclusiones artificiales. 4. Utilizo múltiples proveedores y agentes de IA, con modelos generativos desacoplados, para organizar, explorar y sintetizar la información compleja. 5. Aplico una clasificación multidimensional mediante la abstracción de un Structured Decision Provider (SDP), utilizando TypeSafe AI y su modelo Jev bajo políticas estrictas de activación y gobernanza por dimensión. 6. Trato las salidas de la IA como inferencias computacionales controladas, las separo de la evidencia fuente y requiero una validación humana explícita antes de utilizarlas.

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 teach AI in Business at Western Washington University, and I built a free, case-based AI textbook with Claude and GitHub Pages: https://prof-califf.github.io/ai-in-business/ The 11-chapter digital textbook includes seven real company cases—EveryCure, Netflix, Spotify, Uber, Waymo, Airbnb, and Epic—plus chapters on AI’s environmental cost, ethics, regulation, and the future of work. Seven chapters include hands-on Python labs, and Chapter 8 has an interactive calculator that models the energy and water footprint of a reader’s own AI usage. The textbook is free, has no publisher, and costs $0 to host. The problem was that AI textbooks are stale before they ship. An 18-month publishing cycle means students can pay $200 for a book that is already two model generations behind. Textbooks also tend to teach theory first and postpone business relevance until much later. My students do not need to derive backpropagation. They need to understand why Spotify built a recommender, how it works, what broke, and what it cost—then build one themselves. My stack is Claude, GitHub Pages, VS Code, Google Colab for the labs, and n8n for the Chapter 7 agentic lab. The project started when I was assembling a reading list and could not find anything usable—only outdated textbooks and paywalled cases. I already had years of lecture notes scattered across documents. Step-by-step: 1. I locked in a framework first. I use the AI Factory model—Data → Model → Prediction → Decision → Value → loop—and run every company through it. This is the step people skip: it builds transferable skills for students and gives Claude a stable structural contract across every chapter. 2. I set up the repository before writing. I created a new repo, added `index.html`, opened Settings → Pages, and confirmed that the site deployed. Five minutes up front was better than debugging after 40,000 words. 3. I built one chapter completely and used it as the template. Each chapter is a single, self-contained HTML file with no build step or dependencies. Then I prompted Claude: "Here's my finished Chapter 1 as the format reference. Here are my notes on Uber. Draft Chapter 4 in the same structure and voice." A finished exemplar worked better than an abstract description. 4. I started from my existing material instead of using a blank prompt. Claude structured and clarified my notes, but it did not decide what I think. I rewrote anything that did not sound like me. That distinction preserved the resource’s voice and avoided generated filler. 5. I made the labs builds rather than exercises. Students reconstruct each system in Google Colab using Claude as a coding partner, then publish their work to their own GitHub repositories. They finish with artifacts. 6. I shipped an incomplete version and update it like software. I published with fewer chapters, then edit and push updates when regulation changes so students automatically get the current version.

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

I submit two reports to my directors each month. Both use structured templates, but the updates come from multiple people and sources. Some information is unstructured, such as hallway conversations that are not always captured in email, so I have struggled to get the accuracy I need when using AI to build the reports. I am currently testing CoWork and Copilot Work IQ. These reports used to take me hours, so I am already saving time, but I want to refine the process further. I believe a better way to save and store the source data could improve the final outputs, although I have not worked out the right approach yet. Step-by-step: 1. I collect updates from multiple people and sources for the two monthly reports. 2. I organize the information into the structured templates required by my directors. 3. I use CoWork and Copilot Work IQ to help build the reports. 4. I account for unstructured updates, including information from hallway conversations that may not have been captured in email. 5. I am exploring better ways to save and store the source data so I can improve the accuracy of the reports while continuing to save time.

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 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’m retired and in my early 70s. I never got into RPGs growing up, but I decided to try a tabletop RPG with my wife. The game I purchased included a rulebook and a PDF of the book. I wanted my wife and me to play as the player characters without either of us having to be the game master, so I tested whether AI could take on that role. I used ChatGPT to parse the PDF and walk us through the process. It helped us create our characters, Heisenberg and Felicity, and then started the game as the game master. We’ve only just started, but it seems like this is going to work well. The AI can keep secrets to itself, roll the dice when needed, and guide us through the adventure. Step-by-step: 1. I purchased a tabletop RPG that included a rulebook and a PDF of the book. 2. I used ChatGPT to parse the PDF and walk us through the process. 3. ChatGPT helped my wife and me create our player characters, Heisenberg and Felicity. 4. We had ChatGPT start the game as the game master so neither of us had to fill that role. 5. We began playing while ChatGPT kept secrets to itself, rolled the dice when needed, and guided us through the adventure.

I built three interconnected websites for the Solomon for Jesus ministry. The first, solomonforjesus.com, houses the shining jewel: an AI chatbot named Solomon. The second, solomonforjesus.net, is a ministry academy with four levels of instruction and 16 lessons per level. The third, solomonforjesus.net, is home to my book *Fingerprint of Reality* and other articles and essays. All three websites are still in development, but they are operating and publicly available. I use GitHub repositories for coding, Vercel for hosting, Cloudflare for domains, and Supabase for back-end security. Step-by-step: 1. I built three interconnected websites for the Solomon for Jesus ministry. 2. I used solomonforjesus.com for the Solomon AI chatbot. 3. I used solomonforjesus.net for the ministry academy, which contains four instructional levels with 16 lessons per level. 4. I used solomonforjesus.net for my book *Fingerprint of Reality* and other articles and essays. 5. I use GitHub repositories to code, Vercel to host, Cloudflare for domains, and Supabase for back-end security. 6. I keep all three websites operating and publicly available while they remain in development.

I was tired of tracking events across my WhatsApp groups by hand and overcommitting myself, so I built a daily AI assistant that reads the groups and keeps my Google Calendar up to date automatically. I'm in six busy groups: multiple cricket chats, a tournament group, a volunteering rota, a weekly class, and a tennis club. Events arrive as polls, times change, venues are added, fixtures are cancelled, and the same match is often posted in multiple groups. A Claude Cowork scheduled task runs every morning. Using Claude in Chrome, it opens WhatsApp Web and reads only the fixed list of six named groups, starting from where it stopped last time. It turns messages into calendar events based on polls, merges duplicates across groups by matching the event type, date and time, and venue, and emails me a short digest covering what changed, what needs my attention, and which chats I had already read myself. I can reply to that email to steer it—for example, “delete that,” “move to 6pm,” or “why did you create this?”—and the next run acts on or answers my reply. Three small files next to the prompt make the workflow reliable: - `state.json` records where each chat was last read and which events it owns. It never overwrites a field I edited by hand. - `run.log` contains a one-line record for every action and the reason for it, so the assistant can answer questions weeks later without rereading WhatsApp. - `lessons.md` holds rules it writes for itself when something goes wrong, such as “WhatsApp changed its page layout, use this selector instead.” It reads these rules every run and can improve them. The key prompt rules are: “Your sources are exhaustive: these six chats and nothing else. Reading a chat that is not a source is itself the failure.” “Never create a second event for the same occasion. Merge; the first source owns it.” “Fields I changed by hand are locked. Report conflicts, don't overwrite.” “Send the digest every run, even when nothing happened, so silence means the run failed.” The result is that my calendar follows my WhatsApp groups without me doing anything, and each morning’s email flags the two or three things that actually need a decision. Step-by-step: 1. I define a fixed list of six named WhatsApp groups as the only allowed sources. 2. I schedule a Claude Cowork task to run every morning. 3. Using Claude in Chrome, the task opens WhatsApp Web and resumes reading each source from where it stopped last time. 4. It turns messages and polls into Google Calendar events, updating times, venues, and cancellations as needed. 5. It merges duplicate events across groups by matching the event type, date and time, and venue, while keeping the first source as the event owner. 6. It protects fields I edited by hand and reports conflicts instead of overwriting them. 7. It records chat progress and event ownership in `state.json`, logs every action and its reason in `run.log`, and reads `lessons.md` for rules learned from previous problems. 8. It emails me a digest every run, including what changed, what needs my attention, and which chats I had already read myself. 9. I reply to the digest when I want to delete an event, move it, or ask why it was created; the next run acts on or answers my reply.