Workflow Hub

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.

I run product for Contentstack Canoe at Contentstack, and I use it on our own brand every week. Buyers ask AI what to buy before they ever reach a site, and most teams have no idea what those answers say. You add your domain, it drafts your brand profile and the questions your buyers actually ask, then asks each engine with web search on. The free plan covers ChatGPT and Gemini. Every Monday I open the report and look at three things: how often we're named, which competitors win the questions we lose, and which sources the engines cite. Then I take the top recommendation and fix just that one thing, usually a page AI crawlers can't read or a comparison page we never wrote. On the paid plan I also hook it into Claude through the MCP server, so I can ask "what changed this week and why?" in plain English. Next I want to add Microsoft Copilot and Google AI Mode, and see which AI agents actually read our pages.

The problem: I’m on the customer side, not the engineering side. When something breaks, I usually find out when a customer writes in, and by then a bunch of people have already hit it. We had an error chart in our analytics tool, but I don't often remember to check that dashboard every day, and a basic “alert me over X errors” setup would go off constantly for things that aren’t real problems. What I built: A Claude scheduled task that checks our error chart every morning, filters out the noise, and tells the whole team in Slack only when something’s actually wrong. I set it up just by describing what I wanted in plain English. How it works: Runs every morning before the team starts and looks at the full previous day. Pulls errors by type straight from our analytics tool. Claude connects to it directly, so it sees the same data as the dashboard. Ignores the noise. I gave Claude the rules on which error types are real problems and which aren’t, and it only counts the ones that matter. Checks a threshold. If the real errors go over the number I picked, it posts. Otherwise nothing happens. Posts one clear alert in a shared Slack channel with the total, which errors spiked, and a link to the chart. Never repeats itself. It checks the channel first so the same day never gets flagged twice. Why it’s worth it: I hear about issues before customers have to tell me. Everyone sees the same alert at the same time, so there’s no relaying messages or chasing people down. The right person just picks it up. Quiet days stay quiet, so when an alert shows up, people pay attention. I tested it against the past couple of weeks. It flagged every day something really broke and stayed silent on a busy day that was all harmless errors.

Part 2 of my workflow for taking an AI-built prototype off the vibe-coding platform that created it. I wrote it so I could build, run, and recover the app without reopening that platform. It covers AI app-building platforms only, and I work from what the application actually uses, since some apps need a backend migration and others need only configuration changes. 1. Map every dependency before disconnecting anything. I start with the repository, then check where users sign in, where records and files live, and what sends email, runs scheduled work, or handles payments. For each dependency I decide to keep, move, replace, or retire it, and I record where credentials are managed, not their secret values. 2. Preserve the working version and choose a release candidate. I record the accepted commit, build, and configuration, and keep a recovery copy the builder cannot change or delete. I finish or stop builder edits, confirm what reached the repository, and name an owner for each release decision. 3. Rehearse the destination without activating production. I build the candidate in an isolated environment with test data, and I check whether connecting a repository or merging triggers a deploy. Then I exercise the app on the destination before moving anyone. 4. Move only what needs to move. If the backend stays, I verify access and compatibility. Where needed, I plan pauses for writes, jobs, and incoming events. I check identities, files, and permissions separately. 5. Release the tested version and verify real behavior. I confirm the candidate and recovery plan, switch traffic through the rehearsed path, then test the production address: refresh pages, sign in, create and read back a controlled record, and confirm unauthorized users are blocked. 6. Plan recovery for new activity. Restoring old code does not undo new emails, payments, or database writes, so before release I define when rollback is safe and when I must reconcile instead. 7. Retire old connections and update the rules. After verification and the recovery window, I remove obsolete sync, credentials, and jobs, check shared integrations, confirm billing before canceling, and update the instructions for the next change. The goal is an app I can build, run, and recover from accounts I control, with any remaining platform dependency recorded honestly. The full Platform Detachment Runbook and checklists are at https://github.com/wildeyeai/ai-builder-playbook Part 1 is here: https://app.therundown.ai/community/posts/f1c34207-edc7-4b42-9252-3609d5edbfb7

