Workflow Hub

I built a live camera bubble that floats over my slides during Facebook Live presentations. Because Facebook Live does not let me switch between my camera and a shared screen, I wanted my face to stay visible while I presented. This is useful for anyone who streams presentations to a Facebook Group and wants viewers to see them speaking. Claude Code built the working app within about five minutes. I made one tweak to the camera bubble’s shape, and it was then a finished, usable product. When I’m ready to go live in the Facebook Group, I click the camera bubble app on my local desktop. It uses my laptop camera, and I can drag the bubble around the screen and choose the circle size that suits whatever I’m sharing. Before I go live, I select "share entire screen" in the Facebook Live settings. Viewers then see my slides or screen with my floating camera bubble, so they can see me speaking as I present. The result is a live stream that shows my slides and my face together, and it took about five minutes to build. Step-by-step: 1. I gave Claude Code the challenge of building a live camera bubble for Facebook Live presentations. 2. Claude Code built the working app within about five minutes. 3. I made one tweak to the shape of the camera bubble, creating a finished, usable product. 4. When I’m ready to go live in the Facebook Group, I click the camera bubble app on my local desktop and use my laptop camera. 5. I drag the bubble around the screen and choose the circle size that suits what I’m sharing. 6. In the Facebook Live settings, I select "share entire screen." 7. I present my slides or screen while viewers see my floating camera bubble and my face together.

I spend a good chunk of my week volunteering for our local community group, Byron Bird Buddies, keeping an eye on local and regional bird news. With so much happening across Australia—from avian health updates to local conservation stories—tracking it all by hand takes a lot of time. I recently tried my hand at vibe coding to see if I could build a workflow that automatically gathers interesting regional bird stories into a handy hub that I could share on our Facebook page. It did not quite fly, mostly because our little volunteer group runs without funding, and my prompting skills probably leave a bit to be desired. I am convinced that a simple, free automated workflow like this would be a game changer for grassroots conservation groups and thousands of birders everywhere. If any clever builders in the community have ideas, tips, or would be keen to tackle a project like this, I would love to connect. I also asked my AI buddy, Al, whether an app like this already exists. This was the answer I received: > No, there is no existing single app or consumer platform specifically designed to aggregate, curate, and publish regional bird and conservation news to social media. > > While there is not a pre-made app doing this specific workflow, the reasons you have not seen one come down to how birding technology is structured and the types of tools currently available: > > 1. Data and sighting trackers, such as eBird, Birda, and iNaturalist, track observations, sightings, and checklist data submitted by birders. They do not crawl news sites, press releases, or government databases for written news stories or conservation updates. > 2. Official disease and threat trackers, such as Avian Flu Watch, DAFF, and Wildlife Health Australia, maintain live tracking maps and statistics for specific issues such as avian influenza. They focus on raw data or single-issue reporting rather than general, human-interest, or local conservation news. > 3. Generic news aggregators and RSS readers, such as Feedly and Inoreader, collect RSS feeds from selected websites into one dashboard. They require manual setup for every website or RSS feed, and they do not automatically summarize, filter by region, or publish directly to Facebook in a readable format without paid extensions or third-party automation tools such as Zapier or Make. > > A dedicated app may not exist because scraping news websites or using live search APIs, such as Google News or Bing News, costs money. Without a subscription model, developers may struggle to keep a free news-scraping app running. Region-specific filtering is also difficult: finding bird news specifically for the Northern Rivers and NSW alongside broader Australian stories requires fine-tuned filtering, often using AI or large language model processing, to avoid irrelevant articles. > > In the meantime, a no-cost approach could combine free RSS aggregators and social schedulers. Possible sources include ABC North Coast, NSW DPIRD, local council news, and BirdLife Australia. Google Alerts could also be set up for keyword combinations such as “Byron Bay” bird, “Northern Rivers” conservation, or “NSW” avian flu. > > Another option would be to copy and paste a digest of links or raw text into a free AI assistant such as Claude, ChatGPT, or Gemini once a day or once a week, using a prompt such as: > > “Summarize these articles into a short, friendly 3-bullet-point Facebook post for Byron Bird Buddies readers.” > > The conclusion was that the idea remains relevant for a community of workflow builders. A free-tier automation platform such as Make or n8n, or a Python script, could potentially fill a real gap for volunteer groups like Byron Bird Buddies. > > Written by Gemini AI for Larry > > Larry Larstead > larrylarstead(at)gmail.com Step-by-step: 1. I identified the time-consuming task of manually tracking local, regional, and Australian bird and conservation news for Byron Bird Buddies. 2. I tried using vibe coding to build a workflow that would gather relevant regional stories into a central hub. 3. I planned to share the collected stories through the Byron Bird Buddies Facebook page. 4. After the first attempt did not succeed, I asked my AI assistant whether an existing app already supported this workflow. 5. I reviewed possible alternatives, including RSS aggregators, Google Alerts, manual AI summarization, free-tier automation platforms such as Make and n8n, and Python scripts. 6. I shared the idea with workflow builders in the hope that someone could offer tips or help create a free solution for grassroots conservation groups.

