Share your best AI workflow. We could show it to 2M+ people.

We’re narrowing down high school options for my daughter, who wants to focus on art. I’m using Astra to find public schools in our area and beyond with strong art programs and understand how they compare. Astra can research school rankings and academic results, review art courses and facilities, and bring admissions requirements, portfolio expectations, fees, and commute times into one clear comparison. It can also suggest preparation classes—such as drawing, painting, digital art, or portfolio workshops—based on what each school expects. From there, it’s helping me build a shortlist, organize open days and application deadlines, and prepare questions for school visits. We can work through the options together and find a school she’s excited about. Step-by-step: 1. I use Astra to find public schools in our area and beyond that have strong art programs. 2. I ask Astra to research each school’s rankings, academic results, art courses, and facilities. 3. I bring admissions requirements, portfolio expectations, fees, and commute times into one comparison. 4. I use each school’s expectations to identify helpful preparation classes, such as drawing, painting, digital art, or portfolio workshops. 5. I use the comparison to build a shortlist and organize open days and application deadlines. 6. I prepare questions for school visits so my daughter and I can work through the options together.

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

I’ve been experimenting with agentic coding for quite some time, and I’ve noticed that the tasks I let the agent handle keep getting bigger. For larger tasks and projects, I gradually moved to a standard workflow, which I published at https://github.com/evermeer/CodingAgentOrchestration in part 2 of the tutorial. I use this workflow professionally and in my side projects. My most recent side project is Quadrim, a Four in a row game played in a 4×4×4 cube. I made it open source and included all the prompts for both the code and the artwork: https://github.com/evermeer/Quadrim It took me about eight working days to publish the first version to the app stores. Step-by-step: 1. I start by describing the idea. 2. I brainstorm the idea with the agent. 3. I use `to-spec` to create a specification document for the idea. 4. I use `to-ticket` to create independent, executable tasks. 5. I review the specifications and tickets from the perspectives of a senior software engineer, architect, security officer, and product manager. 6. I implement one ticket at a time. 7. I code-review the generated implementation for each ticket. During the pre-implementation steps, I always add this instruction to my prompt: “Ask clarifying questions until any ambiguities are resolved.” Extra fine-tuning of the idea, specifications, or plan pays off during implementation. When I let the agent build code, I ask it to use TDD, perform a code review at the end, and resolve the major and critical findings.

Every Friday, I inspect random parts of my company the way a factory owner walks the floor: looking for errors, slow processes, and handoffs that shouldn’t exist. The inspection takes 30–60 minutes, but the preparation used to take longer—choosing what to check, finding the right links, and remembering what I flagged the previous week. I turned the entire preparation process into one scheduled Claude task. It runs before I wake up on Fridays, builds the full inspection report in Notion, verifies whether last week’s findings were resolved by checking Slack for evidence, and sends me the link by DM. I arrive to a finished briefing and focus only on judgment. You need Claude with scheduled tasks, plus Notion (or your company’s notes page) and Slack connected. If you use different tools, the prompt can be adapted; the structure is what matters. Step-by-step: 1. Create a page or database in Notion where the weekly reports will live. 2. In Claude, create a new scheduled task, set it to run early Friday morning in your time zone, and paste the prompt below. 3. Replace every bracketed section with your own details. 4. Customize the checklist and wildcard pool for your business. Mine is built for a media company; yours might inspect deployments, client deliverables, or a sales pipeline. 5. Run the task once immediately to identify configuration issues before relying on it on Friday. I use this prompt: ```text You are preparing [your name]’s weekly Digital Factory Inspection report. Context: [your name] runs [your company — one line on what it is and team size]. Every Friday they “walk the factory floor” digitally: inspecting parts of the company looking for errors, slow processes, unnecessary handoffs, and automation opportunities. Your job is to prepare the inspection report in advance so their 30-60 minutes is pure judgment, not gathering. You prepare; they inspect and decide. All reports live in [link to your Notion inspections database or page]. Do not create pages anywhere else. Steps: Read the most recent report. Collect: (a) any findings not clearly marked resolved, and (b) which wildcard areas were used in the last two reports. Create this week’s report as a new entry there, dated today, matching the existing format. Build the content in this order: A. “Follow-ups from last week”: every unresolved finding, each with its owner and a status check — search Slack public channels for evidence it was addressed and mark it “looks resolved”, “no activity found”, or “unclear”. If none, write “No open follow-ups.” B. The standard checklist — include ALL of these every week. Under each: random samples with direct links, 3-5 recent data points you can actually reach, and 2-3 sharp inspection questions: What is slow here? Which handoffs could disappear? What should be automated? What would make this 10 percent better this month? Where something sits behind a login you don’t have, do not attempt access — link it and list what to look for. Randomize sample picks genuinely, and never reuse a specific sample from the previous two reports. [Your standard areas — mine: 3 random published pieces of content, 3 random newsletters, 3 random social posts, ad performance, growth dashboards and funnels, product dev work, live events/workshops, community activity, the team’s weekly reports] C. “Wildcards this week”: pick exactly 2 at random from this pool, never repeating either of the last two weeks’ picks: [Your wildcard pool — mine: random customer support conversations, the public sign-up flow walked as a new user, one specific finance item to verify, one email automation sequence, ads on a secondary channel, one random SOP compared against how the team actually works now, one recent client/sponsor deliverable] D. “Notes \u0026 findings”: empty except the line “[Your name] fills this in during inspection — tag each finding with an owner and Open/Resolved.” E. “Wildcards used”: list the 2 wildcard names, for future rotation. Send [your name] a Slack DM (member ID [find yours in your Slack profile menu]) with the report link, the count of open follow-ups, and the 2 wildcards. Nothing else. Hard rules: this report contains candid internal assessments — the DM goes ONLY to [your name], never to any channel, and you never message anyone else. Read-only everywhere except the one report you create and the single DM. Do not reply to emails, do not post, do not modify existing pages. If Notion is unreachable, send the full report as the DM. If Slack is unreachable, still create the report. If both fail, do nothing. ``` The follow-up section is the whole point. I keep the workflow read-only: the agent gathers and drafts, but it never messages my team or touches live systems. Any feedback after the inspection comes from me, in my own words. Randomness is a feature, not laziness.

