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

I built a workflow called PeopleSparkles for researching people connected to creative fields, schools, collectives, residencies, local art scenes, and cultural networks. The workflow starts from a defined group of people, for example teachers, alumni, artists, current or former members of an association, residents, or associates connected to a specific academy, organization, or cultural scene. A typical research request can be as simple as: “Look at this art website and identify all current and former residents and associates. Build a list. Then research them in batches of ten, checking their websites and other relevant sources, and write a short description of their work. Deliver the results in a format that can be imported into my local database.” Before each new research run, I provide GPT with a ZIP containing the current state of the PeopleSparkles database. This means the research starts from the existing corpus rather than from scratch. New people can be added, existing entries can be expanded, and previously researched people can be recognized before new material is prepared for import. The actual database lives locally on my computer. Apart from the initial development of the code and the research needed to create new lists of people, the database itself runs locally. Once a new batch has been researched and imported, browsing, organizing, scoring, annotating, and using the material does not require the whole corpus to be sent back for analysis. The database also generates a human-readable HTML version with a designed layout, so the research is not trapped inside raw data or spreadsheets. I can browse the people and their notes visually as a small personal research publication, while the underlying structured data remains available for future additions and processing. The “Sparkles” part is personal. I can add my own notes and scores to each person to capture whether their work sparked something in me, and if so, how. That might be curiosity, recognition, inspiration, aesthetic attraction, a strong question, a surprising association, or simply the desire to look again. This means the database does not only record who someone is and what they make. It also records my evolving relationship to their work. Over time, that creates a second layer on top of the research corpus: not just a map of creative people, but a map of resonance. The database also includes a “Surprise me” function that brings up a person from the collection without me choosing them deliberately. This helps break habitual search patterns and allows older, less obvious, or previously overlooked entries to resurface. Someone I barely noticed months ago can suddenly become relevant in a completely different creative context. The purpose is not to create conventional biographies. I am interested in the sparks around a person: what they make, the media and themes they work with, the organizations or people they connect to, and which traces may lead somewhere unexpected. This is particularly useful for creative ecosystems where information is fragmented across artist websites, academy pages, exhibition archives, old posters, association websites, interviews, catalogues, and small cultural organizations. The workflow gathers those fragments into a cumulative research corpus. It also allows the research to grow organically. One artist may lead to a collective, a teacher to a former student, an exhibition to another maker, or an old membership list to someone whose work would never have appeared in a conventional search. In simple terms: existing local database → new source or people list → GPT-assisted discovery and research in batches → import-ready structured data → local database → HTML browsing, notes and scores → surprise rediscovery → new creative connections The result is a living creative research database that combines external research with personal resonance, so I can not only discover people, but also trace which work actually sparks something in me over time.