Let AI build your prototype, but don’t let your prototype own you. A working preview makes it tempting to keep asking for features. But the first screen tells you little about who controls the database, how the application is structured, or what the next prompt might change. I developed this workflow by putting my best-practices guides to work on a client project, then separating the reusable process from that project’s architecture. This workflow is for AI app-building platforms, often called vibe-coding platforms, where you describe an application and the platform generates and runs a working prototype. It focuses on keeping control of the code, repository, backend, and platform connections. It is not a general guide to coding agents or AI-assisted editors. Anyone who has watched a code generator slowly degrade a clean codebase knows why the starting conditions matter. Before asking for features, establish what you own, what the tool may change, and how you will check its work. Step-by-step: 1. Set ownership before the first build prompt. Decide what the application needs and who controls it. If it needs a new database or backend, provision it in an account you control before asking the builder to create the app. An existing API is another option, not a requirement; some prototypes need neither. Confirm the repository destination, integration permissions, and recovery access. Keep production behind a reviewed release process. 2. Give each tool readable rules. Establish one authoritative set of architecture, coding, and design standards. Identify which files each tool may change and which it may only read. Naming a rules file in a prompt does nothing if the tool cannot access it. Assign responsibility for data, authentication, application logic, deployment, and recovery. One person can hold several roles, but a UI task does not grant permission to redesign the backend. 3. Build the framework before the features. Use the opening prompt to establish the framework, runtime, routes, layout, and state ownership. Ask for empty page shells first. Check that navigation uses real routes and that shared elements have a defined home. Keep design values in one designated place. Any temporary authentication placeholder must be clearly labeled and isolated from protected data. Real users require real authentication and authorization. 4. Inspect and preserve the foundation. Read the generated files and inspect the running scaffold. Check for unrequested services, dependencies, and structural changes. A green build alone does not tell you whether the tool followed your instructions. Once accepted, protect the foundation files from routine UI prompts. Record the accepted commit and preserve a recovery copy beyond the integration’s ability to modify or delete. 5. Set up a prompt factory. A prompt factory is an assistant configured to turn a plain-language request into a bounded implementation prompt. Give it the project rules, file map, technical references, and current capabilities. It checks whether the requested behavior is supported before producing instructions. If something is missing, it prepares a prerequisite request for the responsible owner instead of inventing data or behavior to make the screen look finished. Each prompt names the tool, permitted files, protected files, applicable standards, relevant data and interfaces, exact change, what must be preserved, and observable checks. The factory prepares instructions; it does not approve architecture or release changes. 6. Build one governed feature. Where data is involved, establish correct data behavior first. Follow with a separate placement and styling task. Inspect the changes and test the affected behavior. Apply the One Fix Rule: one repair prompt, one attempt. If it fails, the generator is done with that file. Move the repair to manual maintenance rather than feeding another round of guesses into the codebase. After acceptance, save the next recovery point and update the working rules. Preserve the reason behind each rule so a later cleanup does not remove the safeguard. The point is to make the next feature less likely to undo the work you already accepted. Your database, where needed. Your code. Your standards. You control the tether. Part 2 will cover cutover: leaving the development platform with a controlled release, verification, and a recovery plan.

