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

My friend shot a short film and gave me his hard drive to help with post-production. It contained more than 400 clips, with no clear way to tell when each one had been shot. I asked Claude to review the metadata for every clip and group them by timestamp, so they were organized by shoot session instead of sitting in one large folder. Claude also built a spreadsheet listing each clip, its shoot session, the date, runtime, and file size. This saved my friend the hassle of reviewing every clip manually. Step-by-step: 1. I received my friend’s hard drive with more than 400 short-film clips. 2. I asked Claude to review the metadata for every clip. 3. I had Claude group the clips by timestamp and organize them by shoot session. 4. I had Claude create a spreadsheet with each clip’s shoot session, date, runtime, and file size. 5. My friend could avoid going through every clip manually.

One email instead of 50: an n8n workflow that reads all my AI newsletters and sends me a single daily digest in under 2 minutes THE PROBLEM: I subscribe to dozens of AI newsletters. The Rundown, Superhuman, TLDR, The Neuron, AlphaSignal, TheSequence, Turing Post and many more. Reading them took hours every day, and most of them cover the same three stories. I wanted the coverage without the reading time. So I moved every subscription to a dedicated Gmail address and let n8n read that inbox for me. It has run daily since February 2026 and I now read one email a day instead of 50. STACK: n8n (hosted on Hostinger), Gmail, Google Gemini 2.5 Pro. HOW TO BUILD IT: STEP 1: Create a dedicated Gmail account and move every newsletter subscription to it. This one decision makes everything else simple. Your personal inbox stays clean and the workflow never touches mail that is not a newsletter. STEP 2: Schedule Trigger node, daily at 08:00. Set the workflow timezone (mine is Europe/Stockholm) or the trigger runs on server time. STEP 3: Gmail Get Many Messages node on the newsletter account. Filter by read status: unread. Return All: on. Simplify: OFF. That last toggle matters, see gotcha 2. STEP 4: Connect two branches off that node. Branch one is a Gmail Mark As Read node with message ID {{ $json.id }}. Unread is the whole state system: each run only fetches what arrived since the last run. No database, no date filters, no dedupe logic. STEP 5: Branch two is an Aggregate node. Aggregate the "html" field of every email into one array field called CombinedNewsletter. This means one AI call per day instead of one call per email. STEP 6: AI Agent node with a Google Gemini Chat Model attached (models/gemini-2.5-pro). Turn on Retry On Fail with 5000 ms between tries. The prompt: Below is all the news in html format. Only use what is provided; if the HTML looks cut off, still summarize everything you can see. {{ $json["CombinedNewsletter"].join('\n\n').substring(0, 250000) }} The substring cap is load bearing, see gotcha 1. System message (verbatim, numbering written as (1) so this form does not strip it): "You will receive ALL the AI newsletters from the past day in HTML format. Your task: (1) Extract every distinct news item (no duplicates, even if repeated in multiple newsletters). (2) For each item, find: a short, human-readable title, the best URL, a one-sentence summary (max 25 words). (3) Estimate popularity based on how many newsletters mention it. If an item appears only once, rank by how interesting the general public might find it. Output format (Markdown only): # Daily AI News Digest, then '## Top headlines' listing the 5 most popular/important items as 'Title Summary sentence', then '## More news' listing all remaining items in the same format. Rules: Always use Markdown links like Title, never show bare URLs. Do not skip any news item. Do not add any commentary, explanations, or closing text beyond the structure above." STEP 7: Markdown node, mode Markdown to HTML, destination key combinedHTML. STEP 8: Gmail Send node to your personal address. Subject: Here's ALL the AI News! {{now.toFormat('yyyy-MM-dd')}}. Wrap {{ json.combinedHTML}} in a full HTML document with inline CSS: white card, max-width 720px, system fonts, styled links. See gotcha 4. FOUR THINGS THAT COST ME HOURS: (1) Raw newsletter HTML broke Gemini. The workflow refused to execute with a payload limit error. Newsletter HTML is enormous: tracking pixels, nested tables, inline styles. Fifty of them concatenated is millions of characters. The .substring(0, 250000) cap in the prompt fixed it, and the "if the HTML looks cut off, still summarize" line tells the model how to handle the truncation. (2) Gmail's Simplify toggle is on by default and strips the message body. Gemini kept receiving empty or gutted content and no error explained why. Turn Simplify off to get the full html field. (3) Gemini rate limits AND timeouts both hit on big runs. Retry On Fail with a 5 second wait fixed both. Without it, one 429 kills the whole morning digest. (4) Sending the model's raw markdown as email looked broken in Gmail. Two part fix: a Markdown to HTML node, then a proper HTML template with CSS in the send node. RESULT: the latest real run turned 50 unread newsletter emails into one clean digest in less than 2 minutes (1 minute 27 seconds to be exact). Running every morning since February 2026. Honest failure mode: mark as read runs as a parallel branch, so if Gemini fails after all retries, that day's emails are already marked read and drop out of tomorrow's digest. I accepted that trade off. The alternative is duplicate items on every retry, and one missed day costs less than a digest full of repeats. Rebuild time: about 30 to 45 minutes if the dedicated inbox already exists.

