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

I used to open calls by asking people to remind me where we left off. The notes existed, but they were scattered across transcripts that nobody reviewed. I built two scheduled tasks that work together: one files every meeting at the end of the day, and the other sends me a prep brief every morning. At the end of each day, the first task pulls the verbatim transcript of every meeting I had into a shared Notion database. I use the transcript rather than the AI summary because summaries may be useful that afternoon but are less useful three weeks later when I need the exact thing somebody said. Each meeting becomes a page with the date, client, and attendees stored as real relations rather than text, so everything is filterable later. My business partner has access to the same database, so neither of us has to recap our calls for the other. At 7 a.m., the second task reads my Outlook calendar, finds the email thread or threads tied to each meeting, reads the associated transcripts in Notion, and writes a short prep brief for each one: what we said last time, what I owe them, and what is still open. The part that took the most thought was deciding what should not be filed in the main database. Personal meetings are skipped by keyword. Small internal meetings are screened for topics such as pay, hiring, legal matters, or client-confidential material. Those meetings are routed to a separate database with different permissions. When a meeting is ambiguous, it defaults to the restricted database. Failing toward privacy is the right default when a robot is making the decision. Step-by-step: 1. I turned on Zoom AI Companion so every meeting produces a transcript, then connected Zoom, Notion, and Outlook. 2. I built a Notion database for meeting notes with Date, Client, and Attendees as relation properties connected to existing Clients and People databases. These relations make the notes findable later. 3. I wrote the end-of-day task to pull each transcript verbatim, create a page, match the client by keyword against my client list, and add attendees based on the transcript speakers. 4. I filtered the speaker list because notetaker bots appear as attendees. I removed Fireflies, Otter, Fathom, and the other notetaker bots, and automatically created a person page for anyone who was genuinely new. 5. I deduplicated meetings using the title and date. If a page already existed as a placeholder, I updated it in place instead of creating a second one. 6. I added a skip list for personal meetings and a confidentiality screen that routes sensitive internal meetings to a separate, permission-restricted database. When the classification is unclear, it defaults to restricted. 7. I wrote the morning task to read that day’s calendar, search email and transcripts for each attendee and company, and produce one short brief per meeting covering the last contact, open commitments, and what I owe them. 8. I scheduled both tasks: the filing task for the end of the day and the briefing task for early morning.

I built a workflow to select music for a senior fitness class that suits the participants’ general age range and meets the program’s criteria of approximately 120 BPM. I also require the music to be danceable and have a 4/4 beat. After a successful summer using AI-suggested, danceable Motown songs from the 1970s, I continued using AI to help with music selection. I don’t have a music background or the knowledge to do this myself, so I appreciate the help. Yesterday, a participant commented on how enthusiastic she was about the music. Her response was simple: “I love the music.” Step-by-step: 1. I considered the general age range of the senior fitness class participants. 2. I used the program’s target of approximately 120 BPM as a selection criterion. 3. I added my own requirements that the songs be danceable and have a 4/4 beat. 4. I used AI to suggest songs that fit those criteria, including danceable Motown songs from the 1970s during the summer. 5. I used participant feedback to confirm that the music was well received.

I built a workflow that turns the wines I drink into a personal AI wine journal and sommelier that learns my taste over time. I created a master Google Sheet as the database. It includes the wine, vintage, region, grape varieties, price, rating, food pairing, where I drank it, who I was with, whether I would buy it again, and my own comments. Whenever I drink a wine, I send ChatGPT a photo of the bottle and a voice note with my reaction. I do not try to sound like a wine expert; I simply describe what I actually thought. ChatGPT identifies the wine, structures the information, preserves my original words, and adds the experience to the journal. Over time, ChatGPT uses my previous ratings and comments to understand my palate and make recommendations specifically for me. I can show it a restaurant wine list or a few bottles in a shop and ask which I am most likely to enjoy. I can also tell it what I am cooking and ask which bottle from my collection I should open. I record the context and memories around each bottle, so the system is gradually becoming both a wine database and a personal diary. Step-by-step: 1. I created a master Google Sheet to store details about each wine, including the vintage, region, grape varieties, price, rating, food pairing, location, company, whether I would buy it again, and my comments. 2. Whenever I drink a wine, I take a photo of the bottle and send ChatGPT a voice note describing my reaction in my own words. 3. ChatGPT identifies the wine, structures the details, preserves my original comments, and adds the experience to the journal. 4. I record the context and memories associated with each bottle. 5. As the journal grows, ChatGPT uses my ratings and comments to build a better understanding of my palate. 6. I ask ChatGPT for personalized recommendations from restaurant wine lists, bottles in shops, or my own collection based on what I am cooking.