I built a workflow for creating a living book that exists online and that I can add to, edit, and share whenever I like. I’m an occasional writer who publishes nonfiction essays about observations in life. I realized I could collect the essays into a book, but life doesn’t take an appropriate pause, so the book and the essays never really end. That raised the question: When should I publish it? I created a local Claude instance to access all the files on my laptop. Local is almost always better than a cloud instance, and you can ask Claude to enable remote control so you can access it from your phone as well. I used Opus 5.5 because I couldn’t be bothered experimenting with lower-level models to see whether they could do the task more cheaply. A friend who uses Claude professionally once told me to always use the highest model available and move down if I ran into usage limits. I’m on the monthly Pro plan. I gave Claude the locations of my existing writing on Substack and Medium.com. It downloaded all my essays and organized them into rough sections. I argued with it about the organization and approved the sections once it explained its logic. I then had Claude create a Ulysses folder for all my essays, organized into sections and chapters. I can use it to create a new essay, edit an old one, or reorganize and reorder the book, then tell Claude to update the online version. I could have had it scan the folder regularly and update the site automatically, but that seemed unnecessarily lazy. Claude created a section of a website I already owned where readers can access the living book: https://enwaken.com/read/ During the process, I also had Claude restructure and redesign my overall website several times. It’s amazing at that sort of task. I’m still amazed that I can say something like "I want blue and violet and black, but maximize the contrast between each of the colours" and it will actually pick colors that complement each other. I wish more website designers knew they could do this. Now I have a version of my book that is spectacularly easy to read online and that I can update whenever I like. It’s easier to navigate than an ePub on my Kindle and certainly easier to update. The whole process took two days, half of which was spent arguing about the organization of the chapters. Step-by-step: 1. I set up a local Claude instance with access to the writing files on my laptop and enabled remote control so I could access it from my phone. 2. I used Claude Opus 5.5 through the monthly Pro plan. 3. I gave Claude the locations of my existing essays on Substack and Medium.com and had it download them. 4. I reviewed Claude’s rough organization of the essays into sections, argued about its choices, and approved the structure once it explained its logic. 5. I had Claude create a Ulysses folder organized into sections and chapters so I could add, edit, and reorder essays. 6. I told Claude to update the online book when I changed the Ulysses folder. 7. I had Claude create the book as a section of my existing website and redesign the site as needed. 8. I now maintain a living online book that is easy to read, share, and update.

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'm an immigration attorney, and I built this workflow so our team can fill in the template emails we use at each stage of a case without copying a template or hunting for client details. We call up a template by number or case stage, answer a few questions, and Gemini drafts the email in Gmail, ready to send to the client. Step-by-step: 1. I uploaded all of our template emails into a Gemini notebook project inside our Enterprise Gemini account. 2. I connected Gemini to Gmail. 3. I instructed the Gemini project to ask for the details that need to be filled into the templates. 4. The user calls up a template by number or its corresponding case stage. 5. Gemini asks for missing details, such as the client’s name or other information, and tells the user what needs to be attached. 6. Once the user provides all the necessary details, Gemini drafts the email and usually finds the recipient’s email address on its own. 7. Gemini prepares the draft in Gmail for the user to send to the client. The result is a finished client email draft generated from a template number and the missing details, so we don't have to fill in the template by hand.