Trivet is a recipe box for one household. I can photograph a recipe card—handwritten, printed, or a PDF—and get back a structured recipe with ingredients, quantities and units, numbered steps, prep, cook and rest times, oven temperature, and equipment. I can plan a dinner for each night of the week, and the shopping list builds itself: quantities are combined across meals, grouped by aisle, and texted to my phone. I built it because my family’s recipes were scattered across index cards in a drawer, including decades-old handwriting and cards from defunct meal services. Typing everything in was never going to happen. The entire AI workflow uses one model call. The photo is sent to Claude Opus as an image block with a Zod schema attached as the structured output format, so the response is already typed and validated—there’s no JSON parsing, retry loop, or “please respond only with valid JSON.” The extraction schema is intentionally looser than the database schema, with nullable numbers throughout. If a card has no cook time, the model returns `null` instead of inventing a plausible-looking value. The load-bearing instruction in the system prompt is that a missing cook time is a small gap, while an invented one is wrong every time somebody cooks from it. Nothing saves automatically. The extraction first appears in an editable review screen. The model also returns a confidence field, so a blurry card or a page that is not a recipe gets flagged instead of silently becoming a bad entry. Step-by-step: 1. I built a Next.js app with Postgres via Prisma and deployed it on Vercel. 2. I made the upload accept an image or PDF. I check the file size before encoding because the API limit applies to base64, which inflates the bytes by about a third; a 7 MB raw ceiling is the real limit. 3. I defined the extraction shape in Zod and sent it as the output format instead of describing JSON in the prompt. 4. I described fields in the schema. For example, `.describe("Unit as written, e.g. 'tbsp'")` does more than a paragraph of instruction. 5. I render the result into a review form and save it only when the form is submitted, never immediately after the model responds. 6. I store quantities as numbers with separate units so servings can be scaled and ingredients can be combined across recipes later. This is the decision that cannot be retrofitted easily. 7. I sum ingredients across planned meals, round at the end, group them by aisle, and send the list via Twilio. The pattern is not limited to recipes. Anything I would otherwise have to retype—receipts, notes, or forms—can use the same three moves: a schema looser than the database, a model told that `null` is better than a guess, and a review screen between the response and the database write.