A while ago, my dad told me he wanted to use AI to analyze World Cup matches. He had never coded before, and his AI experience was mostly limited to occasionally asking Gemini a question. I installed Claude Code for him and gave him a few prompting tips. He ended up building a full football analytics site himself and deploying it on Vercel so he could show it to his friends. Getting started with AI is easier than people assume. Sometimes, you just need a project you genuinely want to make. Now that the Premier League season has kicked off, he’s already reworking the site for it. Step-by-step: 1. I helped my dad choose a football analytics project he genuinely wanted to build for analyzing World Cup matches. 2. I installed Claude Code for him, since he had never coded before. 3. I gave him a few prompting tips and let him use AI to help build the site. 4. He built a full football analytics site himself. 5. He deployed the site on Vercel so he could show it to his friends. 6. After the Premier League season kicked off, he began reworking the site for the new competition.

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 small GPT automation called PatternSpeak that periodically looks back across my conversations for ideas, themes, or approaches that keep resurfacing over time. It is not meant to analyze me or turn recurring thoughts into tasks. Its job is much simpler: occasionally say, in effect, “Hey, this idea keeps coming back. Maybe there is something here.” I like it because repetition can be meaningful without being urgent. Sometimes an idea disappears for weeks and then returns in a completely different context. PatternSpeak helps me notice those echoes without forcing them into a productivity system. It feels less like tracking and more like having a friendly observer tap me on the shoulder when a thread has quietly become a pattern. It works very well with the scan and analysis workflow I also shared here. Step-by-step: 1. I use PatternSpeak to periodically look back across my conversations. 2. It identifies ideas, themes, or approaches that keep resurfacing over time. 3. When it notices a recurring thread, it surfaces it as a gentle prompt rather than turning it into a task. 4. I review the recurring ideas and notice whether they have become meaningful patterns, even when they return in different contexts. 5. I use the scan and analysis workflow I also shared here alongside PatternSpeak.

I read the news every day, but it had become increasingly depressing and was making me miserable. What bothered me most was that it also felt inaccurate: although bad things are happening, there have been many positive developments over the past five years that rarely receive sustained coverage. Major news sites might publish an article or two about them, but those stories are quickly buried under negativity. I wanted a way to get only positive news stories in my feed each day. Keyword filters did not work: “record” and “breakthrough” also appear in stories about record wildfire seasons, while “war” can appear in “war ends.” Off-the-shelf sentiment analysis was not useful either. A happy press release about layoffs can be classified as positive, while a dry factual story about a disease being eliminated may be classified as neutral. So I trained a basic artificial version of my personality using a series of prompts about what I consider positive in the world. I connected it to Mistral through OpenRouter and gave it access to public RSS feeds from news sites I already trusted. This eventually became Rally News, which I published on Google Play. iOS has been more difficult. The app surfaces positive stories from more than 20 news sites in an endless scroll, giving me an alternative to my uncomfortable TikTok addiction. Because I made it public, I decided not to host article text: publishers keep their traffic and revenue, while the tool remains ethical. The system runs on a GitHub Actions cron job that pushes stories to a PHP and MySQL database. I built the app without coding experience for about $25 per month. Step-by-step: 1. I collected RSS feeds from established publishers I already trusted and stored the list as configuration. I started with about 10 feeds instead of a few hundred so I could realistically read the output. 2. I set up a scheduled GitHub Actions cron job to run a Python script that pulls new items from every feed. 3. I deduplicated incoming articles against the database using the URL and a normalized title. Syndicated stories frequently reappear under slightly different URLs, and I did not want to pay to evaluate the same article twice. 4. I wrote the filter prompt as a long persona document rather than a one-line instruction. It explains what I consider progress, what I consider a puff piece, and which cases should fail—for example, celebrity news is not good news, a company announcing an intention is not the same as taking action, and a local feel-good story without wider significance does not qualify. 5. I sent each new article to an LLM through OpenRouter and required JSON output containing a pass-or-fail decision and a short justification. 6. For the first few weeks, I read the justifications every day. Whenever I disagreed with the model, I added a new rule to the persona document. That review loop required nearly all of the actual work. 7. I wrote passing articles to MySQL with only the headline, source, link, and metadata, leaving the article body with the publisher. 8. I pointed the website and mobile app to the same database. 9. I added a second GitHub Actions job that assembles a daily newsletter from the same data through Brevo, allowing one evaluation pass to feed three surfaces.

