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 designing a publishing system that keeps producing value without requiring constant output. This workflow started with frustration about the usual content model: publish constantly, stay visible, feed the algorithm, and repeat. That model works poorly when my energy varies, my interests shift, and forcing output quickly turns creativity into maintenance. Instead of asking, “How do I post more?” I’m asking: “How can content keep moving without requiring me to keep producing at the same pace?” The system is built around uneven energy. During high-energy periods, I can generate ideas, draft pieces, collect fragments, or prepare several posts at once. During low-energy periods, existing material does not become a failure state. It can sit, mature, be lightly edited, be reused, or simply wait. Ideas can exist in different stages: a note, a half-developed thought, a finished piece, something worth revisiting later, or something that can be repurposed in another format. Older material is not automatically “used up” after publication. A long-form idea can become a short post. A workflow can become a case study. A conversation fragment can become an essay seed. A previous post can return later from a different angle. The goal is not to build a machine that constantly demands feeding. It is to create a content reservoir I can draw from when I have the capacity. This workflow has not been fully implemented yet, but the design principle is useful: > Build around energy reality, not around imaginary consistency. Content should fit into life. Life should not be reorganized to serve the content treadmill. Step-by-step: 1. I design the publishing system around variable energy rather than a constant production schedule. 2. During high-energy periods, I generate ideas, draft pieces, collect fragments, and prepare several posts at once. 3. During low-energy periods, I let existing material sit, mature, receive light edits, be reused, or wait. 4. I allow ideas to remain in different stages, from notes and half-developed thoughts to finished pieces and material worth revisiting later. 5. I repurpose older material across formats, such as turning a long-form idea into a short post, a workflow into a case study, a conversation fragment into an essay seed, or a previous post into a new angle. 6. I draw from the resulting content reservoir when I have the capacity instead of constantly feeding a content treadmill.

I used Claude to build an automated patient scheduler for my husband, who is the Director of Rehab at a skilled nursing facility. Each week, he takes a patient list in Excel and schedules each patient for the types of therapy they need—speech, physical therapy, or occupational therapy—based on therapist availability. The variables change from week to week, making the process time-consuming and error-prone. Automating it saves him at least an hour each week, usually on Sundays when he creates the schedule for the coming week. He uploads the patient spreadsheet and clicks “Generate schedule.” Under the hood, the app uses Google’s OR-Tools CP-SAT solver to optimize the schedule against hard constraints and weighted priorities. Hard constraints include never exceeding a therapist’s daily capacity or a patient’s maximum weekly visits. Weighted priorities include giving higher-acuity patients preference when capacity is tight, providing every patient with daily contact when possible, and balancing the workload across the week instead of simply sorting patients by who fits first. I wrote zero code. I gave Claude all the features in plain English, and it wrote the app in Python and created a test suite of approximately 35 tests. One test was added after we found and diagnosed a bug in production. I also had Claude walk me through creating a `.exe` file that I could send directly to my husband so it would open on his PC. Patient data never leaves his machine. New versions are easily compiled in GitHub, where patient data never touches the process, and enhancements only require sending a new file. Step-by-step: 1. I described the scheduling requirements and features to Claude in plain English. 2. Claude wrote the scheduling app in Python and created a test suite of approximately 35 tests. 3. I provided an Excel spreadsheet containing the weekly patient list. 4. My husband uploads the spreadsheet and clicks “Generate schedule.” 5. The app uses Google’s OR-Tools CP-SAT solver to schedule speech, physical therapy, and occupational therapy according to therapist availability and patient needs. 6. The solver enforces therapist daily-capacity limits and patient maximum-weekly-visit limits. 7. It also applies weighted priorities: higher-acuity patients receive preference when capacity is tight, every patient receives daily contact when possible, and the workload is balanced across the week. 8. After finding and diagnosing a production bug, we added a corresponding test to the suite. 9. I used Claude’s guidance to create a `.exe` file that opens on my husband’s PC, keeping patient data on his machine. 10. I compile new versions in GitHub without patient data entering that process, then send the updated file when enhancements are needed.

