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

AI is useful for researching investments, but most workflows stop at “What should I buy?” The harder part comes afterward: Does the idea make sense given what I already own? What would make me add to the position? When should I take profits? What evidence would prove the original thesis wrong? And how do I track all of that without constantly watching the market? I use AI to turn a one-time investment research session into an ongoing decision and monitoring system. I start by asking AI to research the market for potential opportunities. In my case, I look specifically for strong mean-reversion trades, but the same workflow could start with value opportunities, macro themes, sector rotations, individual stocks, crypto, or almost any other investment strategy. Then I give AI my actual portfolio so it can evaluate those ideas in context. After I decide which recommendations I agree with and manually make the trades, I have AI convert each investment thesis into explicit rules for what should happen next. Finally, I turn those rules into automated monitors that periodically check market conditions and alert me only when something happens that warrants another decision. Step-by-step: 1. I define what I’m looking for by asking AI to research potential investment opportunities using criteria I care about, such as mean reversion, valuation, momentum, macro conditions, risk/reward, or another strategy. 2. I have AI investigate current market conditions and rank the opportunities, narrowing a large universe down to a manageable set of ideas worth examining further. 3. I pressure-test each thesis by asking why the opportunity exists, what could drive the expected outcome, what the major risks are, and—most importantly—what evidence would invalidate the thesis. 4. I provide my current holdings so AI can identify overlapping exposures, concentration risks, hedges, or positions that conflict with the new ideas. 5. I ask AI which existing positions the research suggests reviewing and where new exposure might make sense. The goal is a small number of actionable decisions rather than a giant list of interesting trades. 6. I review the analysis and independently decide whether to buy, sell, hold, or do nothing. I keep actual trade execution under human control. 7. Before the market moves, I define the next decision for every position by asking AI to identify conditions that would warrant reviewing whether to: - Add - Take profits - Reduce exposure - Exit - Reconsider the original thesis 8. I turn those conditions into automated monitors. I have ChatGPT periodically check the relevant prices, yields, economic indicators, news, or other variables. Instead of sending routine updates, I tell it to alert me only when a predefined trigger occurs. 9. When a trigger fires, I return to the original thesis with the new information and decide what—if anything—should change. Instead of using AI for isolated investment recommendations, I now have a repeatable loop for managing an investment thesis over time: Find an opportunity → Understand it → Compare it to what I own → Make a decision → Define what would change my mind → Let AI watch for it The most useful part may actually come after the investment decision. By deciding in advance what evidence would make me add, take profits, or reconsider the thesis, I don’t have to start my analysis from scratch every time the market moves. AI becomes a persistent research and monitoring layer while I remain responsible for every investment decision and trade.

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

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

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

I've been thinking about the value of handoff documents and explanatory documents as we continue exploring efficient ways to work alongside AI to build software and improve communication. Even though we use many different tools, Markdown still has an important place. This new version of an HTML handoff document can document what exists, describe what could exist, or serve as a mockup for a brainstorm. It lets us communicate with remarkable fidelity through visuals, hierarchy, and formatting. It's also an efficient format for AI to understand. We shouldn't underestimate the significance of AI communicating with us through a visual medium. A visual flowchart with thoughtful design, layout, animation, and progressive disclosure can help us understand the logic and flow of incredibly complex systems much faster. I tried all kinds of tools, including React Flow and Mermaid. They're fun to experiment with, but Archify is a game changer for this use case. I can point it at any technology, repository, or brainstorm and work with it to build flowcharts with animations and clean, distinctive design. It's also completely free. https://tt-a1i.github.io/archify/# Step-by-step: 1. I identify whether I need to document what exists, explore what could exist, or mock up a brainstorm. 2. I use Markdown and an HTML handoff document to communicate the ideas with visuals, hierarchy, and formatting. 3. I consider tools such as React Flow and Mermaid for creating visual representations. 4. I point Archify at the relevant technology, repository, or brainstorm. 5. I work with Archify to develop a flowchart with animations, clean design, and progressive disclosure so the system's logic and flow are easier to understand.

