I built a repeatable, human-directed AI workflow for turning an original emotion, memory, or story into a finished WazWorld song, complete with cover artwork and release content. It addresses one of the biggest problems with AI music: a simple prompt can produce something technically impressive but generic, overproduced, or disconnected from the creator’s real intention. The workflow begins with a human trigger—an experience, relationship, place, mood, or musical idea that I genuinely want to express. WazWorld generally moves between dark alternative/electronic music and California coastal country-rock. Step-by-step: 1. I create a detailed artistic brief describing the song’s emotional core, story, genre, energy, vocal character, instrumentation, arrangement, dynamics, and intended listener experience. 2. I work with ChatGPT to develop and challenge the concept, write and rewrite lyrics, remove clichés, and design the full arrangement. This includes the intro, verses, choruses, instrumental passages, transitions, musical peaks, and outro. ChatGPT also helps translate my direction into precise production language and exclusions that Suno can understand. 3. I generate versions in Suno, treating each result as a demo rather than a finished song. I evaluate the vocal delivery, lyrics, bass, guitars, synths, drums, tempo, arrangement, and emotional impact. Then I make targeted prompt changes and generate new versions. A song may go through dozens of iterations before it sounds the way I originally heard it in my head. 4. After selecting the final music, I use ChatGPT and AI image generation to develop cover artwork that matches the song’s emotional identity. I adapt the artwork for streaming, YouTube, Instagram, Stories, and Shorts, then create the metadata, descriptions, captions, and promotional material needed for release. 5. I distribute the finished music through services such as DistroKid and publish it across streaming and social platforms. The final result is not a one-click AI song. AI provides creative and production tools, but I direct every major decision—from the original emotion and lyrics to the arrangement, instrumentation, vocals, artwork, and release strategy. Someone can recreate this workflow by starting with a clear human idea, documenting the desired sound, generating multiple versions, evaluating each one like a producer, and iterating until the finished work communicates the original intention.

I’m researching two separate documentary films. For each project, the bot runs three web crawls and one health check every day. Based on my notes, scripts, and other existing initial research, it identifies research domains by theme and media type, favoring audio and images while applying a higher threshold to other documents. Anything scoring eight or higher is logged in Notion and downloaded automatically when possible. The bot cycles through different themes, and the health check adjusts the similarity threshold based on the results. If many items score eight, it may log and download only nines. If fewer qualifying items appear, it may begin downloading sevens. Most items cannot be downloaded because they are inaccessible to the bot, but they are still logged and linked. I review the items in Notion and mark each one according to criteria such as “people only for research” or “reject—permissions required.” It isn’t a full replacement for professional archival research, but I feel it’s getting me 90% of the way there. As an independent filmmaker, this is a huge benefit. Each morning, it sends me a synopsis, and each week, it sends me a list of pre-written emails to send to archives that require human interaction. Step-by-step: 1. I provide the bot with my notes, scripts, and existing initial research for each documentary project. 2. For each project, the bot runs three web crawls and one health check every day. 3. It identifies research domains by theme and media type, with a preference for audio and images and a higher threshold for other documents. 4. It logs items scoring eight or higher in Notion and automatically downloads them when possible. 5. It cycles through different themes and uses the health check to adjust the similarity threshold: it may focus on nines when many eights appear, or begin downloading sevens when fewer qualifying items appear. 6. It logs and links items that cannot be downloaded because they are inaccessible to the bot. 7. I review each item in Notion and mark it according to criteria such as “people only for research” or “reject—permissions required.” 8. Each morning, I receive a synopsis, and each week, I receive pre-written emails for archives that require human interaction.