I built a system that reads my AI newsletters every morning and turns them into a searchable catalog of AI tools, plus a chat website where I can ask questions about the catalog in plain English. The system has two parts: a workflow that collects the information and a website that answers questions about it. I subscribe to several AI newsletters, and each issue mentions five or ten interesting tools. I would read about one and think, “I should remember that.” Months later, I would vaguely remember it but have no quick way to find it. I wanted a repository of these AI tools that I could search easily. The collector is a scheduled Claude Code Routine that runs once a day. It searches Gmail for newsletters from the last 24 hours and reads each email in full. It extracts every AI tool’s name, description, category, official link if present, and source newsletter. It skips non-AI items and pure ads but keeps sponsors that are genuine tools. Before adding anything, it checks for duplicates. New tools are added under the appropriate category in alphabetical order. If an existing tool has fresh details, its description and “last updated” date are refreshed. Tools mentioned by three or more sources receive a “Highly Mentioned” tag, which is a useful signal for what is catching on. The workflow also creates categories when new tools do not fit into an existing one. The workflow commits and pushes the catalog to a private GitHub repository, then posts a summary to Slack. The catalog is a single Markdown file—plain text, human-readable, and versioned in Git, with no database. The chat website displays the tool count, category count, and last-updated date, along with clickable example questions. If I ask, “Is there anything for voice AI?” it returns a written answer listing every match with descriptions and working links. The site is a React single-page app on Netlify with two small backend functions: one returns the statistics, and the other handles chat. When I ask a question, the backend fetches the Markdown file from the private repository, sends it to Claude along with my question, and returns the answer. To recreate it, you’ll need a GitHub account, Netlify (the free tier is fine), an Anthropic API key, and Claude Code. The routine prompt is the most important part. It names the exact newsletters, lists the fields to extract, and explicitly says: never invent a URL, never delete an entry, and only add or update. Vague instructions produce files that degrade over time. I learned a few things the hard way. Newsletters deleted before the workflow runs may cause it to report “nothing new,” so the logic should also check Trash or Deleted items. Tokens expire, and mine quietly expired, which caused the search site to stop working. Choose a long expiration period and record the date. Also, explicitly say “never invent a URL,” or the workflow may produce plausible links that go nowhere. It now runs every morning without me. When I need something, I ask a question and get an answer in seconds instead of trying to remember which newsletter, and which month, mentioned the tool I’m thinking of. Step-by-step: 1. I created a private GitHub repository with a starter Markdown file containing “Last updated” and “Total tools” fields, category headings, and consistent fields for each tool. 2. I wrote a Claude Code Routine prompt that names the newsletters, specifies the fields to extract, and instructs the workflow never to invent a URL, never to delete an entry, and only to add or update tools. 3. I scheduled the routine to run daily with Gmail access. 4. Each day, the routine searches Gmail for newsletters from the previous 24 hours, reads them, extracts AI tools, skips non-AI items and pure ads, preserves genuine tool sponsors, and checks Trash or Deleted items when necessary. 5. The routine checks for duplicates, adds new tools alphabetically under the right category, updates existing tools with fresh details, creates categories when needed, and applies the “Highly Mentioned” tag to tools found in at least three sources. 6. The routine commits and pushes the Markdown catalog to the private GitHub repository and posts a summary to Slack. 7. I built the frontend with Vite and React, including a statistics header, a scrollable message list, an input box, and example questions. 8. I added two backend functions: one for statistics and one for chat, with the GitHub fetch handled by a shared helper with a short cache. 9. I created a fine-grained, read-only GitHub token limited to the single repository. 10. I deployed the site to Netlify with the required keys stored as environment variables rather than in the code. 11. When I ask a question, the backend fetches the Markdown catalog, sends it to Claude with my question, and returns the matching tools, descriptions, and links.

After nearly 20 years in France, I’m finally applying for citizenship. I’ve spent the past year preparing documents and studying for the required tests, and my final interview is a few weeks away. Alongside the official study materials, I’ve been using ChatGPT to drill key facts and historical dates, run mock oral interviews in voice mode, and create quizzes from YouTube videos I link whenever they cover the right material. ChatGPT sometimes speaks French with a rather heavy accent, but the interactive back-and-forth helps me remember hundreds of details that are difficult to retain by simply reading a page. It’s tedious, but I find rote memorization challenging. We’ll see how it goes under pressure.

I used Claude Code to build a 13-agent workforce for generating micro-courses. Each agent has its own job description and a defined role in the workflow, which begins with document analysis and ends with a course package agent delivering a complete, interactive HTML prototype as a local file. The agentic workforce creates knowledge-check quizzes with corrective feedback. Each micro-course also includes a downloadable handout highlighting the main points. In my case, a human course builder receives the final interactive HTML prototype and uses it to update our organization’s course catalogue. The HTML file is available for everyone to use as well. This reduced the production time from three months to two hours at most. I also included a security gate that redacts information from transcripts used to create course content. I’m happy to share more—we’re talking about folders and files here. Step-by-step: 1. I used Claude Code to build a 13-agent workforce for generating micro-courses. 2. I gave each agent its own job description and defined workflow. 3. I started the workflow with document analysis before the work begins. 4. I used a course package agent to deliver a complete, interactive HTML prototype as a local file. 5. I had the workforce create knowledge-check quizzes with corrective feedback. 6. I included a downloadable handout with highlights at the end of each micro-course. 7. I sent the final interactive HTML prototype to a human course builder, who updates our organization’s course catalogue from it. 8. I added a security gate to redact information from transcripts used for course content. 9. I made the HTML file available for everyone to use.

