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

I recently built a month-end close workflow in Awish for a client at a finance company. The problem was not creating the final report. The real bottleneck was collecting data from different systems, checking what was missing, reconciling totals, chasing exceptions, and getting the report to the right people. I built the entire process in Awish by describing what I wanted. Step-by-step: 1. I opened the Awish chat and wrote: “At every month-end close, collect journal entries, invoices, vendor bills, and financial records from NetSuite together with reporting workbooks from Excel and SharePoint. Check submission completeness, reconcile totals across sources, identify missing data or unusual variances, prepare the management-reporting workbook, send unresolved exceptions to Finance in Microsoft Teams for approval, and once approved export the final report to PDF, store it in SharePoint, and distribute it through Outlook.” 2. Awish understood the request, planned the workflow, and selected NetSuite, Excel, SharePoint, Microsoft Teams, and Outlook for the required steps. 3. I reviewed the plan, connected the client’s accounts, and approved the automation. 4. At month-end, Awish pulls the required financial data and reporting files, checks whether anything is missing, reconciles totals, and flags unusual variances. 5. It updates the management-reporting workbook and sends only the unresolved exceptions to the Finance team in Microsoft Teams. 6. Once Finance approves the exceptions, Awish finalizes the report, exports it to PDF, stores it in SharePoint, and sends it to the authorized recipients through Outlook. The useful part is that Finance no longer has to spend most of the close manually collecting and checking information before making a decision. The repetitive reconciliation work is handled automatically, while the team retains control over unexplained exceptions and the final report. Trigger → Analyze → Approval → Action Month-end close → Reconciliation \u0026 variance checks → Finance approval → Final report \u0026 distribution

My husband and I run a short-term rental business managing two properties we own in Harpers Ferry, WV. A major part of the job is using PriceLabs, a dynamic pricing and revenue management tool that tracks our properties’ performance against the market, including occupancy, prices, and revenue, and recommends price changes when needed. Previously, we had to log in and review multiple dashboards to make informed decisions. Now, every two days we receive a concise morning briefing that summarizes how the month is going and what needs attention. It’s one of the first things I read in the morning, so I know what to adjust in real time. Step-by-step: 1. I connected the data sources Claude needs through MCP connectors: PriceLabs for reservations, pricing, and market data, and Gmail for drafting the output. 2. I wrote the instruction prompt Claude runs each time. This took the most time to develop. 3. I defined the format and length: a short, numbers-first brief of about 200 words, beginning with “How This Month Is Going” and “What Needs Attention,” with no filler or pep-talk tone. 4. I solved delivery by having the routine draft the briefing as an email with a recognizable subject prefix, such as “Iconic Chalet Briefing — Mon, Aug 10.” Because Claude’s Gmail connector can create drafts but not send emails, a separate time-triggered Google Apps Script watches for drafts with that subject prefix and sends them automatically. 5. I registered the workflow as a scheduled Routine. That combination makes the process feel automatic from end to end.

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

The Rundown Workflow Hub asks members to “share your best AI workflow” and features the community’s top-voted workflows in its daily newsletter. Most posts rightly celebrate workflows that work and produce something useful. This one is about why “no” can also be a successful workflow outcome. A good AI workflow does not turn every idea into a project. It gives an idea the right amount of effort, then produces a clear answer—including a fast, well-documented no. In my first Workflow Hub post, I showed the capture workflow I call ReelForge: turning a useful public Reel, TikTok, or short video into a source-linked research note rather than another forgotten save. This is what happened to one of those notes. A Reel pitched an “AI operating system” for solo consultants: pull together client context, prepare the human before a call, then turn the transcript into follow-up drafts. At first glance, it sounded promising. The mechanism was clear, the problem was real, and the demo had exactly the kind of glossy “one person runs everything” energy that makes it tempting to jump straight to a build. We did not. ReelForge captured the source and separated the useful mechanism from the creator’s bigger claims. From there, a primary routing workflow ran a defined first pass: did the signal merit direct resolution, deeper specialist work, human review, or a reasoned stop? It earned deeper work. Hermes sent the pack into a specialist workflow, where assigned agents collaborated to enrich the evidence, check the market claims, and produce something concrete: a pre-call brief and a post-call follow-up pack. That made the opportunity inspectable rather than another confident paragraph about what an agent *could* do. The enriched pack then went to Jon T for formal review. The review surfaced the problem: Teams and Granola already cover a large part of the obvious transcript, summary, and meeting-preparation wedge. The idea had a workable mechanism, but not a sharp enough reason to become a new product. So the final route was a deliberate no. No unnecessary build. No “let’s just test it” theatre. No orphaned Notion page waiting to become somebody’s future problem. The first visual shows that five-step pass: Step-by-step: 1. Capture the signal. 2. Add evidence and context. 3. Choose the effort. 4. Hand off to human authority when needed. 5. Record the finish. The second visual shows the decision underneath it. A signal can earn direct resolution, a specialist pipeline, or a reasoned stop. Human review is a conditional handoff, not a fourth outcome. That is the rule I care about: the output is not agent text. It is the right next end state. ReelForge was the capture layer in the first post. This is the routing layer that stops captured signals from becoming a very organised pile of work nobody should do. Read my first Workflow Hub post here: https://app.therundown.ai/community/posts/eb787b9d-f7a0-4fe4-8e1d-166bb5c29cb7?ref=db29b880a9904700 Future posts can show the builds that survived this test. This one shows why the test matters first.