I use this when I review code for pull requests. Claude breaks the code into relevant sections and presents them in execution order instead of the alphabetical file order GitHub shows, which makes it easier to reason through the logic. 1. Have Claude break the PR into relevant sections, ordered by how the code executes. 2. Have Claude export the walkthrough as a markdown version of the PR diff report. 3. Paste the markdown into ChatGPT. 4. Enter ChatGPT voice mode and talk through the report with it. 5. As I read each section of the code, ask ChatGPT for a summary of that section. 6. Ask questions about the code, the logic, or the story's acceptance criteria to get a deeper understanding of what I'm reviewing. The result is a PR review that follows the code's actual flow, with a spoken walkthrough and section summaries I can check against the code as I go.

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. Download The AI Builder Playbook on GitHub: https://github.com/wildeyeai/ai-builder-playbook

If you've spent any time looking for a nsfw ai chat platform, you already know the problem: the search results are full of sites that promise uncensored conversation and then hand you five free messages, a paywall, and a chatbot that forgets your name the second you close the tab. This is the short version of what I found after testing adult AI chat platforms for several months, written for people who want to pick one account and stop cycling through trials. What actually matters in an adult AI chat platform Every nsfw ai chat service claims uncensored responses, character creation, and image generation. The differences show up in the details. Memory is the first. A companion that remembers a running conversation and the small details of your persona feels completely different from one that resets every session. Test it before you pay: talk to a character for twenty messages, come back later, and ask what you talked about. If it has no idea, that's the product you're buying. Censorship limits are the second. "Uncensored" means different things on different sites. Some allow explicit roleplay but block suggestive image requests. Others allow images but water down the chat. Test both paths on a free account before committing. Image quality is the third. Adult AI image generation has improved enormously, and a platform that generates good images inside the same chat thread beats one where you have to use a separate generator. Finally, pricing. Token packs, monthly plans, and coin systems all hide the real cost differently. Compare the monthly cost of a plan you would realistically use. The options worth considering in 2026 Candy AI is the platform I keep coming back to. It combines uncensored chat with image generation in one account, characters stay in persona across long conversations, and memory carries context forward so ongoing roleplay feels natural rather than disjointed. There's a free tier to judge chat and images before paying: candy.ai Other categories worth mentioning: open companion platforms offer big character libraries but vary wildly in what they allow; specialized image generators produce better visuals but usually have no real chat model; and bare-bones chat sites can be cheap but have short memories. How I test each platform I use the same five prompts everywhere so results are comparable: a straightforward companion chat, a roleplay scenario, an image request, a memory test after twenty messages, and a boundary test to find where the limits sit. Every platform has limits, and knowing them before you pay beats discovering them after. I score each platform from one to five on chat quality, image quality, and value, plus a note on where censorship lines fall. Good chat with weak images is fine if you only want conversation, and vice versa. Common mistakes Judging a platform from its marketing page is the biggest one, since those screenshots are made for the landing page. Buying an annual plan during a short trial before testing memory and images is the second. Ignoring privacy and billing practices is the third, and it matters more in this niche than in almost any other software. Picking one platform and giving it a real month usually beats hopping between ten trials. Where to start Candy AI is the easiest place to begin because it covers both uncensored chat and AI image generation in one account: candy.ai Run the five tests on the free tier, then decide whether to pay. If images matter more, look at a dedicated adult image generator first. If long-running roleplay matters more, test memory across several sessions before committing. Either way, compare your pick against a second option with the same prompts. The difference shows up fast. A final note on safety: use a separate email for adult accounts, avoid reusing passwords, and read the billing terms before subscribing. If a platform wants more identity information than you're comfortable with, walk away. The best nsfw ai chat experience is the one you enjoy without wondering where your data went.

