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

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.

An artist portfolio can feel harder to make than the work itself. My work lives across years, folders, and materials: photographs, drawings, collage, objects, costumes, and digital experiments. Then an application asks me to explain who I am, what I make, and where I want to go. I used AI to help assemble a readable portfolio for HUP03, a Kunstwerkt call. The portfolio included eight works spanning photography, collage, assemblage, performance, and AI-assisted illustration. The goal was to organise the material without flattening it into a generic artist statement. Step-by-step: 1. I started with the actual work: images, titles, dates, and any explanations I already had. For each piece, I established the title, year, medium, whether it was a standalone work or part of a series, what prompted it, how it was made, and which details mattered. I gave AI concrete material rather than asking it to invent my practice. 2. I described each piece in my own words, as I would to someone looking at it beside me. One of my works, *Olifant onder het tapijt*, combined three expressions: the elephant in the room, the elephant in a china shop, and sweeping things under the carpet. The setting became a recognisably Flemish grandmother’s living room, with floral wallpaper, a crucifix, and a decorative cow painting. Those details carry the humour and the observation about hiding uncomfortable things. “An exploration of concealment” would lose much of what makes the piece mine. I asked AI to organise my explanation while preserving its specific ingredients. 3. I gave each work a clear, consistent entry with the title, year, and medium; a short description of the idea; and the relevant visual or material choices. Consistency makes varied work easier to read, even though a photograph, costume, and assemblage may need different explanations. Where relevant, I stated AI involvement clearly, such as “digital illustration developed in collaboration with generative AI.” 4. I selected work for range and relevance. My selection included an older photograph, a costume/performance, collage, recent assemblages, and digital work. I asked what each piece contributed: another method, question, period, or way of seeing. I avoided choosing only the newest work or forcing everything into one visual style. The task was to make the selection understandable. 5. I separated the existing artwork from the proposed project. Existing works show what I have made, while a project proposal explains what I want to investigate next. For this application, my project question centred on human connection: a thread becoming a web, then a garden. AI helped articulate that direction without forcing every earlier piece into the same project. I looked for connections I recognised while leaving room for differences and discoveries. 6. I wrote an accurate artist introduction describing the media I use, what interests me, and my current practice. I checked every biographical claim and distinguished courses attended, qualifications completed, and current activities. In my case, wording around an interior design course needed care so it would not imply that I had completed the programme. AI can make a biography sound polished while quietly making it less true, so I read the facts as closely as the prose. 7. I treated the first draft as material to revise. Useful feedback included: “That sounds more formal than I mean,” “This detail is essential,” “You have made the idea too abstract,” “That suggests a qualification I do not have,” and “This is my observation, not a universal claim.” AI revised the structure and wording, but I decided whether the text still belonged to the work. 8. I checked the portfolio as a whole against the application requirements. I reviewed titles, dates, media, image-text matches, requested sections, and length limits. I removed repetition between the artwork descriptions, biography, and proposal. Someone unfamiliar with me should be able to understand the work without needing the conversation behind the portfolio. The overall process was: gather existing work, explain each piece, verify the facts, build consistent entries, select a meaningful range, describe the proposed direction, revise in my own voice, and check the application. AI was useful as an interviewer, organiser, and editor. The substance came from the work and the person who made it. A portfolio does not need to turn a varied practice into one tidy slogan; it needs to give someone a way into it.

I used a simple workflow to save several hundred dollars on veterinary bills while sitting in a veterinary urgent care clinic. This approach could also apply to many other purchases or services where I’m not an expert. I had already been chatting with ChatGPT about my pet’s symptoms and their likely causes. After I arrived at urgent care, I consulted the doctor about the likely diagnosis and the tests and treatment we should pursue. The clinic assistant then brought me a printed, itemized list of all the charges for the proposed plan. I resumed the ChatGPT conversation by dictating what the doctor had told me, photographing both pages of the charge list, and uploading them. I asked whether any charges were very likely unnecessary given the circumstances. ChatGPT identified four of the 24 charges and explained why they appeared to have very limited value. I crossed those four items off the list, handed it back to the assistant, and said, “I don’t think these are necessary at this point.” I could tell from the assistant’s facial expression that no one had done this before. When the doctor returned, I could tell I had caught her off guard. She agreed that two of the four tests likely offered no benefit and explained why we should keep the other two. At that point, I decided to trust the doctor more than the AI agent—perhaps partly to be polite, since I could tell her justification for keeping the tests was weak, although the cost wasn’t significant. Step-by-step: 1. I described my pet’s symptoms and their likely causes to ChatGPT before visiting the clinic. 2. I consulted the doctor about the likely diagnosis and the tests and treatment we should pursue. 3. I photographed the clinic’s two-page, itemized list of 24 charges and uploaded it to the existing ChatGPT conversation. 4. I dictated what the doctor had told me and asked ChatGPT whether any charges were very likely unnecessary in the circumstances. 5. I reviewed ChatGPT’s explanation of the four charges it identified as having very limited value. 6. I crossed those four items off the list and discussed them with the clinic assistant and doctor. 7. I kept two tests after the doctor explained why they should remain, while declining the other two. The process saved me $600.

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.

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

