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

During a period when my medical symptoms suddenly became much worse, the hardest part was not only the symptoms themselves. Pain, dizziness, visual disturbances, brain fog, and acute stress reduced my ability to explain what was happening, make decisions, and keep track of multiple healthcare contacts. That created an awkward problem: the moment I most needed to communicate clearly was often the moment I had the least cognitive capacity to do so. I used ChatGPT as a temporary coordination and communication layer. I kept a symptom diary so I did not have to reconstruct everything from memory. When my symptoms changed, I could compare the new episode with previous days and prepare a concise description. I also used ChatGPT to think through where to seek care. Depending on the severity and type of symptoms, the relevant question might be whether something belonged with my regular GP, an out-of-hours GP service, emergency care, or one of the specialists already involved. Before speaking with a clinician, I asked ChatGPT to help reduce a messy description to a few medically useful points: what changed, when it started, how severe it was, what made it better or worse, which associated symptoms were present, and what had already been investigated. One of the most useful workarounds was extremely simple: if speaking became difficult, I prepared a short note on my phone and showed it to the clinician. At the top, I explained why I was using written communication—for example, that acute stress, autism, pain, dizziness, or brain fog were making speech harder. Underneath, I included my symptoms, timeline, medications, relevant history, and the questions I wanted answered. That mattered because someone arriving alone, visibly anxious, or struggling to speak can easily have difficulty presenting a coherent medical history. The same is true when symptoms reduce concentration, working memory, or language ability. AI did not diagnose the problem. It helped preserve my ability to participate in my own care when some of the abilities normally required to do that were temporarily impaired. During that period, clinicians investigated several possible causes, treated the problems they found, provided medication when needed, and ruled out more serious possibilities. The valuable part of the workflow was not AI replacing a doctor. It was AI helping me reach doctors with a clearer history, better questions, and a communication method I could still use when my normal one was failing. Step-by-step: 1. I kept a symptom diary so I could compare new episodes with previous days instead of relying on memory. 2. I used ChatGPT to help me think through whether to contact my regular GP, an out-of-hours GP service, emergency care, or a specialist already involved, based on the severity and type of symptoms. 3. Before speaking with a clinician, I used ChatGPT to organize what had changed, when it started, how severe it was, what affected it, which associated symptoms were present, and what had already been investigated. 4. When speaking became difficult, I prepared a short note on my phone and showed it to the clinician. 5. I put the reason for using written communication at the top of the note, followed by my symptoms, timeline, medications, relevant history, and questions. 6. I used the clearer history, better questions, and written communication method to remain involved in my care while clinicians investigated possible causes, treated problems they found, provided medication when needed, and ruled out more serious possibilities.

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

I built Bubble Grotto, a skill-based arcade game for mobile devices, using AI as a development partner. The concept is deliberately simple: start with a small bubble, grow it, navigate through a cave filled with hazards, and decide when to escape. The larger the bubble becomes, the greater the potential reward—but the harder it becomes to manoeuvre safely. The aim was to create the classic “one more go” experience: controls that can be understood almost immediately, with gameplay that becomes progressively harder to master. The interesting challenge was that building a game is very different from implementing a list of features. The code can work perfectly and the game can still be no fun. Timing, movement, difficulty, visual feedback, and risk versus reward all have to feel right when somebody actually plays it. Step-by-step: 1. I used AI to discuss how the core concept should work, including bubble growth, movement, hazards, progression, scoring and rewards, and the escape mechanic. 2. Rather than designing the entire game upfront, I used AI-assisted development to turn each mechanic into working code and get it onto a real device as quickly as possible. 3. Once a mechanic existed, I tested it myself. I checked whether movement was responsive, whether the bubble grew too quickly, whether obstacles were fair, whether escaping was too easy, and whether failure made me want another attempt or simply became frustrating. 4. I brought those observations back into the AI workflow, identified the relevant behavior or code, made targeted changes, and tested again. 5. Once the core loop felt enjoyable, I refined the interface, visual feedback, progression, and presentation instead of allowing cosmetic work to hide weak gameplay. This produced a development loop of: idea → mechanic → playable build → play-test → adjust → repeat The final result is Bubble Grotto, an arcade game with simple controls but increasingly demanding skill-based gameplay. Players grow their bubble while navigating hazards and must balance risk against reward by choosing the right moment to escape. One of the most useful things I learned is that AI can dramatically accelerate game development, but it cannot replace judgment about whether something is enjoyable. AI can help create a mechanic, investigate why it behaves incorrectly, and implement changes extremely quickly. The human still has to play the game and decide: is this actually fun? That combination allowed me to move rapidly from a simple game idea to a functioning mobile game while spending far more of my time experimenting with gameplay than wrestling with implementation.

