Workflow Hub

We needed legal help with a small-claims case. A company owed us $3,500, and the cost of hiring a lawyer would have far exceeded that amount. I used Grok to explain what to do and how to file the paperwork. Last week, I served three writs of garnishment on banks that might hold the company’s money. Whichever bank has its account will now have to freeze the account and turn that amount over to us. Before AI, I would have had no idea how to do this on my own. Grok scans my completed documents for errors and directed me to the correct county sheriff’s office to have the papers served. It can explain things more simply when I don’t understand them. Need legal help in your state? AI can guide you step by step. Step-by-step: 1. I explained the small-claims situation to Grok, including that the company owed us $3,500 and that hiring a lawyer would cost more than the amount owed. 2. I asked Grok what to do and how to file the paperwork. 3. I used Grok to scan my completed documents for errors. 4. I followed Grok’s direction to the correct county sheriff’s office for serving the papers. 5. I served three writs of garnishment on banks that might hold the company’s money. 6. The bank holding the company’s account will have to freeze the account and turn the amount owed over to us.

I use this workflow when I have a problem but do not yet know which software, service, or method could solve it. Instead of immediately asking for “the best app,” I describe the situation in ordinary language: what I am trying to do, what currently annoys me, what I have already tried, and what would make a solution useful. Then AI helps me map the tool landscape. The important shift is that the criteria emerge from the conversation. The workflow does not search for an abstract “best tool.” It builds a model of what a good tool means for this particular problem and person, then evaluates the available options against that model. This also makes the result reusable. When my requirements change later, I can update the comparison rather than redo the entire research process. Step-by-step: 1. I describe the problem and desired outcome. 2. I identify the requirements that actually matter in this situation. 3. I research the relevant tools and approaches. 4. I compare them side by side using practical criteria such as functionality, price, pricing model, platform, setup effort, learning curve, and ease of use. 5. I ask questions where the requirements are still unclear. 6. I react to the comparison—for example, by noting that something is too expensive, that a subscription is a dealbreaker, that an option looks cumbersome, that I need more statistics, or that I do not need project management. 7. I update the comparison using that feedback instead of starting the search from scratch. 8. I narrow the field and, where useful, test the remaining options on one small real-world task. 9. I record why the chosen tool fits and why seemingly similar alternatives did not.

AI can make a child’s drawing look more polished, but it can also erase exactly what made it interesting. A yellow tree, a rabbit larger than a person, a horse with impossible legs, or a tiny floating object may look like mistakes to a model—but they may be the whole point. I use the child’s drawing as art direction: preserve its visual logic, then build outward. The child supplies the invention; AI helps develop the surroundings. Step-by-step: 1. I read the drawing before transforming it by making a neutral description of what is visible: placement, relative sizes, colours, expressions, unusual shapes, and small details. For example: “A large yellow tree stands on the left. Two tiny figures sit near its trunk. A blue shape fills the lower right.” 2. I avoid deciding what an unclear shape represents. “An oval object with three legs” is more faithful than “a rocket” unless the child confirms it. If possible, I ask the child what is happening, since a strange proportion or colour may have a specific story behind it. 3. I separate essentials from flexible details in two short lists. Essentials might include the yellow tree, oversized rabbit, horse’s pose, characters’ arrangement, and red object in the corner. Flexible details might include lighting, textures, materials, environmental detail, and depth. 4. I make clear that the original is the structural source, not just a mood reference. This gives the model room to work while defining the boundaries. 5. I choose a target style, such as a storybook illustration, watercolour, digital painting, comic panel, or 3D scene. 6. I explicitly ask the model to preserve unusual proportions, unexpected colours, expressions, and relationships between characters. I identify details that must remain, even if they appear anatomically impossible or visually awkward. I avoid vague instructions such as “make it better,” because they leave the model to decide what counts as improvement. 7. I use a starting prompt such as: “Use this drawing as the structural blueprint for a storybook illustration. Preserve the composition, relative sizes, poses, expressions and original colour choices. Keep the yellow tree and the rabbit larger than the person. Do not normalize unusual anatomy or remove unexplained objects. Add texture, lighting and environmental depth around the existing scene.” 8. I treat comparison as part of the workflow because specific instructions do not guarantee a faithful result. I expand the world around the invention: a blank background can become a forest, a blue patch can become a pond if that interpretation fits, and two skiing figures can gain a mountain landscape. 9. I keep the original spatial relationships: who stands beside whom, what dominates the scene, which way characters face, and where empty space matters. I give colour the same care, so a yellow tree does not quietly become green because the model expects green trees. 10. I place the source and result side by side and check whether a character disappeared, the rabbit shrank, the palette changed, or the model invented a focal point, “fixed” an unusual shape, or altered the story. I also watch for generic cuteness—big eyes, pastel colours, and perfect symmetry—which can make very different drawings converge into the same image. I ask whether the result still feels like an expansion of this exact drawing. 11. If most of the result works, I request a targeted edit, such as: “Keep this version, but restore the original hair shape.” “Make the rabbit larger again.” “Return the tree to yellow.” 12. I check the whole image after each local edit because changes can affect other areas. I keep useful versions instead of repeatedly starting over. 13. I treat handwritten text separately. I do not guess unclear wording, correct spelling, or invent labels. If the tool cannot reproduce the text faithfully, I retain the original lettering through a separate editing step. 14. I save the original photo or scan alongside the result, instructions, and useful intermediate versions. I also keep a brief note about protected details to make future transformations easier. 15. Once I have a faithful version, I explore alternatives such as a space setting, surreal painting, or cinematic scene, keeping them as branches from the original. Across several drawings, I preserve recurring colours, shapes, and characters without forcing every image into one rigid style. The child has already decided who exists, what matters, how large things are, and what belongs together. Those decisions are creative direction. A drawing does not need to become less itself to become more finished. The impossible colour may be the atmosphere, and the awkward shape may be the character. The question I return to is: “How can I help this drawing become more fully what it already is?”

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

