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

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 wanted to reduce the time and mental effort it takes each morning to figure out what needs my attention across my inbox and calendar. I used Codex Automations to build Briefly, a daily AI-powered email and calendar brief that is automatically delivered to my inbox every day. Instead of manually searching through emails and checking separate calendar events, I can open one message from Briefly and immediately see what is happening, what needs action, and what is coming up. It has become a simple way for me to use AI proactively—not only when I ask a question, but as an automated system that helps me stay ahead of my emails, tasks, and schedule each day. Step-by-step: 1. I connected the email and calendar sources I wanted the automation to review. 2. I created a Codex Automation that runs each morning. 3. I instructed it to review recent and important emails, identify messages that need attention or follow-up, and check my calendar for upcoming meetings and commitments. 4. I had it turn that information into a concise daily brief. 5. I configured the brief to be delivered to my email automatically.

I’m a commercial excellence consultant for industrial B2B businesses, and very few of the clients I speak with have a current view of the competition in their market. Nobody has mapped the competitive landscape recently—sometimes they never have. Clients can often name the companies in the market, but they can’t explain what those competitors do differently or why a customer would choose one over them. That gap is expensive. The mid-market manufacturers I work with, typically in the $75 million to $300 million range, usually don’t have a strategy team to close it. The alternatives are consulting rates for research that goes stale as soon as it’s delivered or a generic template that says the same five things about every market. Neither option is necessarily wrong, but neither is very useful. So I built a Claude Skill: an instruction set that runs live research every time instead of pattern-matching to a generic answer. The input is simple: the company name, its brand voice, the research scope, the geography, and a known competitor list if one is available. Before researching a single competitor, the Skill states the decision the report needs to inform—for example, whether to enter a vertical, how to price against a rival, or where to direct sales next quarter. It checks the client’s own website and capabilities next; an early version once recommended something the client already had. It then maps the competitive field across five tiers: direct, adjacent, disruptor, new entrant, and aspirational for PE-backed clients. It checks Asia-Pacific specifically because that’s the blind spot I’ve seen missed most often. Market size carries a confidence flag instead of false precision. Findings become battlecards phrased the way reps actually talk, rather than in analyst language. The report also includes a threat ranking with a timeline attached, then closes with three opportunities, three risks, and four to six moves for the quarter. Every recommendation is filtered through the original decision instead of being included simply because the research was interesting. The output is two files: an interactive HTML report and a matching PDF. Both are built entirely in HTML and CSS rather than with canvas charts, which can break in exactly the ways that matter—blank on load or missing from the PDF. None of what makes this useful is the AI itself. The important work is naming the decision before researching a competitor, checking what the client already has, tagging confidence instead of faking precision, and writing like a rep rather than an analyst. That’s the difference between a report that gets skimmed once and one that gets acted on. This is one piece of a bigger system I run for industrial manufacturers applying AI to their commercial function. I teach the underlying version of this workflow live. Step-by-step: 1. I provide Claude Skill with the company name, brand voice, research scope, geography, and known competitor list, if available. 2. I define the decision the report needs to inform, such as entering a vertical, pricing against a rival, or directing sales next quarter. 3. I have the Skill check the client’s website and capabilities before researching competitors. 4. I map the competitive field across direct, adjacent, disruptor, new entrant, and, for PE-backed clients, aspirational competitors. 5. I check Asia-Pacific specifically to address a commonly missed blind spot. 6. I assign confidence flags to market-size estimates rather than presenting false precision. 7. I turn the findings into sales-rep-friendly battlecards and add a threat ranking with a timeline. 8. I close the report with three opportunities, three risks, and four to six quarterly moves tied back to the original decision. 9. I deliver the result as an interactive HTML report and a matching PDF, using HTML and CSS instead of canvas charts.