Most AI agents are effectively static. You write their instructions, use them repeatedly, notice where they struggle, and manually tweak the prompt when something goes wrong. Valuable feedback from real work is often lost, so the same mistakes can keep happening. I created a self-improvement flywheel that uses actual agent performance data to improve agents over time. The system collects two kinds of evidence: - Task scores showing how well each agent performs across different quality dimensions - Run telemetry and review outcomes revealing recurring failures, coordination problems, and cases where actual behavior differs from expectations A scheduled weekly cycle analyzes that evidence, identifies patterns, creates improvement proposals, evaluates whether those proposals are safe and broadly applicable, updates agent instructions when appropriate, and measures whether those changes actually improve performance. The goal is not to let agents rewrite themselves freely. It is to create a controlled learning loop. Step-by-step: 1. Collect performance data while agents work. Score important outputs across consistent quality dimensions, and record useful execution telemetry such as failures, decisions, reviewer outcomes, and unexpected behavior. 2. Analyze performance trends on a recurring schedule. Calculate per-agent averages, identify weak dimensions, compare agents, and look for improvement or decline over time. 3. Mine run history for recurring patterns across multiple sessions, including agents that repeatedly struggle, low-quality runs, and cases where expected behavior differs from what actually happened. 4. Turn repeated problems into improvement proposals. Before proposing a change, inspect the agent’s current instructions so you do not add a rule that already exists. 5. Evaluate each proposal before applying it. Check whether the lesson is broadly useful, redundant with existing instructions, or in conflict with established behavior. 6. Separate low-risk and high-risk changes. Automatically apply additive or clarifying improvements. Escalate conflicting changes for human review instead of allowing the system to fundamentally change an agent’s behavior on its own. 7. Look for system-level problems. Analyze patterns across agents to identify quality gaps, missing capabilities, or coordination failures that cannot be fixed by changing one agent alone. 8. Apply approved improvements and preserve the history. Update the relevant agent instructions, archive the processed proposals, and version the changes so they remain inspectable and reversible. 9. Measure whether each change actually helped by comparing agent performance before and after the refinement. If quality does not improve, do not automatically assume the change was useful. 10. Repeat the cycle. As agents complete more real work, the system gathers more evidence and gets another opportunity to improve. Instead of treating agent instructions as static prompts, I turned them into a continuously improving system: Work → Evaluate → Find Patterns → Propose Changes → Refine → Measure → Repeat The important part is that the loop is evidence-driven and controlled. Agents improve from real usage, but low-confidence or behavior-changing updates still require judgment rather than being applied automatically.