Sometimes the best AI workflow starts without a workflow at all. This one began almost accidentally. During an ordinary conversation about my cat, AI offered to write a haiku. I had not set out to create a poetry project; it was simply a small creative response to a moment. I liked it, so another moment with the cat became another haiku, and then another. Over time, those isolated poems started to feel less like chat fragments and more like a collection. The workflow emerged afterward: Step-by-step: 1. I notice something small from everyday life, such as a pose, habit, expression, interaction, or tiny domestic scene. 2. I tell AI about it in ordinary conversational language. 3. When the moment has the right texture, it becomes a short poem. 4. I react to what works, whether that is the humor, tenderness, rhythm, imagery, absurdity, or the particular way the cat was captured. 5. Those reactions gradually shape the voice of later pieces. 6. Instead of forcing every moment into the format, I keep the ones that feel worth preserving. 7. The poems accumulate over time. 8. Eventually, a spontaneous haiku becomes part of a coherent collection documenting a relationship and a period of life. The interesting part is that the collection was not designed from the top down. There was no initial brief, content calendar, or plan to “write a book of cat poetry.” Continuity emerged because the same subject kept returning, the format was small enough to revisit casually, and previous pieces gave later ones a growing creative context. AI therefore acted less like a writing tool and more like a creative companion with continuity: noticing when an everyday moment might be worth turning into something. The end result is more than a stack of generated poems. It is a record of tiny observations that probably would never have been written down otherwise.

I’m behind and self taught when it comes to prompt engineering and would like some guidance. I use terms like “exact replica” of image, “do not alter features”

The content, business plan, and trajectory is established. Coding and execution is the precise matter that is required. I lack coding skills, and have yet to acquire a proper coder to fit the context.

I built a workflow to reconstruct auditable, per-client billing for Claude usage after my Anthropic bill tripled in one month and I discovered there was no reliable way to see why. I run a solo consulting practice on a Max plan and pass AI costs through to clients. In September, my extra usage reached $1,805.76 in nineteen days. The usage page attributed 100 percent of one week to "Cowork" without session detail. Auto-reload was enabled by default with no spending limit, and the only usage I could independently verify—my local Claude Code logs—accounted for about $245. The support bot twice described analytics features that did not exist, including a per-day view it later retracted. When I finally reached a human, I got the truth in writing: Max subscribers have no session-level or per-day reporting, exports are Enterprise-only, and Cowork has been cloud-only on consumer plans since August. The Enterprise path to a readable meter starts at twenty seats. I am one person, so I built my own meter. The irony is that I used Claude to design and code it. Claude Code sessions write logs on my own machine. I price them at list rates with the open-source `ccusage` tool and attribute each session to a client by repo folder. That creates the measured pool: real receipts with no allocation. Other CLIs in the same logs, such as OpenAI Codex, are excluded automatically. Chat and Cowork run in Anthropic’s cloud and leave nothing on my disk, so the remaining overage becomes a cloud pool. I split that pool using evidence my workflow already produces: every Cowork document batch leaves a directive file, snapshots, and a report on disk. A Python script counts executed batches per project and measures the number of bytes each one rewrote. The script splits the cloud pool independently by batch count and byte volume, bills the midpoint, and shows both derivations so each client can see the bracket. Every column ties back to the dashboard total to the penny. A second script pulls per-account AWS charges from Cost Explorer because each client has a separate AWS account. Shell aliases make each report a one-command operation. A Claude skill and a monthly scheduled task turn the outputs into a draft invoice that I approve before anything is sent. The result is that a vendor hands me one unexplained number each month, while I hand my clients an evidence file. Month-end billing takes five minutes. It should not have been necessary to build this, but until consumer plans get real usage analytics, this is how I see in the dark. Step-by-step: 1. I collect local Claude Code session logs and use the open-source `ccusage` tool to price them at list rates. 2. I attribute each Claude Code session to a client by repo folder and automatically exclude other CLIs, such as OpenAI Codex, from the measured pool. 3. I treat the remaining overage from cloud-based Chat and Cowork usage as a separate cloud pool because those services leave no usage logs on my disk. 4. I use Cowork’s directive files, snapshots, and reports to identify document batches, then use a Python script to count executed batches per project and measure the bytes each batch rewrote. 5. I split the cloud pool independently by batch count and byte volume, bill the midpoint, and show both derivations as a client-facing bracket. 6. I verify that every column ties back to the dashboard total to the penny. 7. I use a second script to pull each client’s per-account AWS charges from Cost Explorer. 8. I run the reports through shell aliases, then use a Claude skill and a monthly scheduled task to create a draft invoice for my approval before sending it.