I run nine AI agents on one VPS, each named after its job, with 65 scheduled tasks between them. Most of those tasks never call a model. This is for anyone who wants AI working in the background. 1. One agent per job, not one for everything. Each has its own directory and credentials file, so revoking a compromised one costs one service, not the estate. 2. Write the work as a schedule, not a prompt, using five field cron. "0 3 * * *" backs the fleet up, "0 6 * * *" runs the security scan, and "0 23 * * *" mines the day's session logs. Interval jobs cover the rest, every 15 minutes for the watchdog. 3. Pick the delivery target at creation time: a Discord channel, email, or a local file. Mine go to a channel per officer, so a failure is a message I see and a quiet job is one I stop noticing. 4. Attach a skill instead of pasting a paragraph. Each job loads a skill file with the procedure, pitfalls and exact commands, kept in version control instead of a prompt I edit by accident. 5. Use a plain script when the answer is deterministic. My watchdog is a shell script on a 15 minute interval that checks disk, memory and failed units and pipes the result to the channel. It has run 13,752 times with no tokens and no model. 6. Put a guard in front of the tools. A hook runs before every tool call and refuses secrets in a chat message, deletes without approval, and invites accepted on my behalf. 7. Count your jobs monthly. I have 85 defined and 65 enabled. A disabled job is a plan; an enabled job is a contract that should be able to say what it can reach. The boring half of running a small estate happens without me, the interesting half still gets my attention, and it runs on a VPS I already paid for. The skills are public at github.com/ciberjohn/Hermes-Skills. The agents were never the expensive part. My attention was.

Every Friday at 10 a.m. ET, a scheduled Claude agent refreshes a living "Hevy Workout Log" document with that week's strength-training data, body measurements, and a progress photo. The automation runs fully unattended, with no human in the loop after the owner sets it up. The agent pulls information from three independent systems: the Hevy fitness-tracking API, a Google Drive photo folder, and the living document. It reconciles those sources against a date range, determines what's new versus already recorded, and writes structured, formatted updates in the correct places. This requires more judgment than a simple script or webhook. The scheduled task starts a fresh agent session every Friday at 10 a.m. ET with the full task specification and API key included in the prompt. The Hevy API is the source of truth for workouts from `GET /v1/workouts` and body measurements from `GET /v1/body_measurements`; both endpoints are paginated. Google Drive holds the "Progress Pics" folder, which the agent searches by file timestamp. Claude Docs, through a Claude Artifact, is the living document: it has one tab for each weekday and a Weekly Summary tab, and the agent edits it in place with structured operations rather than full rewrites. To embed a photo, the agent downloads the Drive file locally, uploads it to the Claude Artifact asset store, converts it to a document-native blob, and references it as a Markdown image. There is no custom backend, database, or glue code. The agent calls each system's API directly and keeps the orchestration logic in its reasoning for that run. Step-by-step: 1. Read the document's current state and find the most recent week already recorded in the Weekly Summary tab. 2. Call the Hevy API and determine which Monday–Friday week has just ended, making sure today's date is past that week's Friday. 3. Check whether that week's row is already in the Weekly Summary table, fully populated, and contains the latest matching photo. If everything is already recorded, there may be nothing to update, but the agent still checks for a newer photo that may have appeared in Drive after the data was written. 4. Pull per-set details for every workout that week, including the exercise, weight, and reps. Compute total daily lifted volume by summing weight × reps for each set on each day. 5. Search the Google Drive photos folder for images timestamped within that Monday–Sunday window. Select the single most recent image, replacing any older photo already embedded for that week. 6. Pull body measurements from the same week and calculate weekly averages for weight and body fat, along with the week's waist reading. Convert units as needed from kilograms to pounds and centimeters to inches. 7. Update the Weekly Summary tab with one row per week, including daily volumes, weekly averages, and the progress photo. 8. Update each weekday tab with a dated section containing the workout name, a per-exercise set-by-set table, and a Total row for summed volume and reps. If no workout was logged, add a note instead. 9. Send the human a plain-language summary every time, describing what changed or confirming that nothing changed, because nobody is watching the scheduled run live. The workflow is idempotent without a database. There is no job-tracking table; on each run, the agent reads the live document, compares dates, and checks whether cells are filled before deciding what to write. Progress photos are not tagged by week, so the agent matches them only by whether their Drive timestamp falls within the Monday–Sunday window. It explicitly selects the most recent match, allowing a better photo taken later in the week to replace an earlier embedded photo. The workflow also handles the multi-hop process required to embed an image in a live document: Drive file to local download, artifact asset upload, document-native blob conversion, and Markdown image reference. If the Hevy API key is revoked, the task stops cleanly and tells the owner to generate a new key and provide it, rather than failing silently or looping. Because the workflow runs on a schedule without anyone watching, its specification requires a notification every time, including when nothing changed. This keeps the automation auditable even when it performs no updates.

