Workflow Hub

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.

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.

As a fast-moving startup, many of our team's best ideas come from random Slack threads, but get lost and never fully hashed out. Instead of spending hours a day manually adding tasks to our databases, we used Notion's new Agents feature (rolling out soon for GA) and built an "AI Project Manager" that monitors Slack messages daily and logs tasks autonomously. Step-by-step: 1. I connected Notion’s Agents feature to the Slack conversations where team ideas usually appear. 2. I defined the kinds of messages that should become projects or follow-up tasks. 3. I scheduled the agent to review Slack messages every day. 4. I had it capture qualifying tasks in the team’s database automatically. 5. I used the database as the durable follow-up layer so promising threads did not disappear in chat history.

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.

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.

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.

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 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'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 built AIEnhancer to solve a problem I often encountered when working with low-quality images. Many images contain useful content but are too small, blurry, or lacking in detail to reuse effectively. The project uses AI-based image processing to improve image resolution and recover visual details. I wanted to make the workflow simple: upload an image, process it, and receive an enhanced version without needing professional image-editing software. One challenge was finding the right balance between sharpening details and avoiding artificial-looking results. During development, I experimented with different enhancement approaches and focused on keeping the output natural. I'm still interested in improving enhancement quality for different types of images. I'd like to hear how other developers handle image restoration and super-resolution, especially for difficult or heavily compressed images. Step-by-step: 1. I identified the problem of reusing images that were too small, blurry, or lacking in detail. 2. I built AIEnhancer to process low-quality images with AI-based image enhancement. 3. I designed the workflow around uploading an image, processing it, and receiving an enhanced version. 4. I experimented with different enhancement approaches to improve resolution and recover visual details. 5. I evaluated the results for a balance between sharper details and a natural appearance. 6. I continued exploring ways to improve enhancement quality for different image types, including difficult or heavily compressed images.

I wanted a publicly viewable leaderboard on the web, with input coming from creators. I prompted Gemini: " Can you design good looking leaderboards using Google documents. I want three: all time, rolling 30 days and rolling 90 days. They should be different tabs on the same document. They should be easy to administer/update. Show me a mockup and describe how it would work." After I was satisfied that it would be easy to launch and maintain, I got more specific. Because it was for creative types, I wanted more than a basic spreadsheet ranking. Gemini responded: "It features profile avatars, gamified badges, high-contrast dark visual styling, and clear ranking tabs for All-Time, Rolling 30 Days, and Rolling 90 Days..." That's what AI calls creative, I guess. Later in the chat, Gemini suggested achievement levels with a more creative feel: - 👑 Century Virtuoso / Platinum Mic - 🔥 Monthly On-Fire / Speedster - 🎙️ Heartstring Weaver - 🌟 Smile Architect For the podium treatment, rows 1, 2, and 3 feature custom metallic highlights—Warm Gold, Silver Slate, and Bronze Copper—with circular numerical rank badges to make top contributors stand out instantly. Gemini heavily integrated Google Docs and Google Sheets. The system uses Google Apps Script to update the leaderboard in real time based on creator activity. Step-by-step: 1. I asked Gemini to design three leaderboards—All-Time, Rolling 30 Days, and Rolling 90 Days—as separate tabs in the same Google document. 2. I asked for the leaderboards to be easy to administer and update, along with a mockup and an explanation of how they would work. 3. After reviewing the initial concept, I clarified that the leaderboard was for creative types and should be more distinctive than a basic spreadsheet ranking. 4. Gemini added profile avatars, gamified badges, high-contrast dark visual styling, and clear ranking tabs. 5. I incorporated creative achievement levels, including Century Virtuoso / Platinum Mic, Monthly On-Fire / Speedster, Heartstring Weaver, and Smile Architect. 6. I used Warm Gold, Silver Slate, and Bronze Copper highlights for the top three rows, along with circular numerical rank badges. 7. I connected the system to Google Docs and Google Sheets and used Google Apps Script to update it in real time based on creator activity.

Je veux créer N’ose Digital IA, un SaaS international dédié à l’automatisation et conçu de A à Z comme un véritable business SaaS, avec l’IA au cœur de la plateforme. Le projet comprend un dashboard IA de service client ainsi qu’un agent vocal qui répond aux clients et s’appelle « Client ». Step-by-step: 1. Créer le SaaS N’ose Digital IA. 2. Optimiser la plateforme autour de l’automatisation. 3. Concevoir un dashboard IA dédié au service client. 4. Intégrer un agent vocal appelé « Client » pour répondre aux clients. 5. Développer la plateforme comme un business SaaS international, avec l’IA au cœur du projet.

I’ve been building AIEraser, a browser-based tool for removing unwanted elements from photos. One challenge has been making reconstructed areas blend naturally with nearby textures, especially when removing larger objects from detailed backgrounds. Early versions often left blurred patches, so I focused on improving contextual reconstruction while preserving the image’s original dimensions and sharpness. I also learned that selection flexibility matters. Some users prefer brushing over irregular objects, while others find box or automatic selection faster, so I added all three approaches. I’d appreciate feedback from anyone who has worked on image inpainting or object-removal tools. What types of images or backgrounds usually expose the biggest weaknesses in these models? I’m particularly interested in difficult test cases and suggestions for evaluating output quality. Step-by-step: 1. I built AIEraser as a browser-based tool for removing unwanted elements from photos. 2. I tested object removal on detailed backgrounds and identified blurred patches as a weakness, especially when removing larger objects. 3. I focused on improving contextual reconstruction while preserving the original image dimensions and sharpness. 4. I added brushing, box selection, and automatic selection to support different user preferences and object shapes. 5. I’m seeking difficult image and background test cases, along with suggestions for evaluating the quality of the output.

I put Gemini Deep Research and Perplexity Pro to work as my personal research assistants. For robotics research, I tell them to stick to top-tier journals and primary sources only, and demand citations and dates for everything. Then I have them distill the highlights into a ranked list so I know exactly where to dig deeper. Step-by-step: 1. I defined the robotics research question and the boundaries of the search. 2. I instructed Gemini Deep Research and Perplexity Pro to use top-tier journals and primary sources only. 3. I required citations and dates for every important claim. 4. I asked each tool to distill the results into a ranked list of the most important findings. 5. I used that ranked, cited overview to decide which original papers deserved a deeper read.

I’m building GradePath because schoolwork gets scattered quickly. A lecture, my notes, and the files for a class can all end up in different places. Then, when it’s time to study, I have to dig around to find what I need. The idea is simple: record a class, keep the recording and course materials together, and return to them later. If I ask Tutor about something, it should show me the relevant part of my notes, files, or class recording. If it can’t find an answer, it should say so. I also want students to be able to share useful study sheets with people who are actually in their class. I’m not trying to turn school into another content feed. I want to make it easier to keep up with a class and find the right material when I need it. Step-by-step: 1. I record a class. 2. I keep the recording, notes, and course materials together in GradePath. 3. I return to those materials when I need to study. 4. I ask Tutor about a topic and have it show the relevant part of my notes, files, or class recording. 5. If Tutor can’t find supporting material, it says so instead of presenting an unsupported answer. 6. I share useful study sheets with students who are in the same class.

Vercel provides the domains and the base “wiring.”