Workflow Hub

My father-in-law has had some close calls with phishing attacks, so I built a digital bodyguard with Claude Code to watch over their email around the clock. It’s designed to catch scam and phishing attempts that are specifically crafted to fool people: fake bank alerts, urgent “click here” links, and messages pretending to be from someone they trust. When it spots one, it pulls the message out of the inbox into a separate folder and sends me an alert so I know it happened. I wrote up the full system, including the prompting and context, in GitHub: https://onabetternote.substack.com/p/using-ai-to-guard-against-email-scams?r=6ihgge&utm_campaign=post-expanded-share&utm_medium=web Step-by-step: 1. I built a digital email bodyguard with Claude Code to monitor my father-in-law’s email around the clock. 2. I configured it to look for phishing and scam messages, including fake bank alerts, urgent “click here” links, and messages impersonating trusted people. 3. When it identifies a suspicious message, it moves it from the inbox into a separate folder. 4. It sends me an alert whenever it takes action. 5. I documented the full system, including the prompting and context, in GitHub.

AI chatbots have limitations around memory, numbers and types of attachments, connectors, storage, and other resources. The underlying LLMs also change over time, and data leakage is a concern. Code-based versions such as Claude Code and Grok Build can store essentially unlimited files on your computer, organize them with databases and files, connect to public and private MCPs, and even host interfaces for reviewing results. You can choose between a hosted LLM such as Claude, Grok, or ChatGPT and a local LLM if you prefer. The best part is that these code-based versions have no memory between sessions: everything is stored on your computer, assuming a basic subscription. You start by prompting the system about the domain, what you want to store, how you want to access it, and other requirements. Then it creates the system for you. I started with my own personal health archive. I'm comfortable using the terminal interface for Claude Code and Grok Build, so I use that directly. When I built one for my wife, she couldn't use the terminal, so I had it build a basic website with Q&A interfaces, data access, and upload functionality. I hosted it on my Mac, and I wrote no code. We loaded hundreds of documents in various formats into each of our instances without any trouble. When we have new files, we can simply drop them in. For specific questions or health events we're tracking, the system has perfect memory and no memory limits within the archive. For my archive, I use a Garmin watch and a food tracker. Because public MCPs weren't available for those services, I had the system build local MCP servers by reverse-engineering them. My health tracker now has a continual feed of my food, fitness, sleep, and other data. My wife has some chronic health issues, and we had reached a point where the standard chatbots were hitting their limits. We were struggling and didn't know what to do, so I discussed it with Claude, and we came up with this approach. The best part, besides getting a better handle on our health, is that I can launch any LLM within the project—Claude, Grok, or others—and use it for that session. The project isn't tied to or limited to a single LLM. That lets me manage costs, switch to better LLMs as they improve, and use specialized models for deep research, all while working with one data set. Step-by-step: 1. I prompted a code-based AI about the health domain, the information I wanted to store, and how I wanted to access it. 2. I created a personal health archive and loaded hundreds of documents in various formats into it. 3. I built a second archive for my wife with a basic website, Q&A interfaces, data access, and upload functionality, then hosted it on my Mac. 4. I added new files by dropping them into the appropriate archive. 5. I had the system build local MCP servers for my Garmin watch and food tracker by reverse-engineering those services when public MCPs weren't available. 6. I used the resulting health tracker to maintain a continual feed of food, fitness, sleep, and other health data. 7. I launched different hosted or local LLMs within the same project as needed for each session, including using specialized models for deep research.

I built an agent from scratch that monitors my Claude and Codex usage by adding a runner node directly inside the root of each project repository. It includes agent templates for specific jobs, such as commit, research, janitor, and manager tasks. The agents run automatically at night, when I’m not actively using my five-hour usage period. They monitor their own usage and cap themselves so they leave usage available for me. Later, I built a hive dashboard where I can monitor all of these payloads in one place and execute them from the dashboard as the agents’ jobs become more complex. Step-by-step: 1. I added a runner node to the root of each project repository. 2. I created templates for specific agent jobs, including commit, research, janitor, and manager tasks. 3. I configured the agents to run at night when I’m not actively using Claude or Codex. 4. I had the agents monitor and cap their own usage so they preserve usage for me. 5. I built a hive dashboard to monitor and execute the payloads from a single place as the agents’ jobs became more complex.