I set up an AI assistant to run my entire writing business on autopilot. Every morning, it pulls RSS feeds from more than 30 AI and writing sources, deduplicates them against the previous day’s digest, curates the top items, and sends me a single Telegram message with numbered, linked items before I wake up. At 11 a.m. each day, it generates an original writing craft post. The topic comes from a rotation pool of more than 15 categories, and the assistant avoids anything used in the last 30 days. It also creates accompanying artwork in a rotating fine-art style, then cross-posts the content to Facebook, X, and my blog, including the featured-image upload to WordPress. Each week, it compiles and sends an email newsletter to my subscriber list through Brevo. It pulls from a curated candidates file that I approve before the newsletter goes out. Behind the scenes, the assistant manages a fleet of five servers, including servers for my wife, daughter, and two business colleagues. It handles daily backups, monitors costs across providers, and reminds me when context windows are becoming expensive. The key insight wasn’t the automation; it was the partnership model. My assistant has a persona file (`SOUL.md`) that defines how it communicates, a memory file (`MEMORY.md`) with everything it needs to know about my life and business, and a playbook of behavioral rules built from real mistakes over time. It pushes back on bad ideas, flags risks before executing, and has genuine opinions about craft and content. That shift—from “tool you talk to” to “colleague who has your back”—is what I wrote my book about. *Harnessing the Machine* is the field guide I wish I’d had when I started. It isn’t a tutorial, because the technology changes weekly; it’s a guide to building a working relationship with something that remembers yesterday. The tech stack is OpenClaw, GLM-5.2 as the primary model, DeepSeek V4 Pro as the fallback, and AWS Lightsail. The total monthly cost is under $30. The real cost was calibrating the assistant: teaching it what I care about, what “good” looks like, and when to ask versus when to act. That’s the part most people skip, and it’s why most “AI automation” posts feel like demos rather than relationships. Tools used: OpenClaw, GLM-5.2, DeepSeek, Telegram, WordPress, Brevo Step-by-step: 1. I configured OpenClaw with a persona file (`SOUL.md`), a memory file (`MEMORY.md`), and a behavioral playbook built from real mistakes. 2. I connected it to RSS feeds from more than 30 AI and writing sources and had it deduplicate, curate, and send a numbered Telegram digest each morning. 3. I created a rotation pool of more than 15 writing categories and instructed it to avoid topics used in the previous 30 days. 4. I scheduled it to generate a daily writing craft post, create artwork in a rotating fine-art style, and cross-post the result to Facebook, X, and my WordPress blog with a featured image. 5. I set up a weekly Brevo newsletter that pulls from a curated candidates file I approve before sending. 6. I connected the assistant to five servers, including servers for my wife, daughter, and two business colleagues, and had it manage daily backups, provider costs, and expensive context windows. 7. I configured GLM-5.2 as the primary model, DeepSeek V4 Pro as the fallback, and AWS Lightsail as the hosting environment. 8. I calibrated the assistant by teaching it my standards, what “good” looks like, and when to ask for approval versus acting on its own.

I’m building a mobile game called ExoLab Blast with Astra. I developed it through conversation, starting with the basic concept and continuing through testing the game mechanics. Astra also created and repeatedly updated the game’s graphics and UI based on my feedback. Step-by-step: 1. I discussed the basic concept for ExoLab Blast with Astra. 2. I used Astra to build out the mobile game. 3. I tested the game mechanics. 4. I gave feedback on the graphics and UI. 5. Astra created and updated the graphics and UI multiple times based on that feedback.

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

I'm not a professional developer, but I built Sujido, a live word puzzle, with multiple AI agents. For months, they gave me bloat, lost context, and slop, and neither I nor the models could untangle what had been decided or why. I eventually settled on two agents: one Claude instance that plans and reviews, and another that builds. I imposed rules on both, one failure at a time. None of these rules would surprise a professional engineering team, but nobody handed them to me. That's the key lesson I learned: agents won't bring the discipline for you. You have to impose it. When I showed the first game revision to strangers, their verdict was that the first half was "boring" and the second half was novel. It was hard news to hear about my baby, but I took the feedback to heart and cut the game in half. That required surgery on code tangled across both halves, followed by a rebuild under the rules below. Before the rebuild, a separate AI audit graded the codebase B−. Afterward, it graded it A−. The deployed site shrank by 97.5%, and every serious finding was fixed and locked in by an automated test. The models didn't change drastically, but my operating rules did. Step-by-step: 1. I wrote a constitution before the first prompt. The repo holds what every agent must read before working: `CLAUDE.md` files for the project as a whole and for each major part of the code, a collaboration protocol for how the agents and I work together, a spec for the core data format, and a decision log. The data format is changed there first and then in code. Nothing is remembered unless it is written down. That's my life as well. :) 2. I split the work by role, not by task. One Claude instance is the strategist: it writes briefs, reviews reports, and never commits code. Claude Code in VS Code is the builder: it executes the brief, writes the tests, reports back, and never releases. Neither agent can approve its own work. 3. I made every job start from a written brief, and I never edit briefs. Each brief is committed to the repo with an exact scope, such as "do X only, do not begin Y." If plans change, a dated amendment states what it supersedes. The builder may skip a risky item with a written reason; skipping is better than forcing it. 4. I used mock-ups with real data instead of descriptions. Anything I will look at gets a mock-up, and I approve it before any code is written. I learned this when a status report described only in words arrived on my phone formatted as a wall of text. The approved mock became the spec, and the tests pin the output to it. 5. I proved that every test could fail. No test is trusted until it has been run against deliberately broken code and caught the bug. A test suite that has never failed hasn't proven anything. 6. I verified reports against the real repo. Agent reports drift. One summary said players rated a puzzle "just right" when the log said "too easy." An audit said there were about 25 unused functions; a recount found 29. The strategist spot-checks load-bearing claims against the actual files and data before anything ships. 7. I built gates the agents can't talk their way past. All work lands on a branch that auto-deploys to a test site. GitHub Actions lints and runs the Python and headless-browser tests on every push. A git hook refuses direct pushes to production. Releases are fast-forward merges that only I perform, after CI is green and I've tested the build personally. The live site shows the release's commit ID, and I check it before calling it shipped. Nothing merges automatically. An agent's "looks good" is just another report, and reports drift. 8. I gave the system a memory. Every session ends by updating the decision log and a "resume here" document, so the next session—a fresh model with no recollection—picks up exactly where the last one stopped. Without this, every session starts by relitigating old decisions. 9. I let the data and end users overrule me. A scheduled GitHub Action turns player telemetry into a daily report. It showed that the difficulty dials I assumed mattered did not predict what players found hard; what mattered was how misleading the starting arrangement was. When testers were confused by the tutorial, I rebuilt it even though I had already approved it. Player feedback about their own experience outranks my earlier rulings. AI agents are velocity multipliers, but they multiply bad structure as quickly as good code. The rules came from me, not the models: the AI writes the code, while the rules, gates, and written record keep the process honest. See the result at Sujido.com. Finding the anagram is the easy part; sliding it into place is the hard part. One board took me 902 moves. My S.O. solved it in 242, and I haven't heard the end of it. Try to break it!

