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.

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.

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 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.

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.

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.

I built a custom news agent that skips the Google News and Apple News walled gardens. Eight prompts turn Claude into a personal news editor that reads my trusted RSS feeds, scores every story with a decision model, and delivers a clean daily page for about a dime a month. Each week, pulling two or three good stories for my newsletter digest meant searching multiple sites by hand—hours of clicking and scrolling for a handful of usable links. RSS feeds already deliver that content; the missing piece was a judgment layer that could separate worthwhile stories from noise without the cost or latency of running everything through a full LLM. I used Claude Cowork, Jev from TypeSafe AI, Vercel AI Gateway, RSS feeds, Python, and SQLite. Jev is a decision model rather than a chatbot: it returns a probability and confidence score instead of prose, does not hallucinate facts, and scores a story in a fraction of a second. That makes an automated daily judgment call inexpensive enough to run continuously. Step-by-step: 1. I set up a Claude project to hold the scripts, taste guide, database, and page. 2. I defined the goal and sections, then had Claude interview me to create a short “taste guide” describing what counts as a good story. 3. I found and live-tested the RSS feed for each trusted source instead of guessing feed URLs. 4. I fetched all working feeds into a deduplicated SQLite database and logged failures. 5. I used Jev through Vercel AI Gateway to score every story: first filtering ads and promotions, then ranking stories by section against my taste guide. 6. I selected the winners for each section, with Jev identifying near-duplicate stories so they would not appear twice. 7. I generated one-line summaries and fact-checked them against the source so nothing was invented. 8. I rendered a simple HTML page and scheduled the entire workflow to run every morning. A few details matter. I used Cowork rather than a plain chat because several steps require Claude to work with files, run code, and access the network. I also created a Vercel account and AI Gateway API key manually before the scoring step. Finally, I saved everything to the Claude project instead of a local folder, which allows the morning run to happen in the cloud on its own schedule. Scoring costs roughly $0.10 per month with Jev, compared with a few dollars for a full LLM doing the same job. The workflow turns a two-hour weekly slog into a page that is ready every morning, with each link going directly to the original publisher rather than a Google or Apple aggregator. Full build walkthrough: onabetternote.substack.com/p/build-your-own-news-agent-with-claude — the Substack post includes the exact eight prompts to copy and paste, plus more detail on why a model like Jev matters for cost containment as agents become routine.

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.

I recently built a month-end close workflow in Awish for a client at a finance company. The problem was not creating the final report. The real bottleneck was collecting data from different systems, checking what was missing, reconciling totals, chasing exceptions, and getting the report to the right people. I built the entire process in Awish by describing what I wanted. Step-by-step: 1. I opened the Awish chat and wrote: “At every month-end close, collect journal entries, invoices, vendor bills, and financial records from NetSuite together with reporting workbooks from Excel and SharePoint. Check submission completeness, reconcile totals across sources, identify missing data or unusual variances, prepare the management-reporting workbook, send unresolved exceptions to Finance in Microsoft Teams for approval, and once approved export the final report to PDF, store it in SharePoint, and distribute it through Outlook.” 2. Awish understood the request, planned the workflow, and selected NetSuite, Excel, SharePoint, Microsoft Teams, and Outlook for the required steps. 3. I reviewed the plan, connected the client’s accounts, and approved the automation. 4. At month-end, Awish pulls the required financial data and reporting files, checks whether anything is missing, reconciles totals, and flags unusual variances. 5. It updates the management-reporting workbook and sends only the unresolved exceptions to the Finance team in Microsoft Teams. 6. Once Finance approves the exceptions, Awish finalizes the report, exports it to PDF, stores it in SharePoint, and sends it to the authorized recipients through Outlook. The useful part is that Finance no longer has to spend most of the close manually collecting and checking information before making a decision. The repetitive reconciliation work is handled automatically, while the team retains control over unexplained exceptions and the final report. Trigger → Analyze → Approval → Action Month-end close → Reconciliation \u0026 variance checks → Finance approval → Final report \u0026 distribution

At some point, my newsletters stopped feeling like reading and started feeling like debt. The information was good; I just couldn’t keep up. I wanted a way to turn that backlog back into something useful. So I built The Daily Nexus, a private tool that reads newsletters from a Gmail label and creates two editions: a podcast I can listen to and a separately written, two-page newspaper I can scan. It runs on demand or on a schedule, and it can publish the audio to a private RSS feed for Apple Podcasts. The project also became a hands-on experiment in building with coding agents. Claude Code and Codex helped me implement features, troubleshoot failures, review the design, and tighten security. The stack includes Python, the Gmail API, Antigravity, Kokoro, FFmpeg, Firebase, Cloudflare Workers, and GitHub Actions. The carousel shows the rest of the flow. It started as a personal tool, but I’m sharing the template for anyone who wants to adapt the idea. Each deployment uses its own accounts and credentials, and the design aims to avoid additional API costs by using an existing AI subscription and available free tiers. GitHub Repo Template: https://lnkd.in/eYceS4KR Step-by-step: 1. I label the newsletters I want to process in Gmail. 2. I run The Daily Nexus on demand or on a schedule so it can read the newsletters from that Gmail label. 3. The tool creates a podcast edition and a separately written, two-page newspaper edition. 4. I listen to the podcast or scan the newspaper, depending on how I want to catch up. 5. When needed, the audio is published to a private RSS feed for Apple Podcasts. 6. I use Claude Code and Codex to implement features, troubleshoot failures, review the design, and tighten security. 7. Each deployment uses its own accounts and credentials, with Python, the Gmail API, Antigravity, Kokoro, FFmpeg, Firebase, Cloudflare Workers, and GitHub Actions supporting the workflow.

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

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.

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 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.

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.

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.

“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.