I built a workflow for turning large ChatGPT conversation exports into a usable personal and creative archive instead of simply storing them as backups. The archive is processed incrementally. The inventory is built offline, and conversations that have already been indexed are not needlessly reanalyzed on every run. Each new export is compared with the existing archive, and only newly added conversations or conversations that have been revisited, extended, or otherwise changed are processed again and updated in the inventory. This keeps the workflow lightweight while allowing the archive to evolve over time. A conversation can remain stable for months, then become relevant again and receive new material without forcing the entire archive back through analysis. This matters because many of my conversations are long, layered thinking sessions: creative explorations, project development, research, problem-solving, or extended reflection. Without an inventory, the depth inside those individual conversations and thinking processes becomes difficult to retrieve later. The workflow makes long-form analysis and creative thought processes findable and reusable without flattening them into a few generic summaries. On top of the inventory, I use lightweight “blubscans” (analysis to improve retrieval): small, human-readable summaries that capture what mattered during a day or period without replacing the original conversations. They act as a navigational layer between thousands of raw messages and the things I may want to find, understand, revisit, or continue later. The important principle is that compression never becomes deletion. The raw conversations remain the source of truth, the inventory provides structure, and the scans provide context and tone. The result is more than a backup system. It becomes working creative memory: something I can preserve, search, revisit, connect across time, and reuse for projects, research, writing, pattern-finding, and future creative work. In simple terms, the structure is: raw exports → offline incremental inventory → blubscans/context layer → retrieval and reuse for later projects and creative work That way, the archive stays deep without becoming heavy, and useful without constantly reprocessing everything that was already understood. Step-by-step: 1. I collect large ChatGPT conversation exports as the raw source material for the archive. 2. I build and maintain an offline inventory of the conversations that have been indexed. 3. With each new export, I compare the conversations against the existing archive. 4. I process only newly added conversations and conversations that have been revisited, extended, or otherwise changed. 5. I update the inventory with the results while leaving stable conversations untouched. 6. I create lightweight “blubscans” with small, human-readable summaries of what mattered during a day or period. 7. I use the raw conversations as the source of truth, the inventory for structure, and the scans for context and tone. 8. I retrieve and reuse the archive for projects, research, writing, pattern-finding, and future creative work.

Content Repurposing System: one transcript into 4 platform-ready posts in 18 seconds. THE PROBLEM Every video cost me two hours turning it into posts for Twitter/X, LinkedIn, Skool and Instagram. The writing wasn't hard. The context switching was. Four platforms, four tones, the same idea rewritten four times. Built during the Skool x Hostinger n8n hackathon, Dec 2025. Still my daily workflow. STACK: n8n on a Hostinger VPS, OpenAI, Google Sheets. 13 nodes. HOW TO BUILD IT Manual Trigger. Swap for a Form or Drive trigger if you want it hands-off. Set node "Set Transcript", one string field: transcript. Leave a real sample transcript in the default value so anyone can hit execute and see output immediately. IF node "Check Transcript", two conditions with AND: transcript is not empty, and {{ $json.transcript.length }} > 50. False branch goes to a Stop and Error node. Four minutes of work. It's why I've never burned 5 API calls on a blank field. OpenAI node "Analyze Content", model gpt-5.4-mini, Simplify Output OFF: You are a content analyst. Analyze this video transcript and extract: Main topic/theme 3-5 key insights or takeaways Target audience Tone (educational, motivational, technical, etc.) Any specific examples, statistics, or stories mentioned Transcript: {{ $json.transcript }} Provide your analysis in a structured format. I don't send the transcript to four writers. I send it to one analyst first, and all four writers read that analysis. This lifted quality more than any prompt tweak: the posts share one reading of the material instead of each model guessing. The stronger model goes here for the same reason. Wrong analysis, four wrong posts. 5-8. Four generators, all gpt-4o-mini, Simplify Output OFF, all wired from Analyze Content's single output. Each pulls the same two inputs: Content Analysis: {{ $('Analyze Content').item.json.choices[0].message.content }} Original Transcript: {{ $('Set Transcript').item.json.transcript }} Then its own rules. Twitter (temp 0.8): hard hook, under 280 chars, one insight, no hashtags. LinkedIn (0.7): 150-250 words, 2-3 line paragraphs, ends on a question, no hashtags. Skool (0.8): 100-200 words, always a numbered list of actionable takeaways, ends by inviting replies. Instagram (0.8): 125-175 words, 5-8 hashtags, plus a detailed "Visual suggestion:" for a designer or image model. LinkedIn needed a tone block after v1 read like a press release: talk like you're with a colleague over coffee, use I and you, never "leverage", "in today's landscape", "fast-paced". Naming banned words works. "Write conversationally" does nothing. Merge node "Collect All Posts", 4 inputs, one generator per index. Aggregate node, mode All Item Data. Puts all four posts on one row instead of four. Code node "Format Output". Reads each generator by node name, each in its own try/catch, so one failure still writes a row. Builds a readable timestamp, a 100-character transcript_preview, and status: 'Generated'. Google Sheets, Append Row, Map Automatically. THE SHEET Seven columns, headers in row 1, named to match the Code node exactly: timestamp, transcript_preview, twitter_post, linkedin_post, skool_post, instagram_post, status. Status is a dropdown: Generated > Reviewed > Scheduled > Published. The system drafts, I decide. FOUR THINGS THAT COST ME HOURS Turn Simplify Output OFF on every OpenAI node. Every expression reads choices[0].message.content, which only exists in the raw response. Leave Simplify on and you get four empty columns with no error explaining why. No title row above your headers. I had a merged title in row 1, headers in row 2. Map Automatically stopped seeing my columns and silently built duplicates beside them. Extend data validation down the whole column (G2:G1000, not G2). I set the dropdown on one cell and every appended row arrived as plain text. Kill markdown in the prompt, not after. I wasted an evening regex-stripping ** in the Code node. The fix was upstream: tell Skool and Instagram plain text only, CAPITALS or "quotes" for emphasis. Zero artefacts since. Post-processing cleanup means your prompt is underspecified. RESULT Two hours per piece became 18 seconds of runtime plus 5-10 minutes of review. I tested 20 transcripts across five content types (tutorial, interview, news, explainer, motivational). Most were publishable with light edits. The failure mode never changed: rambling transcript, vague analysis, four vague posts. Which is exactly why the analyst node gets the better model. Budget 30 minutes to rebuild. The prompts are the product. Copy the structure, then rewrite the platform rules in your own voice. That's what decides whether it sounds like you or like everyone else.