I run Mealie, a self-hosted recipe manager, in Docker on a home server. Mealie is good, but it isn't zero-effort: there's a learning curve and ongoing administration just to keep a recipe library populated. My wife is Spanish, so many of her recipes are in her native language. We also have recipes as handwritten notes, WhatsApp messages, photos, and transcribed cooking videos. Translating the Spanish recipes accurately was beyond my ability, and I had no interest in typing everything into Mealie's editor by hand. I built a custom MCP server that exposes Mealie's API to Claude as a set of tools, along with a project-level skill that encodes our household rules: no mushrooms or celery for me, no ginger or coriander for my wife, a child who is fussy about fish, a pizza oven that only comes out at weekends, and batch cooking that needs to cover school lunches. Now I can give Claude a batch of recipes in whatever form they arrive and in any language. It translates them, restructures them into Mealie's schema, checks for duplicates, and writes them straight into the database. There's no manual entry, and I've never needed Mealie's own foodstuffs database. Ingredients stay as plain text, which is one less thing to maintain. For weekly planning, Claude reads recent meal-plan history from Mealie so that meals do not repeat too soon. It pulls the full ingredients for every candidate recipe rather than trusting the recipe name—a "Veggie Traybake" might contain mushrooms—and drafts the week against our constraints. The plan covers seven family dinners, five weekday lunches for the two of us, and two weekend family lunches. School lunches for the kids are often something we've batch-cooked, so that is built in too. Nothing is written to Mealie until I confirm the draft. After I confirm it, Claude seeds the plan into Mealie, merges ingredients across every meal, rounds them to sensible pack sizes, and groups everything by supermarket aisle. The output feeds through to Home Assistant, so the weekly plan and shopping list appear on our wall-mounted display and mobile phones. Step-by-step: 1. Create a self-hosted instance of Mealie in Docker on a home server. 2. Build a custom MCP server that exposes Mealie's API to Claude. 3. Create a project-level skill that encodes our dietary preferences, cooking setup, and usual meal structure. 4. Batch-feed Claude recipes in any format and language, including photos, WhatsApp messages, video transcripts, and handwritten notes. 5. Skip Mealie's structured foodstuffs database and keep ingredients as plain text while Claude parses them into Mealie's recipe schema. 6. Ask Claude to translate recipes, check for duplicates, and write the structured recipes into Mealie. 7. Ask Claude to read recent meal-plan history, check candidate ingredients against our preferences, and draft a new weekly plan covering our required dinners and lunches. 8. Make changes through chat, and confirm the draft before anything is written to Mealie. 9. Have Claude seed the confirmed plan into Mealie, merge ingredients across every meal, round them to sensible pack sizes, and create a categorised shopping list. 10. Install the Mealie integration in Home Assistant to display the plan, recipes, and shopping list on your devices.

Learning baselines of app development, mainly coding. The concept and business model is fully intact, now the requirement is solely leaning on execution. The tools for execution are lacking.