Post-production for each of my podcast episodes used to be a significant task, even when an episode was audio-only. I’ve now built a workflow with Claude and Descript to automate the production process. I clean up the original recording in Descript, export the transcript to Claude, and run a single command to generate the remaining assets. This includes show notes for Hello Audio, opening and closing scripts written in my voice using anti-AI files to avoid a robotic tone, audio clips and audiograms for social platforms through a custom Claude skill, teaser posts for each audiogram on LinkedIn, and launch-day posts for LinkedIn and Substack, where my audience is. I’m sure there’s a way to streamline the workflow further to include distribution of the posts, audiograms, and episodes. It’s a work in progress 😀 Step-by-step: 1. I clean up the original podcast recording in Descript. 2. I export the transcript from Descript to Claude. 3. I run a single command in Claude to produce show notes for Hello Audio. 4. I generate opening and closing scripts for each episode using my voice and anti-AI files to avoid a robotic tone. 5. I use a custom Claude skill to automate the production of audio clips and audiograms for social platforms. 6. I create teaser posts for each audiogram on LinkedIn. 7. I prepare the main LinkedIn and Substack posts for each episode’s launch day. 8. I’m continuing to look for a way to streamline distribution of the posts, audiograms, and episodes.

An AI agent scrapes book marketplaces for recent releases, crawls the web for the corresponding authors’ email addresses, and generates customized marketing pitches based on the authors’ own book descriptions. Just kidding—I’m an author, not an agency. I receive about half a dozen such email pitches every day. I added a spam rule that looks for the text "your book" and sends those messages to spam because my email host obviously isn’t using a smart enough AI-based spam filter. Step-by-step: 1. An AI agent scrapes book marketplaces for recent releases. 2. It crawls the web for the corresponding authors’ email addresses. 3. It generates customized marketing pitches based on the authors’ own book descriptions. 4. I receive about half a dozen of these pitches every day. 5. I use a spam rule that looks for the text "your book" and sends the messages to spam.