I used AI to help investigate a family mystery that had remained unresolved for decades: identifying the biological family of my maternal grandfather. The challenge was not a lack of information. It was almost the opposite. I had DNA matches, family trees, names, dates, historical records, old photographs, obituaries, Facebook genealogy groups, and conversations with possible relatives. The difficult part was connecting all these scattered clues without jumping to conclusions. I built a research workflow in which AI acts as an investigation partner, not as the source of truth. Step-by-step: 1. I gathered the information I already had from genealogy platforms, DNA matches, family trees, historical documents, and family records. 2. I used ChatGPT to organize the evidence into people, dates, locations, relationships, DNA connections, documents, and unresolved questions. 3. I separated the information into three categories: confirmed facts, hypotheses, and missing information. 4. Instead of asking AI, “Who was my grandfather's biological father?”, I asked it to analyze possible family connections and identify which hypotheses were compatible with the available evidence. 5. For each hypothesis, I looked for supporting evidence, contradictory evidence, and information that was still needed. 6. I treated AI-generated connections as leads rather than genealogical proof. The goal was to use AI to decide what to investigate next, not to have it find the answer. 7. I used AI to compare family branches, surnames, generations, locations, and possible relationships among DNA matches whose family connections I did not immediately recognize. 8. When a promising connection appeared, I returned to the original genealogy and DNA sources to verify it. This gradually turned a long list of DNA matches into a smaller number of research paths. 9. I used AI to draft respectful, personalized messages to DNA matches and members of genealogy communities, including people in another country and language. 10. In each message, I explained what I was researching, what connection I suspected, what information I already had, and what I hoped the recipient might be able to confirm or rule out. 11. I treated their responses as new evidence and repeated the investigation loop: evidence → AI analysis → hypothesis → verification → human contact → new evidence → updated hypothesis. The final result is not an “AI-generated family tree.” It is a human-led investigation in which AI helps manage complexity, ask better questions, and identify the next useful action. The most important lesson I learned is that AI is particularly useful in genealogy when you do not ask it to give you the answer. Ask it to help you build the investigation.

Training for a triathlon means three sports and a plan that is fiction by Wednesday. A static plan does not know I slept badly, skipped Tuesday's swim, or that Saturday's long ride wrecked me. Adjusting for that is what you actually pay a coach for. I wanted the adjusting without the retainer. So I built it in ChatGPT Work: a Project holding my plan, plus a scheduled agent run each morning that checks the plan against what my body actually did, then fixes the week. Disclosure: I built freddy, the connector feeding ChatGPT my training and recovery data, so I am not neutral here. Step-by-step: 1. Connect your sources at freddy.coach. For triathlon it is whatever records your swims, rides and runs: Garmin Connect, Polar, Suunto, WHOOP or intervals.icu. I use Oura for sleep and recovery, Garmin Connect for sessions, Hevy for strength. History backfills automatically, so the plan is built on your real training rather than what you tell it you did, which is usually flattering. 2. Add freddy as a custom connector: Settings, then Connectors or Apps and Connectors, then Add new, then custom MCP server. The URL is https://freddy.coach/mcp. Sign in and approve read access. Do it on the web; the mobile app cannot add custom connectors. 3. Connect Google Calendar and turn on write actions. This is the step people miss: write actions are off by default, so until they are enabled through action controls the agent can read your week but not change it. With writes on, ChatGPT Work creates and edits events. 4. Create a Project and put the durable facts in the project instructions: race date and distance, realistic weekly hours, immovable days, injury history, weakest discipline, and how blunt you want it. Long-lived facts only, never this week's session. 5. In the project, with freddy on, ask it to build the block: a periodised plan to race day, justified against your actual last 8 weeks rather than a textbook ramp. Keep the plan as a file in the project so every run starts from the same document, and have it write the week's sessions to the calendar with type, duration and intensity in the event body. 6. Schedule the daily run for mid morning, after you are up and your sources have synced. Last night's sleep does not exist anywhere until the watch or ring syncs, so a 5am run reports on the night before last. The standing prompt: "Using freddy, check whether I completed yesterday's planned session: pull yesterday's workouts with type, duration and intensity and compare against what the plan called for. Then pull last night's sleep and this morning's recovery including HRV and resting heart rate, plus training load over the last 7 days, compared against my own 30 day baseline rather than population norms. Then look at today's planned session on my calendar and decide whether it still makes sense. If it does, confirm in one line. If not, change the calendar event to the session I should actually do, put the reason in the event body, and update the plan file. Tell me what you changed and why, naming which source each conclusion came from. If two sources disagree, say so rather than averaging. Never compare HRV across different sources. If anything is ambiguous, such as an unrecorded session or a workout matching no planned one, ask me instead of guessing. Under 250 words." 7. Let it run a week before trusting it, and read what it changed rather than skimming. Expect to tune the instructions early: the usual failure is turning cautious after one poor night, fixed by a line saying a bad night is noise and to downgrade only on a trend or after a hard day. Two things to know. Depending on your approval settings, a run either makes the change or holds it for a tap. Know which you chose: it is the difference between waking to a changed calendar and a proposed one. And agent runs are metered, so keep the daily check narrow and save long reasoning for a weekly review. What surprised me is how good it is at catching the sessions I quietly did not do. It is easy to tell yourself you are on plan, harder when something reads yesterday's file and notes the intervals were short. Gotchas. Make it commit to one call on today's session; "listen to your body" is what you already had. Make it name the source behind each conclusion so you can tell a real finding from a confident guess. Never let it compare HRV across sources, because RMSSD and SDNN are different measurements, not different units, so mixing them looks meaningful while being nonsense. Scheduled runs auto-pause if ignored, so if the check stops arriving, look there before blaming the connector. It is not a certified coach and I would not rehab an injury with it. It is very good at holding a plan, watching what happened, and closing the gap before it becomes a lost week. Cost: freddy is free for one source, but this is cross source so it is the paid plan, $49 a year, on top of ChatGPT. Individual triathlon coaching runs a few hundred a month.