I’m 78, and I run a homestead, a home server, and a senior center, with dozens of jobs underway at once. Most jobs get done a piece at a time, while to-do apps only track whether something is “done” or “not done.” So I built Taskmaster: a plain-text ledger inside a Claude Project. I first tried building a large custom app, then scrapped it. One of my own rules is, “Build the ugly version first.” In the field, I speak notes into the Claude app on my phone. Claude saves my exact words, updates each job’s progress, and asks me one question at a time when something is unclear. When I ask, “What’s next?” it considers deadlines, weather, and my energy level, then gives me one to three things to do. Anything tied to a specific time goes on my Google Calendar. Home Assistant then reads the reminder aloud through my hearing aids. Today, it checked the forecast and scheduled my paint job for the one day this week that stays above 50°F overnight. The machine carries the complexity, so I don’t have to. Step-by-step: 1. I keep each ongoing job in a plain-text ledger inside a Claude Project. 2. When I’m in the field, I speak notes into the Claude app on my phone. 3. Claude saves my exact words, updates each job’s progress, and asks one question at a time when something is unclear. 4. When I ask, “What’s next?” Claude weighs deadlines, weather, and my energy, then gives me one to three tasks. 5. I put anything with a specific time on my Google Calendar. 6. Home Assistant reads calendar reminders aloud through my hearing aids. 7. For example, Taskmaster checked the forecast and scheduled my paint job for the one day this week that stays above 50°F overnight.

