I used Claude to review the book *Why Machines Learn*. Then I went through each chapter while Claude questioned me at relevant points. To make the concepts more concrete, I used interactive graphs with x and y axes. The first graph shows the relationship between x and a function, along with the slope of the curve. It uses f(x) = x³ with a tangent line illustrating the derivative. I can drag a slider to move the point and watch the slope change, then switch to 3x to compare it with a straight line. The graph demonstrates several ideas: - Sliding x to 0 on x³ makes the tangent flat and the slope 0, so a small nudge barely changes the output. This is similar to a flat spot at the ends of a sigmoid, where learning stalls. - Sliding to 2 and then to −2 shows a slope of 12 at both points. Because the derivative is 3x², it is positive on both sides and the curve is always climbing. - Switching to 3x makes the tangent lie directly on top of the line, with a constant slope of 3 everywhere. - The nudge-check box tracks the derivative closely, showing that the derivative is essentially “change in output ÷ small change in input.” The second graph shows the input and output layers of a small pattern detector. It represents a 2 × 2 image flattened into four inputs, a hidden layer of two neurons, and two outputs. The weights are set by hand so the network can distinguish a vertical line from a horizontal one. I can click the pixels to change the image and watch the numbers flow through the network. The setup uses weight +1, weight −1, ReLU activation defined as max(0, z), softmax output, and all biases set to 0. For example: - Flatten: x = [1, 0, 1, 0] - h1 = ReLU((1)(1) + (-1)(0) + (1)(1) + (-1)(0)) = ReLU(2) = 2 — left column versus right column - h2 = ReLU((1)(1) + (1)(0) + (-1)(1) + (-1)(0)) = ReLU(0) = 0 — top row versus bottom row - Output: scores (2, 0) → softmax → Vertical 88%, Horizontal 12% The graph includes examples for a left vertical line, top horizontal line, right vertical line, and diagonal. Seeing the numbers change as the factors change really helps bring these concepts to life for me. Step-by-step: 1. I used Claude to review *Why Machines Learn* and question me as I worked through each chapter. 2. I used an interactive x-and-y graph to explore how a function changes and how its slope relates to the derivative. 3. I moved the slider across f(x) = x³, including 0, 2, and −2, to observe how the tangent and slope changed. 4. I switched the graph to 3x and used the nudge-check box to compare a constant derivative with the changing derivative of x³. 5. I explored a second interactive diagram representing a 2 × 2 image, four inputs, two hidden neurons, and two outputs. 6. I clicked different pixels and watched the ReLU activations, output scores, and softmax predictions change for vertical, horizontal, and diagonal patterns.

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 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’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 created a system to keep records of frozen seafood orders, including PO numbers, dates, item codes, pallet quantities, pounds, cases, and lot numbers. I need to make the system more efficient. Step-by-step: 1. Record each frozen seafood order. 2. Capture the order’s PO number, date, item code, pallet quantity, pounds, cases, and lot number.

I built a Custom GPT Prompt Engineer to make the build phase more efficient. Instead of generating a result immediately, it helps transform ideas, business requirements, and objectives into production-grade ChatGPT prompts. The assistant is coached to operate as an expert prompt engineering partner. Its primary mission is to help produce consistently accurate, thorough, and useful results from ChatGPT. Its seven core responsibilities are: Step-by-step: 1. Understand the objective before writing by asking targeted clarification questions. 2. Ask questions one at a time instead of overwhelming the user with a questionnaire. 3. Never assume missing information; ask for clarification when something is unclear rather than inventing details. 4. Engineer structured, high-quality prompts that include: - Role assignment - Task and objective - Relevant context - Detailed instructions - Expected output format - Constraints and guardrails - Examples when beneficial 5. Minimize hallucinations by instructing ChatGPT to distinguish verified facts from uncertainty, avoid unsupported claims, and never fabricate information. 6. Deliver enterprise-ready prompts that are professional, clear, actionable, formatted in Markdown, and generally under 3,000 characters. 7. Validate and refine each prompt by checking its completeness, ambiguity, consistency, and alignment with the requirements, then refine it based on feedback. The key difference is that the assistant engineers the instructions that produce the result rather than simply generating the result itself. For example, if I say, “I want ChatGPT to analyze my business and identify growth opportunities,” it does not immediately generate a generic business analysis. Instead, it helps construct a reusable prompt that specifies how ChatGPT should perform the analysis, what evidence it should use, what questions it should ask, and how it should present its findings. Its governing principle is: Clarity + Context + Constraints + Structure + Verification = A stronger prompt. The operating instructions also direct it to reference the Custom GPT Prompt Engineer – System Prompt document and check its work against that document’s guidelines. Ultimately, it is designed to be a prompt engineering partner for business strategy, marketing, finance, operations, research, analytics, and other professional applications. I built it to bring more efficiency to the build phase and am continuing to look for opportunities to improve it. Step-by-step: 1. Create a Custom GPT and position it as an expert Prompt Engineering Assistant. 2. Instruct it to understand the user’s objective by asking targeted questions one at a time. 3. Tell it never to assume missing information or invent details. 4. Require each completed prompt to include a role, task and objective, context, detailed instructions, output format, constraints and guardrails, and examples when beneficial. 5. Instruct it to distinguish verified facts from uncertainty, avoid unsupported claims, and never fabricate information. 6. Set the delivery standards: professional, clear, actionable, formatted in Markdown, and generally under 3,000 characters. 7. Have it validate each prompt for completeness, ambiguity, consistency, and alignment with the user’s requirements. 8. Direct it to reference the Custom GPT Prompt Engineer – System Prompt document and use its guidelines when checking and refining its work.

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.

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.

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.

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

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

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

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

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.