AI image prompting often starts online: search for a style, collect references, describe them, and generate. But your visual vocabulary can also begin in the physical world—a plant, a tile, a book cover, a strange facade, a piece of furniture, or a detail in a church. This workflow turns everyday discoveries into a personal prompt library. AI helps investigate and translate what catches my attention, while I decide what matters. Step-by-step: 1. When something catches my eye, I photograph it and record where I found it and why it interested me. I do not need to understand my attraction immediately. It might be, “This plant has fascinating leaves,” “Who is the writer quoted on this tile?” or “Is it the copper, its patina, or the reflected light that I like?” Attention comes before classification. 2. I ask AI to help identify unfamiliar materials, objects, plants, techniques, or historical connections. A tile might lead to a writer, a literary movement, typography, or metalworking techniques. I preserve the original context—including the location, date, material, maker if known, and my observations—and mark uncertain identifications as uncertain. 3. I separate each object from what makes it visually interesting. For example: - Source: Plant with folded leaves. Principle: Layered fan-like forms with radial repetition. - Source: Weathered copper plaque. Principle: Warm metallic surface, uneven oxidation, and shallow relief. - Source: Facade with irregular windows. Principle: Repeated vertical rhythm interrupted by asymmetry. - Source: Green and coral book cover. Principle: Muted green with a single warm coral accent. This lets me reuse the visual logic without copying the object. 4. I translate each visual principle into concise, reusable prompt fragments, such as: - “Fan-like folded forms with radial repetition” - “Aged copper with dark patina and shallow embossed texture” - “Regular architectural rhythm interrupted by one off-grid element” - “Muted green field with one warm coral accent” These descriptions give me more control than generic words such as “beautiful,” “organic,” or “vintage.” One object can produce multiple fragments related to typography, surface, colour, proportion, lighting, or composition. 5. I store the entries in a document, database, or tagged visual archive. Useful fields include the reference, photo, location, date, what caught my attention, identification and research notes, visual principle, prompt-ready fragment, tags, related references, and confidence. I tag entries by visual function, such as colour, material, texture, rhythm, lighting, or composition, and always preserve links to the original reference. 6. I connect discoveries that may share underlying principles. Folded leaves, pleated fabric, ribbed metal, and fan-shaped architecture might express similar structural rhythms. I ask AI which relationships are visually meaningful, which are superficial, and which could combine well. The library becomes a connected visual vocabulary rather than a collection of isolated images. 7. When creating an image, I select references according to what they contribute. For example, a plant can provide shape language, copper can provide surface and lighting, a facade can provide compositional rhythm, and a book cover can provide colour balance. I ask AI to explain each contribution and remove references without a clear purpose. The goal is not to place all four objects into one image, but to combine their visual principles into something new. 8. I keep collecting and refining. A walk, museum, garden, or café can introduce new references. I update entries when I discover better information and preserve personal reactions, even when the only explanation is, “I just really like this.” Repeated attraction can reveal a personal visual vocabulary I had not consciously recognised. The workflow is: Notice → Capture → Investigate → Extract visual principles → Translate → Store → Connect → Reuse → Refine. AI does not have to be where inspiration begins. The world can stay upstream. A plant can start a prompt. A tile can start a research trail. A material can become a lighting instruction. A facade can become a composition rule. A book cover can become a colour recipe. I notice. AI helps unpack, translate, and connect. The prompt library becomes the bridge between seeing something in the world and being able to use what I saw later.