I built an archery app that uses AI to detect arrows and bullseyes on an archery target. It groups the arrows, measures how tight the groupings are, and calculates each arrow’s distance from the bullseye. It also shows the arrows’ locations and their relationship to the bullseye—for example, whether a shot is too far left, right, high, or low, or is dead on. The app can use targets from competition standings to score a shoot according to different standards. After shooting a set of arrows, the archer takes a photo, and the AI detects the target, identifies one or more bullseyes, predicts which arrows are intended for each target, and completes the measurements and scoring almost instantly. The results can then be sent to a coach, who can provide feedback, tips, and techniques to help improve the archer’s shooting. I trained my own model using 3,000 photographs that I took and hand-labeled with the bullseyes and arrows identified. I ran a series of training sessions over several weeks and refined the model to improve its accuracy. It currently achieves about 95% accuracy for arrows and about 90% accuracy for bullseyes. Step-by-step: 1. I took 3,000 photographs of archery targets. 2. I hand-labeled the arrows and bullseyes in those photographs. 3. I trained my own AI model in a series of sessions over several weeks. 4. I refined the model to improve its detection accuracy. 5. An archer shoots a set of arrows and takes a photo of the target. 6. The app detects the target, one or more bullseyes, and the arrows, then predicts which arrows are intended for each target. 7. The app groups the arrows, measures grouping tightness and distance from the bullseye, identifies each arrow’s position relative to the bullseye, and scores the shoot according to the selected standard. 8. The results are sent to a coach for feedback and advice on improving the archer’s shooting.

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

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

I used Claude Code to find scientific seminars hosted by colleges and universities across the US and collate them into a single, searchable list. Researchers can use it to find talks that match their interests near them. The site, seminarsearch.org, runs mostly on free-tier SaaS services, costs me $5 per month to operate, and currently supports a few thousand users. The same pattern could be adapted to collate all 5K runs in the US, tennis matches, craft shows, quilting bees, or any other type of event that interests you. I started by explaining to Claude what I wanted to build. We then spent a few hours exploring where and how to identify seminar calendars at universities across the US, which was arguably the hardest part. We developed a pluggable framework with scraping plugins for the common CMSs used by universities, along with iCal parsers, HTML parsers, and JavaScript interpreters to handle the complexity of normalizing content from hundreds of departmental websites. Once we had the seminar-scraping infrastructure, we built a database schema in Supabase and simple APIs to create, read, update, and delete records. The APIs are written in Python and hosted on Railway for $5 per month. We used Vercel to deploy a simple React-based frontend for presenting the data. Now I can ask Claude to implement a feature or add a new university to the list of sources. It figures out where the data is hosted, creates entries for the university and its departments, finds their seminar feeds, collects the seminar data, puts it into the database, and runs GitHub Actions to send alerts to registered users. The scraping job runs once a week to collect new data, and it also runs through GitHub Actions. I wrote zero code during this process and have never even looked at the code. I only had to paste a few error messages from Railway into Claude so it could debug them, and there were only a few errors. Since building seminarsearch.org, I have cloned the infrastructure and codebase and modified it to build a site that collects road bike rides and group mountain bike rides across the country. The system is highly extensible to new areas of interest and is useful when traveling or living in a large metropolitan area where it is difficult to keep track of all the opportunities available for your interests. Step-by-step: 1. I explained to Claude Code that I wanted to build a searchable directory of scientific seminars hosted by colleges and universities across the US. 2. We explored where and how to identify university seminar calendars, focusing on the challenge of finding sources across many institutions. 3. We built a pluggable scraping framework with plugins for common university CMSs, plus iCal parsers, HTML parsers, and JavaScript interpreters. 4. We created a Supabase database schema and simple Python APIs for creating, reading, updating, and deleting seminar records. 5. We hosted the APIs on Railway for $5 per month and deployed a React-based frontend on Vercel. 6. We configured Claude to add universities and implement features by finding source locations, creating university and department records, locating seminar feeds, collecting seminar data, and adding it to the database. 7. We used GitHub Actions to run the weekly scraping job and send alerts to registered users. 8. When Railway returned errors, I pasted a few error messages into Claude so it could debug them. 9. I cloned and modified the infrastructure and codebase to create additional sites for road bike rides and group mountain bike rides across the country.

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

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