I built an interactive web app to track a family member’s blood pressure four times a day. She is monitoring how her readings change throughout the day and how they respond when her doctor adjusts her medications. The app displays graphs and bar charts organized by date, time of day, and medication. This makes it easier to see how her blood pressure varies at different times and with different medications. She can upload readings by taking a picture of the blood pressure monitor screen or by entering the data into text fields. Selected data can be downloaded as a spreadsheet. The app works on her phone and laptop through a link hosted on Claude.ai. Step-by-step: 1. I built the app as a Claude artifact with a built-in database. 2. I hosted the web page on Claude.ai so it could be accessed from her phone and laptop through a link. 3. I connected the page to a database so readings persist and sync across devices. 4. I added photo input so she can take a picture of the monitor screen and have Claude read the numbers. She confirms the readings before they are saved. 5. I added table views, graphs, bar charts, and filters for weekly, monthly, or custom date ranges. 6. I added text fields for manually entering readings. 7. I added an export button for a CSV or printable report that she can take to the doctor.

I built an AI-assisted Lightroom Classic workflow that lets photographers create branded marketing images without leaving Lightroom. The problem I wanted to solve was simple: photographers often finish editing an image, export it, open another design tool to add a logo, watermark, text, or promotional graphic, and then export it again. I wanted that entire branding step to happen inside Lightroom. Using AI-assisted development, I built Brandstamp Pro, a Lightroom Classic plugin that lets me add branding, preview the result, save reusable presets, and export the finished image from the same workflow. The result is a much simpler process: edit photo → add branding → preview → export Instead of: edit photo → export → open another design app → add branding → export again I originally built it for my own real-estate photography workflow, but the same idea works for photographers who need branded social images, booking graphics, promotional images, watermarks, or client-ready marketing photos. The biggest benefit is not that AI adds the branding automatically. It helped me build a tool that removes a repetitive step from an existing photography workflow. Step-by-step: 1. I selected an edited photo in Lightroom Classic. 2. I opened the Brandstamp panel. 3. I added a logo, watermark, text, or other branding. 4. I adjusted the size, position, opacity, color, and placement. 5. I previewed the branded result before exporting. 6. I saved reusable presets for branding I use repeatedly. 7. I exported the finished branded image directly from the same Lightroom workflow.

I built a quarterly “AI Audit” of my Claude history, adapted from The Rundown’s AI Audit prompt and turned into a repeating loop. Each quarter, Claude reads every conversation I’ve had and reports patterns I can’t see myself: where my stated priorities differ from where my attention actually goes, which decisions I keep reopening, and connections across work, money, travel, and personal life. It then rewrites its own instructions for working with me based on what it found. I request my Claude data export, and the run finds the export email in Gmail, downloads it through Claude in Chrome, and unzips it on my machine through the desktop app. I never touch a zip file. The conversations are condensed and split by month, and Sonnet subagents pull structured notes from each month. An Opus subagent combines the monthly notes into a quarterly report under strict evidence rules: every finding cites at least three conversations across at least two months, states the strongest counter-evidence, and labels each claim as OBSERVED or INFERRED. When the evidence is thin, it says “insufficient evidence” instead of padding. Claude writes and maintains a Google Doc with two tabs. Reports contains one report per quarter with footnoted citations. Progress compares the quarters and includes two sections I added to the original prompt: Stop / Start / Continue / Change, which generates concrete behavior changes for the next quarter, and a Cross-domain pass, which identifies patterns spanning work, money, body, and personal life that I would not connect on my own. I push back on findings I disagree with. Those corrections go into the doc and a versioned prompt, now v1.1, so the next run does not repeat the mistake. Claude then takes the latest audit and its stored memory about me and proposes rewritten project instructions. The first rewrite removed stale facts and added rules to check memory, docs, and connected apps before saying it does not have something; move long-running threads into a maintained doc because one tracking chat had grown to 434 messages; and name the number that would settle an open decision because the audit showed I close decisions once a number exists and keep circling the ones without one. On the first non-holiday weekday after each quarter closes, a scheduled task emails me to request the export while I am at my desk. Scheduled checks later that day pick up the export and run the whole pipeline from a written runbook. I backfilled Q1–Q3 2026 to start, and Q3 alone covered 151 conversations and 2,922 messages. Step-by-step: 1. I started from The Rundown’s AI Audit prompt. 2. I requested my Claude data export and automated the process of finding the export email in Gmail, downloading it through Claude in Chrome, and unzipping it through the desktop app on my machine. 3. I condensed the conversations, split them by month, and used Sonnet subagents to extract structured notes from each month. 4. I used an Opus subagent to synthesize the monthly notes into a quarterly report. Each finding must cite at least three conversations across at least two months, include the strongest counter-evidence, and be labeled OBSERVED or INFERRED. Thin evidence is reported as “insufficient evidence.” 5. I had Claude write the results to a Google Doc with Reports and Progress tabs, including footnoted quarterly reports, cross-quarter comparisons, Stop / Start / Continue / Change recommendations, and a Cross-domain pass. 6. I challenged findings I disagreed with and stored those corrections in the doc and in the versioned prompt, now v1.1. 7. I had Claude use the latest audit and its stored memory about me to rewrite its project instructions, including rules about checking connected sources, maintaining long-running threads in a doc, and naming the number that would settle an open decision. 8. I scheduled the export request for the first non-holiday weekday after each quarter closes, then used scheduled checks and a written runbook to run the pipeline. 9. I backfilled Q1–Q3 2026, with Q3 covering 151 conversations and 2,922 messages. 10. To build your own version, add the evidence rules and OBSERVED/INFERRED labels, split the work into inexpensive monthly extraction and one strong synthesis, write the output to a living doc instead of a chat, and make the final step “rewrite your instructions for me.” That turns the audit from a report into a feedback loop.