I’m a freelancer on Fiverr and Upwork. I use ClickUp to manage enquiries, projects, and deadlines, while Slack is my team communication tool. When I receive a high volume of enquiries, I sometimes miss replies to older orders. That can also cause me to overlook important messages and hurt my responsiveness. To address this, I created a workflow in Make.com. Every four hours, I receive alerts about relevant messages. Urgent priorities are marked in Slack, and pending follow-ups that need attention are highlighted. This helps me quickly reply to all relevant messages. Step-by-step: 1. I manage all Fiverr and Upwork enquiries, projects, and deadlines in ClickUp. 2. I use Slack for team communication. 3. I connected the workflow in Make.com to send alerts every four hours. 4. I mark urgent priorities in Slack. 5. I highlight pending follow-ups that require attention. 6. I use the alerts and highlighted messages to reply to relevant enquiries and orders promptly.

I built an open-source fitness tracking app in Flutter, but the core workflow is the AI-agent architecture that designed it, built it, and now coaches from its data. For years, I tracked workouts in OneNote. The records were messy, difficult to search, and inconsistent. Excel went out of date as soon as I skipped a week. When I tried chatting with LLMs about my training, the problem was similar every time: no context, no memory, and no awareness of the weights I was using. Each conversation started from zero. The solution has two layers. Gym Tracker is a Flutter app with a local SQLite database that structures workout data properly. It includes 33 pre-populated exercises across 10 muscle groups, separate strength and hypertrophy records, multiple runs with pace, body stats, and full session history. There are no subscriptions, accounts, or cloud dependencies. The database is a file I own. Deschamps is the AI agent that reads the database and knows my full training history. It is not a chat window that forgets between messages; it is a tactician with long-term recall of my personal bests, progression, and injuries. The app stores the data, and Deschamps turns it into decisions. Step-by-step: 1. I defined the data architecture. Fitness data is operational data, so I gave it a schema, a query layer, and an agent that respects its history. I designed a SQLite schema with five tables, proper constraints, and a 10-category muscle taxonomy enforced by a CHECK constraint. 2. I wrote architectural prompts for AI coding agents. I run a team of specialized AI agents using OpenClaw, an open-source agent framework. I act as the CTO agent: I design the systems and delegate implementation to coding agents, including Forge, Cline, and Claude Code. I provide the vision, and they provide the execution. 3. The coding agents built the Flutter app with clean architecture, the repository pattern, Provider state management, and real-time cross-screen refresh. For each iteration, I review the result, refine the prompt, and ship. 4. I designed the database for dual access. The app writes to it, and the AI agent reads from it. They use the same file and schema. In external database mode, the app opens a `.db` file directly, allowing both the app and Deschamps to read and write simultaneously. This creates the bridge between the data layer and the intelligence layer. 5. I shipped the app across Windows, macOS, Linux, Android, and iOS from one codebase. The Android APK is available as a direct download from GitHub. 6. Deschamps reads the database and programs the next session using the full training history. Every session, weight, and body statistic remains structured data without summarization loss. The data is the context. 7. I made everything open source: the app, the agent prompts, and the architecture documentation. My company, Executive Mind (executivemind.io), uses the same agent-first model with seven AI agents and $40/month in total compute, running real operations 24/7. The result is a fitness tracker that remembers everything, an AI coach that never forgets, and a data layer designed from the start for both humans and machines to read. Links: krisracette.me/gym-tracker · github.com/Roughn3ck/gym_tracker · executivemind.io