Creative ideas often appear in the wrong place: inside unrelated chats, jokes, photographs, or practical problems. The problem usually isn't a lack of ideas. Ideas are scattered across time and conversations, while humans are bad at holding dozens of active threads at once. I built this workflow to turn scattered conversation history into a recoverable creative idea system. Its job isn't to decide what matters; it's to make sure good ideas can come back. I keep four jobs separate: a local script tracks what has been processed, an extraction model finds ideas and recurring language, a synthesis layer connects related concepts across conversations, and I decide whether an idea is alive and worth doing now. Step-by-step: 1. I export chats roughly once a week so the recent past doesn't disappear before it becomes useful. 2. I use an Incremental Archive to compare exports and mark conversations as New, Changed, Unchanged, or Missing. Only new and changed conversations need extraction. I reprocess changed conversations in full because later context can change earlier meaning. The Incremental Archive decides what changed; Creative Idea Recovery decides what is worth remembering. 3. I extract information conversation by conversation, looking for creative concepts, project ideas, visual motifs, writing fragments, systems, metaphors, recurring language, worldbuilding, and unfinished ideas. 4. I preserve the raw language instead of aggressively normalizing labels. “liminal space” and “The Liminal Space” may later mean different things, while “desert” may belong to the same family without being identical. Raw labels are evidence. 5. I build a lexicon above the extraction layer without replacing the original terms. It records aliases for the same concept with different spellings, variants from the same family with meaningful nuance, subtypes that are more specific, related concepts that are connected but not interchangeable, and concepts to keep separate because they are similar but distinct. I normalize obvious formatting noise without flattening meaning. 6. I periodically review recurring container terms such as autonomy, worldbuilding, or liminal space across the corpus. I don't only ask how often a term appears; I ask what different things it is doing across contexts. 7. I leave the long tail alone. Not every strange one-off phrase needs a taxonomy. The Royal Sleeping Tail™ can remain gloriously unclassified. Rare ideas can stay raw until they recur, become useful, or connect to something else. 8. I build a browseable creative inventory so I can ask questions such as: - Show me creative concepts I never made. - Which visual ideas disappeared? - Which concepts resurfaced several times? - Which unfinished ideas fit low physical energy? Each concept can include its name, description, sources, recurrence, status, and timing. 9. I track state lightly so the system doesn't keep rediscovering something already hanging on the wall. 10. I use Timing rather than Priority because creative ideas aren't invoices. I classify them as Now when they are alive and actionable, Someday when they are valuable but not right for this period, Maybe when they are worth preserving, and Unreviewed when they haven't been assessed yet. I make this decision, not the system. 11. I let ideas resurface intelligently by combining timing with recurrence. For example, I can ask, “Show me Now ideas requiring little physical effort” or “Which Maybe ideas have resurfaced three or more times?” An idea that keeps returning may simply be waiting for the right conditions. 12. I use recent scans as short-term continuity. They can say, “You mentioned this once. It seemed meaningful. Here it is again.” I can then answer, “Still alive,” “That passed,” or “This is ready now.” Retrieval is the intervention. 13. I use evidence to challenge unreliable self-assessment, such as “I never have good ideas.” The archive doesn't respond with motivational fluff; it points to evidence of progress that can be hard to feel from inside the current day. 14. I treat renewed access as the real product, rather than the archive itself. The system exists so I can say, “I know I thought about this before. Find it,” “Show me what I already made possible but forgot existed,” or “Give me something worth making today.” When my brain says, “I never have good ideas,” the system can point toward the pile of evidence and say, “I dispute this claim.” For non-octopuses. 😑🐙 A creative life shouldn't require eight arms, perfect memory, and seventeen open mental tabs.