I'm Steven Alber, an independent researcher building Quantum Civilization (https://quantumcivilization.org). It's a research platform exploring how quantum computing, AI, autonomous agents, and emerging technologies could transform the future of human civilization. I use ChatGPT and Claude to do the work, and this workflow is for anyone who wants to run a research project with AI models and no traditional team. 1. I identify important developments in quantum computing, artificial intelligence, autonomous agents, and emerging technologies. 2. I use ChatGPT to research scientific publications, analyze the evidence, challenge my assumptions, and explore possible implications for civilization. 3. I develop research questions and conceptual frameworks that connect quantum technologies with AI, economics, and the future of society. 4. I use Claude to help turn the research into structured publications, website code, and interactive digital experiences. 5. I compare the outputs from both models, review the results, correct weaknesses, and publish the work on Quantum Civilization. The goal is to explore whether one independent researcher, working with advanced AI models, can develop a credible international research platform. The process is experimental and still evolving. I direct the research and make the final decisions.

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.

Sometimes I remember something perfectly badly: not its title, creator, or where I found it, but a sound, a color, a vague cover, a sentence, or a period in my life. I know it exists because I loved it, but I cannot name it. I use AI and my digital traces to recover songs, books, videos, articles, and quotes. Memory is not a catalog; it stores traces. AI can turn those traces into searchable hypotheses. Step-by-step: 1. I dump every surviving clue without waiting for a proper search query. The clues can be as rough as “The title sounded like nu nau tau,” “It was ambient or humming,” “The cover was maybe a green desert?” or “I knew it around 2019.” Another example is: “A book about makers and Disney. White 3D-printed figures, tiny people, and bears on a blue cover.” This is raw memory evidence. 2. I separate certainty from guessing by labeling each clue as certain, fairly sure, possible, or probably distorted. I keep uncertain clues, but do not treat them as facts. A wrong attribution or outdated cover does not invalidate everything else. 3. I reconstruct the original encounter. I ask where I was and whether I Shazamed it, saved it, sent it to someone, screenshotted it, or bought it at a book fair. In one case, I remembered hearing a song in someone’s car and Shazaming it because I could not parse the pronunciation. Remembering that capture action pointed to a retrieval source. 4. I search my own collections first: playlists, liked songs, Shazam history, saved videos, old posts, messages, bookmarks, notes, photos, receipts, and reading lists. The object may already be there under metadata I no longer remember. I start with the smallest reliable fragment. 5. I search for “nu” inside my playlists after remembering “nu nau tau.” That recovered Man O To — Nu. The artist and title had blended into one phrase, and the song was sitting in several playlists, including my Shazam collection. A clue does not need to be complete; it only needs to be distinctive enough inside the right collection. 6. I allow memory to scramble metadata. An artist and title may merge, album art may become song art, and a quotation may survive with the wrong poet attached. I split remembered phrases, swap artist and title, try different word boundaries, consider older releases, and search phonetically using similar syllables, vowel sounds, homophones, alternate spellings, or other languages. I also ask what the cover looked like when I knew it, because artwork changes. 7. I use context and cross-reference traces. A year, trip, relationship, or platform can narrow the search more than a half-correct title. Spotify might preserve the song, Shazam the discovery moment, and an old message the recommendation. Old posts are accidental archives, and dead links may still leave names, dates, or descriptions. If memory fails completely, I inspect behavior from the relevant period, such as repeated listening, watch history, purchases, or library loans. 8. I let AI propose candidates and compare them against several independent clues, including sound, subject, period, cover, and personal context. One matching detail is not confirmation. I show titles, covers, creator names, and short descriptions because recognition may succeed where recall fails. Rejections also help: “No, but the cover was more minimal,” “The title was shorter,” or “It was fiction, not nonfiction.” Each correction sharpens the search. 9. I pay attention to the strangest clue. The blue cover with white figures, bears, and a makers-and-Disney theme led to *Makers* by Cory Doctorow. 10. Once I confirm the object, I save the title, creator, link, why it mattered, and how I recovered it. For example: - Clue: “nu nau tau” - Encounter: heard in someone’s car and Shazamed - Search: Spotify/Shazam collection → “nu” - Result: Man O To — Nu - Distortion: artist and title blended together This becomes a retrieval playbook: which clues survive, where traces live, and how my memory distorts them. The overall workflow is: collect fragments → mark uncertainty → reconstruct the encounter → search personal traces → try phonetic, visual, and contextual clues → compare candidates → recognize and confirm → save the result and retrieval path. I do not need to remember the database fields. I need enough fragments to rebuild the trail. Sometimes the best clue is what I did when I first encountered something. Sometimes it has been sitting in five of my own playlists while I spend years wondering what it was called. 😑😭🎧

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.