I built a workflow in which AI agents build a product under the kind of governance I’d expect from a senior engineering team. After 20 years in software engineering, including 10 years running my own businesses, I learned that writing code isn’t the hard part. Keeping control of it is. So I set up a build loop on GitHub. One thing I’ve kept for myself is decision-making: approving plans, answering product questions, and signing off on what the system has learned. The product it’s building is Cordexa, a tool for document-heavy expert work, such as quantity take-offs from engineering drawings or assessing a tender against a company’s own CVs and case studies. It’s designed to run inside the customer’s own cloud, so their documents never leave it. Every figure is cited to the document it came from or flagged for a person. It never guesses. The problem it solves is complex, but the build loop lets the system work in the background and notify my phone when it needs a decision. That allows me to stay focused on my day job. Step-by-step: 1. I start every module with a plain-English plan and approve it before any code exists. 2. One agent writes the tests from the plan. A different agent writes the code, and it cannot modify the tests. 3. An independent reviewer agent checks every change against its plan. Safe changes merge automatically; anything that changes the product waits for my approval. 4. A watchdog checks every 15 minutes for anything that is stuck, fixes it when possible, or tells me why it cannot. 5. Real test jobs run after every merge and are scored against known answers, so progress is measured rather than guessed. 6. I handle the decisions, answer product questions, and sign off on what the system has learned.

I built a daily AI story-scouting workflow that finds potentially viral stories for Instagram Reels, YouTube Shorts, and TikTok without recycling topics we’ve already covered. First, the workflow reviewed Rowan’s public short-form archive once to create a coverage map of past topics and editorial taste. It uses that map as a filter, helping distinguish a genuinely new angle from another version of the same AI launch, robot demo, or research story. Every morning, it scans priority sources, including AI and technology coverage from major newspapers and tech blogs, The Rundown newsletters, company announcements, research papers, and public updates from major AI and robotics companies. The workflow is not limited to same-day news. It also looks back over the past one to six weeks for stories that have not been extensively covered in the media. Each potential story is checked for four things: a clear visual hook, a technical idea that can be explained in 45–90 seconds, broad audience interest, and meaningful novelty compared with Rowan’s past coverage and the previous week’s recommendations. It keeps every story that clears the bar rather than forcing a fixed number. The final brief is ranked by strength and sent as one compact Slack DM at 10 AM each day. Step-by-step: 1. The workflow reviews Rowan’s public short-form archive once and builds a map of past topics and editorial taste. 2. Each morning, it scans priority sources, including major newspapers, tech blogs, The Rundown newsletters, company announcements, research papers, and public updates from major AI and robotics companies. 3. It searches both same-day news and stories from the previous one to six weeks that have not been extensively covered in the media. 4. It filters out topics that substantially repeat Rowan’s past coverage or the previous week’s recommendations, while identifying genuinely new angles. 5. It evaluates each potential story for a clear visual hook, a technical idea explainable in 45–90 seconds, broad audience interest, and meaningful novelty. 6. It keeps every story that meets those criteria instead of forcing a fixed number of recommendations. 7. It ranks the final brief by strength and sends it as one compact Slack DM at 10 AM each day.