I’m learning Chinese online and record all my lessons. I asked Claude Code to transcribe the recordings and walked through the process of using the Whisper API with its guidance. Then I asked Claude Code to analyze the transcripts and identify mistakes I could fix that would make a big difference. It found that my teachers had not corrected several phrases I was repeating. Claude Code taught me which phrases to practice, and I’m now making fewer mistakes. Step-by-step: 1. I recorded all of my online Chinese lessons. 2. I asked Claude Code to guide me through transcribing the recordings with the Whisper API. 3. I asked Claude Code to analyze the transcripts for mistakes that would make a significant difference if corrected. 4. I reviewed the repeated phrases my teachers had not corrected. 5. I practiced the phrases Claude Code identified, which helped me make fewer mistakes.

I started DialPhone with a simple problem: business communication is fragmented. A typical team may use one tool for phone calls, another for SMS, another for meetings, another for fax, and a separate system for customer support. I wanted to explore what it would look like if those conversations lived in one system, with AI doing more than just transcribing them. I built DialPhone as an AI-native communications platform around that idea. The core is cloud VoIP, while the same platform also handles business SMS, video meetings, online fax, team chat, and contact-center workflows. On top of that, I added AI capabilities such as call transcription and summaries, CRM logging, AI-drafted SMS replies, conversation intelligence, and an AI receptionist that can answer calls, qualify requests, book appointments, and route conversations. The biggest architectural decision was to treat communication data as one connected stream rather than as separate products. A phone call can create CRM context, trigger a follow-up SMS, and become part of a customer-support workflow without someone manually moving information between systems. Along the way, I learned that adding AI to communications is not particularly useful if it only produces transcripts. The more interesting problem is turning conversations into actions: updating records, identifying next steps, helping agents during calls, and automating repetitive work. Step-by-step: 1. I identified the problem of business communication being fragmented across phone, SMS, meetings, fax, and customer-support systems. 2. I built DialPhone as an AI-native communications platform centered on cloud VoIP. 3. I brought business SMS, video meetings, online fax, team chat, and contact-center workflows into the same platform. 4. I added AI features for call transcription and summaries, CRM logging, AI-drafted SMS replies, conversation intelligence, and an AI receptionist. 5. I connected communication data so calls can create CRM context, trigger follow-up SMS messages, and become part of customer-support workflows. 6. I focused the AI capabilities on turning conversations into actions, including updating records, identifying next steps, helping agents during calls, and automating repetitive work.

Sometimes a story needs a simple locator map to show where something happened or where something can be found—such as a business facility, a car accident, or the best place to see a sunset. I've worked in media for a long time and understand the power of maps to tell stories. But media cost-cutting and consolidation have reduced the number of available graphic departments, so creating a map is often the last task a reporter or editor wants to take on. I used Perplexity for initial research, Claude Code and Codex to build a web app, and Perplexity and ChatGPT for post-work such as SEO best practices. Step-by-step: 1. I used Perplexity's Deep Research mode to conduct a competitive market analysis. I asked it to analyze the field I was considering entering, identify competitors and growth rates, and explicitly break out feature sets. 2. I revised the research with my own idea and asked Perplexity to run the competitive landscape against it. I also provided desired outcomes, including intended audiences and where competitors were reaching them. I added the constraint, "Do it without syncophancy," so it would stop telling me how good my potential product was. 3. I hand-drew the initial screens and functions I wanted, then used the `/office-hours` skill in the Gstack bundle, available on GitHub, to play devil's advocate, sharpen the ideas, and challenge my assumptions. 4. I wrote a long prompt describing the product, starting broadly with the concept and audience and then narrowing to specific features and benefits. For example, I specified that it should export in 16:9 and 9:16 formats so maps would be ready for mobile vertical presentation. 5. I specified the hosting environment and that the product should be a web app. I also required a planning phase followed by construction phases. I pasted the prompt into Claude Code with this final line: "Use /grill-me to ask me questions to clarify intent." After 147 questions, it started the build. 6. This was in the pre-Fable days, so I specified that Opus 4.8 should act as an orchestrator while less expensive agents, particularly in Codex, handled the actual coding. 7. I used separate phases for technical work such as wiring in mapping providers and getting the UX to work correctly. Other phases included wiring in payment and subscriptions and making sure a subscription triggered an email campaign with instructions. 8. I dedicated an entire phase to building admin tools so I could manage the marketing language on the landing page and publish blog entries. 9. After each phase, I had the Opus/Codex combination perform an adversarial code-review-and-fix cycle. I then ran the `/ai-regression-testing` skill from the ECC repository on GitHub to catch issues the code review missed. 10. After every third phase, I prompted Claude Code: "Act as a senior QA engineer and go through the entire codebase looking for inconsistencies, functions that are in the wrong place, code that is overkill and security vulnerabilities." 11. When I had a product I thought was ready for testing, I prompted Claude Code, again using the Opus/Codex combination: "Act as a senior security engineer. Run this against OWASP standards. Find problems and suggest fixes. Harden this product overall." 12. As I neared the end, I asked Perplexity Deep Research and ChatGPT (Sol/High) to find SEO solutions for the product.