Some of the most vivid ideas do not begin as formal briefs. They begin as a joke, metaphor, image, or strange sentence that suddenly has energy. This workflow captures how a small conversational spark can grow into a much larger creative concept. I might say something funny, absurd, visual, or emotionally loaded. AI extends the image, pushes it further, and adds variations, structure, or playful consequences. That makes me more enthusiastic, associative, and specific. Before long, a throwaway remark can become a complete scene, story world, comic setup, installation concept, or concept art direction. The key is not to force the idea into coherence too early. At first, the goal is energy rather than precision. The playful improvisation reveals whether the concept has legs; structure comes in once the idea has shown that it wants to live. This is especially useful for concepts that combine humor, symbolism, emotional charge, and strong imagery. For example, “the elephant in the room” can become a full comic or visual scenario, while “the lion among the cats” can evolve into a richer concept with social dynamics, character logic, and visual storytelling potential. AI acts less like a generator of finished ideas and more like an improvisational creative partner—one that keeps the momentum going long enough for an offhand remark to reveal its full conceptual potential. The result can be a complete creative direction for writing, comics, concept art, sets, or installations. Enthusiasm is treated as a signal: when a joke or image triggers strong excitement, it may indicate that a larger concept is hiding inside it. Step-by-step: 1. I start with a small conversational spark: a joke, metaphor, visual phrase, or strange idea. 2. I ask AI to continue the thread instead of flattening it too early. 3. I react strongly to whatever feels alive, funny, moving, or visually rich. 4. I expand the idea through playful back-and-forth. 5. Characters, settings, tone, visual motifs, and scene logic begin to emerge. 6. I use AI to organize the growing material without losing its spontaneity. 7. I shape the concept into a usable form, such as a comic strip, story premise, installation idea, character setup, concept art brief, scene sequence, or mini-series. 8. If needed, I turn the raw idea into structured outputs such as panel descriptions, mood, dialogue, staging, or visual prompts.