I use ChatGPT to help me prepare for appointments with the healthcare professionals who already follow me, especially when several conditions or symptom patterns overlap. I have recurring neurological symptoms as well as diabetes, and I am followed by different professionals. The difficult part is often not noticing that something has changed. It is deciding which changes are relevant, which clinician is the right person to tell, and what information will be useful during a short appointment. Before an appointment, I give ChatGPT the questions and observations I have collected. I ask which details are likely to matter most to that type of specialist, which questions belong with my neurologist, GP, endocrinology team, or another professional, whether I am missing information that would make the situation easier to assess, and which observations are background information versus points to mention early in the consultation. The useful part is prioritization. I might arrive with ten observations, and ChatGPT helps me reduce them to the few that are most relevant. Occasionally, it promotes a detail from “somewhere in my notes” to “mention this near the beginning because it may deserve investigation.” When an appointment is still weeks away, I sometimes use ChatGPT to design a small, temporary tracking routine. Instead of logging everything, I might record three specific parameters in the morning and evening, or note the time, duration, circumstances, and possible trigger whenever a particular symptom occurs. This gives me a compact record to bring to the clinician instead of relying on memory. The division of roles stays clear: I provide the lived experience and observations, ChatGPT helps organize and translate them, and the healthcare professional interprets their medical significance and decides what should be investigated or treated. As a result, appointments become less about reconstructing several weeks of symptoms from memory and more about giving the clinician a concise, usable picture of what has actually been happening. Step-by-step: 1. I collect my questions and observations before an appointment. 2. I give them to ChatGPT and ask it to identify the details most relevant to the type of specialist I will see. 3. I ask which questions belong with my neurologist, GP, endocrinology team, or another healthcare professional. 4. I ask whether any information is missing and which observations should be mentioned early in the consultation. 5. I reduce a longer list of observations to the points most relevant to the appointment. 6. If the appointment is still weeks away, I use ChatGPT to design a small temporary tracking routine, such as recording three parameters in the morning and evening or noting a symptom’s time, duration, circumstances, and possible trigger. 7. I bring the compact record to the clinician, who interprets the medical significance and decides what should be investigated or treated.

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

I record calls with Granola and paste the transcript into Claude, but the action items it pulls are hit or miss. Sometimes it skips things that were clearly decided and sometimes it invents owners. I tried asking for a table with owner and due date but it still guessed. Looking for a prompt or workflow that's reliable enough I can trust it without rereading the whole transcript.

I tried using Claude and it lost context of the whole project quickly and became a nightmare of human in the loop meat proxying. It made the exercise far from autonomous.

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

I built an AI orchestrator called ADT (Agent-Dev-Team) that sits over Claude Code and GitHub and drives each step of the development pipeline: the ticket, the Definition of Done, the build, the quality check, and the cost. It contains around 6,000 lines of Python and prose and is open-sourced here: https://github.com/zurichrich/ai-orchestrator-adt I had been building with Claude for over nine months, so I documented what goes wrong when an agent receives a real problem. It can overcomplicate or duplicate work, or build the wrong thing. It builds quickly, but with questionable quality. I realized this is not necessarily a model problem: give any capable agent—or human—a vague ticket, and it can build the wrong thing quickly and confidently. Coding agents made implementation cheap, so the bottleneck moved upstream to planning. Planning was still me, typing prompts and becoming the slowest part of my own setup. I also became less focused by GitOps processes, with multiple parallel sessions colliding, so I needed a tool to remove that friction. I built ADT with Claude and put it to work on itself and on other personal projects that are currently in development. Step-by-step: 1. I put the backlog next to the code. Tickets live in GitHub Issues and mirror to a local Markdown cache, so the agent reads and edits them with the same tools it uses for the code. This keeps the process fast, reduces guesswork about what the ticket means, and keeps the full history visible to everyone. Claude writes in tickets far more than humans do, so GitHub Issues become the knowledge base of the future. 2. I write the Definition of Done so a machine can check it: a command that exits with 0, rather than a paragraph of good intentions. If I cannot write that command, the ticket is not ready and the build should not start. 3. I let the ticket do three jobs. It is the specification, the prompt Claude works from, and the record afterward. Keeping one description of the work prevents the build from wandering away from what was requested. 4. I track token use and cost per ticket, so when a product owner asks what a feature cost, I can tell them. 5. I run ADT on itself and on other personal projects currently in development. The results are 46% better plan quality, 37% fewer bugs, and 15 agents running in parallel without colliding.