Like many people, I had tasks scattered across emails, meeting notes, reminders, recurring responsibilities, and things I was simply trying to remember. Standard task managers helped me store tasks, but they did not solve the harder problem: turning unstructured information into a reliable daily and weekly execution system. I used ChatGPT Work and Codex to build a private, responsive task management application around the way I actually work. The system combines AI-assisted task capture with a Command Center, daily planning, weekly reviews, task lists, a Kanban board, recurring tasks, deadline reminders, search, filters, subtasks, comments, attachments, and a complete activity history. The most useful part is the connection between AI and execution. Emails and free-text descriptions can be interpreted with the OpenAI API and converted into structured tasks, reducing the amount of manual copying and organizing required. Step-by-step: 1. I mapped my real workflow by identifying where my tasks came from and what information I needed to manage them properly: title, description, status, priority, category, deadline, responsible person, subtasks, comments, attachments, recurrence, and activity history. I deliberately designed the system around my existing working habits rather than adapting my work to a generic task management template. 2. I used iterative conversations with ChatGPT Work and Codex to define the requirements, review the interface, build the application, test it, and refine individual functions. Instead of creating one enormous prompt, I worked in short cycles: describe a problem, implement the change, test it with real data, and improve it. 3. I built the application as a responsive web app that works across computers, tablets, and phones. Access is restricted through authentication, an approved-user allowlist, and server-side authorization because the system contains real personal and professional tasks. 4. I migrated my actual task history rather than starting with an empty demonstration: 238 tasks, 37 categories, 25 subtasks, 5 comments, and 671 activity records. I preserved invalid or disconnected historical records in a separate archive instead of silently deleting them. 5. I connected the application to the OpenAI API. The AI can interpret emails and free-text task descriptions and help turn them into structured, actionable tasks. The application also supports an email-to-task workflow, so actionable emails do not have to remain buried in the inbox. 6. I built a daily Command Center that gives me an overview of what requires attention, including deadlines, priorities, task status, and upcoming work. I use the daily planning view to decide what to focus on rather than simply working through the newest emails. 7. I added two complementary execution views. The task list is useful for searching, sorting, and filtering a larger number of tasks. The Kanban board gives me a visual overview of progress; tasks can be dragged between five status columns, and the new status is saved automatically. The default task list shows the newest tasks first, making newly captured work easy to find. 8. I kept the context inside each task by allowing every task to contain subtasks, comments, attachments, and a complete activity history. This keeps the reasoning, follow-up, and progress connected to a task instead of spreading them across several applications. 9. I automated recurring work and reminders. Recurring tasks are recreated according to their schedule, while deadline reminders help surface tasks before they become overdue. This is particularly useful for responsibilities that are important but easy to forget because they do not arrive as new emails. 10. I run a weekly review to check overdue work, upcoming deadlines, open commitments, and tasks that have stopped moving. I can then reprioritize, update statuses, and prepare the following week from the same system. 11. I preserved portability and control through Excel import and export and a full JSON backup. This gives me control over my information and reduces the risk of becoming dependent on one interface or platform. The result is not an autonomous agent making decisions on my behalf. It is a private execution system where AI handles part of the interpretation and structuring, while I remain responsible for priorities and decisions. It has given me one trusted place for capturing, reviewing, prioritizing, and completing work. The tools I used were: - ChatGPT Work - Codex - OpenAI API

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 kept rereading the same Stoic books to find one line I half remembered. So I stopped reading them and started talking to them instead. I took public-domain writing from 13 people—including Marcus Aurelius, Seneca, Sun Tzu, Jane Austen, Tesla, and others—and gave each one its own AI persona on a single page. Each persona answers only from that person’s writing and says when it does not know. There are no made-up quotes. The fun part is seeing the questions people actually ask. The top question this week was: “How do I stay steady when someone wastes my morning?” That is a real problem answered by a Roman emperor who faced the same one. Full disclosure: I am the founder of Mindola, the tool I used. The 13 classic lenses are free to try with no signup: https://mindola.ai/discover Step-by-step: 1. I gathered public-domain writing from 13 people, including Marcus Aurelius, Seneca, Sun Tzu, Jane Austen, Tesla, and others. 2. I created a separate AI persona for each person and put all 13 on one page. 3. I configured each persona to answer only from that person’s writing and to say when it does not know. 4. I use the personas to ask questions I would otherwise search for by rereading the books. 5. I review the questions people ask, including “How do I stay steady when someone wastes my morning?”

I built a website that turns property photos, architectural renderings, or even just an address into cinematic property videos. I’m a civil engineer and photographer/videographer, not a software developer, so I used ChatGPT, Gemini, and Claude Code to help build the site and work through problems as they came up. Much of the process involved translating the way I would personally edit a real estate video into usable software. For example, kitchen and living room shots should usually stay together and have longer durations, bedrooms should stay near their bathrooms, an opening shot should feel different from a detail shot, and every clip should include some movement so the result does not feel like a generic slideshow. I used AI to turn those editing principles into actual logic for the site. The system analyzes and organizes the images, builds a storyboard, ranks scenes to decide which ones to use, creates prompts for video models, generates the clips, and assembles everything into a finished video. Most of the development has been iterative. I test the site with real properties I’ve shot, watch the results, identify what feels off, and then improve the prompts, scene planning, timing, or video assembly process. AI has been useful for much more than generating the final video. I’ve also used it to write code, troubleshoot errors, plan features, improve the user experience, and think through how the product should work from the perspective of its primary user. Step-by-step: 1. I defined the video-editing principles I use for real estate footage, including grouping related rooms, varying shot durations, distinguishing opening shots from detail shots, and adding movement to every clip. 2. I used ChatGPT, Gemini, and Claude Code to translate those principles into software logic. 3. I built the site to accept property photos, architectural renderings, or an address as input. 4. I had the system analyze and organize the images, build a storyboard, rank scenes, and select the footage to use. 5. I used AI to create prompts for video models and generate the clips. 6. I assembled the generated clips into a finished property video. 7. I tested the site with real properties I had shot, reviewed the results, and iteratively improved the prompts, scene planning, timing, and video assembly. 8. I used AI throughout development to write code, troubleshoot errors, plan features, improve the user experience, and think through the product from the primary user’s perspective.