A finished video can be wrong in ways you cannot see—not because of the edit, but because of the delivery file itself. That is what gets work sent back, and it is rarely the craft. I built a delivery check for this. I give it a finished file, tell it where the file is going and what kind of piece it is, and it measures the things that cause rejections: sample rate, mono audio, integrated loudness against the destination target, true peak, dynamic range against a band rather than a single number, A/V drift, whether the shots cut together, and whether the file can stream before it has finished downloading. Most of those checks are for sound, because most of what gets sent back is sound. Picture problems are visible on a screen. A file that is 2 dB too quiet or peaks at -0.7 dBFS can look perfect and still come back. For everything it can fix, the checker gives me the exact `ffmpeg` command, with the numbers already calculated for that file. It does not merely describe the fix, and it does not hand me a corrected file. That was the decision that mattered. A fixer is a black box. You never learn that you had a problem, so you make it again the following week. Then, when your editing tool adds an “optimize on export” button, you have nothing. An inspector that explains the problem in one sentence and gives you the command teaches you the standard once and remains useful when the tools change. Three things determined whether I would actually use it, and none of them are checks. “Two severities, never one.” Something either bounces, or it needs your eyes. A tool that only says “bad” gets ignored on the third run, because half of what it flags is a decision you made on purpose. Sample rate, mono, and true peak bounce without argument, and they get a command. Loudness and dynamic range need to be reviewed first. My dynamic-range check says in plain words that the result is often deliberate and should be fixed at the source rather than in the master. “A check that refuses to give a verdict.” On vertical video, the platform interface covers the bottom 26 percent and the top 12 percent. I flag high-contrast elements in those zones but deliberately do not fail them, because the detector cannot tell a caption from a bright patch of sky. The report explains that limitation. A check admitting what it cannot know is what makes the checks that do commit worth trusting. “The thresholds are mine; the code only applies them.” They live in a table: destination crossed with content. Social wants -14 LUFS, a festival master wants -18 with a wider tolerance because festivals provide a band rather than a number, and broadcast wants -23. A scripted short is allowed to be denser than a screencast. That table is the whole product. For example, to catch shots that do not cut together, I measure the luminance range across the piece. The first version used average brightness per frame and kept flagging legitimate night photography. A fade to black has nothing bright in it; a night scene does—a streetlight, a moon, or a face. Changing the discriminant to the brightest pixel in the frame instead of the average eliminated the false positives. That took ten minutes of thinking, and no amount of better code would have found it. Step-by-step: 1. I wrote down what had actually gotten my work sent back over twenty years before writing any code. I captured the scars rather than making a spec sheet; that list became the product. 2. I gave every check a severity: it bounces, or look before you send. Anything I could not confidently put in one bucket became informational, with no verdict at all. 3. I made every check return four things: the measured value, pass or fail, why it matters in one plain sentence, and, where possible, the command that fixes it. 4. I put the thresholds in a profile table instead of hardcoding one standard, because -14 LUFS is right for social and wrong for a festival. 5. I added a parameter for whether the file is my own master or a copy pulled from a platform. On a downloaded copy, half the container checks measure someone else’s transcode rather than my work, so they are skipped and the report explains why. 6. When two fixes would collide, I output only one command. If loudness already needs a gain change, the limiter goes inside that command instead of being offered separately; otherwise, I would run two instructions that fight each other. 7. I tuned the checker against real files until the false positives stopped. Ignoring the top and bottom five percent of frames eliminated the ones caused by a single stray frame. 8. I made the output a report. I read it, decide, and run the command myself. The functions are an afternoon of work, and anyone can copy them. What is not written down is the list of what to check, at what threshold, and why.

I made an orchestration skill to help me build faster while using my expensive Astra and Fable tokens carefully. The skill plugs into Astra or Fable and delegates tasks that can happen in parallel to multiple subagents running cheaper models suited to the work. This is especially useful for researching or finding data on the web or on my computer, analyzing code, collecting context, and indexing. The most expensive, newest models focus on maintaining delegation control, doing the difficult reasoning and strategic planning, and judging whether everything is coming together correctly. The cheaper agents handle the lighter-weight work, especially implementing code from the plans. The core idea is simple: the expensive model plans, briefs, and judges; cheaper agents do the reading and building. When I ask Claude or GPT to build the skill, I specify five things: Step-by-step: 1. I define a triage ladder: work can happen inline, with one agent, through a parallel fan-out, or in a multi-stage workflow. I choose the approach based on the task shape and include examples from my domain. 2. I define parallel versus sequential execution based on data dependencies. Independent pieces run in parallel, while anything that needs another piece’s output runs afterward. I never split one change into separate planner, coder, and tester roles. 3. I define model routing with a mandatory model pin: judgment work goes to the mid-tier model, mechanical bulk work goes to the cheap model, and every agent call names its model so nothing silently uses premium billing. 4. I define a brief template and a return-envelope cap. Every delegation includes the goal, inputs, output file path, definition of done, and constraints. Every agent returns a 250-word summary instead of raw files. 5. I define a cost gate with specific numbers. Below N agents, the workflow proceeds automatically; above N agents, it states the estimate and waits for approval.