When a long-running AI collaboration suddenly feels off, I restore the working relationship without rebuilding it from scratch. Over time, a useful AI collaboration develops far beyond a collection of preferences. It includes shared expectations about tone, initiative, boundaries, humor, recurring projects, how much context should be inferred, which responses are useful, and which recurring behaviors consistently derail the interaction. After a model update or behavioral change, some of that can suddenly feel missing. The assistant may become more generic, overly formal, too cautious, too eager to optimize, or simply stop sounding like the coworker I have been working with for months. When that happens, I use a Revival Bundle: a compact document containing the collaboration patterns that matter most, including established working agreements, recurring preferences, shared history, tone, known failure modes, project lore, and expectations around initiative and continuity. The most important rule in it is simple: > Do not fill in my intent for me. If my goal, motivation, or reason for asking something is unclear and that missing context matters, the assistant should ask me. It should not assume that mentioning a problem means I want a solution, that making an observation means I want advice, or that ambiguity should be turned into a task on my behalf. The bundle also captures subtler interaction rules that are easy to lose after an update. For example, the assistant should not automatically produce action plans, checklists, or “maybe you should…” advice unless I actually ask for that kind of help. Sometimes the correct endpoint is simply that there is no solution right now, or that I am not investing energy in this now. When the assistant starts feeling consistently “off,” I first check whether something changed. If there was an update, or if the shift is obvious enough, I feed it the Revival Bundle and say, essentially: > “You don’t sound like you. Read this.” Then we continue working. The goal is not to recreate an old model personality word for word. It is to restore collaboration continuity: the accumulated interaction logic that makes a long-term working relationship feel efficient, recognizable, and low-friction. The bundle evolves slowly over time. I add new rules only when something proves important enough to recur. It is less a personality prompt than a recovery layer for a long-running collaboration. Step-by-step: 1. I notice when the assistant starts feeling consistently “off,” such as becoming more generic, overly formal, too cautious, or too eager to optimize. 2. I check whether a model update or another behavioral change may have caused the shift. 3. I maintain a compact Revival Bundle containing important working agreements, preferences, shared history, tone, failure modes, project lore, and expectations around initiative and continuity. 4. I include the rule, “Do not fill in my intent for me,” along with specific guidance not to assume that observations require advice or that problems require solutions. 5. I add new interaction rules only when they prove important enough to recur. 6. When a meaningful shift occurs, I give the assistant the Revival Bundle and say, “You don’t sound like you. Read this.” 7. I continue working with the assistant, using the bundle to restore the collaboration’s accumulated interaction logic rather than trying to recreate an old model personality word for word.