Create an immersive 3D website for artists with an AI avatar that welcomes visitors, answers questions about the artist and artwork in real time, and presents the work throughout the virtual gallery. Step-by-step: 1. Build or download a 3D environment using Claude Code or another suitable development tool. 2. Upload the artworks into the 3D environment. 3. Create a digital avatar, optionally using Adobe Mixamo (free), and import it into the scene. 4. Connect the avatar to an AI language model so it can interact naturally with visitors and answer questions about the artist and the artwork. 5. Give the avatar the ability to point to, manipulate, or present artworks during conversations. 6. Write a detailed artist biography and a description of each artwork. Use this content as the AI avatar’s knowledge base so it can provide accurate, engaging responses. 7. Use open-source voice technologies through Pinokio to enable realistic speech synthesis and voice interaction. 8. Arrange the artworks throughout the 3D environment and optionally display videos on the gallery walls. 9. Configure the audio system so multiple videos do not play sound simultaneously. Audio should activate only when a visitor approaches or interacts with a specific artwork or video. 10. Configure collision detection so the avatar cannot walk through walls or other obstacles. For example, stop the avatar whenever it encounters an obstacle higher than approximately 60 cm (24 inches). 11. Optimize the experience for the web and deploy the website using FileZilla and OVH hosting. 12. Pay special attention to iPhone and iPad compatibility. Apple devices are more sensitive to large assets and memory usage, so it may be necessary to create separate optimized versions for iOS and Android, using compressed models, textures, and videos to ensure smooth performance.

I built an interactive AI recommender for Medium publications and packaged it as a Gemini Gem. Medium writers who want their articles to be discovered can submit their pieces to a publication, which is like a digital magazine focused on a specific topic. However, there are hundreds of publications, so it can be difficult to find the right one for a particular article. A key resource is "Medium's Huge List of Publications Accepting Submissions." It contains basic information about each publication, but the list is difficult to navigate because of its size. My solution was to organize that information and use it as the source for an AI recommender. I packaged the system as a Gem because the interface is cleaner, and users do not need to see the sources I used. Step-by-step: 1. I asked Gemini to compile and format basic information for each publication, including its topic, size by number of followers, and a short description. 2. I consolidated that information in a Google Sheet. 3. I used the spreadsheet as a source for a Google Notebook (formerly NotebookLM). 4. I added instructions for the AI, like the following: "You are an expert guiding the user to find the ideal publications for their articles in Medium. Ask the user to write down what their interests, topics, etc., are; whether they are beginner writers; whether they want to start with a small publication (less than 1,000 followers), mid-size (a few thousand), or only the biggest (tens or hundreds of thousands). Ask them for any other personal information and details about their writing, and take that into account." 5. I packaged the system as a Gemini Gem instead of distributing it as a Notebook so users could access it through a cleaner interface without seeing the sources. It can be accessed at the following link: https://gemini.google.com/gem/1HDPzcE6Jls76V4I2tFZhIn-SbeeDe-_-?usp=sharing

I’m designing a publishing system that keeps producing value without requiring constant output. This workflow started with frustration about the usual content model: publish constantly, stay visible, feed the algorithm, and repeat. That model works poorly when my energy varies, my interests shift, and forcing output quickly turns creativity into maintenance. Instead of asking, “How do I post more?” I’m asking: “How can content keep moving without requiring me to keep producing at the same pace?” The system is built around uneven energy. During high-energy periods, I can generate ideas, draft pieces, collect fragments, or prepare several posts at once. During low-energy periods, existing material does not become a failure state. It can sit, mature, be lightly edited, be reused, or simply wait. Ideas can exist in different stages: a note, a half-developed thought, a finished piece, something worth revisiting later, or something that can be repurposed in another format. Older material is not automatically “used up” after publication. A long-form idea can become a short post. A workflow can become a case study. A conversation fragment can become an essay seed. A previous post can return later from a different angle. The goal is not to build a machine that constantly demands feeding. It is to create a content reservoir I can draw from when I have the capacity. This workflow has not been fully implemented yet, but the design principle is useful: > Build around energy reality, not around imaginary consistency. Content should fit into life. Life should not be reorganized to serve the content treadmill. Step-by-step: 1. I design the publishing system around variable energy rather than a constant production schedule. 2. During high-energy periods, I generate ideas, draft pieces, collect fragments, and prepare several posts at once. 3. During low-energy periods, I let existing material sit, mature, receive light edits, be reused, or wait. 4. I allow ideas to remain in different stages, from notes and half-developed thoughts to finished pieces and material worth revisiting later. 5. I repurpose older material across formats, such as turning a long-form idea into a short post, a workflow into a case study, a conversation fragment into an essay seed, or a previous post into a new angle. 6. I draw from the resulting content reservoir when I have the capacity instead of constantly feeding a content treadmill.