Many organizations have critical process knowledge that exists only in employees’ heads. When someone has a question, they have to track down the right expert, ask questions others may have already asked, and hope they remember every detail. This doesn’t scale and creates knowledge silos. I built a workflow that turns conversations with subject matter experts into structured, searchable organizational knowledge. Instead of asking employees to write documentation, an AI interviewer guides them through the process they know best, converts the conversation into well-structured documentation, and publishes it to an AI-powered knowledge base that anyone can query. Step-by-step: 1. Ask an employee to choose a business process they know well. 2. Have an AI interviewer ask follow-up questions to capture the complete workflow, decisions, exceptions, and best practices through a natural conversation. 3. Save the interview transcript. 4. Use an LLM to convert the transcript into structured documentation with clear sections, steps, decision points, and FAQs. 5. Store the documentation in a searchable knowledge repository and index it in a vector database. 6. Let employees ask questions through an AI assistant that retrieves the most relevant documentation and answers in natural language. 7. Repeat the process over time as processes evolve or additional experts contribute new knowledge. Instead of repeatedly interrupting the same subject matter experts, employees can get consistent answers from an AI assistant backed by documented organizational knowledge. The organization captures valuable expertise before it’s lost, reduces knowledge silos, improves onboarding, and creates documentation simply by having conversations.

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.

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.

How I Use AI: Building a Client's Entire Document System From Scratch I run a boutique accounting practice, and one of my biotech clients — a preclinical oncology company — needed something I didn't have time to build by hand: a real, standardized document management system in SharePoint. Not just folders, but the rules behind the folders — a tagging taxonomy, a naming standard, guides for the team to actually follow it, and a clean way to organize documents for every vendor we work with. The kind of project that's easy to keep putting off because it's tedious, not because it's hard. So I used Perplexity's Computer agent as a genuine working partner on it, not just a search tool. Where it started I already had a first draft of a Tagging Taxonomy and a Document Management Standards document. I asked Computer to review both with an eye toward what a real accounting/finance team would actually need — GAAP-heavy, audit-ready, built for a lean biotech team that's going to scale fast. It came back with concrete recommendations (new functional areas I hadn't accounted for, cleaner naming conventions), and once I gave the go-ahead, it revised both documents into new, cleaner versions — taxonomy v1.1, standards v5.4 — complete with version histories so nothing got lost in the shuffle. Then it went further than I expected: 13 "START HERE" guide files, one for every top-level folder area, each explaining not just what goes where but why, with real examples. That's the part that actually makes a standard stick — nobody follows a rulebook they don't understand. Where it got real Here's the part I'd actually tell someone about: I tried uploading the whole folder structure to the client's SharePoint through the browser, and it failed — quietly, no big error, just close to 100 folders silently missing afterward. I was frustrated, and I said so. Computer didn't get defensive about it — it dug into why, compared the folders that made it against the ones that didn't, found the exact character-length boundary where things broke, and built me a PowerShell script that would fix it if I needed it. Then, while I was testing a fix, I discovered the real answer myself: dragging the folder from my hard drive straight into the OneDrive-linked folder in File Explorer worked perfectly, no script needed at all. When I told Computer that, it didn't just take my word for it — it went and calculated the actual path lengths involved to confirm why that method worked and the browser upload didn't, so I understood the real mechanism instead of just getting lucky once. That back-and-forth — me testing in the real world, it verifying the "why" — is honestly the most useful part of working with it. It's not just generating stuff and hoping it's right. The vendor folder win The last piece was the most tedious one I was dreading: building a dedicated document folder — vendor master file, agreements, POs, invoices, correspondence, the works — for every vendor worth tracking. I pulled a vendor spend report out of QuickBooks, sorted by dollar volume, and picked out the real vendors (CROs, law firms, key consultants) versus the noise (hotels, gas stations, one-off restaurant charges). I handed that list over, and Computer built me a script that took it from there: cleaned up messy vendor names (ampersands, apostrophes, trailing punctuation — all the stuff that breaks Windows folder names), handled the one legal name that was way too long automatically, and made sure nothing silently failed the way the original upload did. It tested the script against my actual vendor list before ever handing it to me, so I wasn't the guinea pig for its own bugs. 133 vendors, 1,463 subfolders, dropped into staging, dragged to OneDrive, and the count matched exactly — 1,474 on the nose once you add back the original template folder. That's not a "looks about right" number. That's a number I checked, twice. Why it's worth it Building this by hand for BreakthruMed Inc. — the folder architecture, the governance docs, 13 training guides, and a dedicated set of folders for 133 vendors — would realistically have taken me a couple of weeks of solid, focused work, not the few days I first assumed. Instead, it took about 28 hours spread across three weeks of back-and-forth, testing, and real-world validation, plus roughly $200 in extra usage on top of my regular subscription. That's a real cost, but a small one next to two or three weeks of my own time — and what I walked away with wasn't just a folder tree. It was a governance framework, training material my team can actually use, and two reusable scripts I'll put to work on the next client — a system I trust, because I checked it, and it checked itself

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.

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