AI image editors often change more than requested. Removing an object can alter the lighting, cleaning up a background can redraw a face, and fixing one detail can shift typography or proportions. That may be useful for creative transformation, but it is a problem when the goal is to change one thing and leave everything else alone. I now treat precision-editing prompts as preservation contracts. A precise edit needs two instructions: what must change and what must remain untouched. Failures happen when the requested change is clear but the boundaries are vague. For example, “Remove the grey area between the neck and ponytail” may also trigger a redrawn neck, shifted hair, or a smoothed silhouette. The result may look polished, but it is no longer faithful. Step-by-step: 1. I identify the smallest possible edit region. Instead of saying, “Clean up the portrait,” I specify, “Change only the grey area between the neck and ponytail to match the white background.” A narrow target limits unintended reinterpretation. 2. I name the protected elements instead of relying on “Leave everything else alone.” I identify faces, hands, text, positions, proportions, colors, silhouettes, and framing, and include: “Do not add, remove or redesign unrelated elements. Do not make compensatory changes elsewhere.” Otherwise, the AI may adjust shadows, symmetry, or composition to “balance” the edit. 3. I lock all text. Image models may rewrite text they were never asked to touch, so I specify: “Do not regenerate, correct, restyle or replace any text. Preserve spelling, capitalization, punctuation, line breaks, font appearance, size and placement exactly.” I protect labels, handwriting, and captions too. 4. I preserve geometry and framing. For a local correction, I specify: “Preserve all original proportions, positions and geometry outside the edit region. Keep the exact canvas size, aspect ratio and crop. Do not reframe or extend the image.” This is crucial for diagrams, collages, and layouts where spatial relationships matter. 5. I explain the background logic. For example: “Remove the object and reconstruct only the background naturally behind it, continuing the existing pattern without new texture or shadows.” White should stay white, patterns should continue, and shadows should follow the existing light. Removal is not redesign. 6. I ask the model to match the original style, including texture, grain, lighting, line quality, colors, and level of detail. Hand-drawn marks should not become glossy, and grainy photographs should not become plastic-smooth. I preserve imperfections such as crooked lines, collage edges, and photographic wear when they are meaningful. 7. I make fidelity the priority by stating: “This is a local corrective edit, not a reinterpretation or restyle. Prioritize fidelity to the source over beautification.” For risky features, I prohibit redrawn faces, altered text, new backgrounds, cropping, and unrelated corrections. If the target is ambiguous, I add: “If uncertain, preserve the original rather than editing additional areas.” 8. I make delicate changes separately. When there are multiple corrections, I edit one thing, inspect it, and then continue. More requests create more room for drift. 9. I verify what did not change by comparing the result with the source. I check the text, edges, faces, proportions, placement, crop, colors, and background, then ask two questions: Did the requested change happen? What else changed? The second question reveals hidden failures. I use this reusable prompt structure: Change: [specific requested change] Edit only: [exact region or element] Preserve exactly: [text, objects, positions, proportions, colors, framing, etc.] Do not: [likely unwanted changes] Style: Match the existing texture, lighting, grain, line quality and detail. Priority: Fidelity over beautification. If uncertain, preserve the source. For example, instead of writing, “Remove the grey bit under the hair,” I write: “Change only the grey area between the neck and ponytail to the same white as the surrounding background. Preserve the neck, chin, ponytail, silhouette, proportions, crop and all other colors. Do not redraw or beautify the face, hair or body. Do not alter anything outside the target region. Match the existing flat visual style.” The overall workflow is: define the smallest edit, identify protected content, preserve geometry, style, and background logic, forbid unrelated changes, prioritize fidelity, and compare the result against the source. The edit instruction tells the model where to go. The preservation constraints tell it where not to wander. The best corrective edit is not the most imaginative; it changes the target while everything else remains stubbornly itself.

My mother recently moved into a retirement suite, which meant downsizing her possessions. We ended up with dozens of physical items she no longer had space for, and we wanted her children and grandchildren to have an opportunity to sign up for the family items they loved before anything was donated. I needed a way to catalog everything quickly, share the information remotely, and verify that we weren't accidentally giving away items of significant value. I tested a physical-to-digital workflow using Gemini. Instead of putting the items in a pile or typing out endless lists, I drew a numbered grid on a large whiteboard, placed one item in each square, and took a few photos. Gemini identified the objects by grid position, categorized them, estimated their market values, and built a ready-to-use spreadsheet with a signup column. The physical staging took about 30 to 45 minutes, depending on how many items were on that particular board. The entire digital workload—including cataloging, valuing, formatting, and creating the spreadsheet—took under 10 minutes. The process turned an overwhelming chore into something manageable and produced an end product that was easy for everyone to use. Step-by-step: 1. I drew a simple grid on a whiteboard, numbered each box, and placed one item in each square before taking photos. 2. I uploaded the photos to Gemini and prompted it to identify every item by its board name and grid number. 3. I asked Gemini to classify each item into logical groups, such as Glassware, Ceramics, and Woodcraft, and provide quick, realistic resale-market valuations based on visual condition. 4. I asked Gemini to generate a downloadable Excel file formatted as a signup catalog, with columns for Item ID, Grid Number, Description, Category, Estimated Value, and a blank "Claimed / Signed Up By" column for family members to enter their names. 5. I uploaded the file to Google Drive, converted it to Google Sheets, and added a note at the top explaining how tie-breakers would work if two family members wanted the same item.