My basement radon fan was pulling outside air down an outdoor stairwell floor drain, which weakened the suction under the slab. I didn't know what part would fix it, so I worked through the problem with my AI assistant, Grok Bot. At first, I asked for "a drain plug that lets water through but keeps air out," and it suggested general waterless trap seals. Once I explained that the drain runs under the slab to the radon fan, it changed its answer to a part made for radon systems: a retrofit floor drain seal with a weighted valve that opens for water and stays shut against the fan's suction. I sent photos of the drain with a tape measure in the shot. Grok Bot asked about the pipe size, the bowl width, and how far the pipe drops straight down, then confirmed that the seal would fit my 2-inch pipe. It compared three suppliers and helped me complete the checkout. We passed control of the screen back and forth to fill in the forms, and it showed me the full total before anything was charged. Apple Pay didn't work from its computer, so we switched to PayPal. I signed in and approved the payment myself. The part cost about $30, or under $50 with shipping and tax, and it arrived within a week. Afterward, I had Grok Bot turn the whole exchange into a slide deck containing the photos, its questions, my prompts, and the checkout back-and-forth. I used that deck to train my facilities leadership team. My point was that you don't need to be a tech person to do this: take a picture, explain the problem the way you would to a coworker, answer the assistant's questions, and stay in charge of anything that costs money. Step-by-step: 1. Describe the problem in plain language, including why it matters—in this case, the radon fan pulling air through the drain. 2. Send photos with a tape measure in the shot for sizing. 3. Answer the assistant's follow-up questions instead of guessing at part numbers. 4. Ask it to compare suppliers with links and prices. 5. Let it fill in the checkout, but review the total and approve the payment yourself. 6. Have it turn the conversation into a slide deck to train others. My first description was too vague and produced a generic answer, so I learned to provide the full context up front. Payment methods that depend on your phone, such as Apple Pay, may not work when the assistant is checking out on its own computer. Since this drain is outdoors, check the valve after hard freezes and leaf fall.

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 built a module that runs in MagicMirror on a Raspberry Pi and displays a real-time to-do list on a television in my office. Claude does an admirable job managing my daily task list, which is stored in `TASKS.md` on my local computer. I wanted an at-a-glance dashboard showing everything I have in progress, sorted by priority and synchronized with that file. I described the goal to Claude Code. Since I already had an old Raspberry Pi 3 and an off-the-shelf widescreen TV in my office, Claude Code suggested running MagicMirror on the Pi and Syncthing on both the Pi and my local computer to keep the file updated. Claude then built the MagicMirror module to read `TASKS.md`. After a few tweaks to remove the default modules and clean up the spacing between items, the display was up and running. I set MagicMirror to start automatically when the Pi boots, so now my to-do list is in front of me all day. Step-by-step: 1. I identified the need for a real-time, at-a-glance view of my prioritized tasks, which were stored in `TASKS.md` on my local computer. 2. I described the goal to Claude Code and told it about the Raspberry Pi 3 and widescreen TV I already had in my office. 3. I followed Claude Code’s suggestion to run MagicMirror on the Pi and Syncthing on both the Pi and my local computer. 4. Claude built a MagicMirror module that reads `TASKS.md`. 5. I removed the default MagicMirror modules and adjusted the spacing between items on the screen. 6. I configured MagicMirror to start automatically when the Raspberry Pi boots.