I’m a commercial excellence consultant for industrial B2B businesses, and very few of the clients I speak with have a current view of the competition in their market. Nobody has mapped the competitive landscape recently—sometimes they never have. Clients can often name the companies in the market, but they can’t explain what those competitors do differently or why a customer would choose one over them. That gap is expensive. The mid-market manufacturers I work with, typically in the $75 million to $300 million range, usually don’t have a strategy team to close it. The alternatives are consulting rates for research that goes stale as soon as it’s delivered or a generic template that says the same five things about every market. Neither option is necessarily wrong, but neither is very useful. So I built a Claude Skill: an instruction set that runs live research every time instead of pattern-matching to a generic answer. The input is simple: the company name, its brand voice, the research scope, the geography, and a known competitor list if one is available. Before researching a single competitor, the Skill states the decision the report needs to inform—for example, whether to enter a vertical, how to price against a rival, or where to direct sales next quarter. It checks the client’s own website and capabilities next; an early version once recommended something the client already had. It then maps the competitive field across five tiers: direct, adjacent, disruptor, new entrant, and aspirational for PE-backed clients. It checks Asia-Pacific specifically because that’s the blind spot I’ve seen missed most often. Market size carries a confidence flag instead of false precision. Findings become battlecards phrased the way reps actually talk, rather than in analyst language. The report also includes a threat ranking with a timeline attached, then closes with three opportunities, three risks, and four to six moves for the quarter. Every recommendation is filtered through the original decision instead of being included simply because the research was interesting. The output is two files: an interactive HTML report and a matching PDF. Both are built entirely in HTML and CSS rather than with canvas charts, which can break in exactly the ways that matter—blank on load or missing from the PDF. None of what makes this useful is the AI itself. The important work is naming the decision before researching a competitor, checking what the client already has, tagging confidence instead of faking precision, and writing like a rep rather than an analyst. That’s the difference between a report that gets skimmed once and one that gets acted on. This is one piece of a bigger system I run for industrial manufacturers applying AI to their commercial function. I teach the underlying version of this workflow live. Step-by-step: 1. I provide Claude Skill with the company name, brand voice, research scope, geography, and known competitor list, if available. 2. I define the decision the report needs to inform, such as entering a vertical, pricing against a rival, or directing sales next quarter. 3. I have the Skill check the client’s website and capabilities before researching competitors. 4. I map the competitive field across direct, adjacent, disruptor, new entrant, and, for PE-backed clients, aspirational competitors. 5. I check Asia-Pacific specifically to address a commonly missed blind spot. 6. I assign confidence flags to market-size estimates rather than presenting false precision. 7. I turn the findings into sales-rep-friendly battlecards and add a threat ranking with a timeline. 8. I close the report with three opportunities, three risks, and four to six quarterly moves tied back to the original decision. 9. I deliver the result as an interactive HTML report and a matching PDF, using HTML and CSS instead of canvas charts.