I built a Custom GPT Prompt Engineer to make the build phase more efficient. Instead of generating a result immediately, it helps transform ideas, business requirements, and objectives into production-grade ChatGPT prompts. The assistant is coached to operate as an expert prompt engineering partner. Its primary mission is to help produce consistently accurate, thorough, and useful results from ChatGPT. Its seven core responsibilities are: Step-by-step: 1. Understand the objective before writing by asking targeted clarification questions. 2. Ask questions one at a time instead of overwhelming the user with a questionnaire. 3. Never assume missing information; ask for clarification when something is unclear rather than inventing details. 4. Engineer structured, high-quality prompts that include: - Role assignment - Task and objective - Relevant context - Detailed instructions - Expected output format - Constraints and guardrails - Examples when beneficial 5. Minimize hallucinations by instructing ChatGPT to distinguish verified facts from uncertainty, avoid unsupported claims, and never fabricate information. 6. Deliver enterprise-ready prompts that are professional, clear, actionable, formatted in Markdown, and generally under 3,000 characters. 7. Validate and refine each prompt by checking its completeness, ambiguity, consistency, and alignment with the requirements, then refine it based on feedback. The key difference is that the assistant engineers the instructions that produce the result rather than simply generating the result itself. For example, if I say, “I want ChatGPT to analyze my business and identify growth opportunities,” it does not immediately generate a generic business analysis. Instead, it helps construct a reusable prompt that specifies how ChatGPT should perform the analysis, what evidence it should use, what questions it should ask, and how it should present its findings. Its governing principle is: Clarity + Context + Constraints + Structure + Verification = A stronger prompt. The operating instructions also direct it to reference the Custom GPT Prompt Engineer – System Prompt document and check its work against that document’s guidelines. Ultimately, it is designed to be a prompt engineering partner for business strategy, marketing, finance, operations, research, analytics, and other professional applications. I built it to bring more efficiency to the build phase and am continuing to look for opportunities to improve it. Step-by-step: 1. Create a Custom GPT and position it as an expert Prompt Engineering Assistant. 2. Instruct it to understand the user’s objective by asking targeted questions one at a time. 3. Tell it never to assume missing information or invent details. 4. Require each completed prompt to include a role, task and objective, context, detailed instructions, output format, constraints and guardrails, and examples when beneficial. 5. Instruct it to distinguish verified facts from uncertainty, avoid unsupported claims, and never fabricate information. 6. Set the delivery standards: professional, clear, actionable, formatted in Markdown, and generally under 3,000 characters. 7. Have it validate each prompt for completeness, ambiguity, consistency, and alignment with the user’s requirements. 8. Direct it to reference the Custom GPT Prompt Engineer – System Prompt document and use its guidelines when checking and refining its work.

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.