I connected ChatGPT to Metricool to get more personalized analytics on how our social media is performing. This workflow is for anyone who manages social channels and wants to see which posts work best on each platform before writing the next batch. Step-by-step: 1. I connected ChatGPT to my Metricool account. 2. I used ChatGPT to analyze social media performance, including which posts were performing best on each platform. 3. I used those results to develop better-performing posts for each platform. 4. Once ChatGPT was trained on my style and content calendar, I automated it to create and schedule posts at optimal times.

I used Astra to redesign my personal wardrobe. I want to dress better, but my absolute worst nightmare is having a closet full of clothes that creates more clutter in my brain. I already have enough to think about, so I built an app that decides what I should wear based on the season and local weather using GPT-6 Astra. I gave it a few full-body photos, my height, weight, sizes, and niche details such as having broad shoulders and needing to tailor my waist. I also shared the colors I like, added a master prompt, and asked it to build a site. The results were incredible. I'm the model in every photo, and Astra's virtual try-on is genuinely impressive. If I can't find a piece online, I update the model and regenerate the pictures. Step-by-step: 1. I opened ChatGPT desktop with GPT-6 Astra and Codex/Sites, then turned on Computer Use and image generation. 2. I started a new chat and uploaded four to eight full-body photos, one clear face photo, and closet photos when available. 3. I pasted the prompt below, filled in my name, city, and sizes, and let it work for one to two hours. 4. I sent a couple of correction passes instead of rebuilding the whole system. I removed things I would never wear and added things I actually wear. PROMPT: GOAL Build a working website called [YOUR NAME]'s Wardrobe. It blends two things: 1) A closed uniform system of exactly 30 looks 2) A personalized shopping portal where I am the model in every photo, Aritzia/Uniqlo catalog quality (seamless studio backdrop, full-body try-on, product-card grid) SITE NAME [YOUR NAME]'s Wardrobe THE ONLY INVENTORY - 7 summer outfits - 7 fall outfits - 7 winter outfits - 7 spring outfits - 1 gym outfit - 1 lounge outfit = 30 looks. Nothing else. Each look is complete: top + bottom or one-piece + shoes + at most 2 extras. Reuse pieces across the 7 looks in a season. Cap unique garments at 35–50 including shoes and outerwear. Throw everything else out. WHO I AM - Name: - Lives: [city] - Height: - Weight: - Sizes (top / bottom / shoe): - Body notes: - Work dress code: - Weekend life: - Style in 5 words: - Colors that work / colors I refuse: - Budget for gap-filling buys: - Hard constraints: Attached photos are the identity lock. Reproduce my real face AND real body in every try-on. Do not slim, lengthen, or beautify me. LIVE WEATHER (required, not a mock) On every page load, fetch live weather for [CITY] from Open-Meteo with no API key. Use the correct lat/long and timezone. Show on the homepage: - “Today in [CITY]” - apparent temperature, condition, rain yes/no - ONE recommended look from the 30 - why that look won - 1 weather swap (if rain starts / if it drops 5°C) Selection logic: - apparent temp ≥ 20°C and dry → Summer pool - 15–19°C dry → Spring pool Mar–May, Fall pool Sep–Nov, otherwise the closer season - 8–14°C → Fall pool, prefer the look that already includes a mid-layer - ≤ 7°C → Winter pool - rain now or daily precipitation ≥ 1mm → jacket + closed shoes, no white sneakers or silk - wind ≥ 25 km/h → prefer a layer - gym / lounge days use those uniforms, add a layer only if ≤ 10°C Never invent an outfit outside the 30. SITE STRUCTURE - Home: today + try-on + wear-this checklist - Summer / Fall / Winter / Spring: 7 look cards each, me wearing the full look - Gym / Lounge - Pieces: every unique garment on me, marked OWNED or BUY - Purge: sell / donate / trash for anything not in the system - Rotation: 4-week calendar per season. Weather can override, but it still has to be one of the 7 (or gym/lounge) VISUAL BAR Premium catalog photography. Gray/white seamless, even light, full body. Do not clone another brand’s logo. This is [YOUR NAME]'s Wardrobe. HOW TO BUILD Step-by-step: 1. Build the 30 looks from my photos, stats, climate, and closet photos. Use owned pieces first. 2. Generate consistent try-ons of me for every look and every piece. 3. Build a real clickable site. Hook live weather. Do not fake it. 4. If an image breaks my face or body, regenerate it before shipping. 5. No payments. Personal wardrobe OS only. OUTPUT Live site, the 30 looks, piece list (owned vs buy), ranked shopping list, purge list, weather mapping, and what you inferred vs what came from my photos. Start now. Make the call if a detail is missing. Only ask if the photos are unusable.