Sometimes AI produces an image you love without your having asked for that exact result. The colours work, the texture feels right, and the atmosphere is exactly what you wanted but could not quite describe. Before moving on, use that image to develop a reusable prompt. Step-by-step: 1. Show the image you are happy with to an AI tool and ask: “How would you describe the visual style of this image? Pay attention to colour, texture, lighting, shapes, composition, detail and atmosphere. Separate the style from the specific subject.” This helps turn “I love this” into something you can name. You are asking for a description of the visible result, not the exact process that originally produced it. 2. Read the description and compare it with the image. Check whether the AI noticed the qualities you love or focused on something incidental. Clarify ambiguous terms—for example, whether “soft” means gentle lighting, blurred edges, or muted colours. Correct the description where needed. You might write: “The uneven shapes and paper texture matter. The pastel palette does not. I want to keep the slightly strange atmosphere without making everything cute.” Your response turns a general description into a record of your taste. 3. Ask: “Write a reusable image prompt based on this description. Keep the visual qualities we identified, but make the subject replaceable. Distinguish essential features from optional ones.” The prompt should describe what makes the result useful to you rather than simply retell what is pictured. A woodland scene might contain the style you love, but that does not mean every future image needs a forest. 4. Apply the prompt to another source image or a different subject. This is the useful test: can the prompt carry the qualities you wanted into new material? A second version of almost the same scene may hide weaknesses in the prompt. A different subject makes them easier to see. 5. Compare the new result against your goal. Ask yourself: - Does this new result have the qualities I loved? - Does the style suit the new subject? - Did the prompt preserve what mattered in the new source? - Did it reproduce incidental details from the first image? - Would I actually use this result? A reusable prompt should transfer the visual direction while giving the new image room to remain itself. 6. If the result misses the mark, identify the specific difference and refine the prompt. For example: - Too smooth? Name the texture. - Too cute? Describe the shapes and expressions more precisely. - Too realistic? Clarify the degree of stylization. - Too similar to the first scene? Remove subject-specific details. Test again when those changes matter. Save the prompt alongside the original result and a successful test image. Note the tool or model used, since the same wording can behave differently elsewhere. One successful test is encouraging, but several varied tests give you a clearer sense of where the prompt works. An unexpected result can help you discover a preference you did not yet have words for. Describe it, decide what matters, turn those choices into instructions, and test whether they travel. You do not need to know the perfect prompt before making something you love. Sometimes the image comes first, and the language follows.

I built a workflow that turned a single plain-English idea into a live, 24/7 crypto trading bot without being a developer. Claude handled the engineering; I made the decisions. Step-by-step: 1. I gave Claude the goal rather than detailed instructions. My first message was roughly: "Create me a trading bot that runs 24/7, makes faster decisions than a human, takes calculated risks, picks the lowest-fee platform, and has a dashboard with profit graphs. Make it your own." Claude designed the whole system and named it Kestrel. 2. Claude explained the setup options, including exchanges versus on-chain trading, laptop versus cloud hosting, and minimum funds. I chose BNB Chain and PancakeSwap, using a brand-new MetaMask wallet dedicated to the bot so it can never touch my other funds. 3. I let Claude build and test the bot. It wrote the strategy—holding good coins in healthy markets and moving to stablecoins in bear markets—along with hard safety limits, including a daily loss cap, emergency brake, and trailing stops. It also built cheapest-route swap selection and automated tests. When the backtests did not clear the bar we had agreed on, Claude told me honestly instead of curve-fitting. 4. Claude walked me through deploying the bot by renting a cloud server, running it in Docker, and locking the server down with Tailscale and a firewall so nothing was exposed to the internet. I only copied commands and sent screenshots when I got stuck. 5. I went live with a small amount and used a private phone dashboard showing the balance, trades, the bot’s reasoning, and Pause and Sell-everything buttons. 6. I kept improving the system through conversation. I added a “strategy league,” where 10 strategies trade on paper and can be promoted only with my approval, along with self-healing, backups, and one-tap sharing of wins and losses to X. My biggest lesson was to talk to Claude like a capable coworker: give it the goal, make the key calls yourself, and ask it to be honest about the risks.