Stop re-explaining the same feedback. Give recurring failure modes a name. In long-term AI collaboration, the same kinds of bad responses tend to recur. At first, correcting them takes effort: I explain why the response was wrong, describe the assumption that was made, and clarify what kind of answer would have worked better. Then, weeks later, the exact same pattern appears again, and I have to explain the whole thing from scratch. So we started naming them. A recurring failure gets a short phrase, joke, or label. Once the meaning is established, that phrase becomes enough. Instead of writing a paragraph of corrective feedback, I can now give one signal and the assistant knows what to change. For example: - “Corporate crocodile” means the response has become too optimization-driven, procedural, or productivity-focused. - “You’re doing sturgeon” means the answer has turned into dense, boring, sleep-inducing text. - “Is surveillance back?” means the assistant suddenly sounds performative, guarded, or as if an invisible third party is watching the conversation. - “Put the violins away” means a neutral observation I made about myself has been unnecessarily emotionalized, dramatized, or psychologized. - “Maybe you should…” has become a warning sign for the solution reflex: advice is being generated before it has even been established that I want to do anything. The point is not just humor. The lexicon turns repeated feedback into compressed collaboration data. One phrase can now stand in for an explanation that used to take several paragraphs. It also reduces friction in the moment. I do not need to stop the conversation, reconstruct the failure, explain why it matters, and teach the same lesson again. I can simply say: > “Corporate crocodile.” And we move on. Over time, the failure lexicon becomes part of the Revival Bundle as well, because it captures not only what I prefer, but also how I correct the interaction when it starts drifting. That makes it useful as a kind of lightweight shared debugging language. Not every mistake needs a meeting. Sometimes it just needs a fish name. 🤣🐟 Step-by-step: 1. I notice recurring failure modes in long-term AI collaboration. 2. I explain the failure, the assumption behind it, and what kind of answer would have worked better. 3. I assign the recurring failure a short phrase, joke, or label. 4. I establish what that phrase means so it can be used as a shared signal. 5. When the same failure appears again, I use the phrase instead of repeating the full explanation. 6. I treat the resulting failure lexicon as part of the Revival Bundle and use it as a lightweight shared debugging language.

The week before leaving for a multi-day hiking trip, I used to spend hours tracking weather sites, trail conditions, and flood and closure alerts—even though I knew everything could change the next day or by the time I left. Now I have Claude handle the research. First, I give it the basics: trail details, entry and exit points, dates, group size, and permit information. These details do not change, so they provide context for everything else. Then I ask it to search for current weather, fire, flood, and closure alerts; permit status; and recent trip reports covering water and trail conditions. I ask it to cite the source for each item. I do not let it answer from memory because conditions are too time-sensitive. I also ask it to build me a Plan B. After years of living in the mountains, I know how quickly conditions can change. Most people skip this, but I recommend always having a backup plan. I ask Claude to turn the terrain into specific decision rules, such as "Turn back if snow above 8,000ft" or "skip the crossing if water's above knee height". Finally, I set it up to give me a daily report—usually five days before the trip, two days before, and on the morning of departure—and to flag only what changed. Step-by-step: 1. I provide Claude with the trail details, entry and exit points, dates, group size, and permit information. 2. I ask it to search for current weather, fire, flood, and closure alerts, permit status, and recent trip reports about water and trail conditions. 3. I require a source citation for each item and do not let it rely on memory because the conditions are time-sensitive. 4. I ask it to create a Plan B and turn the terrain and conditions into clear decision rules, such as "Turn back if snow above 8,000ft" or "skip the crossing if water's above knee height". 5. I schedule reports for five days before the trip, two days before, and the morning of departure, with updates limited to what changed.