I built a workflow to reconstruct auditable, per-client billing for Claude usage after my Anthropic bill tripled in one month and I discovered there was no reliable way to see why. I run a solo consulting practice on a Max plan and pass AI costs through to clients. In September, my extra usage reached $1,805.76 in nineteen days. The usage page attributed 100 percent of one week to "Cowork" without session detail. Auto-reload was enabled by default with no spending limit, and the only usage I could independently verify—my local Claude Code logs—accounted for about $245. The support bot twice described analytics features that did not exist, including a per-day view it later retracted. When I finally reached a human, I got the truth in writing: Max subscribers have no session-level or per-day reporting, exports are Enterprise-only, and Cowork has been cloud-only on consumer plans since August. The Enterprise path to a readable meter starts at twenty seats. I am one person, so I built my own meter. The irony is that I used Claude to design and code it. Claude Code sessions write logs on my own machine. I price them at list rates with the open-source `ccusage` tool and attribute each session to a client by repo folder. That creates the measured pool: real receipts with no allocation. Other CLIs in the same logs, such as OpenAI Codex, are excluded automatically. Chat and Cowork run in Anthropic’s cloud and leave nothing on my disk, so the remaining overage becomes a cloud pool. I split that pool using evidence my workflow already produces: every Cowork document batch leaves a directive file, snapshots, and a report on disk. A Python script counts executed batches per project and measures the number of bytes each one rewrote. The script splits the cloud pool independently by batch count and byte volume, bills the midpoint, and shows both derivations so each client can see the bracket. Every column ties back to the dashboard total to the penny. A second script pulls per-account AWS charges from Cost Explorer because each client has a separate AWS account. Shell aliases make each report a one-command operation. A Claude skill and a monthly scheduled task turn the outputs into a draft invoice that I approve before anything is sent. The result is that a vendor hands me one unexplained number each month, while I hand my clients an evidence file. Month-end billing takes five minutes. It should not have been necessary to build this, but until consumer plans get real usage analytics, this is how I see in the dark. Step-by-step: 1. I collect local Claude Code session logs and use the open-source `ccusage` tool to price them at list rates. 2. I attribute each Claude Code session to a client by repo folder and automatically exclude other CLIs, such as OpenAI Codex, from the measured pool. 3. I treat the remaining overage from cloud-based Chat and Cowork usage as a separate cloud pool because those services leave no usage logs on my disk. 4. I use Cowork’s directive files, snapshots, and reports to identify document batches, then use a Python script to count executed batches per project and measure the bytes each batch rewrote. 5. I split the cloud pool independently by batch count and byte volume, bill the midpoint, and show both derivations as a client-facing bracket. 6. I verify that every column ties back to the dashboard total to the penny. 7. I use a second script to pull each client’s per-account AWS charges from Cost Explorer. 8. I run the reports through shell aliases, then use a Claude skill and a monthly scheduled task to create a draft invoice for my approval before sending it.

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

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

Sometimes the best AI workflow starts without a workflow at all. This one began almost accidentally. During an ordinary conversation about my cat, AI offered to write a haiku. I had not set out to create a poetry project; it was simply a small creative response to a moment. I liked it, so another moment with the cat became another haiku, and then another. Over time, those isolated poems started to feel less like chat fragments and more like a collection. The workflow emerged afterward: Step-by-step: 1. I notice something small from everyday life, such as a pose, habit, expression, interaction, or tiny domestic scene. 2. I tell AI about it in ordinary conversational language. 3. When the moment has the right texture, it becomes a short poem. 4. I react to what works, whether that is the humor, tenderness, rhythm, imagery, absurdity, or the particular way the cat was captured. 5. Those reactions gradually shape the voice of later pieces. 6. Instead of forcing every moment into the format, I keep the ones that feel worth preserving. 7. The poems accumulate over time. 8. Eventually, a spontaneous haiku becomes part of a coherent collection documenting a relationship and a period of life. The interesting part is that the collection was not designed from the top down. There was no initial brief, content calendar, or plan to “write a book of cat poetry.” Continuity emerged because the same subject kept returning, the format was small enough to revisit casually, and previous pieces gave later ones a growing creative context. AI therefore acted less like a writing tool and more like a creative companion with continuity: noticing when an everyday moment might be worth turning into something. The end result is more than a stack of generated poems. It is a record of tiny observations that probably would never have been written down otherwise.