Several months ago, my dad was in and out of the hospital. My two brothers and I were trying to coordinate his doctor appointments, manage his medications and potential interactions, and keep track of all the other details involved in his care. At one point, up to seven different doctors were seeing him in the hospital on any given day. It became important to track every medication he was taking, what each one was for, and information such as his weight and other vital statistics. When he returned home, we also had to make sure someone checked on him and his wife every day, helped him stay on schedule with his medications, and recorded his diet, mood, and weight. We initially used Apple Notes, a shared iCalendar, multiple text threads, and a weekly call between the three of us. The mental load was huge. If we needed to find information from the previous week, we had to scroll through pages of Apple Notes to locate it. We also struggled to keep the rest of the family updated. Before my dad passed away, I started using Claude Code and Codex to build a simple tool that would keep everything organized and searchable. It also displayed trends in areas such as his mood, appetite, and vital signs, and included a calendar showing who was covering which days and times. The tool was still fairly basic when he passed away. Afterward, we encountered the administrative headaches involved in closing out his estate. It was far more complicated than we expected. We thought having a will, power of attorney, and other documents meant we were prepared, but we were wrong. I began integrating those lessons—and the things we learned not to do—into the final product, Eldercare Log: eldercarelog.com. I built the final tool with Claude helping draft a PRD, which I then handed to Codex for the coding work. It took a few weeks of refining the product with Codex. The tool is hosted on Vercel, with Supabase and Stripe on the backend, and includes the security features I built into it. It is the tool I wish had existed when my brothers and I were going through this journey before my dad’s passing. Step-by-step: 1. I coordinated my dad’s doctor appointments, medications, vital statistics, and other care details with my two brothers while he was in and out of the hospital. 2. We tracked his medications, their purposes, his weight, diet, mood, appetite, and other vital signs while he was at home. 3. We coordinated daily visits and coverage using Apple Notes, a shared iCalendar, text threads, and a weekly call. 4. I used Claude Code and Codex to start building a searchable tool that organized his care information and showed simple trends. 5. I added a calendar to track which family member was covering each day and time. 6. After my dad passed away, I incorporated what we learned from handling his estate, including the things we wished we had known earlier. 7. I used Claude to draft a PRD, then gave it to Codex to handle the coding work and refined the product with Codex over several weeks. 8. I built the final tool with Vercel, Supabase, and Stripe on the backend.

While traveling abroad, my partner and I became quite sick near the end of our trip and remained ill after returning home. Because we were in a country where we did not speak the language, we used Google Translate at the pharmacy and used Claude to track our symptoms as they changed from day to day. Claude helped us keep the symptom history organized and research what to ask for at the pharmacy, including differences between the medicines we were familiar with and those commonly used in that country. When our symptoms worsened after we got home, we continued using Claude as a symptom tracker and photographed everything in our medicine cabinet. We often forget what we bought or why, and medicines in the United States can be marketed for different uses in ways that are not always clear. Using the symptom history and medicine photos, we asked Claude what we might be able to use, what to avoid, when to take things, and when to contact a doctor, use telehealth, visit urgent care, or go to the emergency room. It also surfaced newer research suggesting that some medicines once thought to be effective may no longer be supported by current evidence. This simple workflow helped us manage the situation and decide whether we needed to buy anything new or seek additional care. Step-by-step: 1. I used Google Translate to communicate at the pharmacy while traveling in a country where we did not speak the language. 2. I described our symptoms to Claude and kept the symptom history updated as they changed from day to day. 3. I asked Claude to research what to ask for at the pharmacy, taking into account the medicines we were familiar with and those used in the country we were visiting. 4. After we returned home and our symptoms worsened, I continued tracking them in Claude. 5. I photographed the medicines in our cabinet so Claude could help us review what we had, what we might be able to use, and what we should avoid. 6. I used the symptom history and medicine information to think through timing, whether we needed to buy anything new, and whether to contact a doctor, use telehealth, visit urgent care, or go to the emergency room. 7. I also asked Claude to check current research, including whether newer studies had changed the understanding of some medicines’ effectiveness.

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 use Instinct, an AI assistant I text or send voice notes to over iMessage, to manage personal to-dos that used to live in my head or in a pile of iPhone alarms. Many tasks come up when I’m away from my desk, so I used to forget them. Alarms didn’t help much either: they went off once, I swiped them away, and the task was gone. Now, when something comes up, I send Instinct a quick voice note. I don’t need to open another app or type. For example: “Remind me tomorrow at 10 AM to respond to book my next dental appointment, and follow up until I say it's done.” Instinct turns the voice note into a clean reminder with a time attached. If I don’t reply “done,” it checks back in and keeps following up until I close out the task. I use the same thread for recurring tasks, partner follow-ups, ad hoc tasks, and advertising to-dos, so everything I owe people lives in one place. Capturing a task takes a few seconds, which means I actually do it. The built-in follow-up keeps things from slipping just because I was busy when the reminder went off, and the workflow lives in iMessage, where I already am throughout the day. Try sending one voice note today with a real task and end it with “follow up until I say it's done.” Step-by-step: 1. When a task comes up, send Instinct a voice note in iMessage. 2. Include the task, when to be reminded, and whether Instinct should follow up until you confirm it is done. 3. Let Instinct turn the voice note into a scheduled reminder. 4. Reply “done” when you complete the task. 5. If you do not reply “done,” let Instinct check back in and continue following up until you close it out. 6. Keep recurring tasks, partner follow-ups, ad hoc tasks, and advertising to-dos in the same iMessage thread.