Sometimes I want something good to read but don’t know exactly what. Finding the right book, article, or story means searching through existing content and hoping something matches my current mood and interests. Generative AI creates another option: instead of finding something to read, I can create exactly what I want to read right now. I created a personalized Reading Experience Generator that acts as an on-demand writer rather than a recommendation engine. When I tell it I want something to read, it asks me a few questions—one at a time—to understand what I’m in the mood for. It determines whether I want fiction or nonfiction, the tone and mood, the subject or setting, and any particular angle I’m interested in. Once it knows enough, it writes an original 1,000–2,000-word piece specifically for that moment. The key instruction is that it never recommends existing books, authors, stories, or articles. Its only job is to create something new. Step-by-step: 1. I create instructions that give the AI a single role: when I want something to read, it should write something original, not recommend existing content. 2. I tell it to begin each new reading experience by asking 2–4 questions, one at a time, and to stop asking as soon as it has enough information. 3. I have the questions establish whether I want fiction or nonfiction, my desired mood or tone, the subject, setting, or genre, and any particular angle I’m interested in. 4. I explicitly prohibit recommendations of existing books, authors, articles, or stories. This prevents the assistant from turning the experience into a conventional recommendation engine. 5. I define a target length of roughly 1,000–2,000 words—long enough to become immersed without requiring a major time commitment. 6. I tell the AI to begin writing immediately once it understands what I want. There should be no outline, explanation, or preamble; the next thing I see should be the piece itself. 7. When I want something different, I start again. The AI repeats the short interview and creates a completely new reading experience based on what I’m interested in at that moment. Instead of choosing from a fixed library of things other people have already written, I get an effectively unlimited supply of original reading material personalized to my interests and mood. The interesting shift is that I’m not using AI to help me write. I’m using AI as the writer, and I’m the audience.

I used Claude and Nano Banana 2 to create a detailed landscaping plan for my property. The plan included precise recommendations for plant types and locations, soil testing, purchase lists, local suppliers, expected wholesale pricing, and photorealistic images of the mature planting beds. I refined the plan through 20–30 iterations, incorporating all of my requirements. Because I have previous experience working with landscape architects, I was able to use the AI-generated plan effectively and legitimately saved $5,000 in fees. Step-by-step: 1. I used Claude and Nano Banana 2 to develop a landscaping plan for my property. 2. I included requirements for plant types and locations, soil testing, purchase lists, local suppliers, expected wholesale pricing, and photorealistic images of the mature planting beds. 3. I refined the plan through 20–30 iterations until all of my requirements were incorporated. 4. I used my previous experience working with landscape architects to evaluate and apply the plan. 5. I saved $5,000 in landscape architecture fees.

I write murder mysteries, and like every author, I need an editor to help carry a story from the first raw idea to a finished, publishable script. The trouble is that good editors are rare. The insightful, reliable ones are expensive, and they are often slow. My first murder mystery took the better part of six months to edit. Even after all that time, I still found typos and clumsy sentences that should have been caught during the line edit and proofreading. That is not a criticism of editors; it is the reality of a manual, human-paced process that does not scale to the way I want to work. I do not use AI to write my stories. The voice, plot, and subtext are mine. But line editing and proofreading are different jobs, and that is where I started using AI. Basic paid ChatGPT got me part of the way, but it was not enough. In February, I switched to Claude, and it was a quantum leap: sharper suggestions, better reasoning, and output I could actually trust. I wanted more than a clever assistant. I wanted a process. Rather than wait for the perfect human editor—affordable, brilliant, and available precisely when I needed them—I built my own. My Claude Editor-in-Chief contains my entire editing workflow, along with a few innovations of my own. At its heart is a framework I developed: the Tension Coefficient (TC), ReaderGrip, and StoryDrift. These three lenses show whether a scene is pulling its weight, whether it keeps its grip on the reader, and whether the story is quietly wandering off course. Everything feeds into a dashboard, so I can see at a glance what is working and what needs fixing. The result is a workflow that turns editing from a six-month slog into something that takes a fraction of the time and, more importantly, produces a cleaner, tighter manuscript. I stopped waiting for help and built the editor I always wished I could hire. Step-by-step: 1. I kept the creative work—my story’s voice, plot, and subtext—in my own hands and used AI specifically for line editing and proofreading. 2. I started with basic paid ChatGPT, then switched to Claude in February after finding that it provided sharper suggestions, better reasoning, and output I could trust. 3. I built a Claude Editor-in-Chief around my full editing workflow instead of relying on Claude as a general-purpose assistant. 4. I added my Tension Coefficient (TC), ReaderGrip, and StoryDrift frameworks to evaluate whether scenes are effective, maintain reader engagement, and stay on course. 5. I connected those evaluations to a dashboard that shows what is working and what needs fixing. 6. I use the workflow to reduce editing time and produce a cleaner, tighter manuscript.