I build, test, ship, and promote an iPhone and iPad reading app with Claude Code agents, each with a specific job. I wanted a reader for my own PDFs and EPUBs where I could write notes in the margin next to the line they belonged to. Nothing I tried did that well, so I built Helicon, a free reader for iPhone and iPad. I use it every day. I do not write most of the code by hand. I run several Claude Code sessions, each with one responsibility. A development session builds the app in Swift. A marketing session reads the usage numbers and finds places to tell people about the app. A separate designer agent, which did not draw the screens, chooses between two or three prototype variants before any UI change is built. Read-only reviewer agents check finished work against the goals I wrote at the start. The part that made this work is turning every mistake into a check rather than a note. When an agent gets something wrong, we turn the lesson into a test, script, or guard that prevents the same bad step next time. For example, the post script reads the community rules again before every post and stops if they have changed. Today, the app lets me hold the margin so a pin drops beside the line. The pin opens a note that I can type or write with Apple Pencil. Review brings notes back days later, next to their lines. The app also includes dark page themes and a speed-reading guide. Listen, which reads the book aloud with on-device voices, is currently in testing. Step-by-step: 1. I wrote down the goals in plain language: installs, people opening a book, minutes read, and the number of days they return. 2. A development session builds each feature test-first and runs the iOS test suite on a simulator before every push. 3. Before any UI change, the agent draws two or three variants. A designer agent that did not draw them chooses one and explains why. 4. I send each build to TestFlight for a small group of testers. 5. A marketing session reads the PostHog numbers every two hours and tries a new channel whenever a round is flat. 6. I send feedback from posts back to the development session as to-do items. 7. I encode every mistake as a test, script, or guard so it does not happen twice. 8. I keep the irreversible steps for myself: App Store submissions, prices, accounts, and deploys wait for my approval. Helicon on the App Store: https://apps.apple.com/app/apple-store/id6811677202?pt=125973633&ct=rundown&mt=8 Built with help from AI coding tools.

In my ongoing mission to go paperless, I created a web app that runs on tablets and replaces paper sign-in sheets. The admin console gives HR instant visibility and detailed reporting on employee and guest attendance across all our branches from a single pane of glass. In Phase 2, I’m expanding the app to eliminate even more paperwork by allowing employees and managers to request, approve, and manage PTO. Department calendars show everyone’s PTO balance and minimum coverage requirements. Step-by-step: 1. I created a web app that runs on tablets to replace paper sign-in sheets. 2. I added an admin console so HR can view and report on employee and guest attendance across all branches. 3. In Phase 2, I expanded the app to support employee and manager PTO requests, approvals, and management. 4. I added department calendars showing PTO balances and minimum coverage requirements.