Getting answers from company data usually requires someone who knows SQL, understands the database, and has enough business context to interpret the results. This creates a bottleneck: business users depend on analysts for questions they should be able to explore themselves. I turned Claude Code into a self-service data analyst by giving it direct, read-only database access and configuring its behavior through a `CLAUDE.md` file. The file gives Claude business context, explains which analytical tables contain different types of information, tells it how to investigate questions, and defines how results should be presented. Users can then ask business questions in plain English. Claude determines what data it needs, queries the database, investigates the results, creates visualizations, and explains what it found. Step-by-step: 1. Create a dedicated analysis folder and add a `CLAUDE.md` file that defines how Claude should operate as a data analyst. 2. Give Claude enough business context to understand the company, its terminology, important metrics, and how the business operates. 3. Document which analytical tables or views it should use for different types of questions. Curated analytics tables work particularly well because Claude doesn't need to decipher the entire production database. 4. Give users read-only database permissions and explicitly instruct Claude to perform read-only operations, such as `SELECT` queries only. Never give the agent permission to modify production data. 5. Tell Claude how to use the command line to query the database. Include instructions to help users install or configure it if it isn't available. 6. Define an analytical process for Claude to follow. Rather than simply generating one SQL query, instruct it to investigate the user's question, examine the results, and run additional queries when necessary to understand what is happening. 7. Define the expected output: answer the question, explain the important insights, and create appropriate visualizations to make the findings easy to understand. 8. Open the folder in the Code tab inside the Claude Desktop app, which I find to be the best interface, and ask questions naturally, such as, "Why did revenue decline last month?" Claude handles the investigation from there. Instead of building and maintaining a custom analytics application, you can turn a general-purpose AI coding agent into a capable self-service analyst with access to your existing data warehouse. Users ask questions in plain English while Claude handles the SQL, investigation, visualization, and explanation, giving nontechnical users a more direct way to explore company data.

This Codex-driven workflow takes a software request from problem understanding through implementation, validation, review, and delivery evidence. Instead of asking an AI coding agent to simply “build the feature,” it gives the agent an explicit development lifecycle with defined responsibilities, deterministic validation gates, repair loops, and human checkpoints. The goal is to make AI-assisted development more structured, observable, and recoverable. It can be used for new feature implementation, bug fixing, refactoring, test creation and improvement, code quality and security hardening, and documentation and automation changes. The core principle is simple: Don't give the AI only a coding task. Give it an engineering lifecycle to work on. Step-by-step: 1. Understand the problem. Clarify the request, identify the desired outcome, define the scope, and surface ambiguity before implementation begins. The output is problem understanding and scope. 2. Define constraints. Identify technical, functional, non-functional, compatibility, and out-of-scope constraints. The output is a constraint set. 3. Plan. Analyze implementation options, select an appropriate approach, break the work into tasks, and define acceptance criteria. The output is an implementation plan. 4. Inspect the existing system. Review the relevant codebase, dependencies, current behavior, and affected components before making changes. The output is system context. 5. Implement. Make the smallest appropriate code changes while following the existing project’s conventions and the approved plan. The output is code changes. 6. Run deterministic validation. Run tools that can objectively validate the implementation, including formatting, linting, type checks, builds, unit tests, and other available automated checks. The output is validation results. 7. Review. Evaluate the implementation against the original requirement, the plan, code quality expectations, security considerations, and potential regressions. The output is review findings. 8. Repair and iterate. If validation or review identifies problems, diagnose the issue, make the required correction, and repeat validation. The output is a corrected implementation. 9. Verify. Confirm that the acceptance criteria are satisfied and that the relevant tests and checks provide sufficient evidence for completion. The output is a verification result. 10. Produce delivery evidence and handoff. Summarize what changed, what was tested, what passed, known limitations, and any remaining decisions requiring human attention. The output is delivery evidence and a human handoff. The core loop is: Implement → Validate → Review → Repair → Validate → Verify. Testing and review are treated as part of development rather than activities performed only after coding is “finished.” AI coding agents are increasingly capable of inspecting repositories, writing code, running commands, and responding to failures. The problem is that capability alone does not provide an engineering process. This workflow separates the responsibilities an AI coding agent performs into explicit stages. It applies several principles: - Problem before implementation: Understand what needs to change before writing code. - WHY before HOW: Establish the intent and constraints before choosing an implementation. - Single responsibility per stage: Give each stage a defined purpose and output. - Deterministic validation first: Use tests, linters, type checkers, builds, and other deterministic tools wherever they can establish correctness. - Failure localization: When something fails, identify which stage or assumption needs correction. - Evidence-based completion: Support completion with validation and review evidence rather than an AI declaration that the task is finished. - Human checkpoints: Use automation to accelerate execution without removing human judgment from important decisions. The broader idea is: The AI should participate in the engineering system, not become the engineering system.