I built a workflow that prepares late invoice reminder emails for me. Our industry has tight margins, and our back end is rudimentary with limited capabilities, so sending these reminders was annoying, repetitive manual labor. I had Claude Cowork walk me through creating an agent that logs in every Monday night, checks our late AR, and compares the customer names against a Google Sheet list I created. It uses an email template I provided, adds the contact name from the Sheet, and includes each late invoice’s identifying number, amount, and due date. The agent puts the emails in my Drafts folder and emails me a report showing which customers were included, how much each one owes, and the totals. All I have to do is review the drafts, confirm everything looks good, and hit Send. This has saved me about an hour every Monday night of tedious, repetitive manual labor. Step-by-step: 1. I created a Google Sheet with the customer names and contact names. 2. I had Claude Cowork walk me through creating an agent that logs in every Monday night. 3. The agent checks our late AR and compares the customer names against the Google Sheet. 4. It uses my email template and adds the contact name, invoice identifying number, amount, and due date. 5. It places the completed emails in my Drafts folder. 6. It emails me a report listing the included customers, the amount for each, and the totals. 7. I review the drafts, confirm that everything looks good, and send them.

I had about $2K in contributions from past jobs stuck in a government scheme for more than two years. The portal was slow, spread across several forms, and unclear about how to withdraw the money. I gave the task to Claude and Perplexity Comet. Claude worked through the rules and found the withdrawal route that kept my tax bill lowest. Comet then verified and implemented that route. It ran the portal in my browser, filled in and submitted the claim forms, and let me watch the screen and check each detail before submission. Two weeks later, the $2K arrived. After that, Claude compared the amount I received with the scheme’s online statement and found a gap: interest that had not been paid out. It filed a second form for the difference, and I’m waiting for the payment now. I’ll use the same technique to solve this for my wife too. Step-by-step: 1. I gave Claude the details of the contributions stuck in the government scheme and asked it to work through the withdrawal rules. 2. Claude identified the withdrawal route that kept my tax bill lowest. 3. I had Perplexity Comet verify and implement that route in the scheme’s browser portal. 4. Comet filled in and submitted the claim forms while I watched the screen and checked each detail before submission. 5. Two weeks later, I confirmed that the $2K had arrived. 6. I asked Claude to compare the payment with the scheme’s online statement. 7. After Claude identified unpaid interest, Comet filed a second form for the difference. I’m waiting for that payment now.

I've been working with ChatGPT on a personal archive project called Atlas. We developed a specific way of analyzing old conversations, discovering creative ideas, reviewing them one by one, and saving the approved results. The workflow worked well, but every new session meant bringing back the instructions and explaining the process again. So I asked ChatGPT's Create Plugin tool to package our process into a private plugin called Atlas Analysis. Here is how it runs now: 1. I open Atlas Analysis and upload my current project ZIP, the original conversation, and an earlier AI (Gemini) analysis. 2. ChatGPT examines the material and identifies potential discoveries. 3. We review each candidate together. I approve, revise, merge, or reject it. 4. Approved discoveries receive their permanent archive IDs, and the session produces an export for my existing local project. The plugin is a first version and I'm still testing and refining it. My favorite part is that I can package a way of working we already developed together, instead of designing every session around a tool's default behavior. I didn't write any plugin code myself. I explained what I wanted, provided my project materials, and ChatGPT built the first version. The result is a reusable tool that saves me from re-explaining the same process each time.