I built Lumi, an HR assistant in French, with Claude Code in about two hours. It was an experiment: could Claude Code build a working product from a plain brief while being left completely alone? Employees ask questions, and Lumi answers using their company’s own HR documents. Each company has its own space, and HR can see which questions the documents couldn’t answer. Step-by-step: 1. I set up one window with Claude Code on one side and the files appearing on the other. I didn’t write code, but I could always see what was being built. 2. I described the product in plain language. I dictated my brief out loud, typos included: who pays, who uses it, the problem, a demo client, keeping clients separate, the admin view, the language, and the price. 3. I let Claude Code build the product and make every call. Thirty-four minutes later, the first version had 47 files and 3,949 lines. It even invented a fictional client company with a full HR handbook so I could demo it immediately. 4. I put the product online. Claude Code wrote a setup guide for Supabase and Vercel. I followed it one step at a time and sent a screenshot whenever something broke. 5. I improved it with feedback. I told Claude Code that the design looked like it had been created by a junior designer. Eighteen minutes later, it came back with a name, a design system, pricing plans, and everything in French. 6. I checked security, although I had skipped this during the build. When I asked for a full security review eleven weeks later, it took less than six minutes and found three serious problems, including a database function that allowed anyone to read a company’s documents. Claude Code fixed all three. Run `/security-review` before sharing the link and before each new change. The full write-up, including the unedited prompts: https://www.theaithinker.com/p/how-to-build-a-saas-product-with

Mid- and end-of-year self-evaluations used to cost me a week or two of reconstructing a year of work from memory. I rarely recorded or remembered the “small things,” and I couldn’t easily explain how my daily work connected to our goals. People often forget their most impactful work months later, so I wanted continuous capture instead of annual reflection. I also wanted my work goals and development plan grounded in real evidence rather than guesswork. I built an “Achievement Collector” agent as a sub-agent of my Chief of Staff agent. When my Chief of Staff agent recognizes something important, it formats the accomplishment into an Achievement record, asks whether I want to record it, and sends it to the Achievement Collector agent. SharePoint is the system of record, with fields including Details, Business Impact, Key Insights, Related Goal, Significance, and a flag for accomplishments I’m especially proud of. A Power Automate flow lets me log an accomplishment conversationally instead of filling out a form. A Copilot Studio agent sits on top of the list and reads three work-goal documents—mine, my manager’s, and my director’s—so it can map each accomplishment up the chain. Its instructions tell it to prioritize what I’m proudest of, group work into themes, surface business impact, and never invent anything. The result is that my self-evaluation and goal-progress summaries are now queries against real records instead of writing projects. If you want to build one, start with the data-list fields: capturing impact and insight at the moment of the work is what makes everything downstream possible. The combination of my Chief of Staff agent and Achievement Collector has made work a lot more fun for me and turned me into a laser-focused employee. Step-by-step: 1. I created an “Achievement Collector” agent as a sub-agent of my Chief of Staff agent. 2. I configured the Chief of Staff agent to recognize important work, format it into an Achievement record, ask whether I want to save it, and send it to the Achievement Collector. 3. I created a SharePoint list as the system of record, with fields for Details, Business Impact, Key Insights, Related Goal, Significance, and a flag for accomplishments I’m especially proud of. 4. I used Power Automate to let me log accomplishments conversationally instead of filling out a form. 5. I placed a Copilot Studio agent over the SharePoint list and three work-goal documents: mine, my manager’s, and my director’s. 6. I instructed the Copilot Studio agent to map accomplishments up the goal hierarchy, prioritize what I’m proudest of, group work into themes, surface business impact, and never invent anything. 7. I now query the accumulated records when creating self-evaluations and goal-progress summaries instead of reconstructing my work from memory.

Drop the task that’s still eating your time, or the thing AI keeps getting wrong for you. Your answers help decide what we teach next 🙌