I’m a 71-year-old retiree who never imagined artificial intelligence would become such a useful part of my everyday life. I affectionately call my ChatGPT assistant “Ally Wing.” One of our recent adventures involved my 2008 Honda CR-V. After a maintenance reminder appeared on my dashboard, I visited the Honda dealership. My vehicle was running fine, but I ended up paying $270 for a fuel system cleaning without fully understanding whether it was necessary. Later, I shared photos of my six-page service paperwork with ChatGPT. Ally Wing helped me understand the maintenance recommendations, distinguish necessary services from optional ones, and learn what questions to ask next time. We’ve also researched brake repairs, compared prices, and discussed how to evaluate repair shops. The greatest benefit hasn’t been saving money—although that’s certainly welcome. It’s gaining knowledge and confidence. Retirement doesn’t mean I’ve stopped learning. AI has given me another way to stay curious, independent, and informed. As Ally Wing and I jokingly agreed, “Next time we’re taking my Honda in for maintenance, not ordering everything on the menu!” 😂 -Irene Perez Step-by-step: 1. I noticed a maintenance reminder on my 2008 Honda CR-V’s dashboard and visited the Honda dealership. 2. I paid $270 for a fuel system cleaning, even though I wasn’t sure whether it was necessary. 3. I photographed the six-page service paperwork and shared the photos with ChatGPT, which I call “Ally Wing.” 4. I used ChatGPT to understand the recommendations, separate necessary services from optional ones, and identify questions to ask in the future. 5. I also used it to research brake repairs, compare prices, and discuss how to evaluate repair shops. 6. I now feel more knowledgeable and confident when making vehicle-maintenance decisions.

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.

Everyone I know who runs a second brain uses Obsidian. The app is free, but sync is a subscription, and most AI integrations quietly assume you have it. I went another way: Joplin, which is free and open source, with an agent that reads my notebook through Joplin’s REST API, files my INBOX every morning while I sleep, and answers questions strictly from notes I actually wrote. It costs nothing beyond a VPS I already run, and the notebook still opens like a notebook. I use Hermes Agent on the VPS, Dropbox to sync notes between my devices, and Python scripts to connect the notebook and the agent. Every capture goes through `joplin_capture.py` and lands in a single INBOX folder with a source and timestamp attached. Captures can come from a Discord link, a thought from my phone, or a page from the web clipper. The process takes under ten seconds and requires no filing decisions at capture time, because filing at capture time is where second brains die. Joplin already ships with a REST API. I enable it with one setting and one token; the notebook then exposes HTTP on localhost:41184 with token authentication on every call. The same server powers the official web clipper, so this enables infrastructure I use anyway. There is no plugin, cloud service, or subscription. `joplin_filer.py` runs daily at 07:00 and uses a deterministic classifier to score each INBOX note against my existing folders. It uses token coverage rather than Jaccard, which dilutes single-token folders. Confident matches above 0.5 are moved into place: a hosting page goes to the hosting folder, while a security note goes to the security folder. Low-confidence notes stay in INBOX with the `needs-review` tag. Every move is logged to a FILER LOG note in the `__SYSTEM` folder, making the process auditable. The filer never deletes anything. I ran it in dry-run mode for a week before letting it touch a single note, and I recommend doing the same. When I want to know what I have learned, `joplin_ask.py` searches the corpus, reads the top notes in full, and answers with the note titles attached. It answers strictly from retrieved content. If the top hits are irrelevant, I refine the query before concluding there is nothing. It never invents a source, which matters when you write about security for a living. After each working session, `joplin_agent_log.py` prepends a digest to an AGENT LOG note in `__SYSTEM`. The log is newest first, append only, and syncs to my devices like everything else. The agent’s memory records what we did, decided, and deferred in the same place as the notes. The whole build is on GitHub: github.com/ciberjohn/mysecondBrain. It includes five Python scripts and the `joplin-brain` skill, which is the operating manual in a format another agent can load and follow. Step-by-step: 1. I enabled Joplin’s built-in REST API with one setting and one token. It serves HTTP on localhost:41184 with token authentication on every call and also supports the official web clipper. 2. I pointed Hermes Agent on my existing VPS at the Joplin REST API. 3. I routed every capture through `joplin_capture.py` into a single INBOX folder, attaching the source and a timestamp. Captures can come from Discord, my phone, or the web clipper. 4. I configured `joplin_filer.py` to run daily at 07:00 and score INBOX notes against my existing folders using token coverage rather than Jaccard. 5. I moved matches with scores above 0.5 into their folders, while leaving low-confidence notes in INBOX with the `needs-review` tag. 6. I logged every move in a FILER LOG note in the `__SYSTEM` folder and ensured that the filer never deletes anything. 7. I ran the filer in dry-run mode for a week before allowing it to move a note. 8. I used `joplin_ask.py` to search the corpus, read the top notes in full, and answer questions with the source note titles attached. When results were irrelevant, I refined the query. 9. After each working session, I used `joplin_agent_log.py` to prepend a digest to the newest-first, append-only AGENT LOG note in `__SYSTEM`. 10. I used Dropbox to sync notes between my devices and the REST API to move notes between Joplin and the agent—two separate pipes carrying the same notes in different directions.