An AI “executive brain” needs two things: intelligence that, combined with your context, forms the system’s “brain,” and a harness that gives it “hands”—the agentic capabilities to act on your behalf. Claude Code and Codex are two popular options. Their apps provide both the model and the harness in an easy-to-use interface. My workspace is GitHub because popular AI models already understand it and can handle its setup and administration for me. GitHub also syncs automatically with the local file system on my MacBook, so I retain complete ownership and control. If I ever wanted to leave GitHub, I could do so without lock-in. The same setup can work in any file system, from your local file system or Google Drive to a more sophisticated option like Obsidian. A good manager has a structured process for onboarding and staying aligned with a team. You need the same structure to work effectively with AI. My “executive brain” has four layers: the company layer, project folders, operations folders, and the process layer. The company layer contains the mission, vision, values, brand guidelines, and decision-making principles. Project folders contain one folder per project, including its specification, plan, open questions, and decision log. Operations folders cover ongoing areas of the business, such as marketing, finance, and support. They have the same shape as project folders, but they never finish: projects ship, while operations run. The process layer contains standard operating procedures for how we work together, such as processing a meeting, planning a project, publishing a post, and closing out the week. For AI to work successfully, your company has to be “legible” to it. If information is not written down and accurate, it is not legible, and the AI cannot help you with it. This is like onboarding a great new hire: explain what the company is trying to do, what each project is for, what has already been decided and why, and how you like to work. You do not need to write everything alone or all at once. The AI can interview you, draft the documents, and file them in the right place based on the structure you set up. An employee without logins cannot do much, and AI works the same way. Start with the places where you communicate. At my company, we primarily communicate through Zoom and our community forums, so my AI system is connected to both. This allows it to stay up to date as we progress and participate in discussions as an equal participant when asked. Once the AI is connected to your communications, give it access to the places where you want it to execute on your behalf. You can connect it directly through an API or MCP, or it can use a browser to interact with a tool the same way you do by clicking and typing. You decide what it can access, and you can start small. Each connection turns a category of “things I have to do myself” into “things I can delegate.” The final step is incorporating what the AI learns. After every working session and meeting, it updates the record: decisions are logged, task lists are reconciled, and project documents are brought up to date. When we learn something, it goes into the SOP, so every future run is sharper than the last. That is how the AI becomes more useful every week: its knowledge compounds inside the business instead of starting from zero in every conversation. Step-by-step: 1. Choose the intelligence and harness that will power your AI system. Claude Code and Codex are two popular options whose apps provide both in an easy-to-use interface. 2. Create a workspace for alignment, planning, feedback, and learnings. I use GitHub because AI models understand it, it handles setup and administration, and it syncs with my local MacBook file system without locking me in. 3. Organize the workspace into four layers: company information, project folders, operations folders, and process documentation. 4. Make the company legible by documenting its goals, projects, decisions, working preferences, and other relevant context. Have the AI interview you, draft the documents, and file them in the appropriate locations. 5. Connect the AI to your communication tools, such as Zoom and community forums, so it can stay informed and participate when asked. 6. Connect the AI to the systems where you want it to execute tasks. Use a direct API or MCP connection when available, or give it browser access when it is not. 7. After each working session and meeting, have the AI update decisions, task lists, and project documents. 8. Add new learnings to the relevant SOP so each future run improves on the last.

I needed home insurance and was asked to estimate the value of all my personal belongings. I asked Claude to search my personal email and make a list of all the purchases I had made in the past year. I asked my husband to do the same and share his list with me. I also made a list of our valuables and took a picture of each room in the house. I gave all of that information to Claude, which produced a list of everything I owned and estimated its rough value. It cross-referenced the purchases with the items visible in the photos to make sure I did not double-count anything. I sent the list to my insurance broker, who said it was extremely helpful and could also serve as supporting evidence if I ever needed to submit an insurance claim.

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.