I’m sharing “The Architects of Reality,” a short film created as part of an experiment with a multi-agent AI workflow for long-form content creation. Off-the-shelf AI video platforms are brilliant for short clips, but as the duration increases, the challenges compound: character inconsistency, narrative drift, visual discontinuity, and expensive iterations when the output doesn’t match the creative vision. Instead of asking one AI to make a film, I created an AI film crew. Specialised agents and sub-agents take on roles including Director, DOP, Cameraman, VFX Supervisor, Sound Engineer, VO Artist, and Audio Mixer to support the filmmaking process. Creative review and approval are built into every stage, so individual elements can be regenerated before expensive final rendering. This helps optimise tokens, budget, and creative control. It’s been a fun journey building these agents—and even more fascinating to watch the output improve in capability and efficiency as they learn every day. Step-by-step: 1. I set up a multi-agent AI workflow for long-form content creation. 2. I assigned specialised filmmaking roles to agents and sub-agents, including Director, DOP, Cameraman, VFX Supervisor, Sound Engineer, VO Artist, and Audio Mixer. 3. I built creative review and approval into every stage of the process. 4. I regenerate individual elements when they do not match the creative vision, before moving to expensive final rendering. 5. I use the workflow to optimise tokens, budget, and creative control while producing the short film “The Architects of Reality.” 6. I observe how the output’s capabilities and efficiencies improve as the agents learn every day.

I’m building an automated content engine for a client using n8n and the Claude API. Every week it produces blog articles and social posts for eight brands. The client already has a blog with [number] articles, and we want the output to match that voice. What I’ve tried: [e.g. a tone-of-voice description in the system prompt / a few example articles in the prompt]. What I get is text that’s fine but sounds AI-written and slightly translated. It doesn’t read like a native Swedish copywriter wrote it. What I’m weighing: Is it better to extract a tone-of-voice guide from the blog (rules, word choices, sentence length, do’s and don’ts) or to pass example texts as few-shot? How many examples do I need, and should they be full articles or excerpts? Is a separate editor step that only reviews and adjusts tone worth it? How do you handle one shared base voice across eight brands that each have their own variant?

GeneTrust AI — Asistente Genético Virtual (AGV) es una plataforma tecnológica concebida bajo una arquitectura basada en evidencia (Evidence-First), asistida por IA y gobernada por humanos. Está diseñada para facilitar el acceso, la estructuración, la exploración, la clasificación, la priorización y la síntesis trazable de evidencia genética y biomédica. Su diseño busca prevenir riesgos críticos de la IA en biomedicina, como las alucinaciones, las referencias no resolubles, la pérdida de procedencia, el ocultamiento de contradicciones y la atribución indebida de autoridad clínica. Aplica operaciones aditivas y no destructivas: filtrar, clasificar o priorizar los datos nunca modifica ni reescribe la evidencia fuente original. Además, preserva la ambigüedad y los elementos no clasificables en lugar de forzar conclusiones artificiales. El stack tecnológico incluye React, TypeScript, Node.js y servicios en la nube. La plataforma integra un enfoque de múltiples proveedores y agentes de IA, con modelos generativos desacoplados, junto con una clasificación multidimensional de la evidencia mediante la abstracción de un Structured Decision Provider (SDP, Proveedor de Decisión Estructurada). Utiliza específicamente TypeSafe AI, con su modelo Jev, como proveedor de decisiones estructuradas bajo estrictas políticas de activación y gobernanza por dimensión. La IA y sus agentes asisten en la organización, exploración y síntesis de información compleja, pero no actúan como una autoridad diagnóstica ni determinan por sí mismos la verdad clínica. Sus salidas se manejan como inferencias computacionales controladas, separadas estrictamente de la evidencia fuente y sujetas a validación humana explícita. Step-by-step: 1. Accedo y estructuro la evidencia genética y biomédica dentro de una arquitectura basada en evidencia. 2. Exploro, clasifico y priorizo la información mediante operaciones aditivas y no destructivas, sin modificar ni reescribir la evidencia fuente original. 3. Mantengo la procedencia, las contradicciones, la ambigüedad y los elementos no clasificables, evitando forzar conclusiones artificiales. 4. Utilizo múltiples proveedores y agentes de IA, con modelos generativos desacoplados, para organizar, explorar y sintetizar la información compleja. 5. Aplico una clasificación multidimensional mediante la abstracción de un Structured Decision Provider (SDP), utilizando TypeSafe AI y su modelo Jev bajo políticas estrictas de activación y gobernanza por dimensión. 6. Trato las salidas de la IA como inferencias computacionales controladas, las separo de la evidencia fuente y requiero una validación humana explícita antes de utilizarlas.

