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

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

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.

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

I run a small healthcare clinic and needed a monthly performance scoreboard that combined data from three separate sources: Google Analytics (GA4), my booking or appointment system, and a cashflow spreadsheet. Pulling everything manually each month took more than an hour and was prone to errors. I automated the pipeline using Claude-in-Chrome shortcuts and Claude’s analysis capabilities, reducing the process to around 10 minutes of hands-on time. Service businesses often have performance data scattered across a website analytics platform, a booking or practice management system, and a finance tool. Creating a coherent monthly view requires exporting data from each source, cross-referencing it, and manually calculating derived metrics such as rebook rate and conversion rate. This workflow automates data collection and analysis in one step. Step-by-step: 1. I set up two scheduled Claude-in-Chrome shortcuts to run automatically on the 1st of each month. One exports the GA4 Traffic Acquisition CSV, and the other exports the GA4 Pages and Screens CSV. Both save directly to a designated Google Drive folder. 2. On the 1st, I manually trigger a third Claude-in-Chrome shortcut. It logs into my booking system, navigates to the appointments export, and downloads the month’s appointment data. I keep this step manual because most booking systems log users out between sessions. 3. I open my cashflow spreadsheet and note the month’s revenue and profit figures. This takes about 30 seconds to do manually. 4. I open a Claude session and upload all four files together: the two GA4 exports, the appointment data, and the cashflow figures. 5. I prompt Claude to calculate the key metrics: total appointments, new patients, utilisation rate, rebook rate, average spend, online bookings, and website-to-booking conversion rate. The rebook rate is calculated from the appointment data as patients with a future booking divided by total patients seen. 6. Claude produces a formatted monthly scoreboard, flags anything that looks anomalous, and compares the results with the prior-month baseline when I include last month’s scoreboard in the upload. 7. Optionally, I ask Claude to produce individual practitioner breakdowns from the same appointment data, splitting the metrics by staff member for use in one-on-one reviews. The result is a complete, accurate monthly clinic scoreboard in around 10 minutes, with no manual calculations. The rebook rate computation alone, which previously required cross-referencing two separate reports, now takes seconds. The same workflow can adapt to any service business using a booking or practice management system that allows CSV exports. Tools used: Claude (Sonnet 5), Claude-in-Chrome extension, Google Analytics GA4, Google Drive, any booking or appointment system with CSV export capability, and Google Sheets or Excel for cashflow figures.

I use Gemini Learn to fast-track my learning about Unblooms. Here's the prompt I used: ```text "I'm learning about the Unblooms, https://substack.com/home/post/p-194387968, https://unblooms.gainable.ai/, as well as any resource you can find to help me. I need to understand what it is, how it works, and ways I can use it when designing powerful learning experiences for my students." ``` Gemini Learn guided me through classroom examples of how Unblooms works, using examples from my own teaching because I customized my Gemini account with content from my teacher blog. Gemini helped me create three separate graphic organizers that my sixth-grade Math and Science students can paste into their interactive notebooks to track their decision trails when using and critiquing AI in class. Step-by-step: 1. I used Gemini Learn to study Unblooms and understand what it is, how it works, and how I could use it to design learning experiences for my students. 2. I gave Gemini Learn the Unblooms resources and prompt above, along with access to teaching content from my teacher blog through my customized Gemini account. 3. I asked Gemini Learn to explain Unblooms through classroom examples connected to my own teaching. 4. I used Gemini's guidance to create three graphic organizers for my sixth-grade Math and Science students. 5. My students can paste the organizers into their Math and Science interactive notebooks to track their decision trails when using and critiquing AI in class.

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.