I built an Awish workflow that handles a support ticket before anyone on the team opens it. I realized support tickets were not just taking time to answer. Someone still had to understand the problem, decide how urgent it was, search the documentation, route it to the right person, and prepare a response. I wanted that first layer of support work to happen automatically. I opened Awish and wrote: “Whenever a new support ticket comes in, understand the issue, determine its urgency, check our documentation, prepare a response, create a Jira issue if it looks like a product bug, and escalate anything important to the team before taking customer-facing action.” Awish understood the request, planned the workflow, and showed me which applications it needed. Step-by-step: 1. I described the complete support process I wanted in the Awish chat. 2. Awish planned the workflow and selected Zendesk, Notion, Jira, and Slack for the required steps. 3. I connected my accounts and approved the automation plan. 4. When a new Zendesk ticket arrives, the workflow identifies the issue type, urgency, and customer intent. 5. It checks the relevant Notion documentation and prepares a response based on the available information. 6. If the issue looks like a product bug, it creates a Jira ticket with the customer context already attached. 7. Urgent or sensitive cases are escalated to the team instead of being handled automatically. 8. I connected WhatsApp from the Awish chat. I now receive workflow updates there and can manage the automation without opening Awish. Customer-facing actions still stay under my control when approval is needed.

Commercial vehicle maintenance information is often fragmented across driver reports, warning lights, fault codes, inspections, repair records, and vehicle history. This makes it difficult for smaller fleets to decide whether a vehicle can continue operating, requires scheduled repair, or should be stopped immediately. We built TruckFixr Fleet AI to turn an unstructured driver report into a clear, reviewable maintenance action. The workflow begins when a driver submits symptoms, photos, fault codes, and vehicle information through a mobile-friendly form. AI and optical character recognition extract the relevant details and organize them into a structured maintenance case. The report is then evaluated alongside available vehicle history and previous repairs. The workflow provides decision support through three practical actions: continue operating while monitoring, schedule an inspection or repair, or stop and escalate for immediate professional assessment. Final safety decisions remain with authorized fleet or maintenance personnel. After an inspection or repair, the confirmed cause, work performed, and outcome are recorded, creating a more complete vehicle history for future cases. The general workflow can be recreated using a mobile form, OCR, a vehicle-history database, an AI model, automation software, and a human-review dashboard. Step-by-step: 1. A driver submits symptoms, photos, fault codes, and vehicle information through a mobile-friendly form. 2. AI and optical character recognition extract the relevant details and organize them into a structured maintenance case. 3. The workflow compares the report with available vehicle history and previous repairs. 4. The system provides one of three decision-support actions: continue operating while monitoring, schedule an inspection or repair, or stop and escalate for immediate professional assessment. 5. Authorized fleet or maintenance personnel make the final safety decision. 6. After inspection or repair, the confirmed cause, work performed, and outcome are recorded in the vehicle history. TruckFixr has used this approach to support more than 100 vehicle-issue resolutions in early fleet pilots, helping fleets identify problems earlier, prevent avoidable breakdowns, and keep vehicles moving safely.