I regularly come across long articles, reports, papers, ebooks, and other documents that I want to understand but realistically don’t have time to read closely. Instead of letting them pile up in a reading queue, I change the format and turn them into audio I can consume during time that would otherwise be less productive. Step-by-step: 1. I choose a long article, report, paper, ebook, or other document that I want to understand but don’t have time to read closely. 2. I upload it to Google Notebook (formerly NotebookLM) and add it as a source so NotebookLM can work directly from the material. 3. I generate an Audio Overview. NotebookLM turns the source into a conversational, podcast-style discussion that summarizes and explains the major ideas. 4. I listen while walking, driving, working out, doing chores, or running errands. 5. I follow up on what matters. After listening, I know the main ideas, what I want to investigate further, whether the document is worth reading in full, and which sections deserve closer attention. The result is essentially a personal podcast generated from whatever I need to learn. What I like about this workflow is that it doesn’t require me to find more time. It lets me use time I already have differently. Because the material is turned into a conversational discussion rather than simply being read aloud, I find it easier to stay engaged with dense material. I don’t treat the podcast as a replacement for reading the source when the details really matter. I use it as a comprehension and triage layer. Even when I eventually go back and read the original, I’m starting with a mental model of what’s in it rather than approaching it cold. The broader lesson is that AI doesn’t always need to save time by doing the work for you. Sometimes it can save time simply by changing the form of the work so it fits into your life.

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

I use a persistent AI project-orchestration workflow for small-business operations, internal tools, AI-assisted coding, specialist-agent workflows, and projects that need to survive fresh sessions. A root AI receives one bounded objective, reads the project state from files, breaks the work into phases, and delegates implementation to bounded specialist or worker agents. It verifies the results, updates the durable state, and continues until the acceptance criteria are met. This lets me run small-business and coding projects end to end without re-explaining the project every session or manually driving every handoff. The core pattern is: Objective → durable state → root orchestrator → bounded workers → verification → state update → next step → Git checkpoint. Step-by-step: 1. I give the root AI one bounded objective. 2. The root AI reads the current project state from files. 3. It breaks the work into phases and delegates implementation to bounded specialist or worker agents. 4. It verifies the workers’ results. 5. It updates the durable project state. 6. It moves to the next step and creates a Git checkpoint. 7. It continues this cycle until the acceptance criteria are met.