A finished video can be wrong in ways you cannot see—not because of the edit, but because of the delivery file itself. That is what gets work sent back, and it is rarely the craft. I built a delivery check for this. I give it a finished file, tell it where the file is going and what kind of piece it is, and it measures the things that cause rejections: sample rate, mono audio, integrated loudness against the destination target, true peak, dynamic range against a band rather than a single number, A/V drift, whether the shots cut together, and whether the file can stream before it has finished downloading. Most of those checks are for sound, because most of what gets sent back is sound. Picture problems are visible on a screen. A file that is 2 dB too quiet or peaks at -0.7 dBFS can look perfect and still come back. For everything it can fix, the checker gives me the exact `ffmpeg` command, with the numbers already calculated for that file. It does not merely describe the fix, and it does not hand me a corrected file. That was the decision that mattered. A fixer is a black box. You never learn that you had a problem, so you make it again the following week. Then, when your editing tool adds an “optimize on export” button, you have nothing. An inspector that explains the problem in one sentence and gives you the command teaches you the standard once and remains useful when the tools change. Three things determined whether I would actually use it, and none of them are checks. “Two severities, never one.” Something either bounces, or it needs your eyes. A tool that only says “bad” gets ignored on the third run, because half of what it flags is a decision you made on purpose. Sample rate, mono, and true peak bounce without argument, and they get a command. Loudness and dynamic range need to be reviewed first. My dynamic-range check says in plain words that the result is often deliberate and should be fixed at the source rather than in the master. “A check that refuses to give a verdict.” On vertical video, the platform interface covers the bottom 26 percent and the top 12 percent. I flag high-contrast elements in those zones but deliberately do not fail them, because the detector cannot tell a caption from a bright patch of sky. The report explains that limitation. A check admitting what it cannot know is what makes the checks that do commit worth trusting. “The thresholds are mine; the code only applies them.” They live in a table: destination crossed with content. Social wants -14 LUFS, a festival master wants -18 with a wider tolerance because festivals provide a band rather than a number, and broadcast wants -23. A scripted short is allowed to be denser than a screencast. That table is the whole product. For example, to catch shots that do not cut together, I measure the luminance range across the piece. The first version used average brightness per frame and kept flagging legitimate night photography. A fade to black has nothing bright in it; a night scene does—a streetlight, a moon, or a face. Changing the discriminant to the brightest pixel in the frame instead of the average eliminated the false positives. That took ten minutes of thinking, and no amount of better code would have found it. Step-by-step: 1. I wrote down what had actually gotten my work sent back over twenty years before writing any code. I captured the scars rather than making a spec sheet; that list became the product. 2. I gave every check a severity: it bounces, or look before you send. Anything I could not confidently put in one bucket became informational, with no verdict at all. 3. I made every check return four things: the measured value, pass or fail, why it matters in one plain sentence, and, where possible, the command that fixes it. 4. I put the thresholds in a profile table instead of hardcoding one standard, because -14 LUFS is right for social and wrong for a festival. 5. I added a parameter for whether the file is my own master or a copy pulled from a platform. On a downloaded copy, half the container checks measure someone else’s transcode rather than my work, so they are skipped and the report explains why. 6. When two fixes would collide, I output only one command. If loudness already needs a gain change, the limiter goes inside that command instead of being offered separately; otherwise, I would run two instructions that fight each other. 7. I tuned the checker against real files until the false positives stopped. Ignoring the top and bottom five percent of frames eliminated the ones caused by a single stray frame. 8. I made the output a report. I read it, decide, and run the command myself. The functions are an afternoon of work, and anyone can copy them. What is not written down is the list of what to check, at what threshold, and why.