I moved from public school to a private school with no autism-specific training, and I found students on the spectrum struggling with one-size-fits-all lessons. AI helped close that gap for both me and my students in about five minutes per lesson. I take a standard lesson and rebuild it around the individual student. I upload only the blank assignment—never any student data—and prompt AI to adapt it to that learner. I include their favorite colors and niche interests, replace abstract examples with personalized ones, add sentence starters, and allow them to draw responses instead of writing dense paragraphs. Step-by-step: 1. I take an existing lesson and create a blank version of the assignment. 2. I upload only the blank assignment to my AI tool, without including any student data. 3. I provide the student’s interests, preferred colors, and reading level. 4. I ask the AI to rebuild the lesson for that specific student. 5. I use personalized examples, sentence starters, and drawing-based response options to make the lesson more accessible. The result is no shutdowns, no walls, and a genuinely engaged and grateful student. One untrained teacher can now individualize any lesson for a unique learner in minutes.

Turn a collection of documents, reports, spreadsheets, and notes into an evidence-backed decision brief with ChatGPT. Instead of asking AI to simply summarize the information, this workflow makes it identify what matters, connect the evidence, compare it with historical context, explore scenarios, and highlight what should be considered before making a decision. Step-by-step: 1. I gather the information relevant to one decision, including reports, PDFs, spreadsheets, research, historical data, meeting notes, and existing analysis. I upload everything into ChatGPT. 2. I ask ChatGPT to understand the situation using this prompt: > “Analyze the information I provided and build a structured understanding of the situation. Identify the key entities, important facts, relationships, metrics, trends, assumptions, and constraints. Do not make recommendations yet.” This creates the context before jumping to conclusions. 3. I build an evidence brief by asking: > “Create an evidence brief. Separate verified facts, derived insights, assumptions, conflicting information, and missing information. For every important conclusion, identify the supporting source or evidence.” This gives me a clearer picture of what is known versus what is inferred. 4. I add historical context when it is available by asking: > “Compare the current situation with the historical information provided. Identify meaningful patterns, similarities, differences, and changes. Highlight which historical observations could be relevant to the current decision.” This turns historical data into context rather than simply another report. 5. I explore three scenarios by asking ChatGPT: > “Based on the evidence and historical context, evaluate three scenarios: upside, base case, and downside. For each scenario, identify the assumptions, key drivers, risks, likely impact, and evidence supporting the assessment.” The objective isn't to pretend the future can be predicted perfectly. It is to understand how the decision changes when assumptions change. 6. I generate the decision brief by asking: > “Create a concise decision brief containing: > > 1. Current situation > 2. Most important evidence > 3. Key insights > 4. Historical context > 5. Critical assumptions > 6. Key risks > 7. Scenario analysis > 8. Evidence gaps and uncertainties > 9. Questions that should be investigated > 10. Possible actions and their implications. > Do not make the final decision on my behalf.” This produces a structured decision brief instead of another AI-generated summary. 7. I review the brief and challenge its conclusions before making the decision. I ask follow-up questions such as: > “Which assumption has the greatest impact on this decision?” > “Show me the strongest evidence against the current conclusion.” > “What information would most likely change the recommendation?” The AI helps structure the decision, but I make the decision. The important shift is: Summarize the information → Understand the situation → Establish the evidence → Add historical context → Explore scenarios → Evaluate the decision This approach can be applied to almost any domain where decisions depend on complex and interconnected information. A property investment is one example. A business strategy, product decision, operational problem, financial analysis, research question, or engineering decision can follow the same pattern.

After nearly 20 years in France, I’m finally applying for citizenship. I’ve spent the past year preparing documents and studying for the required tests, and my final interview is a few weeks away. Alongside the official study materials, I’ve been using ChatGPT to drill key facts and historical dates, run mock oral interviews in voice mode, and create quizzes from YouTube videos I link whenever they cover the right material. ChatGPT sometimes speaks French with a rather heavy accent, but the interactive back-and-forth helps me remember hundreds of details that are difficult to retain by simply reading a page. It’s tedious, but I find rote memorization challenging. We’ll see how it goes under pressure.