I prompted Claude Code to build a Star Trek-themed website for my sixth-grade math and science students. I can use it to enter assignments and track what students complete, while students can sign in to check which assignments they are missing. Students can see their XP and levels and choose an affiliation: gold for Operations, red for Security or Engineering, or blue for Medical or Science. They have dilithium crystals for energy and health points. Operations can defend, Engineering provides more crystals, and Medical heals. Step-by-step: 1. I prompted Claude Code to build the website around my students’ assignments and progress. 2. I use the site to enter assignments and track what students complete. 3. Students sign in to their accounts to see which assignments they are missing. 4. Students view their XP and levels and choose gold for Operations, red for Security or Engineering, or blue for Medical or Science. 5. Students use dilithium crystals for energy and health points, with Operations defending, Engineering providing more crystals, and Medical healing.

Design taste is hard to put into words. I may know immediately that one website, presentation, report, or graphic feels right and another doesn't, but still struggle to explain whether the difference comes from the typography, spacing, colors, density, layout, or overall aesthetic. That makes working with AI frustrating. If I can't describe what I want, the AI has to guess. Instead of trying to explain my design taste upfront, I turned the process into an iterative visual feedback loop. I first asked the AI to suggest existing websites with different design styles so I could identify examples I liked. Once it had those references, I asked it to create three substantially different HTML mockups for the same content. I picked the direction I liked best, explained what I liked and disliked, and had the AI generate another set of alternatives based on that feedback. After about three rounds, the AI had a much better understanding of my design preferences than I could have given it in a written prompt. The basic loop is: show me examples → I choose → generate alternatives → I react → refine → repeat. This is essentially preference elicitation through examples. Research on human-AI interaction has similarly found that people can refine difficult-to-articulate preferences by reacting to concrete alternatives rather than specifying everything upfront. Step-by-step: 1. I asked the AI for several visual references, including websites or designs that represented distinctly different styles. 2. I reviewed the examples and identified the ones I liked. I didn't need sophisticated design terminology; I simply described what I preferred and anything obvious that I liked or disliked. 3. I gave the AI something real to design. I used an actual report I was working on so I could evaluate the styles in context. 4. I asked the AI to create three substantially different visual directions rather than minor variations of the same design. 5. I chose the direction closest to my taste and explained what I liked, what I didn't, and which elements from the other versions I wanted to incorporate. 6. I asked the AI to generate three new alternatives using everything it had learned so far. 7. I repeated the process until the designs began to converge. I did roughly three rounds, with each round narrowing the design space and giving the AI more information about my preferences. 8. I asked the AI to summarize what it had learned into reusable design guidelines so future projects could start with those preferences. Instead of trying to translate an aesthetic preference into design terminology, I let the AI learn my taste from my choices. The important shift is simple: don't describe what you like—show, choose, react, and refine. This can work for websites, presentations, reports, branding, graphics, interior design, clothing, invitations, or almost anything else where I know what I like when I see it.

I wanted to book a specific cruise, so I used Claude to get Python code that scans sold-out cruise pages for changes in status. If something becomes available, it sends a text message to my phone. Step-by-step: 1. I used Claude to generate Python code. 2. I configured the code to scan sold-out cruise pages for status changes. 3. I set it to text my phone if something becomes available.

I’m creating a master plan in Google Docs that documents my file structure and naming conventions for different file types, including insurance documents, receipts, contracts, and others. I’ll give Claude access to my file server through a file-sharing link and have it create a Markdown file with guidelines for how I want my files organized. To define those guidelines, I can have Claude interview me about my business and what I want the system to do. I’ll then copy and paste a file path into Claude Code and ask it to organize the files according to the master plan. Eventually, I plan to create a folder on all my employees’ desktops that Claude can scan regularly, naming and filing everything placed there. That way, I won’t have to worry about files being misfiled or named incorrectly. Step-by-step: 1. I’ll create a master plan in Google Docs that lists the file structure and naming conventions for each file type, such as insurance documents, receipts, and contracts. 2. I’ll give Claude access to my file server through a file-sharing link. 3. I’ll have Claude create a Markdown file with guidelines for the organization system, using an interview about my business and requirements to define what it should do. 4. I’ll copy and paste a file path into Claude Code and ask it to organize the files according to the master plan. 5. Eventually, I’ll create a folder on each employee’s desktop for regular scanning, so files placed there can be named and filed automatically.