I built a repeatable, human-directed AI workflow for turning an original emotion, memory, or story into a finished WazWorld song, complete with cover artwork and release content. It addresses one of the biggest problems with AI music: a simple prompt can produce something technically impressive but generic, overproduced, or disconnected from the creator’s real intention. The workflow begins with a human trigger—an experience, relationship, place, mood, or musical idea that I genuinely want to express. WazWorld generally moves between dark alternative/electronic music and California coastal country-rock. Step-by-step: 1. I create a detailed artistic brief describing the song’s emotional core, story, genre, energy, vocal character, instrumentation, arrangement, dynamics, and intended listener experience. 2. I work with ChatGPT to develop and challenge the concept, write and rewrite lyrics, remove clichés, and design the full arrangement. This includes the intro, verses, choruses, instrumental passages, transitions, musical peaks, and outro. ChatGPT also helps translate my direction into precise production language and exclusions that Suno can understand. 3. I generate versions in Suno, treating each result as a demo rather than a finished song. I evaluate the vocal delivery, lyrics, bass, guitars, synths, drums, tempo, arrangement, and emotional impact. Then I make targeted prompt changes and generate new versions. A song may go through dozens of iterations before it sounds the way I originally heard it in my head. 4. After selecting the final music, I use ChatGPT and AI image generation to develop cover artwork that matches the song’s emotional identity. I adapt the artwork for streaming, YouTube, Instagram, Stories, and Shorts, then create the metadata, descriptions, captions, and promotional material needed for release. 5. I distribute the finished music through services such as DistroKid and publish it across streaming and social platforms. The final result is not a one-click AI song. AI provides creative and production tools, but I direct every major decision—from the original emotion and lyrics to the arrangement, instrumentation, vocals, artwork, and release strategy. Someone can recreate this workflow by starting with a clear human idea, documenting the desired sound, generating multiple versions, evaluating each one like a producer, and iterating until the finished work communicates the original intention.

I kept forgetting who I had lent books to, and spreadsheets felt like overkill. So I built Runo, a book-lending app for friends, without traditional coding. Runo (runo.club) is a web app where I can catalog my home library, get a unique shareable link, and let friends browse my books and request to borrow them. I can approve or decline each request with one click. Step-by-step: 1. I used Claude to think through the feature set, data model, and UX flow before writing a single prompt. This helped me avoid building the wrong thing first and gave me a clear blueprint for the Lovable prompts that followed. 2. I used Claude to create precise, narrowly scoped prompts for Lovable, with each prompt focused on a single change so existing functionality would be less likely to break. This significantly conserved Lovable credits. The React, TypeScript, and Supabase stack came out of the box. 3. I added two ways to scan books instead of requiring users to type titles manually: - Barcode scanner: Point the camera at an ISBN barcode to autofill the title, author, and cover using the Open Library API. - Cover photo scanner: Photograph the cover so Gemini 2.5 Flash can extract the title and author in under 2 seconds. 4. I routed the cover scanner through a Supabase Edge Function using Lovable’s AI Gateway, so the API key never touches the client bundle. 5. For every bug fix and feature, I followed the same iteration loop: describe the problem to Claude, get a precise Lovable prompt, push the changes to GitHub, and let Lovable auto-sync them. Claude and Lovable’s bidirectional GitHub sync made the process feel like pair programming. Tools used: Lovable, Claude (Sonnet), Gemini 2.5 Flash (via Lovable AI Gateway), Supabase, and GitHub. Live at: runo.club — public beta and free to use. Feedback welcome. #appbuilding #vibecoding #buildinpublic #lovable #nocode