I built a workflow for turning large ChatGPT conversation exports into a usable personal and creative archive instead of simply storing them as backups. The archive is processed incrementally. The inventory is built offline, and conversations that have already been indexed are not needlessly reanalyzed on every run. Each new export is compared with the existing archive, and only newly added conversations or conversations that have been revisited, extended, or otherwise changed are processed again and updated in the inventory. This keeps the workflow lightweight while allowing the archive to evolve over time. A conversation can remain stable for months, then become relevant again and receive new material without forcing the entire archive back through analysis. This matters because many of my conversations are long, layered thinking sessions: creative explorations, project development, research, problem-solving, or extended reflection. Without an inventory, the depth inside those individual conversations and thinking processes becomes difficult to retrieve later. The workflow makes long-form analysis and creative thought processes findable and reusable without flattening them into a few generic summaries. On top of the inventory, I use lightweight “blubscans” (analysis to improve retrieval): small, human-readable summaries that capture what mattered during a day or period without replacing the original conversations. They act as a navigational layer between thousands of raw messages and the things I may want to find, understand, revisit, or continue later. The important principle is that compression never becomes deletion. The raw conversations remain the source of truth, the inventory provides structure, and the scans provide context and tone. The result is more than a backup system. It becomes working creative memory: something I can preserve, search, revisit, connect across time, and reuse for projects, research, writing, pattern-finding, and future creative work. In simple terms, the structure is: raw exports → offline incremental inventory → blubscans/context layer → retrieval and reuse for later projects and creative work That way, the archive stays deep without becoming heavy, and useful without constantly reprocessing everything that was already understood. Step-by-step: 1. I collect large ChatGPT conversation exports as the raw source material for the archive. 2. I build and maintain an offline inventory of the conversations that have been indexed. 3. With each new export, I compare the conversations against the existing archive. 4. I process only newly added conversations and conversations that have been revisited, extended, or otherwise changed. 5. I update the inventory with the results while leaving stable conversations untouched. 6. I create lightweight “blubscans” with small, human-readable summaries of what mattered during a day or period. 7. I use the raw conversations as the source of truth, the inventory for structure, and the scans for context and tone. 8. I retrieve and reuse the archive for projects, research, writing, pattern-finding, and future creative work.

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 workflow called PeopleSparkles for researching people connected to creative fields, schools, collectives, residencies, local art scenes, and cultural networks. The workflow starts from a defined group of people, for example teachers, alumni, artists, current or former members of an association, residents, or associates connected to a specific academy, organization, or cultural scene. A typical research request can be as simple as: “Look at this art website and identify all current and former residents and associates. Build a list. Then research them in batches of ten, checking their websites and other relevant sources, and write a short description of their work. Deliver the results in a format that can be imported into my local database.” Before each new research run, I provide GPT with a ZIP containing the current state of the PeopleSparkles database. This means the research starts from the existing corpus rather than from scratch. New people can be added, existing entries can be expanded, and previously researched people can be recognized before new material is prepared for import. The actual database lives locally on my computer. Apart from the initial development of the code and the research needed to create new lists of people, the database itself runs locally. Once a new batch has been researched and imported, browsing, organizing, scoring, annotating, and using the material does not require the whole corpus to be sent back for analysis. The database also generates a human-readable HTML version with a designed layout, so the research is not trapped inside raw data or spreadsheets. I can browse the people and their notes visually as a small personal research publication, while the underlying structured data remains available for future additions and processing. The “Sparkles” part is personal. I can add my own notes and scores to each person to capture whether their work sparked something in me, and if so, how. That might be curiosity, recognition, inspiration, aesthetic attraction, a strong question, a surprising association, or simply the desire to look again. This means the database does not only record who someone is and what they make. It also records my evolving relationship to their work. Over time, that creates a second layer on top of the research corpus: not just a map of creative people, but a map of resonance. The database also includes a “Surprise me” function that brings up a person from the collection without me choosing them deliberately. This helps break habitual search patterns and allows older, less obvious, or previously overlooked entries to resurface. Someone I barely noticed months ago can suddenly become relevant in a completely different creative context. The purpose is not to create conventional biographies. I am interested in the sparks around a person: what they make, the media and themes they work with, the organizations or people they connect to, and which traces may lead somewhere unexpected. This is particularly useful for creative ecosystems where information is fragmented across artist websites, academy pages, exhibition archives, old posters, association websites, interviews, catalogues, and small cultural organizations. The workflow gathers those fragments into a cumulative research corpus. It also allows the research to grow organically. One artist may lead to a collective, a teacher to a former student, an exhibition to another maker, or an old membership list to someone whose work would never have appeared in a conventional search. In simple terms: existing local database → new source or people list → GPT-assisted discovery and research in batches → import-ready structured data → local database → HTML browsing, notes and scores → surprise rediscovery → new creative connections The result is a living creative research database that combines external research with personal resonance, so I can not only discover people, but also trace which work actually sparks something in me over time.