I built three interconnected websites for the Solomon for Jesus ministry. The first, solomonforjesus.com, houses the shining jewel: an AI chatbot named Solomon. The second, solomonforjesus.net, is a ministry academy with four levels of instruction and 16 lessons per level. The third, solomonforjesus.net, is home to my book *Fingerprint of Reality* and other articles and essays. All three websites are still in development, but they are operating and publicly available. I use GitHub repositories for coding, Vercel for hosting, Cloudflare for domains, and Supabase for back-end security. Step-by-step: 1. I built three interconnected websites for the Solomon for Jesus ministry. 2. I used solomonforjesus.com for the Solomon AI chatbot. 3. I used solomonforjesus.net for the ministry academy, which contains four instructional levels with 16 lessons per level. 4. I used solomonforjesus.net for my book *Fingerprint of Reality* and other articles and essays. 5. I use GitHub repositories to code, Vercel to host, Cloudflare for domains, and Supabase for back-end security. 6. I keep all three websites operating and publicly available while they remain in development.

Build a Tiny HTML Research Logger Instead of Fighting a Spreadsheet Turn repeated research measurements into a simple phone-friendly interface instead of making participants wrestle with spreadsheets. Some research data is simple. Collecting it often isn't. Imagine recording pain, energy, mood and a few additional variables several times during a study. A spreadsheet can technically do this. But on a phone? Open the file, find the right row, locate the columns, enter values without accidentally changing something, save and close. That's a ridiculous amount of interface for a tiny measurement. If recording how you feel takes ten seconds mentally but two minutes administratively, the tool has become part of the research burden. So I asked: What is the smallest interface someone actually needs when logging an observation? My answer was a tiny HTML page that works on both phone and desktop. 1. Separate the interface from the dataset Participants shouldn't need to interact with rows, columns or database structures. They should see a few simple fields: Pain, Energy, Mood, Optional Note and Save. Behind the interface, each submission becomes a structured record containing the measurements, a timestamp and any optional context. The researcher gets organised data. The participant gets simple controls. 2. Define the research measures first Before asking AI to build anything, establish what you're measuring. Which variables matter? What does each scale mean? Which values are allowed? Should measurements remain comparable over time? These are research decisions, not interface-design decisions. AI can help implement your measurement system, but shouldn't quietly invent the methodology. 3. Design for repeated use A questionnaire completed once can tolerate some friction. A logger used several times a day cannot. Make controls large enough to tap comfortably. Use readable labels, vertical layouts and obvious actions. Avoid unnecessary navigation, tiny cells and repeated setup. Design for the phone first, then let the interface adapt to larger screens. And test the fifth entry, not just the first. Something that looks elegant during development can become irritating when you're tired, distracted or recording yet another observation. The ideal repeated action is almost boring. That's a compliment. 4. Automate the invisible work Participants shouldn't have to enter information the system already knows. A logger can automatically generate timestamps, record identifiers and technical metadata. Each submission should become one coherent record. Show a clear confirmation when saving succeeds and prevent accidental duplicates. Keep optional notes available without turning every measurement into a diary assignment. Don't make participants do the database's job. 5. Keep the interface neutral A research logger is a measurement instrument. Its colours, labels, ordering and controls shouldn't subtly suggest which answers are desirable. Likewise, the logger doesn't need to interpret someone's measurements or announce that their mood seems lower on Tuesdays. That's analysis, not collection. First gather observations reliably. Interpret them later using appropriate research methods. 6. Decide where the data lives A single HTML file can provide the interface without requiring a full application. But HTML alone doesn't provide persistent storage or synchronisation. Browser storage may work for a local prototype, although it has limitations. For research involving several devices, participants or longer periods, you'll need suitable storage and export options. A phone and laptop displaying the same interface don't automatically share observations. Keep the dataset consistent and exportable, for example as CSV. For sensitive information, include appropriate privacy and security safeguards. 7. Build only what's necessary It's tempting to expand a tiny logger into an entire platform. Dashboards! Charts! Profiles! Notifications! Accounts! Perhaps later. Start with Open → Measure → Save. Test the process repeatedly on phone and desktop. Improve whatever causes genuine friction. You can enlarge buttons or rearrange the layout without changing the study. But changing a measurement scale is a research-design decision, not a cosmetic update. The workflow Define the variables and scales → ask AI to build a responsive HTML logger → add automatic timestamps and structured records → choose suitable storage and export methods → test repeated logging → refine usability without changing the measurements. Why this works A spreadsheet is excellent at displaying a dataset. That doesn't make it the best place to create one. Researchers think in variables, records and analysis. Participants simply need to answer the question in front of them. Those shouldn't have to be the same interface. Sometimes the best research tool isn't a sophisticated platform. It's a tiny page that gets the spreadsheet out of the participant's way.

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.