I'm 78, a former army officer, and I live alone in the woods in southern British Columbia on satellite internet. In late January 2026, I knew nothing about AI and considered myself a novice in technology. After watching a YouTube video about advanced AI models, I started learning from YouTube channels that explain new AI research papers. I decided to run an experiment: what could a technology novice build with AI? I've been building for about 15 hours a day ever since. My goal is to build a system that improves itself in a continuous loop: it finds an upgrade proposal, builds and tests it, filters and grades it, approves or rejects it, installs it if it passes, monitors its performance, and learns from the result. We custom-built FORGE3 RSI in 900 hours. It consists of four plug-in modules: Forge2 RSI, which runs the improvement cycle; Bridge, the checker and connector; JAZ RSI, an upgrader in RAM built from a research paper; and Forge SecureBox, a high-security Mac app that runs security tests and code in a fresh, disposable virtual machine with no network device. I don't write code—it feels like a foreign language to me. Instead, I set the direction and run a team of AIs, mostly low-cost, near-Frontier models: Gemini 3.1 Pro and Hark as chiefs of staff; Cline and Devin as builders; and other models as independent, adversarial auditors. The rule that has made this work is simple: nothing gets built without an adversarial audit before and after. Our critical build pipeline is: Plan → audit → blueprint → audit → tests → audit → build → audit → test → audit → commit Each module has been built and fully tested on its own. Forge2 RSI alone has more than 1,000 tests. The first complete end-to-end cycle, using one upgrade proposal that we feed it by hand, is the next step. Our first attempt was fragile, and models that sound confident are often wrong. That is why audits matter more than any single model. FORGE3 RSI is my own custom-built plug-in module project. Our hardware and models are an MBP i9, Mac mini M4, Gemini 3.1 Pro, Hark, Cline (GLM 5.3/SPARK 1.3/MiMoV2.6), Devin (SWE2/GPT SOL 6), KUN (DeepSeek V4.1), and Git. Step-by-step: 1. We select a promising published research paper and have the team prepare and build it. 2. For every file, the team follows the same sequence: plan, audit, blueprint, audit, write tests, audit, build, audit, run tests, audit, and commit. 3. A different AI audits the work than the one that built the file. I decide when and how each audit happens. 4. Nothing is written or changed without my explicit GO. Reading and checking code is free; writing is work and waits for me. 5. We handle one building task at a time and avoid bundled instructions. 6. Any code the system wants to test runs inside SecureBox, sealed off from my Mac and the internet. 7. Everything that passes is committed to Git. The builders also maintain shared memory documenting what was decided and why, so the next session can pick up where the previous one stopped. 8. Next, we will run one complete improvement cycle with a hand-fed upgrade, then scale up slowly to two or three papers a week, prioritizing quality over speed as we work toward full autonomy.

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.

I built Show Hole to solve my family’s classic streaming problem: we spend too much time deciding what to watch, and the answer changes depending on who is actually on the couch. We each have different tastes, but the more interesting problem is that our tastes overlap differently in different combinations. I watch one kind of thing with my spouse, my spouse watches something different with our kid, and my kid and I have our own lane too. Most recommendation tools flatten that into one account profile, one watch history, or broad genre buckets, so they miss the real context of a household. Show Hole treats people and viewing contexts as first-class citizens. It recommends titles “in the vein of” something we liked, filters recommendations to the streaming services we actually subscribe to, avoids titles that the people present have already seen or vetoed, and explains why a recommendation fits tonight. Instead of relying mainly on genres such as comedy, drama, or sci-fi, Show Hole looks at more human taste signals: pacing, world building, humor, emotional weight, complexity, tone, and similar dimensions. It also learns from what we actually do after a recommendation: what we watch, skip, save for later, love, and drop. The result is a personal household recommender that understands “who is watching tonight?” as part of the question, instead of pretending one streaming profile can represent everyone. I designed the app using Claude design, then used those designs with Claude Code to build it. Step-by-step: 1. I identified the household viewing problem and accounted for the different combinations of people who might be watching together. 2. I designed Show Hole around people and viewing contexts instead of treating the household as one account profile, watch history, or set of broad genre preferences. 3. I had it recommend titles “in the vein of” something we liked, filter them to the streaming services we subscribe to, exclude titles already seen or vetoed by the people present, and explain why each recommendation fits that night. 4. I used taste signals such as pacing, world building, humor, emotional weight, complexity, tone, and similar dimensions instead of relying mainly on genres. 5. I made the recommender learn from what we watch, skip, save for later, love, and drop after receiving a recommendation. 6. I designed the app using Claude design and used those designs with Claude Code to build it.

I built a daily literature quiz game from a spreadsheet containing thousands of classic literature quotes, which I previously posted on Instagram each day. I uploaded the document to Claude Code, which organized and tagged the quotes, created multiple-choice questions with increasing difficulty, and wrote short summaries of each book along with a fun fact supported by academic sources. I also vibe-coded the game’s UI/UX in a day or two, and I think it looks pretty beautiful. You can play it at play.writt.org. Step-by-step: 1. I collected thousands of classic literature quotes in a spreadsheet and posted them on Instagram each day. 2. I uploaded the document to Claude Code. 3. Claude Code organized and tagged the quotes. 4. Claude Code created multiple-choice questions with increasing difficulty. 5. Claude Code wrote short summaries of each book and a fun fact with academic sources. 6. I vibe-coded the game’s UI/UX in a day or two. 7. I published the game at play.writt.org.