I’m building an AI travel assistant called SundayAtlas, and I wanted a systematic way to keep learning from what travelers are talking about between individual user conversations. Reddit is useful for this because people are unusually candid about trip-planning frustrations, destinations, bad experiences, and what they wish travel products did better. The problem is volume: I didn’t want to manually read hundreds of posts every week, so I built a Reddit Signal Agent that does the first pass and sends me a weekly travel-insights newsletter. Each week, the workflow collects posts from selected travel subreddits and passes them through an LLM-based classification and analysis pipeline. The report is organized around: - New or intensifying signals - Steady baseline themes - Fading signals - Rising destinations - Competitor mentions - Anomalies unusual enough to warrant attention This week, for example, the agent analyzed 77 posts. It surfaced a spike in discussion around short-term rental restrictions in Tokyo, growing payment friction for travelers in Japan, increased interest in quieter alternatives to heavily touristed Asian destinations, and recurring trust issues involving travel platforms. I use the newsletter as one input into product discovery for SundayAtlas. It gives me a weekly pulse on problems and behaviors that may be worth investigating further, rather than relying purely on my own assumptions about what travelers need. Step-by-step: 1. I collect recent posts from a defined set of travel subreddits. 2. I clean and structure the Reddit data for analysis. 3. I run the posts through an LLM using a defined signal taxonomy. 4. I aggregate the classifications across the weekly sample to identify patterns, changes, and anomalies. 5. I generate the report in a consistent newsletter format. 6. I run the full pipeline automatically with GitHub Actions so a new report is produced each week. I built the agent in Node.js and used Claude Code extensively during development. Evaluation ended up being the most important part. Early outputs looked convincing, but I had no objective way to know whether the classifications were actually good. I manually labeled 91 Reddit posts and created a blind golden dataset, then built a deterministic scorer to compare the agent’s classifications with my labels. The first held-out evaluation scored only 0.23, which gave me something concrete to improve against. I iterated on the classification approach and inspected individual failures. Along the way, I found three separate defects in the data collection pipeline. The held-out score eventually improved to 0.61, while the score across the full dataset increased from 0.33 to 0.67. The finished loop is: Reddit conversations → signal classification → trend analysis → weekly insights newsletter → product discovery for SundayAtlas The golden dataset remains underneath the workflow as a regression test, so when I change the agent, I can measure whether I’ve actually improved it.

I built an AI-assisted vertical grain supply-chain resilience workflow after discovering that the rye flour we normally use for homemade bread had been discontinued. I started by asking ChatGPT to locate alternative retail and bulk suppliers for rye and spelt flour. We compared package sizes and prices, contacted local mills and bulk-food suppliers directly, and expanded the search from finished flour to locally available whole grain. The workflow then moved offline. ChatGPT helped us identify the resources we already had: agricultural land, grain bins, a cultivator, a seeder, an old but functional industrial grain crusher, and even a combine. We also realized that a friend owns a seed-cleaning plant and that our farming neighbors can connect us with local rye and spelt growers. Our next steps are to test whether a household coffee grinder can produce sufficiently fine flour from grain, source fresh food-grade rye and spelt locally, and investigate growing a small crop ourselves. The biggest lesson was that AI was most useful not because it gave us one answer, but because the conversation kept changing the question. We began with “Where can I buy rye flour?” and ended with “Why are we buying rye flour when we already have most of the infrastructure required to produce it ourselves?” Step-by-step: 1. I asked ChatGPT to find alternative retail and bulk suppliers for rye and spelt flour after our usual rye flour was discontinued. 2. We compared package sizes and prices, contacted local mills and bulk-food suppliers directly, and expanded the search from finished flour to locally available whole grain. 3. We reviewed the resources already available to us, including agricultural land, grain bins, a cultivator, a seeder, an old but functional industrial grain crusher, and a combine. 4. We identified additional local resources: a friend’s seed-cleaning plant and farming neighbors who can connect us with local rye and spelt growers. 5. We plan to test whether a household coffee grinder can produce sufficiently fine flour from grain, source fresh food-grade rye and spelt locally, and investigate growing a small crop ourselves. 6. We reframed the question from where to buy rye flour to whether we could produce it ourselves using the infrastructure already available to us.