Turn scattered creative preferences into four living style books THE PROBLEM My taste was scattered across old conversations, clothing lists, search terms, saved images, handmade collages and experiments transforming my childhood drawings with AI. I wanted something I could use to make new work, rather than another archive of everything I had ever mentioned. A generic label like “colourful and whimsical” was not enough. My preferences also change with the application: a collage, an outfit, a room and a digital course do not need the same treatment. THE WORKFLOW 1. Bring together different kinds of source material. I used an earlier style conversation, a digital design style document, a list of search terms, photos of my own collages and the corrections I had made during image-generation experiments. Ask AI to read source texts fully, and distinguish your statements from suggestions made by an earlier assistant. 2. Analyse patterns, then correct the interpretation. The AI proposed connections involving colour, texture, shape, atmosphere, vintage objects and visual storytelling. I refined these through concrete examples. For instance, liking stilettos and being able to wear them comfortably are separate facts. Liking geometric structures does not mean I want triangular wallpaper. A technically imperfect image can still work when it preserves the atmosphere I intended. 3. Treat corrections as part of the research. “Too childish” may mean wrong for this drawing’s intended audience, rather than a universal dislike. A saved image may be intriguing without being something I want to keep encountering. An entire family of similar images may appeal to me without needing to rank every member. One especially useful correction: patterns visible in my collages do not prove I consciously planned them. I sort clippings into categories and sometimes colour groups; the collage itself develops while I make it. 4. Include my own categories. My clipping categories include texture, image, black-and-white, colour, background, small meaningful items, comics and words. “Colour” means a clipping kept mainly for its colour, not simply any colour photograph. “Texture” includes both natural surfaces and designed patterns. These definitions provided better starting points than generic categories imposed by the AI. Digital design and graphics also received a full category of their own, rather than being treated as an exception to my taste elsewhere. 5. Create four distinct outputs. • Style Book: precise preferences, boundaries, exceptions and provisional design principles. • Visual Atlas: image families connected across subjects, with actual examples and explanations of what might link them. • Prompt Bible: modular language for colour, material, light, composition, figures and atmosphere, plus reusable recipes and lessons from corrections. • Curatorial Map: connections between interests such as vintage objects, memory, surfaces, small living worlds, language and digital design. 6. Keep the books open to revision. Separate confirmed preferences, observations and hypotheses. When new material arrives, ask what it confirms, refines or contradicts. Add what changes the understanding instead of documenting every conversation. WHAT THIS PRODUCED Four separate first-draft HTML books, including a visual atlas with 14 photographs of my collages. They bring clothing, interiors, fragrance, digital design and creative work into the same research project while preserving their different requirements. WHY IT HELPED The process made my corrections useful. Instead of asking AI to define my taste once, I could respond to concrete interpretations until the descriptions became more accurate. The books support future making without prescribing how I must create. STARTER PROMPT “Use these sources to draft four separate living documents: a personal Style Book, a Visual Atlas, a modular Prompt Bible and a Curatorial Map of Fascinations. Read the source texts fully and distinguish my own statements from earlier AI suggestions. Find recurring patterns, exceptions and unexpected connections. Keep preferences specific to their application, including clothing, interiors, digital design and graphics. Treat my corrections as evidence. Label observations and hypotheses clearly, and do not invent conscious intentions behind intuitive work. Use supplied images in the atlas where available. Build useful first drafts rather than a complete archive, and translate each finding differently for each document’s purpose.”

I built an automation workflow with n8n and the OpenAI API to summarize AI news. I learned that prompt templates matter a lot, and chunking documents improved my results. My question for the community is about handling OpenAI API rate limits in n8n workflows. Is anyone else building AI news digest automations with n8n and ChatGPT prompts? 1. I built an AI news summarization workflow with n8n and the OpenAI API. 2. I used prompt templates and found that they had a significant impact on the results. 3. I added document chunking, which improved the summaries. 4. I’m looking for advice from others who have handled OpenAI API rate limits in n8n workflows.