I was charged with leading my book club’s discussion of *Shrines of Gaiety* by Kate Atkinson. The book has many well-developed characters and murder-mystery plotlines, so I decided to create a “Who Is This Character?” game using simple supplies from my home office: envelopes, printed clues, a stapler, and markers. I asked ChatGPT to help design the game. It came up with eight potential characters, then selected the five most important so the game would still work if some book club members were absent. For each character, it created five clues and a simple rules sheet. Characters were assigned numbers and read in order. Players heard each clue without asking questions, but they could guess after every clue. Many characters were identified, and the game led to a meaningful discussion of each character’s motivations. ChatGPT also provided a discussion question for each character, which made the activity easy for me to run. As a bonus, ChatGPT found a 1920s cocktail recipe for the Mother’s Milk drink mentioned on page 336. It included appropriate warnings, nonalcoholic options, and a sample size suitable for an afternoon book club for senior women. Step-by-step: 1. I chose a “Who Is This Character?” game for my discussion of *Shrines of Gaiety* because of its many characters and murder-mystery plotlines. 2. I gathered envelopes, printed clues, a stapler, and markers from my home office. 3. I asked ChatGPT to suggest eight potential characters and select the five most important in case some members were absent. 4. I asked ChatGPT to create five clues for each selected character, along with rules explaining that the characters would be read in numerical order, with guesses allowed after each clue and no questions during the clues. 5. I used the clues and rules to run the game during the book club discussion. 6. I used ChatGPT’s character-motivation questions to guide the discussion after the game. 7. I also used ChatGPT’s 1920s Mother’s Milk cocktail recipe, including its warnings and nonalcoholic options, for the afternoon gathering.

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 built Able (uable.store) because I was tired of chat tabs that explain how to do a job but leave me to paste the result into PowerShell. I wanted an agent that lives on this Windows PC and can actually move files, run tools, and write code here after I approve the actions. I work on Able, so this is the workflow I run on my own machine—not a theory. The job was to organize a Downloads folder that had become a dump and make a code change without affecting the live app. Step-by-step: 1. I open Able on Windows and describe the task conversationally: “organize my Downloads — keep installers, put photos together, leave anything I’m not sure about.” 2. I review the actions Able plans to take and let it run only after I approve them. Native file moves stay on this PC and do not use cloud credits. 3. For a code task, I enter `able job:` followed by the ticket. Able creates a separate Git worktree, writes a plan, and runs `cargo check` on that copy so the live app stays unchanged. 4. I keep secrets in the local vault, Septaguard. Cloud models—Claude, Gemini, Grok, and Kimi—receive the prompt I send, not the vault password. I enter Google and Gmail logins in the masked vault UI rather than in chat. 5. I remember that the job stops if the PC is off; there is no cloud-based substitute running in the background. 6. I verify the result on this machine: the folders are sorted, and the code check either passes or fails locally. If I only needed a sentence, I would have stayed in ChatGPT. The point of this loop is that the disk actually changes. What I learned is that “agent” is cheap until it has to touch the real folder and the real compiler. Chat is the easy half; confirm-then-act on Windows is the hard half. If you already use Claude or Cursor in a tab, what is the first job on your PC you still do by hand because the model cannot touch the files?

I build an office platform for small nonprofits, and every week users ask how to do something. I also keep changing features they have already learned, so written instructions go stale quickly. Screen recordings take an afternoon each and can be out of date by Friday. I use Claude Code in my project to turn each user question into both a software change and a how-to video. The video runs against a throwaway copy of the app filled with a made-up organization, so no real data appears on screen. It performs the task as a person would—clicking, typing, and waiting—while displaying captions one step at a time and moving a yellow pointer to each button before clicking it. There is no voice. I tried narration but dropped it because captions can be paused and read, and they never mispronounce anything. The important part is that the script also tests what it films. After each step, it confirms that the screen did what the caption says and prints PASS or FAIL. If anything fails, there is no video yet; I fix the bug first. In one day, the videos found four real defects that our automated tests had missed, so the video is also the test. `ffmpeg` turns the recording into an MP4 and a poster image. I watch and approve the result, then publish it on our videos page and inside the app’s Help box, next to the instructions for that screen. When the screen changes, I run the same script again and get a new video in minutes. The first videos were too fast. I am not as fast as Claude, and the person watching is trying to learn something new. Now each caption stays on screen long enough to read—about 1.5 seconds plus a third of a second per word—before the next click. The workflow produced 35 how-to videos in five days, most of them one to three minutes long. The checking in step 4 started on day four, after the videos kept finding problems. Every video since then has checked itself. Step-by-step: 1. I take a user’s email question or request and use Claude Code in my project to make the requested software change. 2. In the same session, I have Claude write a short script for a how-to video of the task. 3. The script starts a throwaway copy of the app, fills it with a made-up organization, and performs the task by clicking, typing, and waiting. 4. The script displays captions one step at a time and moves a yellow pointer to each button before clicking it. I use captions instead of narration so viewers can pause and read them without hearing mispronunciations. 5. After each step, the script confirms that the screen did what the caption says and prints PASS or FAIL. If anything fails, I fix the bug before producing the video. 6. I use `ffmpeg` to create an MP4 and a poster image from the recording. 7. I watch and approve the video, then publish it on our videos page and in the app’s Help box next to the relevant screen instructions. 8. When the screen changes, I run the same script again to create an updated video in minutes. 9. I keep each caption on screen for about 1.5 seconds plus a third of a second per word before the next click.

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.