Sometimes a playlist disappears before you realise how much you depended on it. That happened to a meditation playlist I used constantly for months. Then Spotify removed it, and I discovered an inconvenient detail: I barely knew the track or artist names. I remembered the music and what it did for me, but I could not reliably search for it. The reconstruction began accidentally. While analysing my Spotify listening history for another purpose, AI noticed that I had played roughly the same fifty tracks again and again for about four months. Suddenly, I did not need to remember the missing playlist. My listening history had remembered it for me. A playlist can leave a behavioural fingerprint even when its name and contents are gone. Look for repetitive periods, recurring groups of tracks, similar sequences, and songs that appear together for several months before disappearing around the same time. Step-by-step: 1. I inspected my historical Spotify listening data instead of relying only on which songs I could remember. 2. I used unusual repetition to identify the likely time window. In my case, a four-month cluster helped me recognise the missing meditation playlist, even though I did not know the exact dates beforehand. 3. I built a broad candidate pool of tracks played frequently during that period, recording titles, artists, play counts, dates, listening duration, and nearby tracks. 4. I looked for tracks that repeatedly occurred in the same sessions, on the same days, or in similar sequences. Tracks that travelled together were stronger evidence than songs that were merely popular individually. 5. I compared listening outside the suspected period. A song played throughout several years might be a general favourite, while one that appeared repeatedly within the cluster and rarely elsewhere was a stronger candidate. 6. I used timestamps to recover possible order, including tracks that usually followed each other or appeared near the beginning or end of sessions. Because shuffle may obscure the original order, I treated these smaller sequences as clues rather than proof. 7. I showed the candidate tracks to the person, including names, artists, and, where useful, album art or audio previews. I asked whether each track felt familiar and belonged to the playlist. 8. I relied on recognition rather than recall. Someone may be unable to name a single song but still recognise dozens when presented with them. This is especially useful for instrumental music, mantras, classical works, or unfamiliar names, because remembering the sound does not require remembering its spelling. 9. I ranked candidates as highly likely, likely, possible, or uncertain using repetition, co-occurrence, timing, listening elsewhere, and human confirmation. I did not treat every recovered track as equally certain. 10. I created a provisional playlist from the strongest candidates and listened to it. A list can look convincing in a spreadsheet but feel wrong when played; listening may reveal an unrelated song, a missing transition, or immediate recognition. 11. I used confirmed tracks as anchors and checked which uncertain candidates repeatedly appeared beside them. Data suggested candidates, recognition confirmed anchors, and those anchors improved the next search. 12. I recorded why the playlist mattered, when it was used, and whether its order mattered. Mine was a meditation playlist, so recovering that musical environment mattered even if the exact original list remained uncertain. 13. I saved an external record containing the playlist name, track titles, artists, albums, links or identifiers, reconstruction date, and uncertainty or contextual notes. I kept the listening history, candidate analysis, and confirmed playlist separately so I could revise the result without losing the evidence. The workflow was: analyse listening history → find repeated clusters → locate the time window → collect candidates → compare co-occurrence and sequence → remove unrelated tracks → confirm through recognition → rebuild and listen → refine → save externally. The deeper principle is that humans often remember experiences better than metadata. I remembered that the playlist existed, what it did, and how constantly I played it. I did not remember what most of it was called. The platform had lost the collection, but the listening history still contained its shadow. One observation made it searchable again: > “Hey. For about four months, you were basically listening to the same fifty songs.” 😅🎧

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.