I built an episode with the wrong voice. It was not a bad take; it was the voice of a different project entirely—a narrator I had cloned for another series months earlier. Nothing in my files identified which voice belonged to which show, so the assistant picked the one it had seen most recently. I did not catch the mistake until the mix. That is what working with agents on anything long actually costs you: not bad output, but amnesia. Every session starts cold, so settled decisions get reopened, undocumented rules get broken, and the same argument returns every week wearing a different hat. I run several short-form historical and science-fiction series at once, and they all survive on one file each. It is not documentation or a spec. It is what film crews have used for a century: a series bible combined with a daily production report, pointed at an agent instead of a hundred people. I use one Markdown file, read at the start of every session and updated when the session closes rather than when it opens. Four sections do the work: Step-by-step: 1. Closed canon: Each decision includes its reason. Mine says the opening shot is never a contemplative establishing shot. It opens mid-action, with the text hook on screen by the first second, and the beautiful wide shot comes second as the breather. I write the reason next to the decision because the plan for the current episode came back with that wide shot opening the sequence, and I had to reorder it again. The decision alone stops nothing; the reason keeps the rejected version from returning. 2. Rejected list: I record what was already tried and exactly why it was dropped. The wrong voice lives here now as one line: never reuse assets across projects without confirming. This is half the value of the document, and it is the half almost nobody writes. 3. State table: I track each item, its known defects, and the decision already made about it. Mine currently reads: lips at 62.5 to 63.5 seconds, native voice at 64.1 to 65.6, voice moved forward and the original position ducked. A defect written down with its fix is an instruction. A defect nobody records is work you pay for twice. 4. Next three actions: I list concrete next steps, each naming the file it touches. Never “keep going.” Step-by-step: 1. Create `HANDOFF.md` at the root of the project before any real work starts. 2. Write the goal, deadline, and delivery constraints. Anything external that forces your hand goes here instead of staying in your head. 3. Add every consequential decision to the canon, along with its reason and what broke with the alternative. 4. Whenever something is tried and rejected, add a row to the rejected table. It takes fifteen seconds and can save an afternoon. 5. Maintain a state table of the real items, including their defects and agreed fixes. 6. Close every session by updating only three things: the state, the new rejections, and the next three actions. 7. Open every session with: “Read `HANDOFF.md` in full before proposing anything. The canon and rejected list are not up for discussion. Verify the real state against the files, then tell me where we are in two lines.” The discipline that makes this work is updating the file when you close a session, not when you open one. At the end of a session, you still remember why you made the decisions. The next morning, you do not—and neither does the agent. The template is at the bottom. It costs nothing and it is a text file.

Some of the most vivid ideas do not begin as formal briefs. They begin as a joke, metaphor, image, or strange sentence that suddenly has energy. This workflow captures how a small conversational spark can grow into a much larger creative concept. I might say something funny, absurd, visual, or emotionally loaded. AI extends the image, pushes it further, and adds variations, structure, or playful consequences. That makes me more enthusiastic, associative, and specific. Before long, a throwaway remark can become a complete scene, story world, comic setup, installation concept, or concept art direction. The key is not to force the idea into coherence too early. At first, the goal is energy rather than precision. The playful improvisation reveals whether the concept has legs; structure comes in once the idea has shown that it wants to live. This is especially useful for concepts that combine humor, symbolism, emotional charge, and strong imagery. For example, “the elephant in the room” can become a full comic or visual scenario, while “the lion among the cats” can evolve into a richer concept with social dynamics, character logic, and visual storytelling potential. AI acts less like a generator of finished ideas and more like an improvisational creative partner—one that keeps the momentum going long enough for an offhand remark to reveal its full conceptual potential. The result can be a complete creative direction for writing, comics, concept art, sets, or installations. Enthusiasm is treated as a signal: when a joke or image triggers strong excitement, it may indicate that a larger concept is hiding inside it. Step-by-step: 1. I start with a small conversational spark: a joke, metaphor, visual phrase, or strange idea. 2. I ask AI to continue the thread instead of flattening it too early. 3. I react strongly to whatever feels alive, funny, moving, or visually rich. 4. I expand the idea through playful back-and-forth. 5. Characters, settings, tone, visual motifs, and scene logic begin to emerge. 6. I use AI to organize the growing material without losing its spontaneity. 7. I shape the concept into a usable form, such as a comic strip, story premise, installation idea, character setup, concept art brief, scene sequence, or mini-series. 8. If needed, I turn the raw idea into structured outputs such as panel descriptions, mood, dialogue, staging, or visual prompts.