I use AI to turn my watch history into a personal recommendation engine that can answer situational questions such as, “What should I watch tonight?” Generic recommendation algorithms know what is popular and what resembles something I clicked before. They usually know much less about why I want to watch something tonight. For this workflow, I give AI two different datasets: - Already watched: Evidence of my actual viewing history and taste. - Want to watch: Shows my curiosity, intentions, and unexplored directions. This should not automatically be treated as proof that I will like something. AI analyzes both lists for patterns such as genre, themes, emotional intensity, pacing, humor, visual atmosphere, storytelling style, cultural interests, darkness versus comfort, realism versus imagination, and other recurring preferences. Instead of reducing everything to genres, the workflow builds a descriptive taste profile. It keeps confirmed preferences separate from hypotheses based on the watchlist and uses my later reactions to refine the profile. When I want a recommendation, I add my current context: available time, mood, energy, desired emotional intensity, whether I want something comforting or challenging, and whether I want a movie or an episode. The system matches that temporary context against my longer-term taste profile and the available watchlist. So instead of asking: > “Recommend me a good series.” I can ask: > “I have about 90 minutes, my brain is tired, I want something comforting but not stupid, and I don't want anything emotionally brutal tonight.” The recommendation is based on three layers at once: past taste, future curiosity, and present state. Over time, the system becomes less like a recommendation list and more like a personal cultural navigation tool. Step-by-step: 1. I import or paste my watched films and series. 2. I add a separate list of things I still want to watch. 3. I ask AI to analyze recurring themes and less obvious connections. 4. I build a descriptive taste profile rather than reducing everything to genres. 5. I keep confirmed preferences separate from hypotheses based on the watchlist. 6. I use my later reactions to refine the profile. 7. When choosing something to watch, I add the current context, including available time, mood, energy, desired emotional intensity, whether I want something comforting or challenging, and whether I want a movie or an episode. 8. I match that temporary context against my longer-term taste profile and the available watchlist.

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 used Claude Code to find scientific seminars hosted by colleges and universities across the US and collate them into a single, searchable list. Researchers can use it to find talks that match their interests near them. The site, seminarsearch.org, runs mostly on free-tier SaaS services, costs me $5 per month to operate, and currently supports a few thousand users. The same pattern could be adapted to collate all 5K runs in the US, tennis matches, craft shows, quilting bees, or any other type of event that interests you. I started by explaining to Claude what I wanted to build. We then spent a few hours exploring where and how to identify seminar calendars at universities across the US, which was arguably the hardest part. We developed a pluggable framework with scraping plugins for the common CMSs used by universities, along with iCal parsers, HTML parsers, and JavaScript interpreters to handle the complexity of normalizing content from hundreds of departmental websites. Once we had the seminar-scraping infrastructure, we built a database schema in Supabase and simple APIs to create, read, update, and delete records. The APIs are written in Python and hosted on Railway for $5 per month. We used Vercel to deploy a simple React-based frontend for presenting the data. Now I can ask Claude to implement a feature or add a new university to the list of sources. It figures out where the data is hosted, creates entries for the university and its departments, finds their seminar feeds, collects the seminar data, puts it into the database, and runs GitHub Actions to send alerts to registered users. The scraping job runs once a week to collect new data, and it also runs through GitHub Actions. I wrote zero code during this process and have never even looked at the code. I only had to paste a few error messages from Railway into Claude so it could debug them, and there were only a few errors. Since building seminarsearch.org, I have cloned the infrastructure and codebase and modified it to build a site that collects road bike rides and group mountain bike rides across the country. The system is highly extensible to new areas of interest and is useful when traveling or living in a large metropolitan area where it is difficult to keep track of all the opportunities available for your interests. Step-by-step: 1. I explained to Claude Code that I wanted to build a searchable directory of scientific seminars hosted by colleges and universities across the US. 2. We explored where and how to identify university seminar calendars, focusing on the challenge of finding sources across many institutions. 3. We built a pluggable scraping framework with plugins for common university CMSs, plus iCal parsers, HTML parsers, and JavaScript interpreters. 4. We created a Supabase database schema and simple Python APIs for creating, reading, updating, and deleting seminar records. 5. We hosted the APIs on Railway for $5 per month and deployed a React-based frontend on Vercel. 6. We configured Claude to add universities and implement features by finding source locations, creating university and department records, locating seminar feeds, collecting seminar data, and adding it to the database. 7. We used GitHub Actions to run the weekly scraping job and send alerts to registered users. 8. When Railway returned errors, I pasted a few error messages into Claude so it could debug them. 9. I cloned and modified the infrastructure and codebase to create additional sites for road bike rides and group mountain bike rides across the country.