I’m Jesús Núñez, an artist and the owner of J. Nunez Gallery, an independent contemporary art gallery with locations in Summit and Millburn, New Jersey. Founded in 2020, the gallery presents original abstract and figurative art, landscapes, still life, and photography. We help people discover artwork for their homes and work with interior designers on residential projects. Alongside running the gallery, I’m exploring how ChatGPT can help a small business improve its operations, marketing, and decision-making. I manage the business myself, so the practical question is how to turn existing information into useful, completed work. The workflow starts with real source material: website content, spreadsheets, analytics exports, screenshots, and the gallery’s business rules. I use focused conversations to examine one area, prepare concrete changes, and review the results. The work includes website improvements, artwork catalog organization, marketing analysis, audience segmentation, and outreach preparation. For example, AI-assisted troubleshooting helped identify duplicate website page-view tracking and guided its correction, which we checked against live analytics. That is an operational improvement; it is not evidence of increased sales. Another small-business owner can recreate the approach as follows. Step-by-step: 1. Record the business context: customers, products, geographic market, budget, brand preferences, and operating constraints. 2. Choose one specific task and define what completion means. Provide the relevant source material. 3. Require the AI to distinguish verified facts, interpretations, missing information, and proposed actions. It should not guess prices, contact details, or results. 4. Ask for a concrete deliverable, such as revised website copy, a classification table, implementation instructions, or an outreach draft. 5. Review the work and verify the actual result after implementation. Keep preparation, implementation, verification, and blocked work clearly identified. 6. Preserve approved decisions and completed actions in a current record so later sessions can continue from the existing work. 7. Measure qualified inquiries, appointments, proposals, and sales alongside marketing activity. This is an ongoing project. AI can repeat recommendations or lose track of previous decisions, so human review and continuity remain essential. I have not established a measured revenue increase or time-saving figure. I’m testing whether this approach can build a stronger business while allowing more attention for art, artists, and clients. If this example makes you curious about the gallery, you can browse available artwork and find information about our Summit and Millburn locations at https://www.jnunezgallery.com. You are welcome to explore the collection or contact us through the website for help choosing art. Jesús Núñez Artist and Owner, J. Nunez Gallery Summit and Millburn, New Jersey https://www.jnunezgallery.com

My pool water looks great, and I’ve taken over the weekly water-care routine myself after years of using a pool service. I first gave Claude the relevant information about my in-ground pool setup. Now, each week, I check the water’s chlorine, pH, alkalinity, and other chemical levels, then enter the results into Claude. I often take a water sample to a local pool store, where they provide a printed analysis. I snap a photo of the analysis with my phone and upload it to the Claude chat. Claude tells me which chemicals to add and when. Over time, the water has stayed balanced and looks great, while I’ve saved a lot of money on pool service and avoided wasting chemicals. This workflow has paid for itself many times over through this one use case. Step-by-step: 1. I gave Claude the relevant information about my in-ground pool setup. 2. I checked the pool water weekly, including chlorine, pH, alkalinity, and other chemical levels. 3. I either entered the results into Claude or took a water sample to a local pool store for a printed analysis. 4. I photographed the printed analysis with my phone and uploaded it to the Claude chat. 5. I followed Claude’s guidance on which chemicals to add and when. 6. I repeated the process over time to keep the water balanced and avoid wasting chemicals.

For the start of the new school year, I wanted to use the current eastern Washington wildfires near Spokane with my two sixth-grade science classes. I wanted an AI tool to create a website I could upload to my hosting service. The site needed to provide daily updates from verified news sources, along with air quality data comparing Spokane in eastern Washington, Kirkland near Seattle, and Chimacum, where we live, on the western side of the state. I also wanted to include a simulation where students could change different variables to see how they affect the direction of the smoke and air quality. I could not decide which AI service to use, so I entered the same prompt into my personal paid Claude and Gemini Spark accounts, as well as my free teacher ChatGPT and Claude accounts, to compare which one created the best site for students. Here is the prompt I used: "Create a dynamic website with information of the Spokane, WA 2026 wildfires. Information include only verified facts from credible news sources. Information needs to be updated from when the largest fire started until it is completely put out. At that point, this website is complete and done. Include a page with air quality data. Provide air quality data on a daily basis from the onset of the fire to the end of the fire. Include Spokane, Kirkland, and Chimacum to compare the air quality from eastern WA near the fire, mid WA, and western WA. Include factors that explain the air quality such as winds, inversion, altitude of smoke and any other relevant data that students can view to answer questions. Provide a way for students to click on different variables to see how different factors affect the fire, direction of smoke, and air quality. Use the /inversa-design skill to make the website." Here is a portal page with links to all four sites: https://educatoral.com/2026SpokaneFire/ Step-by-step: 1. I identified the eastern Washington wildfires near Spokane as a topic for my two sixth-grade science classes. 2. I defined the website requirements: verified news updates, daily air quality data, comparisons among Spokane, Kirkland, and Chimacum, and a student-facing smoke and air quality simulation. 3. I used the same prompt with my paid Claude and Gemini Spark accounts and my free teacher ChatGPT and Claude accounts. 4. I compared the sites created by the four AI accounts to determine which one would be best to use with students. 5. I collected links to all four sites on this portal page: https://educatoral.com/2026SpokaneFire/