I moved from public school to a private school with no autism-specific training, and I found students on the spectrum struggling with one-size-fits-all lessons. AI helped close that gap for both me and my students in about five minutes per lesson. I take a standard lesson and rebuild it around the individual student. I upload only the blank assignment—never any student data—and prompt AI to adapt it to that learner. I include their favorite colors and niche interests, replace abstract examples with personalized ones, add sentence starters, and allow them to draw responses instead of writing dense paragraphs. Step-by-step: 1. I take an existing lesson and create a blank version of the assignment. 2. I upload only the blank assignment to my AI tool, without including any student data. 3. I provide the student’s interests, preferred colors, and reading level. 4. I ask the AI to rebuild the lesson for that specific student. 5. I use personalized examples, sentence starters, and drawing-based response options to make the lesson more accessible. The result is no shutdowns, no walls, and a genuinely engaged and grateful student. One untrained teacher can now individualize any lesson for a unique learner in minutes.

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

I wanted to reduce the time and mental effort it takes each morning to figure out what needs my attention across my inbox and calendar. I used Codex Automations to build Briefly, a daily AI-powered email and calendar brief that is automatically delivered to my inbox every day. Instead of manually searching through emails and checking separate calendar events, I can open one message from Briefly and immediately see what is happening, what needs action, and what is coming up. It has become a simple way for me to use AI proactively—not only when I ask a question, but as an automated system that helps me stay ahead of my emails, tasks, and schedule each day. Step-by-step: 1. I connected the email and calendar sources I wanted the automation to review. 2. I created a Codex Automation that runs each morning. 3. I instructed it to review recent and important emails, identify messages that need attention or follow-up, and check my calendar for upcoming meetings and commitments. 4. I had it turn that information into a concise daily brief. 5. I configured the brief to be delivered to my email automatically.

I built a workflow to track my monthly credit card expenses and keep them within my budget. Tracking my expenses is important to me because I want to reach my financial goals through consistency and healthy habits. However, entering each expense manually into Google Sheets was tiring and took several hours. I used Make to automate the process. The workflow reads the email from my bank every time I use my card, gathers the necessary information, converts it to JSON, and adds it to Google Sheets. It runs every six hours, every day, so I no longer need to spend my weekends reviewing expenses. Now I have more free time to build something else and only need a couple of minutes to review Google Sheets and make sure everything is working properly. Step-by-step: 1. I set up a workflow in Make to monitor emails from my bank whenever I use my credit card. 2. The workflow gathers the necessary expense information from each email. 3. It converts the information into JSON format. 4. It adds the expense data to Google Sheets. 5. The workflow runs every six hours, every day. 6. I spend a couple of minutes reviewing Google Sheets to make sure everything is working properly and that my expenses remain within budget.