I built SITREP, a self-hosted AI RSS reader that turns roughly 30 articles a day into a single briefing I can act on. It runs in a Docker container on my home NAS, ingests full article text instead of the teasers most feeds provide, and uses OpenAI embeddings to collapse the same story reported by five outlets into one item. Every morning, it writes “The Brief” with the sections Headline, Defense & Aerospace, AI & Tech, and Elsewhere, followed by the two sections I care about most: Implications for my company and Personal Leverage. Each section includes numbered citations linking back to the source articles. SITREP only proposes leverage when the evidence supports it. It also uses a curated, non-sensitive profile of my business lanes and priorities, synced from my Obsidian vault, so its recommendations are specific to my work as a defense-industry VP rather than generic advice. I can select Update Brief at any time during the day to regenerate the briefing in place with a timestamp. Step-by-step: 1. I run SITREP in a Docker container on my home NAS. 2. I have it ingest the full text of roughly 30 articles each day rather than relying on feed teasers. 3. I use OpenAI embeddings to identify and combine the same story when it is reported by multiple outlets, including cases where five outlets cover it. 4. Each morning, SITREP generates “The Brief” with the sections Headline, Defense & Aerospace, AI & Tech, and Elsewhere. 5. It adds Implications for my company and Personal Leverage, using my curated, non-sensitive business profile and priorities synced from Obsidian. 6. It includes numbered citations to the source articles and proposes leverage only when the evidence supports it. 7. I select Update Brief during the day when needed, and SITREP regenerates the briefing in place with a timestamp.

I turned vague fragrance preferences into a usable scent profile by combining perfume notes, dislikes, changing sensory perception, and real-world feedback. I started by telling AI which perfumes I already liked. Rather than immediately recommending more fragrances, it broke those perfumes down into their notes and broader families, such as floral, woody, musky, citrus, sweet, powdery, spicy, green, and amber. I used product information from a qualitative webshop I liked to support that analysis. I then added scents and individual notes I do not enjoy. That distinction matters because liking a perfume does not necessarily mean liking every ingredient in it. A note may work beautifully in one composition and become overwhelming in another. My perception of fragrance had also changed. After a long period of not smoking, many scents seemed to arrive more sharply than before. Perfumes I might once have experienced as soft or pleasant could now feel much more intense. The important part is that AI does not treat perfume notes as a fixed formula. Instead of assuming, “You like vanilla, therefore recommend vanilla perfumes,” it can learn something more nuanced: “You like vanilla when it is softened by certain notes, but dislike it when it is combined with others, and you currently experience certain sharp notes more strongly.” Price can become another layer rather than a separate search. Once a promising scent profile emerges, AI can look for fragrances with similar structures at different price points. The result is a personal scent map: not only a list of perfumes I like, but an evolving model of why certain combinations work for me. The best validation is eventually reaching the highly scientific fragrance classification: > “HALLELUJAH, HOW GOOD DOES THIS SMELL?!” 😂🌺 Step-by-step: 1. I listed perfumes I already enjoy. 2. I analyzed their notes, scent families, and recurring combinations, using product information from a qualitative webshop I liked. 3. I added notes and fragrance types I dislike on their own. 4. I described how perfumes actually feel when worn, using reactions such as sharp, soft, warm, clean, heavy, sweet, fresh, comforting, or overwhelming. 5. I used those reactions to refine my scent profile. 6. I generated new fragrance suggestions based on the emerging pattern. 7. When a perfume looked promising but was expensive, I asked for similar lower-cost alternatives. 8. I smelled or wore the suggested fragrances in real life. 9. I fed my reactions back into the model, including whether a scent was too sharp or sweet, became nicer after an hour, had an opening I loved but a dry-down I disliked, or was simply amazing. 10. I repeated the process until the recommendations became increasingly precise.

I use this workflow when I have a problem but do not yet know which software, service, or method could solve it. Instead of immediately asking for “the best app,” I describe the situation in ordinary language: what I am trying to do, what currently annoys me, what I have already tried, and what would make a solution useful. Then AI helps me map the tool landscape. The important shift is that the criteria emerge from the conversation. The workflow does not search for an abstract “best tool.” It builds a model of what a good tool means for this particular problem and person, then evaluates the available options against that model. This also makes the result reusable. When my requirements change later, I can update the comparison rather than redo the entire research process. Step-by-step: 1. I describe the problem and desired outcome. 2. I identify the requirements that actually matter in this situation. 3. I research the relevant tools and approaches. 4. I compare them side by side using practical criteria such as functionality, price, pricing model, platform, setup effort, learning curve, and ease of use. 5. I ask questions where the requirements are still unclear. 6. I react to the comparison—for example, by noting that something is too expensive, that a subscription is a dealbreaker, that an option looks cumbersome, that I need more statistics, or that I do not need project management. 7. I update the comparison using that feedback instead of starting the search from scratch. 8. I narrow the field and, where useful, test the remaining options on one small real-world task. 9. I record why the chosen tool fits and why seemingly similar alternatives did not.