AI can make a child’s drawing look more polished, but it can also erase exactly what made it interesting. A yellow tree, a rabbit larger than a person, a horse with impossible legs, or a tiny floating object may look like mistakes to a model—but they may be the whole point. I use the child’s drawing as art direction: preserve its visual logic, then build outward. The child supplies the invention; AI helps develop the surroundings. Step-by-step: 1. I read the drawing before transforming it by making a neutral description of what is visible: placement, relative sizes, colours, expressions, unusual shapes, and small details. For example: “A large yellow tree stands on the left. Two tiny figures sit near its trunk. A blue shape fills the lower right.” 2. I avoid deciding what an unclear shape represents. “An oval object with three legs” is more faithful than “a rocket” unless the child confirms it. If possible, I ask the child what is happening, since a strange proportion or colour may have a specific story behind it. 3. I separate essentials from flexible details in two short lists. Essentials might include the yellow tree, oversized rabbit, horse’s pose, characters’ arrangement, and red object in the corner. Flexible details might include lighting, textures, materials, environmental detail, and depth. 4. I make clear that the original is the structural source, not just a mood reference. This gives the model room to work while defining the boundaries. 5. I choose a target style, such as a storybook illustration, watercolour, digital painting, comic panel, or 3D scene. 6. I explicitly ask the model to preserve unusual proportions, unexpected colours, expressions, and relationships between characters. I identify details that must remain, even if they appear anatomically impossible or visually awkward. I avoid vague instructions such as “make it better,” because they leave the model to decide what counts as improvement. 7. I use a starting prompt such as: “Use this drawing as the structural blueprint for a storybook illustration. Preserve the composition, relative sizes, poses, expressions and original colour choices. Keep the yellow tree and the rabbit larger than the person. Do not normalize unusual anatomy or remove unexplained objects. Add texture, lighting and environmental depth around the existing scene.” 8. I treat comparison as part of the workflow because specific instructions do not guarantee a faithful result. I expand the world around the invention: a blank background can become a forest, a blue patch can become a pond if that interpretation fits, and two skiing figures can gain a mountain landscape. 9. I keep the original spatial relationships: who stands beside whom, what dominates the scene, which way characters face, and where empty space matters. I give colour the same care, so a yellow tree does not quietly become green because the model expects green trees. 10. I place the source and result side by side and check whether a character disappeared, the rabbit shrank, the palette changed, or the model invented a focal point, “fixed” an unusual shape, or altered the story. I also watch for generic cuteness—big eyes, pastel colours, and perfect symmetry—which can make very different drawings converge into the same image. I ask whether the result still feels like an expansion of this exact drawing. 11. If most of the result works, I request a targeted edit, such as: “Keep this version, but restore the original hair shape.” “Make the rabbit larger again.” “Return the tree to yellow.” 12. I check the whole image after each local edit because changes can affect other areas. I keep useful versions instead of repeatedly starting over. 13. I treat handwritten text separately. I do not guess unclear wording, correct spelling, or invent labels. If the tool cannot reproduce the text faithfully, I retain the original lettering through a separate editing step. 14. I save the original photo or scan alongside the result, instructions, and useful intermediate versions. I also keep a brief note about protected details to make future transformations easier. 15. Once I have a faithful version, I explore alternatives such as a space setting, surreal painting, or cinematic scene, keeping them as branches from the original. Across several drawings, I preserve recurring colours, shapes, and characters without forcing every image into one rigid style. The child has already decided who exists, what matters, how large things are, and what belongs together. Those decisions are creative direction. A drawing does not need to become less itself to become more finished. The impossible colour may be the atmosphere, and the awkward shape may be the character. The question I return to is: “How can I help this drawing become more fully what it already is?”

I have been testing Perplexity Computer, and it really makes you rethink a lot of workflows. It has been particularly useful for surfacing interesting and viral social content across X and Reddit, with internet search abilities that seem much more capable for quick canvassing of different platforms. I have also used it for clipping and captioning video content for social, with Computer able to find, transcribe, give recommendations on the most viral quotes/sections, and caption in just minutes — a wild process that would normally take me (with little video experience) much longer and have to leverage a ton of different apps to make happen. Step-by-step: 1. I used Perplexity Computer to canvass X and Reddit for interesting social content with signs of viral momentum. 2. I narrowed the results to the posts and videos worth developing further. 3. I had Computer find and transcribe the source video content. 4. I asked it to recommend the strongest quotes and sections for short-form clips. 5. I used the same workflow to clip and caption the selected sections in minutes.