I’m sharing “The Architects of Reality,” a short film created as part of an experiment with a multi-agent AI workflow for long-form content creation. Off-the-shelf AI video platforms are brilliant for short clips, but as the duration increases, the challenges compound: character inconsistency, narrative drift, visual discontinuity, and expensive iterations when the output doesn’t match the creative vision. Instead of asking one AI to make a film, I created an AI film crew. Specialised agents and sub-agents take on roles including Director, DOP, Cameraman, VFX Supervisor, Sound Engineer, VO Artist, and Audio Mixer to support the filmmaking process. Creative review and approval are built into every stage, so individual elements can be regenerated before expensive final rendering. This helps optimise tokens, budget, and creative control. It’s been a fun journey building these agents—and even more fascinating to watch the output improve in capability and efficiency as they learn every day. Step-by-step: 1. I set up a multi-agent AI workflow for long-form content creation. 2. I assigned specialised filmmaking roles to agents and sub-agents, including Director, DOP, Cameraman, VFX Supervisor, Sound Engineer, VO Artist, and Audio Mixer. 3. I built creative review and approval into every stage of the process. 4. I regenerate individual elements when they do not match the creative vision, before moving to expensive final rendering. 5. I use the workflow to optimise tokens, budget, and creative control while producing the short film “The Architects of Reality.” 6. I observe how the output’s capabilities and efficiencies improve as the agents learn every day.

I wanted a way to turn my meeting and call notes into a to-do list while also surfacing the themes I had been discussing over the weeks and months. That helps me see where my priorities really lie and who I have been discussing them with. I use the free Granola app to record meetings. Claude Code then connects through MCP, pulls in each meeting summary, and creates a web page that runs on my machine. The workflow also creates an `.md` file for each meeting using a standard set of formatting instructions. Now I can track actions, review recurring themes, and stay on top of my to-do list. Step-by-step: 1. I record my meetings and calls in the free Granola app. 2. I use Claude Code to connect through MCP and pull in the meeting summaries. 3. Claude Code creates an `.md` file for each meeting using a standard set of formatting instructions. 4. It creates a web page that runs on my machine and organizes the meeting information into a to-do list and themes. 5. I use the page to track actions, review themes over time, and stay on top of my to-do list.

A reusable Claude Skill called `trust-due-diligence`, packaged as a `.skill` file. It is not a single report; it is a methodology made up of a `SKILL.md` file and three reference documents that teach Claude a repeatable process for investigating a named person, company, coach, or offer before you commit money or trust to them. Once installed, it activates automatically whenever you ask something like “deep dive on X” or “is this legit,” so you do not need to explain the process each time. Step-by-step: 1. Package the `trust-due-diligence` Claude Skill as a `.skill` file. 2. Include a `SKILL.md` file and three reference documents. 3. Use the files together to teach Claude a repeatable due-diligence methodology. 4. Install the Skill so it activates automatically for prompts such as “deep dive on X” or “is this legit.” 5. Use it to investigate a named person, company, coach, or offer before committing money or trust.

I ask Claude every month or so to be my Claude Code learning coach by simply typing the /insights command. It provides a hyper-personalized website report card with advice to help me use Claude Code better, with exact examples of where things go wrong, features, and prompts I should try. Step-by-step: 1. I ran the /insights command in Claude Code to analyze how I had been using the tool. 2. I reviewed the personalized website report card it generated, especially the examples of where my workflow was breaking down. 3. I pulled out the recommended features, prompts, and habits that were most relevant to the mistakes I was making. 4. I practiced those recommendations in my normal projects instead of treating the report as generic advice. 5. I repeat the exercise every month or so to see what changed and what I should learn next.