I built a system that reads my AI newsletters every morning and turns them into a searchable catalog of AI tools, plus a chat website where I can ask questions about the catalog in plain English. The system has two parts: a workflow that collects the information and a website that answers questions about it. I subscribe to several AI newsletters, and each issue mentions five or ten interesting tools. I would read about one and think, “I should remember that.” Months later, I would vaguely remember it but have no quick way to find it. I wanted a repository of these AI tools that I could search easily. The collector is a scheduled Claude Code Routine that runs once a day. It searches Gmail for newsletters from the last 24 hours and reads each email in full. It extracts every AI tool’s name, description, category, official link if present, and source newsletter. It skips non-AI items and pure ads but keeps sponsors that are genuine tools. Before adding anything, it checks for duplicates. New tools are added under the appropriate category in alphabetical order. If an existing tool has fresh details, its description and “last updated” date are refreshed. Tools mentioned by three or more sources receive a “Highly Mentioned” tag, which is a useful signal for what is catching on. The workflow also creates categories when new tools do not fit into an existing one. The workflow commits and pushes the catalog to a private GitHub repository, then posts a summary to Slack. The catalog is a single Markdown file—plain text, human-readable, and versioned in Git, with no database. The chat website displays the tool count, category count, and last-updated date, along with clickable example questions. If I ask, “Is there anything for voice AI?” it returns a written answer listing every match with descriptions and working links. The site is a React single-page app on Netlify with two small backend functions: one returns the statistics, and the other handles chat. When I ask a question, the backend fetches the Markdown file from the private repository, sends it to Claude along with my question, and returns the answer. To recreate it, you’ll need a GitHub account, Netlify (the free tier is fine), an Anthropic API key, and Claude Code. The routine prompt is the most important part. It names the exact newsletters, lists the fields to extract, and explicitly says: never invent a URL, never delete an entry, and only add or update. Vague instructions produce files that degrade over time. I learned a few things the hard way. Newsletters deleted before the workflow runs may cause it to report “nothing new,” so the logic should also check Trash or Deleted items. Tokens expire, and mine quietly expired, which caused the search site to stop working. Choose a long expiration period and record the date. Also, explicitly say “never invent a URL,” or the workflow may produce plausible links that go nowhere. It now runs every morning without me. When I need something, I ask a question and get an answer in seconds instead of trying to remember which newsletter, and which month, mentioned the tool I’m thinking of. Step-by-step: 1. I created a private GitHub repository with a starter Markdown file containing “Last updated” and “Total tools” fields, category headings, and consistent fields for each tool. 2. I wrote a Claude Code Routine prompt that names the newsletters, specifies the fields to extract, and instructs the workflow never to invent a URL, never to delete an entry, and only to add or update tools. 3. I scheduled the routine to run daily with Gmail access. 4. Each day, the routine searches Gmail for newsletters from the previous 24 hours, reads them, extracts AI tools, skips non-AI items and pure ads, preserves genuine tool sponsors, and checks Trash or Deleted items when necessary. 5. The routine checks for duplicates, adds new tools alphabetically under the right category, updates existing tools with fresh details, creates categories when needed, and applies the “Highly Mentioned” tag to tools found in at least three sources. 6. The routine commits and pushes the Markdown catalog to the private GitHub repository and posts a summary to Slack. 7. I built the frontend with Vite and React, including a statistics header, a scrollable message list, an input box, and example questions. 8. I added two backend functions: one for statistics and one for chat, with the GitHub fetch handled by a shared helper with a short cache. 9. I created a fine-grained, read-only GitHub token limited to the single repository. 10. I deployed the site to Netlify with the required keys stored as environment variables rather than in the code. 11. When I ask a question, the backend fetches the Markdown catalog, sends it to Claude with my question, and returns the matching tools, descriptions, and links.