Training for a triathlon means three sports and a plan that is fiction by Wednesday. A static plan does not know I slept badly, skipped Tuesday's swim, or that Saturday's long ride wrecked me. Adjusting for that is what you actually pay a coach for. I wanted the adjusting without the retainer. So I built it in ChatGPT Work: a Project holding my plan, plus a scheduled agent run each morning that checks the plan against what my body actually did, then fixes the week. Disclosure: I built freddy, the connector feeding ChatGPT my training and recovery data, so I am not neutral here. Step-by-step: 1. Connect your sources at freddy.coach. For triathlon it is whatever records your swims, rides and runs: Garmin Connect, Polar, Suunto, WHOOP or intervals.icu. I use Oura for sleep and recovery, Garmin Connect for sessions, Hevy for strength. History backfills automatically, so the plan is built on your real training rather than what you tell it you did, which is usually flattering. 2. Add freddy as a custom connector: Settings, then Connectors or Apps and Connectors, then Add new, then custom MCP server. The URL is https://freddy.coach/mcp. Sign in and approve read access. Do it on the web; the mobile app cannot add custom connectors. 3. Connect Google Calendar and turn on write actions. This is the step people miss: write actions are off by default, so until they are enabled through action controls the agent can read your week but not change it. With writes on, ChatGPT Work creates and edits events. 4. Create a Project and put the durable facts in the project instructions: race date and distance, realistic weekly hours, immovable days, injury history, weakest discipline, and how blunt you want it. Long-lived facts only, never this week's session. 5. In the project, with freddy on, ask it to build the block: a periodised plan to race day, justified against your actual last 8 weeks rather than a textbook ramp. Keep the plan as a file in the project so every run starts from the same document, and have it write the week's sessions to the calendar with type, duration and intensity in the event body. 6. Schedule the daily run for mid morning, after you are up and your sources have synced. Last night's sleep does not exist anywhere until the watch or ring syncs, so a 5am run reports on the night before last. The standing prompt: "Using freddy, check whether I completed yesterday's planned session: pull yesterday's workouts with type, duration and intensity and compare against what the plan called for. Then pull last night's sleep and this morning's recovery including HRV and resting heart rate, plus training load over the last 7 days, compared against my own 30 day baseline rather than population norms. Then look at today's planned session on my calendar and decide whether it still makes sense. If it does, confirm in one line. If not, change the calendar event to the session I should actually do, put the reason in the event body, and update the plan file. Tell me what you changed and why, naming which source each conclusion came from. If two sources disagree, say so rather than averaging. Never compare HRV across different sources. If anything is ambiguous, such as an unrecorded session or a workout matching no planned one, ask me instead of guessing. Under 250 words." 7. Let it run a week before trusting it, and read what it changed rather than skimming. Expect to tune the instructions early: the usual failure is turning cautious after one poor night, fixed by a line saying a bad night is noise and to downgrade only on a trend or after a hard day. Two things to know. Depending on your approval settings, a run either makes the change or holds it for a tap. Know which you chose: it is the difference between waking to a changed calendar and a proposed one. And agent runs are metered, so keep the daily check narrow and save long reasoning for a weekly review. What surprised me is how good it is at catching the sessions I quietly did not do. It is easy to tell yourself you are on plan, harder when something reads yesterday's file and notes the intervals were short. Gotchas. Make it commit to one call on today's session; "listen to your body" is what you already had. Make it name the source behind each conclusion so you can tell a real finding from a confident guess. Never let it compare HRV across sources, because RMSSD and SDNN are different measurements, not different units, so mixing them looks meaningful while being nonsense. Scheduled runs auto-pause if ignored, so if the check stops arriving, look there before blaming the connector. It is not a certified coach and I would not rehab an injury with it. It is very good at holding a plan, watching what happened, and closing the gap before it becomes a lost week. Cost: freddy is free for one source, but this is cross source so it is the paid plan, $49 a year, on top of ChatGPT. Individual triathlon coaching runs a few hundred a month.

I built a workflow to evaluate whether communication with a legal counseling service was as slow and incomplete as it felt. Email was my primary—and necessary—communication channel with them. I had become increasingly dissatisfied with delayed replies, partial answers, and questions that seemed to remain unresolved. Rather than relying only on memory or frustration, I asked GPT to review the relevant Gmail correspondence and turn it into a structured communication inventory. The workflow identified my outgoing questions, their replies, and whether each question had been fully answered, partially answered, or left open. From that inventory, we could calculate concrete indicators such as the median response time, the longest delay between a question and a substantive reply, and the number of questions that remained unresolved or were only partly addressed. This was useful because long email threads can create a distorted sense of what happened. A few frustrating exchanges can dominate memory, while other delays or omissions disappear into dozens of messages. Structuring the correspondence made the pattern measurable. The analysis was not meant to decide whether the counselors were “good” or “bad.” It was meant to answer narrower questions: How quickly were questions usually answered? Which ones were not answered? Were replies resolving the issues raised, or only responding to part of them? Afterward, we created a clear list of the questions that were still open. I used that list as a set of dossier questions when moving the case to another counselor, turning the analysis into practical continuity rather than just a complaint about the past. In simple terms: Gmail correspondence → question-and-response inventory → response-time and completeness analysis → unresolved-question list → handover to another counselor What I liked about this workflow is that it turned a vague feeling that “this communication is not working” into a documented overview I could actually use. Step-by-step: 1. I gathered the relevant Gmail correspondence with the legal counseling service. 2. I asked GPT to identify my outgoing questions, the counselors’ replies, and the status of each question. 3. I classified each question as fully answered, partially answered, or left open. 4. I calculated indicators including the median response time, the longest delay before a substantive reply, and the number of unresolved or partly addressed questions. 5. I created a clear list of the questions that remained open. 6. I used that list as dossier questions when handing the case over to another counselor.

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