I wanted a way to keep score during pickleball games and know which side of the court to serve from, so I made a pickleball scorekeeper for my Garmin Instinct 2 watch. When I open the app on my Garmin watch, I can keep score, see which side of the court to serve from, and know whose turn it is to serve. It supports both singles and doubles games, which is something none of the other pickleball apps can do. I thought I knew enough about VS Code to upload the app myself, but Garmin’s compiler was difficult to use. I had Claude walk me through the upload process step by step so I wouldn’t miss anything. Step-by-step: 1. I made a pickleball scorekeeper for my Garmin Instinct 2 watch. 2. I used the app to keep score, identify which side of the court to serve from, and track whose turn it is to serve. 3. I included support for both singles and doubles games. 4. I tried to upload the app myself using VS Code, but Garmin’s compiler was difficult to use. 5. I used Claude to walk me through the upload process step by step.

I built Timelanes so you can type any topic into one text box, such as “The Space Race” or “my grandfather's war years,” and generate a visually engaging, sourced, shareable timeline in seconds. Step-by-step: 1. Type a topic into the text box. 2. Let AI generate the timeline with dated events, short descriptions, and source links. 3. Review citation coverage for each event to see what's verified at a glance. 4. Edit and reorder events, add images and milestones, and choose a theme. 5. Publish the timeline with one click to create a shareable page and embeds that auto-render in Substack and Notion. 6. Export the timeline as a PDF, Markdown file, or CSV. Bonus: Compare mode places two or more timelines on one shared axis so overlaps stand out.

I have an electric car, solar panels on my home, and a home battery. On cloudy days, charging my car drained the battery and drew power from the grid, which I wanted to avoid. I used Claude to write code for my EV charger and inverter. The code monitors my solar panels’ output and adjusts the charging speed so the battery still receives some charge without drawing power from the grid. Step-by-step: 1. I identified that charging my EV on cloudy days was draining the home battery and drawing power from the grid. 2. I asked Claude to write code for my EV charger and inverter. 3. I set up the code to monitor the output from my solar panels. 4. I configured it to adjust the EV’s charging speed based on that output. 5. I used the adjusted charging speed to ensure the home battery received some charge while avoiding grid power draw.

I keep a long wishlist on Audible, but whenever I want a new audiobook, I face the same question: does my library already offer it for free through Libby? Checking hundreds of titles manually feels like too much work, so I often spend a credit instead. I had Claude build a workflow that checks for me. It reads my Audible wishlist and cross-references every title against my library’s Libby catalog, sorting each one into three categories: borrow now, join the waitlist, or not available. The important part was learning to interpret Libby accurately. Badges and time estimates can make an audiobook look ready when it isn’t, and a pending hold can look like an active one. The reliable signal is the exact text on the button: “Borrow” means I can borrow it; anything else means I should wait or move on. Step-by-step: 1. I gave Claude a workflow to read my Audible wishlist. 2. I had it cross-reference every title against my library’s Libby catalog. 3. I had it sort each title into “borrow now,” “join the waitlist,” or “not available.” 4. I configured the workflow to interpret availability using the exact button text rather than relying on badges or time estimates. 5. Before spending an Audible credit, I check whether Libby already has the audiobook ready.

The available task apps don’t meet my needs, so I’m building a personal dashboard to manage my tasks from email.