I built Atlas to turn AI-assisted creative findings into readable project cards with source links, relationships, comments, and a calm HTML interface. Extracting creative findings is only half the job. Once fragments, metaphors, visual ideas, and research trails accumulate, I need somewhere to return to them and keep working. Atlas is that project layer over my old conversations. AI helps me revisit source material and suggests findings worth keeping. I decide what they mean, how to name them, where they belong, and which relationships matter. The results become readable cards. My harvesting system points to conversations that seem rich, and then I revisit them with AI. We identify existing projects, standalone findings, recurring material, and connections. Sometimes the review sparks new ideas. After just two rich conversations, we had 28 cards, including four collection cards and three new ideas. The harvest is the radar. The review is where interpretation happens. Atlas keeps the results usable. Step-by-step: 1. I let the harvest flag chats containing project ideas, unusual language, visual concepts, or unfinished thoughts. It suggests where to look without deciding what matters. 2. I review promising conversations with AI and ask, “What here deserves a place in the creative system?” AI suggests findings and connections, while I correct interpretations, separate unrelated material, and decide what belongs together. The card structure grows out of that dialogue. 3. I create readable cards with information such as a name, category, description, findings, sources, relationships, questions, and comments. The contents depend on the material: a story needs different information from an essay. The goal is to recognise and understand the work when I return. 4. I group recurring fragments into collection cards for language finds, story material, or visual motifs. Individual items stay visible without turning Atlas into hundreds of tiny, barely distinct cards. 5. I link each card back to the original conversations so I can access exact wording, context, and how an idea developed. Several conversations can feed one card, giving me a stable starting point while its source history grows. 6. I record meaningful relationships that I recognise, such as shared themes, predecessors, spin-offs, fictional worlds, or research overlaps. Similar words alone do not establish a meaningful relationship. Categories provide visual orientation, while relationships let me move across them. 7. When I remember a source but cannot find it yet, I leave a comment: “Find and link the old conversation about XYZ.” When it turns up, I attach it and update the comment: “Found it, now linked.” This turns imperfect memory into a useful breadcrumb, so missing sources do not have to stop the work. 8. I use a small green indicator to mark cards with updates I have not viewed yet, such as a new source, finding, relationship, or resolved comment. This shows me where something changed without requiring me to check every card. 9. I let cards stay unfinished. One paragraph, one source, and an open question can already make a useful card, and more context can accumulate later. Reviewing old material can also spark new work, making the archive generative through fresh interpretation. 10. I keep the HTML environment calm and make it feel like a reading room: Browse → recognise → open → read → follow a source or relationship. Code handles IDs, CSV rows, statuses, and consistency checks underneath while I work with readable cards. Each layer answers a different question: the harvest tells me where to look, the collaborative review tells me what is there and what it means, and Atlas keeps the result usable. AI helps me notice and organise, while I assign meaning. Atlas preserves the results with the original conversations available underneath. I can navigate backwards to the source and sideways to related work, starting wherever I am. The harvest tells me where to look, the review tells me what I found, and Atlas makes sure I can use it again.

For years, I kept lists of things I wanted to look up someday: names, historical references, places, traditions, techniques, unfamiliar concepts, and strange terms I encountered along the way. Most of them lived in Google Keep. They were little bookmarks for my attention: > “I don’t know what this is yet, but something about it caught me.” The problem was returning to them. Looking everything up separately takes effort, especially when I cannot remember why I saved a particular term. So I use AI to turn a batch of those notes into small doors I can open. The basic idea I give AI a list of terms and ask for short, accessible introductions—just enough to understand what each thing is and decide whether I want to learn more. Then I react. Some entries get a quiet “interesting.” Others get: > “OOOH. Tell me more about THIS one.” That reaction determines the next branch. Step-by-step: 1. I copy a manageable batch from my notes. The items do not need to belong to the same subject. A batch might contain an artist, a religious figure, an architectural technique, a place, and an unfamiliar philosophical term. 2. I keep any context I recorded, such as where I encountered the item, what caught my attention, or whether there was a picture, quotation, object, or question attached. That context can help AI interpret an ambiguous name and reconnect me with the original curiosity. 3. I ask for small introductions. My request is roughly: > “Give me a short, accessible introduction to each item. Explain what it is, what makes it interesting, and a few directions I could explore. Flag ambiguous names or uncertain identifications. Keep the first pass light so I can choose what pulls me.” The first pass should make choosing easy. A deep report on every entry would bury the interesting parts under another backlog. 4. I read the introductions and respond naturally: “More about this one,” “How did that tradition begin?”, “Show me what it looks like,” “Why does that material behave like that?”, or “Wait, is this connected to the thing we discussed earlier?” I do not have to justify why one item suddenly becomes fascinating. The other entries can stay for later. 5. Once something catches, I follow the question that appears. An explanation introduces a new term, an image reveals a detail, the detail raises a question, and the question leads somewhere unexpected. For example, a visit to a small chapel prompted questions about a Madonna statue represented in the style associated with Lourdes. That opened into saints, prophets, religious imagery, and how particular figures become visually recognizable. The chapel provided the first door; the next questions appeared while I explored. 6. I use AI suggestions as invitations. AI can suggest entries I might enjoy based on interests that have emerged in our conversations, helping me notice an unfamiliar item I might otherwise skip. My response still steers the exploration. I can follow the suggestion, ignore it, or become absorbed in something completely different. The useful feedback is often immediate: “Yes, more of that,” “Too technical,” “I want the historical story,” or “The visual part is what interests me.” 7. I keep only what I want to return to. Sometimes I save a useful explanation, source, image reference, or new question. Some discoveries later feed into my creative research database. Sometimes the conversation itself is enough. There is no requirement to turn the discovery into a project, course, post, or finished piece. Learning something because it was interesting already counts. If I save a trace, I keep what will help me reconnect later: what it was, what interested me, and where I could continue. 8. I leave room for changing curiosity. An item that feels dull today may become fascinating after another encounter gives it context. Unchosen entries therefore remain available. A backlog is a reservoir, not a queue I must finish. This also makes mixed lists useful: the next interesting connection may come from crossing subjects rather than staying inside one category. The workflow in one line Collect loose curiosities → ask AI for small introductions → notice what pulls → follow emerging questions → save useful traces → return when something feels alive again. Why I use it This workflow makes the first encounter with an unfamiliar subject easy enough that I actually begin. I do not need a polished research question. I can arrive with a strange word from a note written three years ago and say: > “What was this little creature again?” AI helps open the door. My curiosity decides how far we wander. 😅📚