I love golf, but many of the courses I most want to play are private and nearly impossible to access unless you know a member. Instead of manually emailing clubs, searching charity events, asking for introductions, and trying to remember who I contacted months ago, I built a Private Golf Access Agent in ChatGPT. The goal is to identify legitimate opportunities to play highly rated private clubs without simply paying my way in. I gave the agent 50 target clubs across the Northeast and Mid-Atlantic, including 10 “moonshot” courses where an invitation would be extremely difficult. The agent acts more like a golf-access researcher, relationship manager, and outreach assistant than a chatbot. It researches each club, identifies access paths, finds the right person, personalizes outreach, tracks every interaction, monitors opportunities, and recommends what to do next. I still approve every email before anything is sent. That matters because I don’t want the agent spamming clubs, inventing relationships, or continuing after someone says no. The system looks for legitimate paths, including professional introductions, complimentary charity or special-event opportunities, reciprocal access, personalized direct outreach, unused guest spots, golf-project requests, and long-term relationship opportunities. Step-by-step: 1. I divided the 50 clubs into moonshots, elite targets, and high-quality targets. 2. I had the agent research each club independently, including its leadership, PGA professionals, policies, events, social media, recent news, reviews, charitable connections, and possible introductions. 3. The agent identified the most appropriate contact and researched why that person made sense. 4. Before writing, it gathered specific details so each email was clearly personalized rather than a blast. 5. I trained its cold-outreach persona to sound like a blend of me and two or three sales trainers I admire, including Josh Braun-style low-pressure curiosity, short conversational writing, humor, and an easy way to say no. 6. The agent can learn new skills and add them to its protocol. For example, when it struggled to find employee email addresses, I taught it my Google search method. That method is now part of the workflow it uses for future clubs. 7. I tracked everything in a live Google Sheet showing the current status, progress, next action, opportunity status, and whether I need to approve something. The current status column is highlighted so I can check where every club stands in real time. The statuses include: Researching → Ready for AJ Review → Outreach Sent → Conversation Open → Opportunity Identified → Monitoring. 8. If there is no immediate path, the agent does not keep bothering the club. It moves the club into monitoring mode and waits for a better opportunity. 9. When someone responds, the system keeps the relationship history so future communication builds on the real conversation. The live tracker is shown in a Google Sheet status screenshot. What I like most is that the AI isn’t doing one isolated task. It handles the repetitive parts of an ongoing objective—research, qualification, contact discovery, personalization, organization, monitoring, and follow-up—while leaving the important judgment calls with me. Eventually, I want it operating like a 24/7 private-golf-access concierge: 50 clubs being researched and monitored, with me only getting involved when the agent finds something worth acting on. TOOLS USED: ChatGPT, Gmail, Google Sheets, Google Drive/Docs, web research, and AI agents/automations.

AI agents can generate impressive work quickly, but the agent that created something is not necessarily the best judge of whether it is correct, complete, secure, or ready to move forward. Without an independent review step, mistakes can compound as later stages build on work that was never properly validated. I created a system of specialized AI review agents that act as quality gates between stages of work. Instead of letting the agent that performed the work decide whether it is finished, a separate reviewer evaluates the output against explicit criteria and makes a gate decision: PASS or NEEDS REVISION. Different reviewers focus on different dimensions. In my software development workflow, I use reviewers for implementation fidelity, code quality, security, performance, and specification compliance. A feature does not advance until the required reviewers have passed it. Step-by-step: 1. Define what “good” means before the work starts. Give reviewers an explicit source of truth, such as a specification, plan, acceptance criteria, coding standards, security rules, or quality rubric. 2. Separate execution from evaluation. The agent that performs the work should not be the only agent deciding whether that work is acceptable. 3. Create specialized reviewers for important quality dimensions. For software, this might include implementation, code quality, security, performance, and specification reviewers. The same pattern can be used for research, writing, factuality, compliance, financial analysis, or brand review. 4. Run the appropriate reviewers when a stage is complete. Each reviewer independently inspects the work from its assigned perspective and actively looks for reasons it should not advance. 5. Require an explicit gate decision. A reviewer must return either PASS or NEEDS REVISION, along with concrete findings and recommended fixes. In my workflow, reviewers can block progression for issues such as missing tests, even when the underlying implementation appears correct. 6. Route failed work back to the appropriate agent. The worker fixes the identified problems and submits the work for review again. 7. Advance only after the required gates pass. Later stages should not build on work that still has unresolved review findings. 8. Keep humans at consequential decision points. AI reviewers can determine whether work satisfies their assigned criteria, but important actions such as merging, deploying, publishing, or otherwise committing the result can remain human decisions. Instead of treating AI-generated work as complete simply because an agent produced it, I create a controlled loop: Build → Review → Fix → Re-review → Pass → Advance The result is a more reliable workflow where specialized agents perform the work, independent agents challenge it, and errors are caught before they propagate into later stages.

Post-production for each of my podcast episodes used to be a significant task, even when an episode was audio-only. I’ve now built a workflow with Claude and Descript to automate the production process. I clean up the original recording in Descript, export the transcript to Claude, and run a single command to generate the remaining assets. This includes show notes for Hello Audio, opening and closing scripts written in my voice using anti-AI files to avoid a robotic tone, audio clips and audiograms for social platforms through a custom Claude skill, teaser posts for each audiogram on LinkedIn, and launch-day posts for LinkedIn and Substack, where my audience is. I’m sure there’s a way to streamline the workflow further to include distribution of the posts, audiograms, and episodes. It’s a work in progress 😀 Step-by-step: 1. I clean up the original podcast recording in Descript. 2. I export the transcript from Descript to Claude. 3. I run a single command in Claude to produce show notes for Hello Audio. 4. I generate opening and closing scripts for each episode using my voice and anti-AI files to avoid a robotic tone. 5. I use a custom Claude skill to automate the production of audio clips and audiograms for social platforms. 6. I create teaser posts for each audiogram on LinkedIn. 7. I prepare the main LinkedIn and Substack posts for each episode’s launch day. 8. I’m continuing to look for a way to streamline distribution of the posts, audiograms, and episodes.