I am a Mohs surgeon who built and shipped an iOS app without formal software engineering training. The surprising part was not only getting AI to write the code; it was getting AI to remember what it had already done. I built ErgoSherpa because up to 90% of surgeons in my field report musculoskeletal symptoms, while our training fails to address them. I wanted to help surgeons improve their health easily between cases. It is free on the Apple App Store and at ergosherpa.com. The bottleneck was maintaining coherence over time. Many sessions seemed to start from zero: I would re-explain the architecture, then watch a fix quietly undo something I had solved earlier. Three habits fixed that. First, I created persistent project documentation: a `MEMORY.md` index file plus separate topic files for architecture and business decisions. I update them at the end of every session so a new session can read the files first and pick up where the last one stopped. Second, I stopped handing one model the whole job. I use three models and match them to the task. Claude Fable audits only. I open a separate session, point it at the codebase, and require a prioritized checklist with the file path, the problem, and the fix in one sentence—without writing code. A model that did not write the code and has no memory of the project reviews it more honestly than the session that built it. I paste that checklist into a Claude Opus session, which handles the codebase repairs. Claude Sonnet handles routine work such as content updates, image processing, and scheduled maintenance, often from handoffs written by Opus or Fable. Nothing gets implemented on the auditor’s word alone: I have Opus flag any decision that needs human input. This workflow caught a deep-link handler that accepted authentication tokens from any URL and a database policy missing its write-side check. Third, I verify against production, not just the code. Some of the most frustrating parts of the project involved fixes that were correct in the file but wrong on the user’s screen because of a cached asset, a stale database row, or an iOS process that needed a force-quit. I no longer consider anything fixed until I have checked the live app. Step-by-step: 1. I keep a project memory directory with a `MEMORY.md` index and separate topic files for architecture and business decisions, updating them at the end of every session. 2. I open a separate Claude Code session running Claude Fable and prompt it to audit the codebase and return only a prioritized checklist: file path, line number, the problem in one sentence, the fix in one sentence, with no code or commentary. 3. I keep the auditor in its own session with no project history so it reviews the code independently instead of defending work it wrote. 4. I paste the checklist verbatim into a Claude Opus session and have it work from the top down, reading each file and making each change. 5. I tell Opus to flag anything it believes is a false positive instead of implementing it, keeping a human in the loop on key findings. 6. I use Claude Sonnet for routine work such as content updates, image processing, and scheduled maintenance, often from handoffs written by Opus or Fable. 7. I verify every change against the live production site rather than the local files because cached assets and stale database rows can make correct code behave incorrectly for users. 8. I append confirmed lessons and architectural decisions to the project memory so the next session starts from the project’s current state.

Midlifecurious is a newsletter for women navigating midlife—honest, funny, and allergic to being talked down to. Its Sunday issue, the Midlife Missive, is a roundup covering health, wellness, money, beauty, and family. My sister, Claire, edits it; I build the machine behind it. That machine is Missive, a five-part publishing intelligence system that runs the newsletter as one closed loop: scan → triage → publish → measure → remember. It monitors Reddit, search trends, and RSS to identify what midlife women are paying attention to before those topics reach our feeds. Discovery pulls in those sources, ranks every feed using a click-rate-based quality score, and lets Claire triage articles into the week’s issue. Curation composes Sunday’s newsletter and drafts the introduction in her voice. Performance reads the Mailchimp results back into the system and feeds them into the rankings, so strong sources rise and weak ones fall over time. Underneath all four stages is Memory: a vector-searchable corpus of every article, save, rejection, and the reasoning behind each decision. Memory is the real spine of the system. It lets Missive ask editorial questions such as “Have we covered this before?” and “Is this source still earning its slot?” instead of requiring one person to hold everything in her head. We’re a two-person operation: I build with Claude Code, and Claire edits. The system runs on one database for under $25 a month. I built it because the alternative was Claire drowning in a Feedly-and-spreadsheet routine that discarded everything as soon as an issue shipped. We had no record of what we had run and no feedback on what actually landed. My bet is that the corpus is the moat. Claire’s editorial taste—every save, rejection, and “cornerstone” stamp, with the reasoning stored alongside the decision—is a training set no one else has. A system that remembers turns her job from synthesizer into judge. Missive is deliberately internal-only: no SaaS and no customers, ever. That frees me to build for our exact workflow instead of a hypothetical buyer, and to build for 2028 instead of this quarter. The near-term payoff is a calmer Sunday. The long-term goal is a proprietary editorial-intelligence layer we could never buy off the shelf—the foundation for the research and audience products that come next. Step-by-step: 1. I monitor Reddit, search trends, and RSS for topics that midlife women are paying attention to. 2. I pull those sources into Missive and rank each feed using a click-rate-based quality score. 3. Claire triages the ranked articles into the week’s Midlife Missive. 4. Missive composes Sunday’s newsletter and drafts the introduction in Claire’s voice. 5. I import the Mailchimp results so the system can update source rankings based on performance. 6. Missive stores every article, save, rejection, “cornerstone” stamp, and the reasoning behind each decision in a vector-searchable corpus. 7. We use that memory to check whether a topic has already been covered and whether a source is still earning its place. 8. I build and maintain the internal system with Claude Code, while Claire handles editing, using one database that costs under $25 a month.