I built an automation workflow with n8n and the OpenAI API to summarize AI news. I learned that prompt templates matter a lot, and chunking documents improved my results. My question for the community is about handling OpenAI API rate limits in n8n workflows. Is anyone else building AI news digest automations with n8n and ChatGPT prompts? 1. I built an AI news summarization workflow with n8n and the OpenAI API. 2. I used prompt templates and found that they had a significant impact on the results. 3. I added document chunking, which improved the summaries. 4. I’m looking for advice from others who have handled OpenAI API rate limits in n8n workflows.

I’m on a GLP-1 medication that heavily suppresses my appetite, and I’m also managing a bilateral vestibular condition that causes balance and gaze issues. I needed a way to hit my protein and calorie targets despite having a low appetite, track body composition accurately, log vestibular symptoms, connect my actual training data, and get coaching guidance that reflects my situation instead of generic fitness-app advice. I built FuelStrong: three connected apps created with Claude over many sessions. They include a daily tracker for meals, water, energy, and training check-ins; a Progress and analytics module; and a standalone Vestibular symptom tracker. They share a Cloudflare Worker and D1 database backend, with KV for cross-device sync. I describe a feature or problem to Claude in plain language. Claude proposes structural options, I push back or choose a direction, and Claude writes the HTML, CSS, and JavaScript. I program my lifts in Fitbod using an Upper/Lower/Upper split, with an arms-and-back priority and the Build Muscle goal. I export those workouts as CSV and drop them into FuelStrong’s import zone, which parses exercises, sets, reps, and volume into my training history. Custom foods receive macro estimates through a Claude API call routed through my own Worker endpoint. Evolt body-scan data feeds dynamic calorie and protein targets based on BMR × activity factor, minus a deficit, with hard floors instead of static numbers. The Vestibular module intentionally uses open text fields for now, so Claude and I can identify which data matters before formalizing the inputs. Everything syncs across devices through Cloudflare KV. The coaching layer uses a three-tier framework—evidence floor, confirmed operating range, and aspirational target—to drive every recommendation. Two calorie floors, a daily target of approximately 1,000–1,100 kcal and a weekly average of approximately 1,300–1,400 kcal, reflect that chronic under-eating—not missed protein—is the real GLP-1 risk. Muscle mass has remained stable since my February 2026 baseline, so the coaching treats that as a genuine win rather than a plateau. Vestibular-training coaching connects dry-needling focus areas—SCM, suboccipitals, and splenius capitis/cervicis—to gaze-stabilization symptoms, since cervical proprioception substitutes for non-functional vestibular canals. The result is one dashboard that brings together training, nutrition, body composition, vestibular symptoms, and coaching logic. My muscle mass has held stable through it all. Step-by-step: 1. I describe a feature or problem to Claude in plain language, review its structural options, choose a direction, and have Claude write the HTML, CSS, and JavaScript. 2. I use FuelStrong’s daily tracker to record meals, water, energy, and training check-ins, while the Progress and analytics module tracks body composition and related trends. 3. I program my Upper/Lower/Upper workouts in Fitbod with an arms-and-back priority and the Build Muscle goal. 4. I export Fitbod workouts as CSV and import them into FuelStrong so it can parse exercises, sets, reps, and volume into my training history. 5. I route Claude API requests for custom-food macro estimates through my own Cloudflare Worker endpoint. 6. I use Evolt body-scan data to calculate dynamic calorie and protein targets from BMR × activity factor, minus a deficit, while maintaining hard floors. 7. I log vestibular symptoms in the standalone Vestibular tracker using open text fields while Claude and I determine which inputs should eventually be formalized. 8. I sync the three apps across devices through the shared Cloudflare Worker, D1 database, and KV backend. 9. I use the evidence floor, confirmed operating range, and aspirational target framework to guide recommendations, including the daily and weekly calorie floors. 10. I connect vestibular-training coaching to dry-needling focus areas and gaze-stabilization symptoms, then use stable muscle mass since the February 2026 baseline as a positive outcome rather than treating it as a plateau.