Most AI agents are built around general best practices. That’s useful, but it doesn’t mean they work the way I want them to. I’ve started using a simple calibration process to tailor my agents to my preferences. Instead of telling an agent what to do on each task, I have it interview me about how I like work done in its specific domain. A writing agent asks different questions than a research agent, and a strategy agent asks different questions than a coding agent. The goal is to make my working preferences part of how the agent operates. Step-by-step: 1. I pick an agent I use regularly, such as one for writing, research, strategy, coding, analysis, or career advice—especially where my personal preferences matter. 2. I ask the agent to interview me about how I prefer work to be done in its domain. A writing agent might ask about tone, structure, editing style, and how much pushback I want. A research agent might ask about source quality, depth, recency, citations, and how much synthesis I prefer. 3. I have the agent summarize what it learned and separate durable preferences from temporary or situation-specific ones. 4. I review the proposed changes and ask the agent to show me exactly how it wants to update its instructions or skills. I correct anything it misunderstood and explicitly approve the changes before anything is modified. 5. Once I approve the changes, I have the agent apply them to its instructions or skills so those preferences become part of how it works going forward. 6. I use the agent normally and pay attention to where it feels more aligned and where it still misses the mark. 7. When I notice recurring friction, I add or adjust the relevant preference instead of repeatedly correcting the same behavior task by task. 8. I repeat the interview periodically. My preferences, tools, and workflows change, so the agent should be able to ask which preferences are still valid, which ones I keep overriding, what has been annoying me, and what should be added or removed. The result is an agent that doesn’t just know how to do the job; it knows how I want the job done. Because every change is proposed and approved before it becomes permanent, the personalization stays intentional rather than turning into a collection of guesses about me.

Most AI agents start with someone writing a prompt from scratch. I wanted a better way. So I built an Agent Creator. I describe the kind of agent I need, and it determines whether I actually need a new one, figures out how that agent should work, creates it, and adds it to the rest of my agent team. Step-by-step: 1. I describe what I need by telling the Agent Creator what I want the new agent to do. 2. It checks what already exists by reviewing my existing agents and skills. If something already does most of the job, it recommends improving or reusing that instead of creating another overlapping agent. 3. If a new skill is needed, it researches the role, including current best practices, common mistakes, useful tools, and what good work looks like in that area. 4. It creates the agent by defining its job, required information, outputs, available tools, and the steps it should follow. 5. It gives the agent the right skills by creating or reusing supporting skills, including examples, reference material, and checks that help it work consistently. 6. It sets clear boundaries so the agent knows what it should handle, what it should not handle, and when another agent should take over. 7. If the new agent belongs in an existing workflow, it adds the agent to the team by updating the handoffs so the other agents know when to use it. 8. Before finishing, it checks the agent’s work by running validation checks to confirm that the new agent follows the standards I’ve set for the whole team. The result is that I don’t have to manually design every new agent from scratch. I can describe the kind of help I need, and one agent can research the role, create the new specialist, connect it to the rest of the system, and make sure it’s ready to use. In other words, I built an AI agent that can help grow its own team.