I built a workflow in which AI agents build a product under the kind of governance I’d expect from a senior engineering team. After 20 years in software engineering, including 10 years running my own businesses, I learned that writing code isn’t the hard part. Keeping control of it is. So I set up a build loop on GitHub. One thing I’ve kept for myself is decision-making: approving plans, answering product questions, and signing off on what the system has learned. The product it’s building is Cordexa, a tool for document-heavy expert work, such as quantity take-offs from engineering drawings or assessing a tender against a company’s own CVs and case studies. It’s designed to run inside the customer’s own cloud, so their documents never leave it. Every figure is cited to the document it came from or flagged for a person. It never guesses. The problem it solves is complex, but the build loop lets the system work in the background and notify my phone when it needs a decision. That allows me to stay focused on my day job. Step-by-step: 1. I start every module with a plain-English plan and approve it before any code exists. 2. One agent writes the tests from the plan. A different agent writes the code, and it cannot modify the tests. 3. An independent reviewer agent checks every change against its plan. Safe changes merge automatically; anything that changes the product waits for my approval. 4. A watchdog checks every 15 minutes for anything that is stuck, fixes it when possible, or tells me why it cannot. 5. Real test jobs run after every merge and are scored against known answers, so progress is measured rather than guessed. 6. I handle the decisions, answer product questions, and sign off on what the system has learned.

I produce cinematic AI video. What ruins a sequence is almost never image quality; it is drift. The face, jacket, and light change between shots, so what should read as one scene becomes a gallery of near misses. Most people fight this by regenerating until something matches. I built the opposite: a set of chained Claude skills that locks a character once and never lets the model improvise again. The lesson that started it cost me 72 credits in one unusable shot. I fed a finished POV frame as an image reference to “set the world” for a motorcycle sequence. The model treated it as a strong identity reference, cloned the entire cockpit from that frame, and ignored the bike I was describing in the prompt. Image references are read as identity, not atmosphere. That misunderstanding is why most people’s characters mutate. Step-by-step: 1. I lock the character before generating anything. I fill nine layers in order: identity and facial structure, skin realism, wardrobe and materials, emotional energy, environment, lighting scheme, camera language, vertical 9:16 framing, and a fixed block of negative instructions. A generic prompt returns a generic face. This is direction, not a portrait. 2. I shoot a character sheet: a neutral, multi-view image of the locked character on white. That sheet—not a pretty hero frame—is what I reuse as a reference from then on. 3. I expand coverage instead of reinventing the scene. One locked scene becomes a full shot list with hero angles, macro inserts, and establishing shots. The subject, wardrobe, weather, and lighting never change between prompts. Only the camera, focal length, framing, and distance change. Every prompt restates the entire world from scratch because the generator has no memory between images. Consistency comes from redundancy, not from the model remembering. 4. I time the story before animating. I create a 3x3 board with nine beats over fifteen seconds, with each panel showing its timecode, shot title, and action. The rule is strict: the character, wardrobe, world, and light stay identical across all nine panels; only the story advances. The emotional scale rises toward panel nine. 5. I generate with reference discipline. I pass the object or vehicle in a clean exterior shot as the only image reference, then describe the world, framing, and interior in text, repeating that description word for word across shots. I chain consecutive shots by feeding the last frame of one as the start image of the next. The joins are invisible. 6. I review the board against the renders, keep the shots that hold, and regenerate only the ones that drift. The result is that I stopped paying the regeneration tax. Shots are budgeted, not gambled, and a fifteen-second sequence holds together because it was blocked like a real scene—with coverage and continuity—before a single frame existed. The nine-layer character build and the coverage framework are adapted from two AI video courses plus twenty years of production. I learned the reference discipline in step five the expensive way.