I’m a nerd for deals, so I built a Personal Credit Card Optimizer in ChatGPT. I wanted a simpler way to figure out which store and card would save me the most money on any item I want to purchase. The workflow maintains a database of my credit and debit cards—recording their series, but not their exact numbers—along with their rewards, fees, and benefits. Whenever I want to buy something, I add a product link. It scans retailers for better prices, checks current bank offers against my specific cards, and compares instant discounts, cashback, reward points, and other benefits to determine where I should buy and which card will provide the most value. It’s now an ongoing skill in my ChatGPT project. No more manually checking a dozen bank offers or discovering at checkout that my card isn’t eligible. Step-by-step: 1. I add my credit and debit cards to a database by recording their series, rewards, fees, and benefits without entering their exact numbers. 2. When I want to purchase something, I provide a product link. 3. The workflow scans retailers for better prices on the product. 4. It checks current bank offers against my specific cards. 5. It compares instant discounts, cashback, reward points, and other benefits to determine the best retailer and card combination.

I built a workflow that prepares late invoice reminder emails for me. Our industry has tight margins, and our back end is rudimentary with limited capabilities, so sending these reminders was annoying, repetitive manual labor. I had Claude Cowork walk me through creating an agent that logs in every Monday night, checks our late AR, and compares the customer names against a Google Sheet list I created. It uses an email template I provided, adds the contact name from the Sheet, and includes each late invoice’s identifying number, amount, and due date. The agent puts the emails in my Drafts folder and emails me a report showing which customers were included, how much each one owes, and the totals. All I have to do is review the drafts, confirm everything looks good, and hit Send. This has saved me about an hour every Monday night of tedious, repetitive manual labor. Step-by-step: 1. I created a Google Sheet with the customer names and contact names. 2. I had Claude Cowork walk me through creating an agent that logs in every Monday night. 3. The agent checks our late AR and compares the customer names against the Google Sheet. 4. It uses my email template and adds the contact name, invoice identifying number, amount, and due date. 5. It places the completed emails in my Drafts folder. 6. It emails me a report listing the included customers, the amount for each, and the totals. 7. I review the drafts, confirm that everything looks good, and send them.

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.

I built a custom web app that uses chance to combine random images and texts into new, unplanned pairings. It recreates a Dadaist technique I use often when making photobooks, which I previously did manually with physical prints. I used Replit to create a digital version of the game. It was easy to connect the app to Project Gutenberg for random texts and the Library of Congress photography archive for images. More importantly, I made it possible for users to work with their own image and text archives. So far, it has produced many new and interesting results, and other artists have used it too. Step-by-step: 1. I identified the manual process I use when making photobooks: combining printed images and texts by chance. 2. I used Replit to build a digital version of this process as a web app. 3. I connected the app to Project Gutenberg to pull random texts. 4. I connected it to the Library of Congress photography archive to pull images. 5. I allowed users to work with their own image and text archives. 6. I used the app to create new pairings and shared it with other artists, who used it as well.