“Honey, do you remember where Ryan’s practice is? Do you remember our Wi-Fi password? Do you know my TSA PRE number? Remember who that painter was that we used last year?” If you have a family with children, you may hear questions like these all the time. In a large family, there always seem to be questions about the house, the kids, or technology that could be answered more easily. The information is usually stored in different places: password files, a Rolodex of business cards, or sheets of paper in junk drawers. I set out to build an app where anyone in my family could use voice to save something for the future or retrieve something they had already stored. I integrated AI to understand the meaning of each voice note. It might create a calendar event, store a password in a vault, or simply remember a phone number. Then anyone else in the family could access the information. The app uses multi-factor authentication for anything particularly secret. It is not intended to be a dedicated password protector; I would build in much more security if that were the goal. Instead, it is an everyday-life app for remembering the little things: How long is the warranty on this appliance? Which exact light bulbs did we use here last time? What was our daughter’s email address that we needed to set up on her phone? Being able to use voice to enter information or retrieve it was the key for me. I think that will save people time. As I started adding entries and validating the idea, my wife came up with the name. After a few weeks, I knew she was completely right, because I now use it about 10 times a day—and I hear that exact phrase every time. Step-by-step: 1. I identified recurring family questions about locations, passwords, identification numbers, contacts, warranties, and household items. 2. I built an app that lets family members use voice to save or retrieve information. 3. I integrated AI to interpret the meaning of each voice note and determine whether to create a calendar event, store a password in a vault, or remember a phone number. 4. I made the stored information accessible to other family members. 5. I added multi-factor authentication for information that is particularly secret, while keeping the app focused on everyday memory rather than dedicated password protection. 6. I added entries and validated the idea through regular use, eventually using the app about 10 times a day.

Most people use AI as a single general-purpose assistant. The problem is that every new conversation starts from scratch, while one AI constantly switches between roles such as researcher, writer, programmer, strategist, and editor. This often leads to inconsistent results and repeated prompting. Instead, I built a team of specialized AI agents, each with a single responsibility. By giving every agent a clear role, instructions, and context, I created reusable experts that become more consistent over time. Step-by-step: 1. I identified the different roles I needed, including researcher, writer, programmer, strategist, and editor. 2. I assigned each AI agent a single responsibility instead of asking one general-purpose assistant to handle every role. 3. I gave each agent a clear role, instructions, and relevant context. 4. I reused these specialized agents instead of starting every conversation from scratch.

AI agents are much more useful when they can remember important context across sessions. However, giving every agent access to one giant memory creates a different problem: irrelevant information accumulates, context becomes noisy, and agents waste time sorting through details that do not apply to their task. The challenge is not only giving AI memory. It is deciding what should be remembered, which agent should remember it, and where that memory belongs. I use a three-tier memory system that separates knowledge by scope: - Global memory: Information that should be available across the entire AI system - Agent memory: Knowledge specific to an individual specialist and how it should work - Project memory: Decisions, constraints, discoveries, and context that matter only within a particular project Instead of copying everything into every agent’s context, I store information at the narrowest level where it remains useful. Step-by-step: 1. Create a global memory layer for durable information that is useful across many agents and projects, such as important user preferences, shared conventions, and system-wide decisions. 2. Give each specialist its own memory. Store knowledge that helps a particular agent perform its role better, such as recurring preferences, domain lessons, and patterns learned from previous work. 3. Create project-specific memory for decisions, constraints, terminology, discoveries, current state, and other context that belongs with the project rather than in global memory. 4. Classify new information by scope. Whenever something worth remembering is learned, ask: - Does the whole system need this? - Does only this agent need it? - Does it matter only for this project? 5. Store the information at the narrowest useful level. Avoid promoting project-specific details into global memory unless they are genuinely reusable elsewhere. 6. Have agents load relevant memory before they work. A specialist can combine its accumulated knowledge with the current project context instead of starting every session cold. 7. Update memory as important decisions are made. Persist decisions and reusable lessons rather than relying on conversation history to remain available indefinitely. 8. Keep historical artifacts separate from active memory. Run logs, old handoffs, and detailed history can remain available for reference without automatically loading into every future interaction. Instead of treating memory as one giant bucket, I create a hierarchy: `Global → Agent → Project` Each agent gets the context it actually needs while unrelated information stays out of its working context. This provides better continuity across sessions, reduces repeated explanations, keeps context cleaner, and helps AI agents accumulate useful knowledge without requiring every agent to remember everything.