After a sales call, the conversation is only part of the work. Someone still needs to write the notes, update the CRM, remember the next step, prepare the follow-up email, and make sure the deal does not disappear between meetings. I wanted that entire post-call process to happen automatically. I created an Awish workflow that starts when a sales call ends. It analyzes the conversation, extracts the important sales information, updates the CRM, creates the next actions, drafts a personalized follow-up email, and sends the team a short summary. The workflow looks for the information I would normally write down myself: what the prospect needs, the objections they raised, their timeline, agreed next steps, and anything that could affect the deal. Customer-facing actions stay under my control. The workflow prepares the follow-up, but I can review important messages before they are sent. Step-by-step: 1. I tell Awish what I want to happen after every sales call: analyze the conversation, update the CRM, prepare the follow-up, and notify the team. 2. Awish understands the request, plans the workflow, and determines which applications are needed. 3. I connect my meeting platform, HubSpot, Gmail, and Slack to the automation. 4. When a call ends, the workflow analyzes the transcript and extracts the prospect’s needs, objections, timeline, decisions, and agreed next steps. 5. It creates or updates the contact and deal in HubSpot and adds any follow-up tasks that came out of the conversation. 6. It drafts a personalized Gmail follow-up based on what was actually discussed instead of using a generic sales template. 7. It sends a short Slack summary to the team with the deal status, important points, and next action. Instead of a sales call ending as a transcript or a page of notes, it immediately becomes structured CRM data, clear next actions, and a follow-up that is ready to review. The useful shift for me is that the workflow is not replacing the sales conversation. It is handling everything that normally gets forgotten or delayed after the call.

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.

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.

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.

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.

Having a team of specialized AI agents creates a new problem: someone still needs to decide which agents should work on a project, what order they should work in, what each one needs from the others, and whether the project is actually finished. Without coordination, the human becomes the project manager, manually moving context and outputs between agents. I created a project-manager agent that acts as the orchestrator for my AI team. I give it an objective, and it determines what work needs to happen, selects the appropriate specialist agents, sequences their work based on dependencies, and presents the execution plan to me before anything starts. Once I approve the plan, it coordinates the agents, manages their handoffs, tracks project state, and maintains enough persistent context for the work to continue across sessions. Step-by-step: 1. I create several specialized agents with clearly defined responsibilities, capabilities, and expected outputs. 2. I create a project-manager agent that knows what each specialist does and is instructed to orchestrate the work rather than perform specialist work itself. 3. I give the project manager a high-level objective. It analyzes the goal, inspects the project context, identifies the required work, and selects the appropriate agents. 4. I have it create an execution plan showing which agents will be used, what each one will do, their dependencies, and the order of execution. 5. I require human approval before execution begins. I can approve the plan, narrow the scope, change the sequence, or redirect the project as needed. 6. Once the plan is approved, I let the project manager delegate each task to the appropriate specialist and pass relevant context and prior outputs between agents through structured handoffs. 7. I track progress and project state as the agents complete their assignments. If an agent uncovers new work, fails review, or changes the project assumptions, the project manager updates the plan and routes the next work accordingly. 8. At the end of the session, I save the current state, completed work, important decisions, and next actions so another session can continue without reconstructing the project from scratch. Instead of personally coordinating every AI agent, I manage the project at a higher level: I define the objective, approve the plan, review important decisions, and evaluate the result. The AI project manager handles the coordination layer, turning a collection of specialized agents into a team that can execute complex, multistep projects coherently.

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

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.

I’ve been using the Awish app I built less as an automation builder and more as a way to solve specific business problems people bring me. One hotel client, Aurelia Bay Hotel, had an interesting marketing problem. They could see travel trends across search, Instagram, YouTube, website traffic, and ads, but connecting those signals early enough to spot a real campaign or guest-experience opportunity was difficult. I built an automation for them with Awish and gave it to them to test. Step-by-step: 1. I opened the Awish chat and wrote: “For Aurelia Bay Hotel, monitor Google Trends, YouTube, Instagram, Google Analytics, and Google Ads every day. Find rising interests around Dubai travel, staycations, family trips, wellness, dining, events, and hotel experiences. Cross-check those trends with social engagement, website behavior, and campaign performance. Rank the strongest opportunities, send them to the marketing team in Microsoft Teams for approval, and create a campaign or guest-experience opportunity brief in SharePoint for anything they approve.” 2. Awish understood what I wanted, planned the complete workflow, and selected the apps required for each step. 3. I reviewed the plan, connected the client’s accounts, and approved it. 4. Awish added Microsoft Teams as the human approval step and SharePoint for the final opportunity briefs. 5. Once everything was connected, Awish built the workflow and started running it daily. 6. It now cross-checks trend growth, social engagement, website behavior, and ad performance. When it finds a strong opportunity, the marketing team gets the evidence in Teams. If they approve it, Awish creates the full campaign or guest-experience brief in SharePoint. The useful part is that a trend isn’t treated as an opportunity just because it is growing on one platform. Awish checks whether the same signal is appearing across the business before recommending action. Do you have any time-consuming, repetitive tasks or problematic aspects in your job? I would be happy to develop an automation solution for you as well.

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.

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

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