Most businesses don't need another AI tool. They need to automate the repetitive bottleneck already slowing the team down. A simple example is connecting the tools already in use: Lead → AI qualification → CRM → WhatsApp → follow-up Instead of adding more software, automate the repetitive steps between these tools. The goal isn't more AI; it's less manual work and faster execution. Step-by-step: 1. Identify the repetitive bottleneck slowing the team down. 2. Capture the lead and use AI to qualify it. 3. Send the qualified lead to the CRM. 4. Use WhatsApp for follow-up. 5. Connect the steps so the process requires less manual work and supports faster execution.

I have tried many AI Tools however - I feel the time I Input data and effort into schedulign and resourcing is the problem - I need a Fix or a rubust reliable AI workflow so i can buy my time back. Any suggestions?

I submit two reports to my directors each month. Both use structured templates, but the updates come from multiple people and sources. Some information is unstructured, such as hallway conversations that are not always captured in email, so I have struggled to get the accuracy I need when using AI to build the reports. I am currently testing CoWork and Copilot Work IQ. These reports used to take me hours, so I am already saving time, but I want to refine the process further. I believe a better way to save and store the source data could improve the final outputs, although I have not worked out the right approach yet. Step-by-step: 1. I collect updates from multiple people and sources for the two monthly reports. 2. I organize the information into the structured templates required by my directors. 3. I use CoWork and Copilot Work IQ to help build the reports. 4. I account for unstructured updates, including information from hallway conversations that may not have been captured in email. 5. I am exploring better ways to save and store the source data so I can improve the accuracy of the reports while continuing to save time.

I’m the Export and Operations Manager at Supreme Poultry & Chickens, an Australian poultry processing business. My original request to ChatGPT was straightforward: find and track grants that could help us grow our business. As we worked together, I began to see the potential to build a management system that could organise our operations and help us prepare a business case when an opportunity arose. That led me to discover Sites and the possibility of building our own system. We already use SafetyCulture for inspections. It also offers maintenance functionality, but that system didn’t connect with the other parts of our management processes in the way we needed. We wanted our records, schedules, and actions connected across the business. Over roughly ten weeks, working with ChatGPT and Sites, we progressively developed the Supreme Poultry Management System (SPMS). It brings together: * Export enquiries, customers, and shipping schedules * Purchase orders and approvals * Vehicles, registration, insurance, and inspection dates * Assets, maintenance schedules, and job history * Supplier certificates and HACCP records * Environmental compliance and complaints * Water management and daily processing records * Dashboards and operational reporting * A central 45-day action calendar * A system backup module Behind SPMS, we also built a database that stores the records and supports the system. It provides a shared foundation for the different modules, allowing information to be linked across our management processes. The database stores the underlying records and history, while SPMS makes that information accessible through screens, reports, and the action calendar. Water management is a particularly important example. Water is one of the most critical factors in our poultry processing business. SPMS receives tank-level readings from a laser-operated monitoring device that transmits data over the 4G network. We placed a water management widget at the top of every SPMS page, keeping that information visible wherever we’re working and helping us stay on top of our water supply throughout the day. The process hasn’t been without setbacks. At one stage, we nearly lost the whole system, and I had to rebuild it using screenshots I had saved. That experience made backups a priority. We’ve since built a dedicated backup module and now back up the system regularly. For anyone following a similar path, I recommend establishing backups early. The most useful part has been turning our actual business rules and priorities into system behaviour. An export order needs to remain visible until it ships. Completing a recurring maintenance job should preserve its history and its next scheduled occurrence. Supplier certificates need expiry tracking and a record of whether replacements have been requested. Critical operational information, such as water management, needs to stay visible across the system. We developed the system progressively: describe a problem or process, build the workflow, use it in daily operations, and then refine it. Here’s how someone else could recreate the approach: Step-by-step: 1. Start with a real business need. Ours was finding grants. 2. Gather the records, spreadsheets, and forms you already use. 3. Explain how the process works, including responsibilities, deadlines, and exceptions. 4. Use ChatGPT and Sites to build one manageable module, with a database to store its records. 5. Establish regular backups early and check that you can restore them. 6. Check the module against real examples and refine it through daily use. 7. Add related modules, connecting shared database records and actions. 8. Identify your most critical operational information and keep it visible wherever people work in the system. This is the starting prompt I used: “Help me build a management system for my business using Sites, backed by a database for our records. Start with [workflow]. These are our current records and business rules. Identify missing information, help me build the first module and its database structure, and check it against real examples. Include a backup and recovery process, and a shared widget across pages for [critical operational information].” SPMS is still evolving. What started as a grant search has become a practical tool for managing our business and building an organised foundation to support future growth.

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?”