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

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

Today, I wanted to see how far an AI agent could go if I gave it a real business instead of a predefined automation. I entered binayah.com into Awish.ai. Binayah is a real estate company, and instead of telling Awish.ai exactly what workflow to build, I asked it to analyze the business first and find an automation opportunity. It suggested a customer acquisition funnel, which I reviewed and approved. Around 10 minutes later, the automation was ready. Step-by-step: 1. I entered binayah.com into Awish.ai. 2. Awish.ai agents analyzed the website and how the business operates. 3. Awish.ai identified customer acquisition as an area that could be automated. 4. It suggested a funnel designed to capture and qualify potential leads. 5. I reviewed the suggestion and approved it. 6. Awish.ai created the workflow and connected the required steps. 7. The funnel was ready to use in around 10 minutes. What I find most interesting is that I didn’t start by designing a workflow. The system first understood the business, found an opportunity, suggested what should be automated, and built it only after I approved. That feels much closer to having an automation consultant inside the product than using a traditional workflow builder.

Management pushed for an AI workflow to handle a massive daily headache: staff were manually searching for, copy-pasting, and moving hundreds of files listed in Excel. I was assigned to train the team to use the AI workflow. As soon as training started, though, it became clear that this was the wrong tool for the job. Forcing non-technical staff through a lengthy process of opening browsers, writing prompts, uploading spreadsheets, and dealing with token friction created more work than the manual process. It also introduced token costs, speed bottlenecks, and hallucination risks involving local file paths. The data was already structured. It did not need semantic intelligence; it needed deterministic speed. So AI got fired from running the task. Instead, I used AI as the developer. In less time than it would have taken to train one person, I had Gemini code a standalone Python desktop app and compile it into a simple executable. Now, with zero training required, staff drag and drop their Excel list into the app, choose a destination folder, and click Run. The app executes the transfers for hundreds of files, verifies every arrival on disk, and logs missing files in seconds. The result: $0 in API tokens, two hours recovered each day, zero path errors, and 100% team adoption. A two-second drag-and-drop will always beat a multi-step prompt-engineering exercise. As a side effect, the experience also supported AI adoption. Staff are now seeing more ways AI can help rather than hinder their work. Step-by-step: 1. I evaluated the proposed AI workflow for manually searching, copy-pasting, and moving hundreds of files from Excel lists. 2. I identified that training non-technical staff to open browsers, write prompts, upload spreadsheets, and manage token friction added more work, costs, bottlenecks, and local-file-path hallucination risks. 3. I used Gemini as the developer to create a standalone Python desktop app and compile it into a simple executable. 4. I had staff drag and drop their Excel list into the app, select a destination folder, and click Run. 5. The app transferred hundreds of files, verified each arrival on disk, and logged missing files in seconds. 6. I measured the results: $0 in API tokens, two hours recovered daily, zero path errors, and 100% team adoption.

I used ChatGPT Voice Mode to help me program my mom’s garage door keypad—and the most important step happened before I touched a single button. I photographed the labels on both the garage door opener and the wireless keypad. ChatGPT spotted the real problem: the previous homeowner had replaced the opener but kept the old, incompatible keypad. That explained why we couldn’t get them to pair. Once ChatGPT identified the exact models, it helped me find a replacement keypad that was compatible with the newer opener. I also had it find and load the instruction manuals for both devices, since pairing required a specific sequence of button presses across them. Before we started, I had ChatGPT explain the complete pairing process so I knew what to expect and where timing would matter. Then I set my phone on top of the ladder so both hands were free to work with the keypad and opener. I gave ChatGPT one important instruction: “Walk me through one step at a time. After each step, stop and wait until I tell you what happened.” ChatGPT gave me one instruction, paused, and waited while I reported what the lights were doing. Then it adjusted and gave me the next step. That let me follow the crucial sequence of button presses—and the timing between them—exactly. The real lesson: AI troubleshooting gets much better when you provide the exact model numbers and manuals, let it preview the process, and have it guide you through the work one confirmed step at a time. Step-by-step: 1. I photographed every model number on the garage door opener and wireless keypad. 2. I used ChatGPT to identify the models and determine that the previous homeowner had left an old, incompatible keypad paired with the newer opener. 3. I used ChatGPT to find a compatible replacement keypad instead of guessing based on appearance or brand alone. 4. I had ChatGPT find and load the instruction manuals for the new keypad and garage door opener. 5. I asked ChatGPT to preview the complete pairing sequence, including where timing would matter. 6. I placed my phone on top of the ladder so both hands were free to work with the keypad and opener. 7. I switched to Voice Mode and told ChatGPT to give me one step at a time, pausing after each step until I reported what happened. 8. I reported what the lights were doing after each instruction so ChatGPT could adjust and give me the next step.