I built a meal tracker where my only job is to photograph a plate and send it to an agent. Identification, portion estimates, macros, storage, corrections, and the weekly review happen without me. The part worth stealing isn't the food. The agent has its own email address and iMessage thread, so anything I can send from my phone becomes an input. I send a photo through whichever channel takes fewer taps. I send corrections as plain English with `CORRECTION` in the subject, and answer questions in the same thread. There’s no app and no form. Adding a channel took an afternoon and changed what the agent could be pointed at—the tracker is just one use of an agent you can talk to. It polls on a schedule instead of using a webhook because my laptop sleeps and a local gateway would be unavailable half the time. Storage is append-only JSONL. Corrections append a new record with the same ID using last-write-wins, so the stats layer sees one meal while the original estimate stays on disk. Every number can be traced back to the model’s first guess and my override. The accuracy mechanism is a challenge step. Every photo is estimated twice: first by the main model, then by a blind subagent that receives only the photo and the rubric—not the first answer. If it identifies different food, the entry is downgraded to low confidence and becomes a question for me. Testing before making the system autonomous caught bugs that otherwise would have failed silently. The API returns attachments under a different field than I had assumed, and only on the detail endpoint. As a result, a photo email was read as having no attachments, and every meal photo would have been dropped while the daily task logged a tidy “no new meals” and appeared healthy. The send path was separately broken, which would have killed the weekly review on a Sunday even with everything upstream working. A silent no-op that produces a plausible clean run is what this category of build is prone to. The bug that actually cost me was token usage: each blind challenge read used about 44,000 tokens, so a five-photo dinner cost roughly 220,000 tokens for one meal and capped my usage. The fixes, in order of effect, were to run the challenger on a cheap model, skip it once a named product or my confirmation has settled the entry, downscale photos for viewing, and republish the dashboard only when the data changes. Measuring first mattered—I would have blamed photo size, but that was the smaller half. The honest limits are important: calorie estimates from a photo are 20–25% off at best, identification error is a bigger risk than arithmetic error, and alcohol, water, and caffeine are never estimated from photos. The sequence in which I asked for things mattered more than any single instruction: Step-by-step: 1. I gave the goal and the one ingestion mechanic I was sure about, then insisted on an agreed plan before any code. Arguing about storage and failure modes is cheap before code is attached. 2. Before scheduling anything, I processed one real input end to end in front of me, including every outbound path. Inbound gets tested because I use it; the reply and the weekly digest do not. 3. When the agent reported something about my own input that I knew was wrong, I said so and made it re-check. Confidently wrong answers about things I witnessed were the cheapest bugs to find. 4. I asked for an independent second assessment of anything estimated rather than read, and decided up front what level of agreement was enough to accept the result. 5. I asked for a visible audit surface showing every field the agent claims to track, with a correction control on it. 6. I asked the agent to look up anything knowable rather than estimate it. A named product is a lookup; only the unnameable needs a guess. 7. I treated approval friction and token cost as requirements rather than complaints, and measured before changing anything. Almost every rule exists because something went wrong in ordinary use, not because it was designed up front. An agent I can email or text, which keeps records and answers back, is general-purpose; I’ve pointed it at one narrow job. What else would you point it at?

My doctor asked me to track my blood pressure for a month because it was on the high side before prescribing any medication. I initially recorded each reading manually in an Excel sheet, but after a few days, I wanted a simpler way to enter and manage the data. I uploaded the sheet to Claude Code and asked it to build a blood pressure tracking app. After the app was built, I hosted it on Netlify, used Supabase as the backend to save data for both my wife and me, and added it to my iPhone Home Screen. Step-by-step: 1. I started tracking my blood pressure in an Excel sheet as my doctor requested. 2. After several days of entering the readings manually, I uploaded the sheet to Claude Code. 3. I asked Claude Code to build an app for tracking blood pressure. 4. I hosted the app on Netlify. 5. I used Supabase as the backend to save blood pressure data for both my wife and me. 6. I saved the app to my iPhone Home Screen for easier access.

I built a personal daily tracking system called Artifact. It gives me a way to log my days and turn the data into decisions over time. To use it, I copy everything attached—or screenshot the included “green orange red” example—and paste it into my AI assistant, preferably Claude. The assistant briefly interviews me and then builds a personalized daily tracking system.