Sometimes I remember something perfectly badly: not its title, creator, or where I found it, but a sound, a color, a vague cover, a sentence, or a period in my life. I know it exists because I loved it, but I cannot name it. I use AI and my digital traces to recover songs, books, videos, articles, and quotes. Memory is not a catalog; it stores traces. AI can turn those traces into searchable hypotheses. Step-by-step: 1. I dump every surviving clue without waiting for a proper search query. The clues can be as rough as “The title sounded like nu nau tau,” “It was ambient or humming,” “The cover was maybe a green desert?” or “I knew it around 2019.” Another example is: “A book about makers and Disney. White 3D-printed figures, tiny people, and bears on a blue cover.” This is raw memory evidence. 2. I separate certainty from guessing by labeling each clue as certain, fairly sure, possible, or probably distorted. I keep uncertain clues, but do not treat them as facts. A wrong attribution or outdated cover does not invalidate everything else. 3. I reconstruct the original encounter. I ask where I was and whether I Shazamed it, saved it, sent it to someone, screenshotted it, or bought it at a book fair. In one case, I remembered hearing a song in someone’s car and Shazaming it because I could not parse the pronunciation. Remembering that capture action pointed to a retrieval source. 4. I search my own collections first: playlists, liked songs, Shazam history, saved videos, old posts, messages, bookmarks, notes, photos, receipts, and reading lists. The object may already be there under metadata I no longer remember. I start with the smallest reliable fragment. 5. I search for “nu” inside my playlists after remembering “nu nau tau.” That recovered Man O To — Nu. The artist and title had blended into one phrase, and the song was sitting in several playlists, including my Shazam collection. A clue does not need to be complete; it only needs to be distinctive enough inside the right collection. 6. I allow memory to scramble metadata. An artist and title may merge, album art may become song art, and a quotation may survive with the wrong poet attached. I split remembered phrases, swap artist and title, try different word boundaries, consider older releases, and search phonetically using similar syllables, vowel sounds, homophones, alternate spellings, or other languages. I also ask what the cover looked like when I knew it, because artwork changes. 7. I use context and cross-reference traces. A year, trip, relationship, or platform can narrow the search more than a half-correct title. Spotify might preserve the song, Shazam the discovery moment, and an old message the recommendation. Old posts are accidental archives, and dead links may still leave names, dates, or descriptions. If memory fails completely, I inspect behavior from the relevant period, such as repeated listening, watch history, purchases, or library loans. 8. I let AI propose candidates and compare them against several independent clues, including sound, subject, period, cover, and personal context. One matching detail is not confirmation. I show titles, covers, creator names, and short descriptions because recognition may succeed where recall fails. Rejections also help: “No, but the cover was more minimal,” “The title was shorter,” or “It was fiction, not nonfiction.” Each correction sharpens the search. 9. I pay attention to the strangest clue. The blue cover with white figures, bears, and a makers-and-Disney theme led to *Makers* by Cory Doctorow. 10. Once I confirm the object, I save the title, creator, link, why it mattered, and how I recovered it. For example: - Clue: “nu nau tau” - Encounter: heard in someone’s car and Shazamed - Search: Spotify/Shazam collection → “nu” - Result: Man O To — Nu - Distortion: artist and title blended together This becomes a retrieval playbook: which clues survive, where traces live, and how my memory distorts them. The overall workflow is: collect fragments → mark uncertainty → reconstruct the encounter → search personal traces → try phonetic, visual, and contextual clues → compare candidates → recognize and confirm → save the result and retrieval path. I do not need to remember the database fields. I need enough fragments to rebuild the trail. Sometimes the best clue is what I did when I first encountered something. Sometimes it has been sitting in five of my own playlists while I spend years wondering what it was called. 😑😭🎧

I built a daily literature quiz game from a spreadsheet containing thousands of classic literature quotes, which I previously posted on Instagram each day. I uploaded the document to Claude Code, which organized and tagged the quotes, created multiple-choice questions with increasing difficulty, and wrote short summaries of each book along with a fun fact supported by academic sources. I also vibe-coded the game’s UI/UX in a day or two, and I think it looks pretty beautiful. You can play it at play.writt.org. Step-by-step: 1. I collected thousands of classic literature quotes in a spreadsheet and posted them on Instagram each day. 2. I uploaded the document to Claude Code. 3. Claude Code organized and tagged the quotes. 4. Claude Code created multiple-choice questions with increasing difficulty. 5. Claude Code wrote short summaries of each book and a fun fact with academic sources. 6. I vibe-coded the game’s UI/UX in a day or two. 7. I published the game at play.writt.org.

I'm always looking for ways to add cool motion design to our videos. Recently, I've been playing with Expressions, snippets of JavaScript that automate animations and link properties in After Effects. Previously, I had to dig through forums and Reddit to find the right snippet, but now I describe the effect to Claude, and it gives me options, explaining each line of code. Step-by-step: 1. I described the animation effect I wanted to create in After Effects. 2. I asked Claude for several JavaScript Expression options instead of searching forums and Reddit. 3. I had it explain every line so I understood what the expression controlled. 4. I pasted the best option into After Effects and tested it against the real composition. 5. I brought the result back to Claude for adjustments until the motion behaved correctly.

I built a band scraper to identify bands on Bandcamp, interact with them, and offer mixing and mastering services. A daily cron job runs an Apify Bandcamp scraper, stores the data, and supports a website hosted on Lightsail. Step-by-step: 1. I configured an Apify Bandcamp scraper to collect band data. 2. I scheduled the scraper to run daily with a cron job. 3. I stored the collected data. 4. I used the data to interact with bands and offer mixing and mastering services through a website hosted on Lightsail.