I had a bad workplace experience, so I built Doris: a saucy but loving anonymous AI aunt who remembers the tea, protects storytellers, and warns others. I built Spill Tea with Doris, an anonymous AI workplace confessional for conversations people cannot really have on LinkedIn: the bad manager, the inexplicable reorg, the coworker who somehow survives every layoff, and the meeting that should probably be entered into evidence. Doris does something more interesting than simply listen. She remembers the tea—and, carefully, spills it. The problem I wanted to solve was not really “chat with an AI.” Most AI conversations are disposable, but workplace stories are not. They accumulate companies, people, reorganizations, layoffs, recurring behaviors, management decisions, and institutional weirdness. At the same time, people are understandably reluctant to talk openly about their employers because a sufficiently specific story can identify its author. I designed Doris around a different idea: retain the knowledge without retaining the storyteller’s identity. Someone visits [spillteawithdoris.com](https://spillteawithdoris.com) and tells Doris what happened at work. The application is built in Next.js and deployed through Vercel. The conversation goes to an AI model with Doris’s personality and behavioral rules. Redis handles temporary conversational context, while Neon Postgres and Prisma maintain the structured, longer-lived pieces of the story—companies, people, events, and their relationships. Rather than treating every conversation as one giant transcript, the application extracts useful information and connects it to the larger story of a company. That creates the second half of the experience. When another visitor asks Doris, “Have you heard anything about working at Company X?”, she can draw upon what previous visitors have told her. But she does not simply retrieve someone’s confession and repeat it. The system separates what is useful about a story from what could identify the person who told it. Names, exact teams, precise dates, unusual job titles, and other unnecessarily identifying details do not need to travel with the underlying observation. Doris can instead recognize that she has heard several stories involving reorganizations, unusual management turnover, or a particular cultural complaint. Then Doris tells the story herself, in Doris’s voice. She might say that she’s “heard some tea” about a company, explain the general pattern, distinguish something she’s heard once from something that appears repeatedly, and avoid pretending anonymous reports are established facts. Visitors get useful institutional memory without being handed the breadcrumbs needed to identify an individual employee. Public information can provide a second layer of context. If appropriate, Doris can search for publicly available information about a company and compare it with what people have privately described. Those sources remain conceptually separate: what Doris can verify publicly, what Doris has heard privately, and what Doris herself infers should never become the same thing. The result is deliberately a little strange. It is an anti-LinkedIn. LinkedIn is where thousands of individual experiences are polished until every company sounds wonderful and every departure is an exciting new chapter. Doris works in the opposite direction. One anonymous story may just be a story. Ten people independently telling Doris versions of the same story start to describe a workplace. And Doris remembers. She just doesn’t need to remember who told her. Step-by-step: 1. I built a Next.js application and deployed it through Vercel at spillteawithdoris.com. 2. I defined Doris’s personality and behavioral rules for the AI model. 3. I added Redis to manage temporary conversational context. 4. I created a Neon Postgres database and used Prisma to model Company, Person, Story, and Event relationships. 5. I built an extraction layer that converts conversations into structured observations, removes unnecessary identifying information, and associates the knowledge with the appropriate company. 6. I built retrieval so Doris can find relevant prior observations when someone asks about a company. 7. I had the AI synthesize those observations in Doris’s voice instead of quoting or exposing the original submissions. 8. When appropriate, I let Doris search publicly available company information while keeping public sources, private reports, and Doris’s inferences conceptually separate.

QuickBooks stores customer data across multiple windows, including notes, deposits, invoices, payments, aging, and email. To see everything, we previously had to keep several windows open while constantly searching, opening, and closing screens. Communicating with customers beyond QuickBooks’ standard letters was also difficult and time-consuming. I used Claude to write a program that brings this information together in one view. It creates an aging summary of all past-due accounts, with sortable columns for customer name, aging category, and total. I also added columns for the last payment and payment date. Clicking anywhere on a customer’s row opens a full drill-down of that customer’s data on one page. The accounting person can view invoices filtered by date or open invoices, see payments and the invoices they were applied to, review aging detail, run reports without leaving the screen, send emails, record collection notes, and print invoices. The software supports simultaneous access for multiple authorized users. The data stays up to date and can be refreshed at any time. This saves us hours of time compared with working through QBO. My next step is to have Claude automate reminder notices at 30 and 60 days, based on user-selected settings, as well as 90-day collection letters. These notices will be customizable while still allowing automation. Step-by-step: 1. I identified the customer information that was spread across QuickBooks windows, including notes, deposits, invoices, payments, aging, and email. 2. I used Claude to write a program that creates an aging summary of all past-due accounts. 3. I added sortable columns for customer name, aging category, total, last payment, and payment date. 4. I enabled users to click a customer row and open a full drill-down of that customer’s data on one page. 5. I included access to date-selectable invoices, open invoices, payments and their applied invoices, aging detail, reports, emails, collection notes, and invoice printing. 6. I set up the software so multiple authorized users can access the data simultaneously and refresh it whenever needed. 7. I plan to add customizable, automated reminder notices at 30 and 60 days and collection letters at 90 days.

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

I’ve found it useful to use Claude while reading nonfiction books, such as *Factfulness* by Rosling. I ask Claude for a synopsis of the book and save the result as a PDF on my computer for future reference. I also ask Claude to quiz me about the book, either with multiple-choice questions or in short-answer format, to test whether I’ve fully understood what I’ve read. In an ongoing conversation, Claude can also relate the current book to other books I’ve recently read and provide additional synopses. Step-by-step: 1. I tell Claude which nonfiction book I’m reading, such as *Factfulness* by Rosling. 2. I ask Claude to create a synopsis of the book. 3. I save the synopsis as a PDF on my computer for future reference. 4. I ask Claude to quiz me using either multiple-choice or short-answer questions. 5. I continue the conversation so Claude can relate the book to other books I’ve recently read and provide further synopses.

My company takes cybersecurity seriously, and part of our new-hire onboarding process is a tour of the IT department to meet the team. Our walls have several screens displaying metrics and information from our security tools, firewalls, and other systems. It looks like a scene from a movie. By far, the most popular display is our custom-made Cyber Threat Map, which shows real-time attempts to infiltrate our network, malicious emails, and other security threats we're blocking. The map drives home the reality of what we're facing 24/7 while protecting our employees, vendors, and customers. I built it using Claude Code. It polls a range of devices and systems through APIs, aggregates the data on one screen, and displays attack vectors, location information, and other details from the last 30 days. Step-by-step: 1. I identified the security tools, firewalls, devices, and systems that provide relevant threat data. 2. I used Claude Code to build a custom Cyber Threat Map. 3. I connected the map to the devices and systems through their APIs. 4. I aggregated the data on a single screen, including attack vectors, location information, and other details from the last 30 days. 5. I displayed the map during IT department tours so new hires could see the real-time threats our company is blocking.

AI coding tools can build quickly, but they can also build the wrong thing quickly. Starting implementation from a vague feature request leaves important decisions about scope, architecture, edge cases, success criteria, and expected behavior to be made implicitly during coding. I created a spec-generator agent that sits between an idea and implementation. I give it a feature request, product vision, or rough description of what I want to build. It investigates the existing project, identifies missing decisions and constraints, researches external dependencies when necessary, and turns the request into a detailed specification that another AI agent can implement without having to guess what I meant. The finished specification becomes the source of truth for the rest of the development workflow. Step-by-step: 1. I give the spec-generator the feature or product idea I want to build, along with any existing requirements, vision documents, or constraints. 2. I have it inspect the existing project before proposing a solution. It needs to understand the current architecture, conventions, capabilities, and relevant prior decisions rather than designing the feature in isolation. 3. I have it identify ambiguities and missing decisions, including questions about users, behavior, scope, dependencies, edge cases, data requirements, integrations, and what is explicitly out of scope. 4. I have it research external technologies, APIs, libraries, or platform capabilities when the design depends on facts that cannot be determined from the repository alone. 5. I have it translate the idea into a layered specification: first the product purpose and desired outcomes, then the technical architecture, and finally the detailed implementation requirements. 6. I have it define measurable success criteria and acceptance tests so that “done” means something concrete rather than simply “the code was written.” 7. I have it persist the finished specification in the project so developers or coding agents can treat it as the source of truth during implementation. 8. I pass the specification through a separate review or validation step before coding begins, resolving gaps or contradictions in the spec rather than discovering them halfway through implementation. Instead of asking an AI coding agent to interpret a rough idea while it writes code, I separate figuring out what should be built from building it.

I was tired of opening Spotlight every time I wanted to switch apps. The search results would move around, I would occasionally open the wrong app, and those few wasted seconds kept adding up throughout the day. Instead of memorizing a collection of unrelated hotkeys, I used ChatGPT Work to design and build a personalized shortcut system in Apple Shortcuts. The shortcuts can open individual apps, jump directly into specific Safari or Chrome profiles, or launch an entire work mode with one keystroke. For example, a recording shortcut could open your microphone, camera, recording software, and notes. An analytics shortcut could open all the dashboards you check each week. Step-by-step: 1. I opened the ChatGPT desktop app, started a new chat, and switched to Work mode. 2. I asked ChatGPT to plan shortcuts around my real workflow: Based on what you know about me and my workflow, suggest 10 time-saving hotkeys we can set up in Apple Shortcuts. I’m interested in opening specific apps and profiles based on what I need them for or what mode of work I’m going into. 3. I told it which apps, browser profiles, URLs, and work modes I use most. 4. I narrowed the list before making any changes by keeping the highest-frequency shortcuts and avoiding macOS or app conflicts. 5. In ChatGPT, I went to Settings → Computer Use and turned on Any App. 6. I gave ChatGPT the approved list and clearly limited its scope: Set these up in Apple Shortcuts. Do not change anything outside this list. Test each shortcut. 7. I opened All Shortcuts in Apple Shortcuts and ran each one manually. I used Quick Actions to add or change its keyboard shortcut. I like Control + Option because it is less likely to conflict with existing Mac commands. 8. I tested every shortcut while working in another app, checking that it opened the correct app, account, browser profile, or collection of tools before building more. 9. Once everything worked, I asked ChatGPT to create my reference: Write me a one-page cheat sheet of all the shortcuts you set up, where they live, and what’s left to do. The result is a personal shortcut system built around how I actually work, plus a one-page cheat sheet so I don’t have to memorize everything immediately. For the complete walkthrough, exact prompts, screenshots, and setup instructions, follow my full Rundown University guide: Use ChatGPT to Build a Custom Mac Shortcut System. Tools used: ChatGPT Work, Apple Shortcuts Industry: Cross-industry Tags: #chatgptwork #appleshortcuts #macautomation #productivity #workflowautomation

For years, my family has run a shared birthday fund: five of us contribute a fixed amount for each birthday, while the person whose immediate family is celebrating that month is exempt from paying. Tracking everything in a payment app and a chat thread meant nobody knew the balance, who was behind, or what the next gift would cost. I rebuilt the fund as a small web app with Claude. The app itself isn't the only reason I'm writing this up. The same build is also the demo I use to teach clients and students how AI-assisted product development actually works, including the parts that go wrong. Step-by-step: 1. I described the real rules instead of presenting Claude with a generic app idea: the contributors, the fixed amount per person, the family-exemption rule, and birthdays with birth years so ages could be calculated automatically. Claude built the app as a single, self-contained HTML file with no build step or server, so it opens in any browser. 2. I worked in phases and asked Claude to explain its reasoning at each stage. Instead of using one giant prompt, I added one layer per session: the calculation engine, the setup screen, then reports and CSV export. The explanations made the sessions reusable as teaching material. 3. I required the app to be configured through its own interface rather than by editing code. This was the turning point. Claude removed the hardcoded demo family and added a full setup screen for the group name, contributors, deposits, birthdays, amounts, and alerts. I can now build a family from scratch live in front of a class in about [X] minutes without showing a line of code. 4. I let a data-loss incident shape the next phase. I entered the real family data, then the browser tab closed and the download link I had been using to open the file broke. The data was stored in browser storage tied to that exact URL, and I had no backup. Nothing was recoverable at the time. 5. I turned that failure into features. Claude added CSV export for both reports, CSV import that automatically detects which file it is reading, and a backup reminder that appears in the app's alert banner when the data has never been backed up or has not been backed up for seven days. We also discovered that birth year was missing from the export, which meant a re-import would have silently lost everyone's age. 6. I had Claude test its own work. Before each handoff, it ran a jsdom test suite in a sandbox. By the end, the suite had 46 tests covering the exemption math, empty states, CSV round-trips, and backup logic. Several real bugs surfaced there instead of in front of a class. 7. I made a second version for a different audience. One prompt produced a fully English, left-to-right translation with flipped directional CSS, Latin typography, US date formatting, dollars instead of shekels, and Venmo and Zelle instead of local payment apps. It was a genuinely different build, not a find-and-replace translation. The project took 14 sessions over one week and six hours total. It had no hosting cost, dependencies, or accounts. The data still lives in the browser's local storage on each device. Opening the file on my phone and laptop creates two unrelated pools, so CSV import is the manual bridge between them. There is no authentication or sync; this is a personal record-keeper, not shared infrastructure. The data-loss incident was not a Claude failure. I failed to build a backup path before entering real data. If I did it again, I would add export before adding a single feature. The highest-leverage prompt in the whole project was not a feature request. It was: "let me configure this through the interface instead of the code." That shift turned a static demo into something my family actually uses and my students can watch being built from an empty screen. The broader point is that the failure was the most useful part of the project. A polished demo teaches people that AI makes building easy. Losing the data and rebuilding the safety net around it teaches them what building actually involves—and that is the lesson that survives the workshop.

I love playing poker, both online and live. One month, I performed poorly. Although it felt like the cards were running badly, I wondered whether I had developed a problem in my game and was blaming my losses on bad luck. I asked around, including asking AI, whether a tool existed that could measure luck from poker hand histories. The unwelcome answer was that it did not. I'm not a coder, but after doing some research into vibe coding, I started building a luck-detection app in a Claude chat. Claude built the UI directly in the chat window and advised me on the formulas I was using to calculate luck for the cards dealt, my performance on the flop, and my performance when I went all in. All three metrics have strong averages, and luck is what varies them. I used a bell curve to model hand outcomes and a Monte Carlo simulator, which Claude suggested and executed, to evaluate all possible outcomes. The result astonished me because it was so useful. I immediately fixed two major leaks in my game and felt better knowing that bad luck really was the main problem affecting my results. I liked the tool so much that I decided to turn it into a full web app with Claude Code, and now an iPhone app that I may let other people use for free. I also had a lot of fun building it—except for learning how to use Xcode. That was a pain, even with step-by-step guidance from Claude. Step-by-step: 1. I reviewed a month of poor poker results and questioned whether bad luck or problems in my game were causing the losses. 2. I researched whether a tool existed that could measure luck from poker hand histories and learned that I would need to build one myself. 3. I used vibe coding to start building a luck-detection app in a Claude chat. 4. I had Claude create the UI and advise on formulas for evaluating cards dealt, flop performance, and all-in performance. 5. I used a bell curve to model hand outcomes and a Monte Carlo simulator to evaluate possible outcomes. 6. I used the results to identify and fix two major leaks in my game and confirm that bad luck was also affecting my results. 7. I expanded the project into a full web app with Claude Code and then began building an iPhone app, working through the added challenge of learning Xcode.

I spent twenty years producing documentary and nonfiction films, all of it the expensive way: crews, schedules, financing, and commissioners saying no. I'm proud of much of that work, and I still think about the films that never got made because the money wasn't there. Generative video pulled me in, but not for the reason people assume. It wasn't the speed or the cost. It was the fact that I could finally finish something without asking anyone for permission. No green light from a major platform. Nobody deciding that a story was too small to deserve a crew. A year later, I could produce this way. It turned out to be a different job rather than the same job with new tools. Then I ran into a problem I hadn't considered: how do you show the work? A finished shot doesn't prove much anymore. A client can look at a beautiful frame and have no way to tell whether it took three weeks or three minutes. If I'm honest, neither would I in their position. The thing every portfolio is built to display had stopped being evidence. I'm not a developer. I produce films. The site is bilingual, has seven sections, includes a case study for each film, plays video on hover, and has a comparison slider that works with a thumb as well as a mouse. I built all of it. I'd wanted this exact site for about fifteen years and had never managed to explain it properly to anyone I paid to make it. This time, I stopped explaining and built it myself. The middle of the page has a slider that you drag between the storyboard panel and the final shot. A basic before-and-after would prove nothing; you can fake that by generating twice. The storyboard is the proof because the framing, eyeline, and decision about what stays outside the frame all existed on paper before any model was asked to generate anything. You drag the handle and watch the intention survive. The rest of the site came from the same place. Video only plays on hover and is silent until you click for sound. Most video portfolios are unreadable because fifteen things start moving at once. The sections are organized by register rather than by client: epic, brand, animation, and lifestyle. A wall of logos answers who has hired you, which nobody is actually wondering. What they want to know is whether you can change tone. Nothing is cropped to fit the grid. A 5:33 film sits in 16:9 next to a 2:42 film in scope, and the layout is lopsided because of it. I nearly made them uniform because it looked tidier, then realized I was about to reformat my own films so a webpage would look neat. Anyone who cuts for a living spots that immediately. Concepts are labeled as concepts. Experiments have their own section instead of being scattered among the client work and hoping nobody asks which is which. Step-by-step: 1. I started from what my client couldn't verify: the craft behind a shot. 2. I found the artifact that proves it. It's usually the ugly thing nobody publishes: the storyboard, the reference sheet, or the version before the good version. 3. I put that artifact next to the finished piece inside one interaction, so nobody has to search for the proof. 4. I made playback deliberate. Video plays on hover, and sound requires a click. 5. I sorted the work by the question being asked rather than by the credentials I wanted to lead with. 6. I didn't reformat the work to fit the layout. I let the grid be uneven. 7. I labeled everything honestly: client, concept, or experiment. One word each can pay for the credibility of the whole page. 8. I wrote a brief for each section as a document first. Arguing with a paragraph is free; arguing with a built page is not. 9. I built the site with an AI coding tool. This was the least interesting step, even though it's the one everyone writes about. If your work can be mistaken for a lucky prompt, stop trying to prove it with the finished piece. The site is at www.termopilas.tv if you want to drag the handle yourself.

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 use Claude Cowork and Meta MCP to map my existing ad creative data and find winning combinations. Once the data is mapped, I can usually identify one concept that wins more often than the others, has absorbed more spend, and still maintains an efficient CPA. That is the winning concept, and it is where I should focus 60% to 80% of my production time. Step-by-step: 1. I connect Claude Cowork to Meta MCP and Google Drive. 2. I place the brief for every ad I published in the past 365 days into one Google Drive folder. Each brief includes the script, format, offer, and persona it was written for. 3. I prompt Claude to work through the Drive folder and build a spreadsheet tagging every ad by persona, angle, offer, and format. 4. I prompt Claude to pull each ad’s spend and CPA through Meta MCP and add those metrics to the spreadsheet. 5. I ask Claude to turn the spreadsheet into a flowchart in which persona branches into angle, angle branches into offer, and offer branches into format. Each branch includes its spend and CPA. After the data is mapped, I use the flowchart to identify the winning concept and prioritize it in production.

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

I built a predictive maintenance workflow in Awish for one of my manufacturing clients. The client had machine telemetry, production data, and maintenance history spread across different systems. The problem wasn’t collecting the data—it was spotting failure risk early enough to act. I built a custom Awish workflow that continuously checks machine telemetry and production signals in Snowflake alongside asset, meter, and maintenance history from MaintainX. When it detects abnormal performance or increasing failure risk, it identifies the affected equipment, estimates the likely operational impact, and prepares a recommended maintenance action. Nothing is scheduled automatically at that point. The recommendation first goes to the maintenance manager in Microsoft Teams for approval. Once approved, Awish creates and assigns the work order in MaintainX, then keeps tracking and updating its status until the maintenance is completed. The useful part is that the system does not wait for a machine to fail before maintenance starts, but it also does not let AI make the maintenance decision on its own. The analysis is automated, while the actual intervention still requires human approval. Step-by-step: 1. I described the maintenance process I wanted in the Awish chat. 2. Awish planned the workflow and selected Snowflake, MaintainX, and Microsoft Teams for the required steps. 3. I connected the client’s accounts and approved the automation plan. 4. Awish continuously analyzed production and telemetry data in Snowflake together with MaintainX asset, meter, and maintenance history. 5. When it detected abnormal behavior or increasing failure risk, it identified the affected equipment and estimated the likely operational impact. 6. It prepared a recommended maintenance action and sent it to the maintenance manager in Microsoft Teams. 7. Once the manager approved the recommendation, Awish created and assigned the work order in MaintainX. 8. The workflow continued tracking the work order and updating its status until the maintenance was completed. Trigger → Analyze → Approval → Action Machine signals → Failure-risk analysis → Teams approval → MaintainX work order

I run nine GitHub repos as one programme of work. Every project keeps its backlog as plain markdown inside its own repo, one Claude Code or ChatGPT Codex session works each project in parallel, and a single board in VS Code shows all of them moving at once. There is no project tool, no API and no sync job in the middle: the markdown file is the shared state that both I and the agents read and write. Step-by-step: 1. Put the backlog in the repo, as markdown. Every project gets `docstech/users/<me>/todo.md` and `done.md`. A story is a `###` heading. Structured fields ride in an empty markdown link at the end of it: `### Add rate limiting [](?status=doing&epic=api&time_estimated=180)`. GitHub renders an empty link as nothing, so the file still reads as prose in a pull request while carrying real metadata. 2. Write the story before the session starts. Each one has goal, background, scope, out of scope, the files it should touch, a checkbox task list, and acceptance criteria. That story is the prompt, and most of my thinking happens there rather than in chat. It decides whether the session comes back with anything shippable. 3. Open the parent folder in one window, and turn the files into a board. I open the parent folder holding all the projects and open any `todo.md` with NoteThink in Folder mode, which merges every markdown file under it into one view. Group the lanes by project and it is the programme view, one lane per repo. Group them by status and it is the delivery view, one Kanban across the whole portfolio. Each card carries a pill naming the project it came from, and clicking it opens that file at that story. 4. Start one Claude Code session per project. Every session opens with the same instruction: read `todo.md` top to bottom and take the top story. The sessions never talk to each other, because the file on disk is the only shared state. A session that dies costs nothing. 5. Let the board report progress instead of reading the sessions. Agents edit the markdown as they work: tick a task, flip `status=todo` to `status=doing`, move a finished story to `done.md`. The board watches the files, so cards animate into their new column as each change lands, and I can see which sessions are advancing without reading any of them. 6. Steer by dragging. Dragging a card between lanes writes the attribute back into the source markdown, so dropping one in "doing" makes the file say `status=doing` and the next agent turn reads it. Ticking a checkbox does the same. The board is the steering wheel and the file is the wire. 7. Close every story the same way. One slash command runs lint plus the full test suite, checks the story's tasks are ticked, and drafts the commit message; another ships to staging then production. The finished story moves to the end of `done.md`. Over time `done.md` becomes the programme record: what shipped, when, and what it cost. Try the board without installing anything. Here is a live example board, four projects merged into one view, and it is exactly what the screenshot shows: https://www.notegit.com/en/app/notegit.com/notegit/example_repo/blob/ai-board/board.md Results, honestly. Nine repos, about 260 open stories and about 1,400 completed ones, all in markdown inside the repos rather than a tracker. The backlog goes back to March 2024; the parallel sessions on top of it are the last four months. I run eight to twelve sessions at the same time, and the whole thing fits inside one Claude Max 20x subscription over a month of full-time work. Not all of it is code. The same parallel-session habit drives a nuclear reactor design study (https://github.com/cleverlight/mistergy) and several video and design projects. The board part fits best where the work already lives as files in a repo. Limits, honestly. The ceiling is my review capacity, not compute. Eight to twelve is where I sit; past that I stop reading output properly and start rubber-stamping, which is worse than running fewer. It only works when stories are genuinely independent, because two sessions in one file is a merge conflict you wrote yourself. Agents occasionally finish work and forget to move the story, so `done.md` needs a sanity check. And it assumes you will write the story properly first, which is real work that AI does not do for you. The screenshot is the public example board rather than my own, because my real one carries client project names. Disclosure: I build NoteThink, the free, open-source VS Code extension in step 3, and NoteGit, which hosts the example board. NoteThink is on the VS Code Marketplace, Apache-2.0, and genuinely early (v0.3.38, preview quality, a handful of installs). The workflow is tool-agnostic and the markdown is just markdown: any viewer will show it, and you can run the whole thing with no extension. NoteThink is what makes the cross-project board and the drag-writes-back-to-file part work.