A reusable Claude Skill called `trust-due-diligence`, packaged as a `.skill` file. It is not a single report; it is a methodology made up of a `SKILL.md` file and three reference documents that teach Claude a repeatable process for investigating a named person, company, coach, or offer before you commit money or trust to them. Once installed, it activates automatically whenever you ask something like “deep dive on X” or “is this legit,” so you do not need to explain the process each time. Step-by-step: 1. Package the `trust-due-diligence` Claude Skill as a `.skill` file. 2. Include a `SKILL.md` file and three reference documents. 3. Use the files together to teach Claude a repeatable due-diligence methodology. 4. Install the Skill so it activates automatically for prompts such as “deep dive on X” or “is this legit.” 5. Use it to investigate a named person, company, coach, or offer before committing money or trust.

Midlifecurious is a newsletter for women navigating midlife—honest, funny, and allergic to being talked down to. Its Sunday issue, the Midlife Missive, is a roundup covering health, wellness, money, beauty, and family. My sister, Claire, edits it; I build the machine behind it. That machine is Missive, a five-part publishing intelligence system that runs the newsletter as one closed loop: scan → triage → publish → measure → remember. It monitors Reddit, search trends, and RSS to identify what midlife women are paying attention to before those topics reach our feeds. Discovery pulls in those sources, ranks every feed using a click-rate-based quality score, and lets Claire triage articles into the week’s issue. Curation composes Sunday’s newsletter and drafts the introduction in her voice. Performance reads the Mailchimp results back into the system and feeds them into the rankings, so strong sources rise and weak ones fall over time. Underneath all four stages is Memory: a vector-searchable corpus of every article, save, rejection, and the reasoning behind each decision. Memory is the real spine of the system. It lets Missive ask editorial questions such as “Have we covered this before?” and “Is this source still earning its slot?” instead of requiring one person to hold everything in her head. We’re a two-person operation: I build with Claude Code, and Claire edits. The system runs on one database for under $25 a month. I built it because the alternative was Claire drowning in a Feedly-and-spreadsheet routine that discarded everything as soon as an issue shipped. We had no record of what we had run and no feedback on what actually landed. My bet is that the corpus is the moat. Claire’s editorial taste—every save, rejection, and “cornerstone” stamp, with the reasoning stored alongside the decision—is a training set no one else has. A system that remembers turns her job from synthesizer into judge. Missive is deliberately internal-only: no SaaS and no customers, ever. That frees me to build for our exact workflow instead of a hypothetical buyer, and to build for 2028 instead of this quarter. The near-term payoff is a calmer Sunday. The long-term goal is a proprietary editorial-intelligence layer we could never buy off the shelf—the foundation for the research and audience products that come next. Step-by-step: 1. I monitor Reddit, search trends, and RSS for topics that midlife women are paying attention to. 2. I pull those sources into Missive and rank each feed using a click-rate-based quality score. 3. Claire triages the ranked articles into the week’s Midlife Missive. 4. Missive composes Sunday’s newsletter and drafts the introduction in Claire’s voice. 5. I import the Mailchimp results so the system can update source rankings based on performance. 6. Missive stores every article, save, rejection, “cornerstone” stamp, and the reasoning behind each decision in a vector-searchable corpus. 7. We use that memory to check whether a topic has already been covered and whether a source is still earning its place. 8. I build and maintain the internal system with Claude Code, while Claire handles editing, using one database that costs under $25 a month.

I submit two reports to my directors each month. Both use structured templates, but the updates come from multiple people and sources. Some information is unstructured, such as hallway conversations that are not always captured in email, so I have struggled to get the accuracy I need when using AI to build the reports. I am currently testing CoWork and Copilot Work IQ. These reports used to take me hours, so I am already saving time, but I want to refine the process further. I believe a better way to save and store the source data could improve the final outputs, although I have not worked out the right approach yet. Step-by-step: 1. I collect updates from multiple people and sources for the two monthly reports. 2. I organize the information into the structured templates required by my directors. 3. I use CoWork and Copilot Work IQ to help build the reports. 4. I account for unstructured updates, including information from hallway conversations that may not have been captured in email. 5. I am exploring better ways to save and store the source data so I can improve the accuracy of the reports while continuing to save time.