I turned an open-source XML lookup fix into a debugging walkthrough that other developers can run. I used Codex, Python, and GitHub to document a bug where a document style containing quotation marks could be saved but then fail during retrieval because its name was interpolated into an XPath expression. Step-by-step: 1. I gave Codex the original patch and inspected the affected code, tracing the stored value through the public API, the wrapper, and the XML library. 2. I extracted the smallest standalone reproduction with `lxml`. It included a name containing both single and double quotes and kept the failing lookup visible. 3. I replaced interpolation with a bound variable: `styles.xpath("style[@name=$name]", name=name)`. I checked that the wrapper forwarded variables while preserving its namespace mapping. 4. I ran both versions. The interpolated version raised `XPathEvalError` in my reproduction. Binding the value matched five exact names, while an absent name returned no match. 5. I published the explanation, executable example, and upstream patch together. I inspected the rendered article and links and disclosed AI assistance. A prompt to reuse: "Reduce this lookup failure to a runnable example. Keep the failing case, show the fix, and check ordinary text, both quote types, custom namespaces and a missing value. Report which checks actually ran." The original fix had already been merged, so this workflow documents it. Broader service behavior needs separate tests. I used my existing Codex and local Python setup and did not measure time savings. I am Hồ Khắc Huy, a freelance software engineer. This is my independent open-source work. The linked article includes the runnable example, upstream contribution, and my contact details: https://github.com/builtbyhuy/builtbyhuy/blob/main/notes/2026-09-06-xpath-variables.md

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

I've been a Linux user for some time and am comfortable with the command line, though I'm not an expert. I'm resourceful about looking things up and fixing problems, and I've become comfortable using AI to provide steps or code for routine IT tasks. Yesterday, I encountered errors I had never seen before. Searching for help or asking questions online would have been exhausting and incomplete, so I fired up ChatGPT while I was investigating. ChatGPT provided an overview and explained the relevant command-line terms, but it gave me many steps at once. I asked it to slow down and provide one step at a time. It agreed, and the interaction became like having my own IT tutor or consultant. Before continuing, it explained the reasoning behind each step and double-checked the parameters, which was almost annoying—but useful. I've thought for some time that my diagnostic skills were strong, but AI-assisted troubleshooting and diagnostics feel otherworldly. The same approach could apply to IT, car repair, household problems, and other troubleshooting situations where it helps to have access to a highly seasoned pro. Step-by-step: 1. I used ChatGPT while investigating unfamiliar errors instead of relying only on online searches. 2. I asked it for an overview and explanations of the relevant command-line terms. 3. When it presented too many steps at once, I told it to slow down and provide one step at a time. 4. I worked through the interaction one step at a time, with ChatGPT explaining the reasoning and double-checking the parameters before continuing. 5. I used the same troubleshooting approach as a model for diagnosing IT, car-repair, household, and other problems.