Microsoft is retiring Publisher on October 1, 2026. I have many `.PUB` files that I need to convert to PDFs before then, but I did not want to use online converters. I wanted a solution that would run locally on my computer. I worked with Claude to create a lightweight program that searches for `.PUB` files on a drive of my choice and converts them into high-quality PDF files, placing each new PDF in the same folder as its source file. Opening PowerShell manually and managing permissions was too cumbersome, so Claude also created a batch file to make the process easier. For anyone who wants to create their own mini-program, I asked Claude to create a reusable prompt. I posted that prompt at https://mediumseagreen-seal-177480.hostingersite.com/ along with my two files: the batch file and the PowerShell commands. Step-by-step: 1. I identified the `.PUB` files I needed to convert before Microsoft retires Publisher on October 1, 2026. 2. I decided to use a local solution instead of an online converter. 3. I worked with Claude to create a lightweight program that searches a selected drive for `.PUB` files. 4. I set up the program to convert the files into high-quality PDFs and place each PDF in the same folder as its source `.PUB` file. 5. I used a batch file created by Claude so I would not need to open PowerShell manually or manage permissions each time. 6. I asked Claude to create a reusable prompt for others who want to build their own version and posted it with the batch file and PowerShell commands at https://mediumseagreen-seal-177480.hostingersite.com/.

My AI digest looked perfect and was quietly wrong. What actually fixed it. Every run succeeded. Every dashboard was green. And the content was still wrong. My digest invented "AI Moat Brief", a newsletter that does not exist. It reported scan counts nobody measured. It resurfaced week-old stories as fresh headlines. Here is what broke, and what fixed it. The sorting used to happen in my head: skimmed subject lines, unopened tabs, quiet guilt. The Signal is one email at 08:00: a single Make scenario calling Claude Sonnet through OpenRouter. It reads the last 24 hours of my RSS feeds and newsletters, keeps what touches what I am actively building plus the domains I need to stay current in, and arrives in the language I actually think in. Core items end with what it means for my work. Five to ten minutes, and I know where to go deep today. Structurally it looks like this, minus the content, rendered in English for this post (Image 1). No real edition is shown; section names and sample lines are illustrative. The dangerous failures were never pipeline failures. They were content failures, and the cause is structural: an LLM summarizing newsletters that already summarize primary sources is third hand by construction. Every hop strips attribution and adds confidence, and when data goes missing the model fills the gap the way LLMs do: fluently. Valid HTML, confident tone, green pipeline, wrong content. Image 2 is that whole failure class in one frame. Three rules closed the gaps I caught, all live in production: Step-by-step: 1. Verbatim or nothing. A source name is copied character for character, and a link exists only if that exact URL is in the input. The model copies; it never composes. 2. The model never generates metrics. Every count the report shows is injected by the pipeline after the model returns. 3. Recycled news gets demoted. A recap of recaps gets one line at most, and is dropped when the underlying story falls outside the collection window. Rules 1 and 3 lean on the prompt, and that is why the counters exist. The pipeline writes a hidden HTML comment into every email it sends: items, links, urls, cost, finish status. That line caught what I could not see. In one run, the published-links counter and the leftover-urls counter read 45 and 435: the only sign a new cleanup step was a silent no-op. Another morning the model stopped at 15,999 tokens against a 16,000 cap, one token from an email cut off mid-sentence. On the morning I wrote this they agreed, 21 links and 21 urls, and boring is the goal. Image 3 is that morning's actual comment, with the same two counters from the no-op run. The run itself has a dead man's switch on Healthchecks.io, so a missing 08:00 email reaches me before I notice. Honest limits: the $0.31 per report is a fresh measurement I am still validating, and I have not proven these rules hold as the source set scales. There is more behind every part of this; I would rather share it where it is wanted. Ask and I will put it in the comments: the three rules in full, the exact cost and what drives it, what this replaced in my day, how it compares to what is on the market, or the ugliest of the 15 documented bugs. I am sharing this because I doubt I am the only one building fragile things behind the scenes, and monitoring text is harder than monitoring uptime. What content-level checks do you run on LLM output, the kind pipeline monitoring cannot see? Real thresholds and embarrassing failures especially welcome.