I built an AI workflow to automate guest-posting outreach. I use Claude to analyze target website requirements, draft personalized pitch emails for editors, and optimize my responses so I can pursue high-quality backlinks more efficiently. Step-by-step: 1. I provide Claude with the requirements for each target website. 2. I use Claude to analyze those requirements and identify what to address in the outreach. 3. I ask Claude to draft a personalized pitch email for the editor. 4. I use Claude to optimize my responses during the outreach process.

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 love playing poker, both online and live. One month, I performed poorly. Although it felt like the cards were running badly, I wondered whether I had developed a problem in my game and was blaming my losses on bad luck. I asked around, including asking AI, whether a tool existed that could measure luck from poker hand histories. The unwelcome answer was that it did not. I'm not a coder, but after doing some research into vibe coding, I started building a luck-detection app in a Claude chat. Claude built the UI directly in the chat window and advised me on the formulas I was using to calculate luck for the cards dealt, my performance on the flop, and my performance when I went all in. All three metrics have strong averages, and luck is what varies them. I used a bell curve to model hand outcomes and a Monte Carlo simulator, which Claude suggested and executed, to evaluate all possible outcomes. The result astonished me because it was so useful. I immediately fixed two major leaks in my game and felt better knowing that bad luck really was the main problem affecting my results. I liked the tool so much that I decided to turn it into a full web app with Claude Code, and now an iPhone app that I may let other people use for free. I also had a lot of fun building it—except for learning how to use Xcode. That was a pain, even with step-by-step guidance from Claude. Step-by-step: 1. I reviewed a month of poor poker results and questioned whether bad luck or problems in my game were causing the losses. 2. I researched whether a tool existed that could measure luck from poker hand histories and learned that I would need to build one myself. 3. I used vibe coding to start building a luck-detection app in a Claude chat. 4. I had Claude create the UI and advise on formulas for evaluating cards dealt, flop performance, and all-in performance. 5. I used a bell curve to model hand outcomes and a Monte Carlo simulator to evaluate possible outcomes. 6. I used the results to identify and fix two major leaks in my game and confirm that bad luck was also affecting my results. 7. I expanded the project into a full web app with Claude Code and then began building an iPhone app, working through the added challenge of learning Xcode.

I teach and direct a required general education public speaking class at a small college. I’ve built the course around critical inquiry, critical thinking, and public advocacy of a localized problem. Over the years, I’ve noticed that students are increasingly reluctant to engage with the underlying problem. They are often content to identify a problem with enough certainty that they assume their perspective is obviously shared by everyone else. They may also believe that their preferred sources are more certain or credible, leading them to build a case based only on their limited perspectives. With the help of ChatGPT, I built an AI tool that guides students through the problem- and solution-discovery process. It begins with a general question: “what is your topic and what is the problem?” Students often respond with a one-word or incomplete answer, such as “poverty,” “crime,” or “the high cost of education.” These answers do not identify the topic’s deeper dimensions, the extent of the harm, or who is affected by the issue. The AI pushes back on these statements and helps students explore the issue in greater depth. It consistently asks, “what do you mean by x?” I constrained the AI to draw most of its knowledge from the coursepack I wrote for the class, which outlines the assignments, lessons, and instructional content. This keeps the tone of the interaction and the examples provided to students aligned with the overall feel of the course. The AI does not create speeches, make outlines, or find sources for students. Instead, it asks questions that help them refine the direction of their speeches. Whenever possible, the AI also identifies alternative viewpoints from sources traditionally associated with the student’s own perspective. For example, if a student is advocating a progressive viewpoint, the AI may identify statements or research from progressive sources that disagree with that perspective. If the student is advocating a conservative viewpoint, it may identify statements or research from conservative thinkers that challenge the student’s position. This helps students recognize the complexity of ideas and understand that people on the same political, religious, or ideological side do not necessarily agree on every topic. As is often the case when I build GPTs, the 8,000-character limit requires me to move many instructions into a document that I upload to the GPT’s resources. ChatGPT is helpful when I decide which content belongs in the configuration and which content can go in an uploaded document. Step-by-step: 1. I designed the public speaking course around critical inquiry, critical thinking, and public advocacy of a localized problem. 2. I identified a recurring challenge: students often named broad topics such as “poverty,” “crime,” or “the high cost of education” without exploring the depth of the issue, the degree of harm, or who is affected. 3. With help from ChatGPT, I built an AI tool that begins by asking, “what is your topic and what is the problem?” 4. I configured the AI to push back on incomplete answers by repeatedly asking, “what do you mean by x?” 5. I constrained the AI to draw most of its knowledge from my coursepack, including the class assignments, lessons, and instructional content. 6. I instructed the AI to guide students with questions rather than create speeches, make outlines, or find sources for them. 7. I configured it to identify alternative viewpoints, including disagreements from sources traditionally associated with the student’s own political, religious, or ideological perspective. 8. Because of the 8,000-character limit, I moved some instructions into a document uploaded to the GPT’s resources and used ChatGPT to help decide what belonged in the configuration and what belonged in the document.