My partner and I were tired parents trying to help our child sleep better. We had spent hundreds of euros on expert services and courses, but because every child is different, we still hadn't found an approach that worked consistently. For months, we had talked about trying to improve her sleep. She was waking us up multiple times each night, so we used Gemini to develop a plan with stages. In the first stage, we helped her start sleeping in her own room, which she achieved within a week. The second stage focused on getting her to sleep in her bed for the whole night, and we saw great success after the first night. The game changer was having immediate help when things didn't go as planned. At 2 a.m., I described situations such as my child lying on the floor and refusing to move, asking me to stay, wanting to cuddle or be carried, waking up her sibling, or coming back to our room again. Gemini adjusted the plan and told my tired brain what to do next. My child came back from her room 10 times, and each time I described the situation to Gemini and received practical advice. She eventually slept through the night and woke up in the morning feeling proud and happy. To me, that showed that the techniques Gemini suggested had helped create a safe space for sleep. Step-by-step: 1. I described our child's sleep challenges and the approaches we had already tried, including expert services and courses. 2. I asked Gemini to develop a staged plan tailored to her individual needs. 3. I followed the first stage until she was sleeping in her own room, which took one week. 4. I moved on to the second stage: helping her sleep in her bed for the entire night. 5. When unexpected situations came up during the night, I described them to Gemini in real time. 6. I followed the adjusted advice each time she got out of bed, including when she returned 10 times. 7. I continued until she slept through the night and woke up proud and happy.

I built a custom AI knowledge-transfer GPT designed to prevent institutional knowledge from walking out the door when an experienced employee leaves. The trigger was an experienced operations manager preparing to leave the organization. I realized that while we had procedures, files, emails and account documentation, a huge amount of operational knowledge existed only in that manager’s head: customer preferences, recurring staffing problems, site-specific quirks, key relationships, historical issues, workarounds, lessons learned and the small details that can take a replacement months to discover. My goal was to capture that knowledge and turn it into an interactive resource for the incoming operations manager. First, I conducted and recorded an in-depth interview with the departing manager. Instead of only asking standard turnover questions, I had them walk through the operation as if they were personally training their replacement. We discussed customers, employees, locations, scheduling, recurring problems, escalation procedures, communication preferences, historical decisions and things they believed a new manager might not realize immediately. I then transcribed the conversation and used AI to analyze the interview for knowledge gaps. I asked the AI to approach the transcript from the perspective of someone taking over the job and identify important questions that had not yet been answered. Using those gaps, I had AI create customized knowledge-transfer questionnaires specifically for the departing manager. These asked more targeted questions such as: What problems happen repeatedly? What customer preferences are not documented? What exceptions exist to normal procedures? What mistakes is a new manager likely to make? What information exists only in your memory? What would you make sure your replacement understood during their first 30 days? The departing manager completed those documents, giving me another layer of institutional knowledge that would normally be lost. Next, I organized the interview transcript, completed questionnaires, operational procedures, account information, contacts, historical notes and other relevant documents into a knowledge base. I uploaded that information into a custom GPT and instructed it to function as an operational knowledge-transfer assistant. The GPT was told to base answers on the captured information, not invent answers when information was missing, and clearly tell the user when something needed to be verified. The incoming operations manager can now interact with that knowledge conversationally. Instead of searching through folders or wondering who to ask, they can say things like, “I’m meeting with this customer tomorrow. What should I know?”, “Has this location had staffing problems before?”, “Why do we handle this account differently?”, or “What should I watch for during my first month?” The GPT is now being used by the incoming manager as an ongoing reference tool. The result is essentially a searchable, interactive version of the institutional knowledge that previously would have disappeared with the departing employee. It reduces the “I don’t know what I don’t know” period of starting a new position, shortens the learning curve, improves operational continuity and helps prevent the next person from having to relearn years of lessons through trial and error. The same workflow could be recreated for retiring executives, salespeople, plant managers, administrators, project managers, maintenance supervisors or anyone whose experience contains valuable institutional knowledge. The employee can leave. Their knowledge doesn’t have to.

I connected Claude Code to my WordPress website through MCP and used it to update hundreds of existing posts. It searched for custom fields, extracted the relevant data, and saved many hours of repetitive human work. Step-by-step: 1. I connected Claude Code to my WordPress website through MCP. 2. I used it to work through hundreds of existing posts. 3. I had it look for custom fields and extract the relevant data. 4. I used the extracted data to update the posts, replacing repetitive manual work with a repeatable process.