I built a weekly interactive training-course generator for my 10-year-old son and eventually landed on a much simpler final version than where I started. I wanted a way to teach him practical safety and life skills, starting with how to swim confidently and what to do if he gets into trouble in the water. I needed something more engaging than simply talking at him, but writing a polished, interactive lesson from scratch every week was not sustainable. First, Claude and I designed a single interactive HTML course as a proof of concept. It was a swim-safety course with a branded look, including a custom color palette, fonts, and a progress tracker styled like pool lanes. The course was divided into modules: a welcome screen, a comfort-and-basics lesson, a step-by-step skills walkthrough, a safety checklist, a “what to do if something goes wrong” module, a quiz, and a certificate at the end. The “what to do if something goes wrong” module was the most important part. Once the course worked, I wanted to reuse the same format for a new topic every week. Claude first built a version that called the Claude API live from inside the page to generate new content on demand. However, it only worked while the page stayed open inside Claude.ai, and occasionally a section failed to generate cleanly. We pivoted to a simpler approach. Instead of using a live tool, Claude documented the entire course format—including the visual identity, module structure, tone, and content rules—as a standing “brief” document. Each week, I open Claude Cowork, paste in the brief and that week’s topic—bike safety, fire safety, or whatever is next—and Cowork returns a finished, fully self-contained HTML file. There is no app to babysit and no live API call; I can simply open the file and hand it to my son. The result is a repeatable, no-maintenance weekly workflow for turning any topic into a polished interactive lesson for my kid. Step-by-step: 1. I identified a need for more engaging lessons on practical safety and life skills, starting with swimming and water safety. 2. I worked with Claude to create a proof-of-concept interactive HTML swim-safety course. 3. I structured the course into a welcome screen, comfort-and-basics lesson, skills walkthrough, safety checklist, emergency-response module, quiz, and certificate. 4. I tested a live-generation version that called the Claude API from inside the page, then noted that it only worked while open inside Claude.ai and that sections sometimes failed to generate cleanly. 5. I had Claude document the course’s visual identity, module structure, tone, and content rules in a reusable brief. 6. Each week, I open Claude Cowork, provide the brief and a new topic, and receive a finished, self-contained HTML course file. 7. I open the file and give the interactive lesson to my son without maintaining an app or making live API calls.

I took a picture of my wife's spice rack, uploaded it to Grok, and asked it to organize the contents into three categories: Must Have, Keep, and Discard, based on age or lack of common usage. Step-by-step: 1. I took a picture of my wife's spice rack. 2. I uploaded the picture to Grok. 3. I asked Grok to categorize the contents as Must Have, Keep, or Discard based on age or lack of common usage.