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

I use Claude Cowork and Meta MCP to map my existing ad creative data and find winning combinations. Once the data is mapped, I can usually identify one concept that wins more often than the others, has absorbed more spend, and still maintains an efficient CPA. That is the winning concept, and it is where I should focus 60% to 80% of my production time. Step-by-step: 1. I connect Claude Cowork to Meta MCP and Google Drive. 2. I place the brief for every ad I published in the past 365 days into one Google Drive folder. Each brief includes the script, format, offer, and persona it was written for. 3. I prompt Claude to work through the Drive folder and build a spreadsheet tagging every ad by persona, angle, offer, and format. 4. I prompt Claude to pull each ad’s spend and CPA through Meta MCP and add those metrics to the spreadsheet. 5. I ask Claude to turn the spreadsheet into a flowchart in which persona branches into angle, angle branches into offer, and offer branches into format. Each branch includes its spend and CPA. After the data is mapped, I use the flowchart to identify the winning concept and prioritize it in production.

I was tired of opening Spotlight every time I wanted to switch apps. The search results would move around, I would occasionally open the wrong app, and those few wasted seconds kept adding up throughout the day. Instead of memorizing a collection of unrelated hotkeys, I used ChatGPT Work to design and build a personalized shortcut system in Apple Shortcuts. The shortcuts can open individual apps, jump directly into specific Safari or Chrome profiles, or launch an entire work mode with one keystroke. For example, a recording shortcut could open your microphone, camera, recording software, and notes. An analytics shortcut could open all the dashboards you check each week. Step-by-step: 1. I opened the ChatGPT desktop app, started a new chat, and switched to Work mode. 2. I asked ChatGPT to plan shortcuts around my real workflow: Based on what you know about me and my workflow, suggest 10 time-saving hotkeys we can set up in Apple Shortcuts. I’m interested in opening specific apps and profiles based on what I need them for or what mode of work I’m going into. 3. I told it which apps, browser profiles, URLs, and work modes I use most. 4. I narrowed the list before making any changes by keeping the highest-frequency shortcuts and avoiding macOS or app conflicts. 5. In ChatGPT, I went to Settings → Computer Use and turned on Any App. 6. I gave ChatGPT the approved list and clearly limited its scope: Set these up in Apple Shortcuts. Do not change anything outside this list. Test each shortcut. 7. I opened All Shortcuts in Apple Shortcuts and ran each one manually. I used Quick Actions to add or change its keyboard shortcut. I like Control + Option because it is less likely to conflict with existing Mac commands. 8. I tested every shortcut while working in another app, checking that it opened the correct app, account, browser profile, or collection of tools before building more. 9. Once everything worked, I asked ChatGPT to create my reference: Write me a one-page cheat sheet of all the shortcuts you set up, where they live, and what’s left to do. The result is a personal shortcut system built around how I actually work, plus a one-page cheat sheet so I don’t have to memorize everything immediately. For the complete walkthrough, exact prompts, screenshots, and setup instructions, follow my full Rundown University guide: Use ChatGPT to Build a Custom Mac Shortcut System. Tools used: ChatGPT Work, Apple Shortcuts Industry: Cross-industry Tags: #chatgptwork #appleshortcuts #macautomation #productivity #workflowautomation

I produce cinematic AI video. What ruins a sequence is almost never image quality; it is drift. The face, jacket, and light change between shots, so what should read as one scene becomes a gallery of near misses. Most people fight this by regenerating until something matches. I built the opposite: a set of chained Claude skills that locks a character once and never lets the model improvise again. The lesson that started it cost me 72 credits in one unusable shot. I fed a finished POV frame as an image reference to “set the world” for a motorcycle sequence. The model treated it as a strong identity reference, cloned the entire cockpit from that frame, and ignored the bike I was describing in the prompt. Image references are read as identity, not atmosphere. That misunderstanding is why most people’s characters mutate. Step-by-step: 1. I lock the character before generating anything. I fill nine layers in order: identity and facial structure, skin realism, wardrobe and materials, emotional energy, environment, lighting scheme, camera language, vertical 9:16 framing, and a fixed block of negative instructions. A generic prompt returns a generic face. This is direction, not a portrait. 2. I shoot a character sheet: a neutral, multi-view image of the locked character on white. That sheet—not a pretty hero frame—is what I reuse as a reference from then on. 3. I expand coverage instead of reinventing the scene. One locked scene becomes a full shot list with hero angles, macro inserts, and establishing shots. The subject, wardrobe, weather, and lighting never change between prompts. Only the camera, focal length, framing, and distance change. Every prompt restates the entire world from scratch because the generator has no memory between images. Consistency comes from redundancy, not from the model remembering. 4. I time the story before animating. I create a 3x3 board with nine beats over fifteen seconds, with each panel showing its timecode, shot title, and action. The rule is strict: the character, wardrobe, world, and light stay identical across all nine panels; only the story advances. The emotional scale rises toward panel nine. 5. I generate with reference discipline. I pass the object or vehicle in a clean exterior shot as the only image reference, then describe the world, framing, and interior in text, repeating that description word for word across shots. I chain consecutive shots by feeding the last frame of one as the start image of the next. The joins are invisible. 6. I review the board against the renders, keep the shots that hold, and regenerate only the ones that drift. The result is that I stopped paying the regeneration tax. Shots are budgeted, not gambled, and a fifteen-second sequence holds together because it was blocked like a real scene—with coverage and continuity—before a single frame existed. The nine-layer character build and the coverage framework are adapted from two AI video courses plus twenty years of production. I learned the reference discipline in step five the expensive way.

I work with long talking-head videos for my online course and Instagram. Turning them into vertical shorts used to take hours per video: finding the best moments, cropping to 9:16, adding captions, or paying for clipping subscriptions. I built a video-clipping agent as a Claude skill that runs entirely on free, open-source tools. Step-by-step: 1. I drop a long video—either talking-head footage or an already-produced 16:9 video—into a folder and invoke my "clipper" skill in Claude. 2. Claude transcribes the video locally with faster-whisper using word-level timestamps, so no API key is needed. ElevenLabs Scribe is an optional upgrade for tricky audio. Before transcription, the workflow cleans the audio with declipping and normalization because clipped microphone peaks can make Whisper skip words or hallucinate. 3. The skill scores every candidate moment against a rubric: hook strength (30 points), whether it can stand alone (25), emotional charge (20), rhythm (15), and ending (10). Only segments scoring 70 or higher survive, so I do not publish a weak clip simply because it exists. 4. Claude cuts the selected moments with word-level precision and reframes them to 9:16 in one of two modes: face-tracking crop for raw footage, or "pad" mode, which centers the full 16:9 video over a blurred background. The latter lets me repurpose already-edited videos without chopping off centered graphics or captions. 5. ffmpeg masters everything to a fixed specification: 1080x1920, 24fps, H.264 CRF18, and audio normalized to -14 LUFS. The files are ready for Instagram, TikTok, and Shorts. 6. I review the scored shortlist and publish the winners. What used to take hours—or require a monthly subscription—now takes minutes and costs zero. The scoring rubric also makes the agent explain why each clip deserves to exist instead of simply cutting wherever the waveform looks loud.

I’ve found it useful to use Claude while reading nonfiction books, such as *Factfulness* by Rosling. I ask Claude for a synopsis of the book and save the result as a PDF on my computer for future reference. I also ask Claude to quiz me about the book, either with multiple-choice questions or in short-answer format, to test whether I’ve fully understood what I’ve read. In an ongoing conversation, Claude can also relate the current book to other books I’ve recently read and provide additional synopses. Step-by-step: 1. I tell Claude which nonfiction book I’m reading, such as *Factfulness* by Rosling. 2. I ask Claude to create a synopsis of the book. 3. I save the synopsis as a PDF on my computer for future reference. 4. I ask Claude to quiz me using either multiple-choice or short-answer questions. 5. I continue the conversation so Claude can relate the book to other books I’ve recently read and provide further synopses.

A friend who had just started a pet-sitting and dog-walking business asked me to build a booking app. I used Google AI Studio to design the initial prototype. The process was straightforward, and I had a basic working system running within two hours. AI Studio created a Firebase database to store the details and was also effective at designing frontend changes. It published the app for me, and the resulting UI was intuitive. After demonstrating the app, I identified many additional features that needed to be added. This went beyond AI Studio’s capabilities, so I exported the code from AI Studio and started using Claude. I asked Claude to analyze the code and suggest the required changes. Claude identified critical security flaws in the database. I fixed them manually at first, but then realized that Claude could access the Firebase database and fix issues automatically. I continued prompting Claude with additional feature requests, and it built them. There were errors along the way, so I needed to be familiar with Google Chrome’s developer tools to copy the errors and ask Claude how to fix them. I used MailJS for email templates and Resend for email transport. I stored the app in GitHub and allowed Claude to access the repository so it could commit changes automatically. I ran the app locally with npm during development and then hosted it on Vercel. Eventually, I purchased an inexpensive domain name, and the app is currently hosted at Names. One major problem was that when Google AI Studio created the Firebase database, the permissions were locked, preventing me from making administrative changes. I solved this by recreating the database and asking Claude to write the SQL query to set it up. The permissions were still tricky, and I had to continue asking Claude to correct them. Google’s service permissions can be difficult to understand, and finding the correct settings was not always easy. Firebase was also complex to navigate, and getting the permissions configured correctly took time. Once I allowed Claude to connect to the app and its background services through the Google plugin, development became much faster. However, you need to trust the tool carefully and always work on a copy of the live app. Overall, I think app development with Google AI Studio and Claude is impressive. You can create professional apps quickly. I come from an IT support background, though, and I think people who are new to IT may find it difficult to troubleshoot errors without a basic understanding of networking and systems administration. I also built a litter-tracking app using ChatGPT, and it was equally effective. I eventually started using Codex and Claude Code, but I think standard Claude and ChatGPT are more intuitive for nontechnical users. Step-by-step: 1. I used Google AI Studio to create an initial booking-app prototype for a pet-sitting and dog-walking business. 2. I used the Firebase database created by AI Studio to store the app’s details and used AI Studio to design frontend changes. 3. I published the initial app with AI Studio and demonstrated it to identify additional features. 4. I exported the code from AI Studio and asked Claude to analyze it and suggest changes. 5. I addressed the critical database security flaws identified by Claude, first manually and later by allowing Claude to access the Firebase database. 6. I prompted Claude to build additional features and used Google Chrome’s developer tools to copy errors and ask Claude for fixes. 7. I recreated the Firebase database when AI Studio’s locked permissions prevented administrative changes, then asked Claude to write the SQL query to set it up. 8. I used MailJS for email templates and Resend for email transport. 9. I stored the app in GitHub and allowed Claude to commit changes automatically. 10. I ran the app locally with npm during development, hosted it on Vercel, and later purchased an inexpensive domain name that is currently hosted at Names. 11. I connected Claude to the app and background services through the Google plugin, while continuing to work on a copy of the live app.

I own a rental property where a water leak has occurred roughly every year or two. The leak typically runs for weeks before the water utility detects usage above its threshold. Because billing cycles last three months, the utility may notify me weeks or months after the problem begins. By then, the leak can have produced a bill more than $1,000 higher than the usual $100–$300 amount. The utility offers a one-time, per-account waiver for accidental leak overages. After using that waiver the first time, later incidents are entirely out of pocket. The utility also cannot notify me sooner than when usage exceeds 25,000 gallons during a billing cycle, which moves the account into a quadruple-rate tier for the rest of that cycle. I repeatedly asked whether they could provide an immediate alert when a user-set or company-set daily usage threshold was exceeded, but they said they had no system or solution for it. I tried checking my usage manually every day, but after weeks or months of normal readings, it was easy to become complacent or forget. After receiving another $1,300-plus bill, I asked ChatGPT whether I could automate the process of logging into my utility account, checking usage daily, and emailing me about the prior day’s usage or an overage. ChatGPT suggested several options, including paid AI-agent tools and a free script running on my own hardware. I wanted a completely free, cloud-based solution that would not require my computer to stay on, so I compared the paid options, including Google Spark, with a GitHub-based system. GitHub apparently includes 2,000 minutes of script runtime per month, while my system was estimated to use about 100 minutes. I spent part of a day asking ChatGPT questions, copy-pasting code into GitHub, and refining it. I now have a cloud-based system that logs into my water utility account, checks daily usage, emails me when my daily or seven-day-average thresholds are exceeded, and adds each day’s usage to an Excel spreadsheet for ongoing history. I have verified that it works, and it is set up to keep running and sending alerts without ongoing cost. I had never coded before. The system uses Python, GitHub Actions/YAML, Playwright, pandas, openpyxl, Excel, and Gmail for email alerts. Excel and Gmail were the only tools in that list I had used previously. If I want to change an alert threshold or another setting, I can log into GitHub and ask ChatGPT for the relevant code adjustment. I also added a second rental property in the same city that uses the same water utility. Replicating the process for that property required only a small amount of additional code and took almost no time. I now have a perpetually self-updating, cloud-based water-usage database with daily email alerts for both rental properties, at zero ongoing cost.

Every RSVP tool I found wanted a monthly subscription to collect a few hundred yes-or-no answers, and none would return my data in a format I could use. So I built my own with Claude Code. The RSVP system is small: a form deployed on Vercel and embedded into our wedding website. We also emailed the direct link because plenty of guests might never visit the site. The form asks for more than a yes-or-no response. It collects meal choices, dietary restrictions, and plus-ones. Every submission adds a row to a Google Sheet through the Sheets API. That sheet ended up mattering more than the app. Months later, when it was time to create the seating chart, every guest was already represented in clean, structured rows that I could give to a completely different tool. For seating, I opened the same sheet in Claude and wrote out the rules in plain English: who had to sit together, who could not sit anywhere near each other, which relatives needed a quiet corner, and which friends could anchor a table of people who did not know anyone else. Claude produced a first draft that respected those constraints, along with an interactive board where I could drag people between tables. Step-by-step: 1. Tell Claude Code which fields you want on the RSVP form and have it build the front end and back end. Have Claude deploy it to Vercel. 2. Set up a Google Cloud service account, enable the Google Sheets API, and share the sheet with the service account’s email address. Configure each submission to append a row. 3. Embed the form on your wedding website and email the direct link separately. Some people will never open the website. 4. Ask for everything you will eventually need, not just attendance. Your caterer and venue will want meal counts and dietary restrictions, and going back to collect that information later is miserable. 5. When it is time to seat people, point Claude at the same sheet and write your rules in plain language: who must sit together, who cannot sit together, who needs a quiet table, and who can anchor a table of strangers. 6. Have Claude generate a first draft based on those rules, then move people yourself. This works anywhere you have a public form collecting data and a private tool that needs to reason about it. Put a spreadsheet between them instead of building one app that tries to do both. The form stays simple, and whatever you build six months later can read from the same place.

I spent twenty years producing documentary and nonfiction films, all of it the expensive way: crews, schedules, financing, and commissioners saying no. I'm proud of much of that work, and I still think about the films that never got made because the money wasn't there. Generative video pulled me in, but not for the reason people assume. It wasn't the speed or the cost. It was the fact that I could finally finish something without asking anyone for permission. No green light from a major platform. Nobody deciding that a story was too small to deserve a crew. A year later, I could produce this way. It turned out to be a different job rather than the same job with new tools. Then I ran into a problem I hadn't considered: how do you show the work? A finished shot doesn't prove much anymore. A client can look at a beautiful frame and have no way to tell whether it took three weeks or three minutes. If I'm honest, neither would I in their position. The thing every portfolio is built to display had stopped being evidence. I'm not a developer. I produce films. The site is bilingual, has seven sections, includes a case study for each film, plays video on hover, and has a comparison slider that works with a thumb as well as a mouse. I built all of it. I'd wanted this exact site for about fifteen years and had never managed to explain it properly to anyone I paid to make it. This time, I stopped explaining and built it myself. The middle of the page has a slider that you drag between the storyboard panel and the final shot. A basic before-and-after would prove nothing; you can fake that by generating twice. The storyboard is the proof because the framing, eyeline, and decision about what stays outside the frame all existed on paper before any model was asked to generate anything. You drag the handle and watch the intention survive. The rest of the site came from the same place. Video only plays on hover and is silent until you click for sound. Most video portfolios are unreadable because fifteen things start moving at once. The sections are organized by register rather than by client: epic, brand, animation, and lifestyle. A wall of logos answers who has hired you, which nobody is actually wondering. What they want to know is whether you can change tone. Nothing is cropped to fit the grid. A 5:33 film sits in 16:9 next to a 2:42 film in scope, and the layout is lopsided because of it. I nearly made them uniform because it looked tidier, then realized I was about to reformat my own films so a webpage would look neat. Anyone who cuts for a living spots that immediately. Concepts are labeled as concepts. Experiments have their own section instead of being scattered among the client work and hoping nobody asks which is which. Step-by-step: 1. I started from what my client couldn't verify: the craft behind a shot. 2. I found the artifact that proves it. It's usually the ugly thing nobody publishes: the storyboard, the reference sheet, or the version before the good version. 3. I put that artifact next to the finished piece inside one interaction, so nobody has to search for the proof. 4. I made playback deliberate. Video plays on hover, and sound requires a click. 5. I sorted the work by the question being asked rather than by the credentials I wanted to lead with. 6. I didn't reformat the work to fit the layout. I let the grid be uneven. 7. I labeled everything honestly: client, concept, or experiment. One word each can pay for the credibility of the whole page. 8. I wrote a brief for each section as a document first. Arguing with a paragraph is free; arguing with a built page is not. 9. I built the site with an AI coding tool. This was the least interesting step, even though it's the one everyone writes about. If your work can be mistaken for a lucky prompt, stop trying to prove it with the finished piece. The site is at www.termopilas.tv if you want to drag the handle yourself.

I used ChatGPT Voice Mode to help me program my mom’s garage door keypad—and the most important step happened before I touched a single button. I photographed the labels on both the garage door opener and the wireless keypad. ChatGPT spotted the real problem: the previous homeowner had replaced the opener but kept the old, incompatible keypad. That explained why we couldn’t get them to pair. Once ChatGPT identified the exact models, it helped me find a replacement keypad that was compatible with the newer opener. I also had it find and load the instruction manuals for both devices, since pairing required a specific sequence of button presses across them. Before we started, I had ChatGPT explain the complete pairing process so I knew what to expect and where timing would matter. Then I set my phone on top of the ladder so both hands were free to work with the keypad and opener. I gave ChatGPT one important instruction: “Walk me through one step at a time. After each step, stop and wait until I tell you what happened.” ChatGPT gave me one instruction, paused, and waited while I reported what the lights were doing. Then it adjusted and gave me the next step. That let me follow the crucial sequence of button presses—and the timing between them—exactly. The real lesson: AI troubleshooting gets much better when you provide the exact model numbers and manuals, let it preview the process, and have it guide you through the work one confirmed step at a time. Step-by-step: 1. I photographed every model number on the garage door opener and wireless keypad. 2. I used ChatGPT to identify the models and determine that the previous homeowner had left an old, incompatible keypad paired with the newer opener. 3. I used ChatGPT to find a compatible replacement keypad instead of guessing based on appearance or brand alone. 4. I had ChatGPT find and load the instruction manuals for the new keypad and garage door opener. 5. I asked ChatGPT to preview the complete pairing sequence, including where timing would matter. 6. I placed my phone on top of the ladder so both hands were free to work with the keypad and opener. 7. I switched to Voice Mode and told ChatGPT to give me one step at a time, pausing after each step until I reported what happened. 8. I reported what the lights were doing after each instruction so ChatGPT could adjust and give me the next step.

My girlfriend has a professional camera and lens for photographing birds. Because the camera captures an enormous number of images per second, sorting through them and keeping only the good ones after a day at the wetlands took a very long time. She showed me the two tools she was using to tag, crop, view, and zoom into photos, inspect focal points, and view the color histogram. I decided to vibe-code a C# tool using Cursor, Grok, and Claude Opus. The tool reads the EXIF and MakerNotes metadata in each picture and lets her scroll through all the photos in fullscreen with the mouse. It displays the histogram in the top-right corner and useful information—aperture, shutter speed, focal length in millimeters, and ISO—in the top-left, with color coding from red to green. It also shows the Nikon focus zone. Clicking the left mouse button zooms to 75%, allowing us to pan, while clicking the right mouse button zooms to 100%. Once we decide visually on the best crop and judge the photo’s potential, pressing a keyboard key instantly crops the image at the current view, saves a copy, tags the photo, and adds her copyright in the bottom-right corner. This makes the process much faster because she can view, tag, crop, and add copyright at the same time. It took about two hours of working with her to iterate on the tool and find the right balance of features and ease of use. Step-by-step: 1. I observed the two tools she was using to tag, crop, view, and inspect bird photographs. 2. I used Cursor, Grok, and Claude Opus to vibe-code a C# application for her workflow. 3. I made the tool read each photo’s EXIF and MakerNotes metadata. 4. I added fullscreen mouse scrolling, a histogram in the top-right, and camera information in the top-left, including aperture, shutter speed, focal length, and ISO. 5. I added red-to-green color coding and a display of the Nikon focus zone. 6. I set up left-click zoom to 75% with panning and right-click zoom to 100%. 7. I added a keyboard shortcut that crops the image at the current view, saves a copy, tags the photo, and adds her copyright in the bottom-right corner. 8. I iterated on the tool with her for about two hours until the features and ease of use were balanced for her needs.

It starts when someone clicks “Find My Best AI Opportunity” on my website. Instead of going straight to a booking page, they enter a short AI chat. The assistant asks about their work, business, main pain point, AI experience, urgency, name, and email. The workflow runs in n8n. Once the chat has enough information, it creates an AI Readiness Summary, saves the lead in Notion, sends me an internal brief, and emails the visitor their summary with a link to book a 30-minute call through Cal.com. The result is a better-qualified call: the visitor gets useful value first, and I have the context I need before we meet. Step-by-step: 1. A visitor clicks “Find My Best AI Opportunity” on my website. 2. The visitor completes a short AI chat about their work, business, main pain point, AI experience, urgency, name, and email. 3. n8n uses the collected information to create an AI Readiness Summary. 4. The workflow saves the lead in Notion and sends me an internal brief. 5. The visitor receives their summary by email, along with a link to book a 30-minute call through Cal.com. 6. I review the context before the call, making it better qualified.

Before I ship anything built with AI—whether I use Lovable, Cursor, Replit, or Bolt—I run a security and readiness audit. I ask my AI assistant to clone the free, open-source repo at github.com/edgewiselab/ship-kit and scan my project. It identifies my stack from the code on its own, with no configuration required. The audit checks for 113 known launch mistakes, including open databases, leaked secrets, emails going to spam, missing error tracking, and more. It skips anything that doesn't apply to my app. It generates a plain-English report: green means everything is fine, red means I need to fix something, and amber means I need to confirm it myself. I hand the red items back to my AI assistant to fix, then rerun the scan until the report is clean. The tool is free, MIT licensed, and runs entirely on my own machine. Step-by-step: 1. I ask my AI assistant to clone `github.com/edgewiselab/ship-kit` and scan my project. 2. I let it identify my stack from the code without adding any configuration. 3. I review its checks for 113 known launch mistakes, including open databases, leaked secrets, emails going to spam, and missing error tracking. 4. I review the plain-English report and focus on the red items while confirming the amber items myself. 5. I give the red items back to my AI assistant to fix. 6. I rerun the scan until the report is clean.

I used to create a skeptical VC investor persona through prompting whenever I ran ideas and actual business plans through AI. Recently, after working on a business plan for weeks, I used Claude Cowork with Opus 5/High to evaluate the same concept. Instead of prompting for critique and redesign each time, I built a Skill upfront. The concept is the same, but the Skill makes the execution much more effective. It reviews ideas or detailed business plans, researches first, and critiques only after that. It also analyzes and suggests wedges and new moats and, when instructed, generates detailed business plans. It works well as a one-shot analysis, but it is most effective when I push back and challenge it further. I’m sharing the Claude Skill for free under the MIT license: https://github.com/zszendro/vc-teardown Step-by-step: 1. I used to prompt AI to role-play a skeptical VC investor when reviewing ideas and business plans. 2. After working on a business plan for several weeks, I ran the same concept through Claude Cowork with Opus 5/High. 3. Instead of prompting separately for critique and redesign, I built a Skill upfront. 4. I designed the Skill to research first and critique only afterward. 5. I used it to review ideas or detailed business plans, analyze and suggest wedges and new moats, and generate detailed business plans when instructed. 6. I continued the analysis by pushing back and challenging the Skill beyond its initial one-shot response. 7. I shared the Claude Skill for free under the MIT license at https://github.com/zszendro/vc-teardown

I run nine GitHub repos as one programme of work. Every project keeps its backlog as plain markdown inside its own repo, one Claude Code or ChatGPT Codex session works each project in parallel, and a single board in VS Code shows all of them moving at once. There is no project tool, no API and no sync job in the middle: the markdown file is the shared state that both I and the agents read and write. Step-by-step: 1. Put the backlog in the repo, as markdown. Every project gets `docstech/users/<me>/todo.md` and `done.md`. A story is a `###` heading. Structured fields ride in an empty markdown link at the end of it: `### Add rate limiting [](?status=doing&epic=api&time_estimated=180)`. GitHub renders an empty link as nothing, so the file still reads as prose in a pull request while carrying real metadata. 2. Write the story before the session starts. Each one has goal, background, scope, out of scope, the files it should touch, a checkbox task list, and acceptance criteria. That story is the prompt, and most of my thinking happens there rather than in chat. It decides whether the session comes back with anything shippable. 3. Open the parent folder in one window, and turn the files into a board. I open the parent folder holding all the projects and open any `todo.md` with NoteThink in Folder mode, which merges every markdown file under it into one view. Group the lanes by project and it is the programme view, one lane per repo. Group them by status and it is the delivery view, one Kanban across the whole portfolio. Each card carries a pill naming the project it came from, and clicking it opens that file at that story. 4. Start one Claude Code session per project. Every session opens with the same instruction: read `todo.md` top to bottom and take the top story. The sessions never talk to each other, because the file on disk is the only shared state. A session that dies costs nothing. 5. Let the board report progress instead of reading the sessions. Agents edit the markdown as they work: tick a task, flip `status=todo` to `status=doing`, move a finished story to `done.md`. The board watches the files, so cards animate into their new column as each change lands, and I can see which sessions are advancing without reading any of them. 6. Steer by dragging. Dragging a card between lanes writes the attribute back into the source markdown, so dropping one in "doing" makes the file say `status=doing` and the next agent turn reads it. Ticking a checkbox does the same. The board is the steering wheel and the file is the wire. 7. Close every story the same way. One slash command runs lint plus the full test suite, checks the story's tasks are ticked, and drafts the commit message; another ships to staging then production. The finished story moves to the end of `done.md`. Over time `done.md` becomes the programme record: what shipped, when, and what it cost. Try the board without installing anything. Here is a live example board, four projects merged into one view, and it is exactly what the screenshot shows: https://www.notegit.com/en/app/notegit.com/notegit/example_repo/blob/ai-board/board.md Results, honestly. Nine repos, about 260 open stories and about 1,400 completed ones, all in markdown inside the repos rather than a tracker. The backlog goes back to March 2024; the parallel sessions on top of it are the last four months. I run eight to twelve sessions at the same time, and the whole thing fits inside one Claude Max 20x subscription over a month of full-time work. Not all of it is code. The same parallel-session habit drives a nuclear reactor design study (https://github.com/cleverlight/mistergy) and several video and design projects. The board part fits best where the work already lives as files in a repo. Limits, honestly. The ceiling is my review capacity, not compute. Eight to twelve is where I sit; past that I stop reading output properly and start rubber-stamping, which is worse than running fewer. It only works when stories are genuinely independent, because two sessions in one file is a merge conflict you wrote yourself. Agents occasionally finish work and forget to move the story, so `done.md` needs a sanity check. And it assumes you will write the story properly first, which is real work that AI does not do for you. The screenshot is the public example board rather than my own, because my real one carries client project names. Disclosure: I build NoteThink, the free, open-source VS Code extension in step 3, and NoteGit, which hosts the example board. NoteThink is on the VS Code Marketplace, Apache-2.0, and genuinely early (v0.3.38, preview quality, a handful of installs). The workflow is tool-agnostic and the markdown is just markdown: any viewer will show it, and you can run the whole thing with no extension. NoteThink is what makes the cross-project board and the drag-writes-back-to-file part work.

I never ask AI to “build the app.” I move the work through a fixed assembly line, and the most valuable stations are the ones whose only job is to attack what came out of the previous station. I’m a solo developer, and this is how I build and ship software for paying clients without a team to catch my mistakes. I choose the next chunk of work—a “phase”—and run one command. Each phase gets its own fresh context window, which matters more than any single agent because a long-running session gradually forgets its own rules. Step-by-step: 1. I discuss the phase with an agent that interrogates me until every gray area is decided. The decisions go into a file instead of staying in chat, where they can get lost. 2. A planner writes an executable plan covering the tasks, files to be changed, a threat model, and the acceptance checks that will prove the work succeeded. 3. A different agent, working from a fresh context, checks the plan by working backward from the goal and trying to prove that the plan will not achieve it. This agent can block the phase, and regularly does. 4. I execute the plan task by task, making one atomic commit for each task so the changes can be reverted cleanly. 5. I send the diff to a different model than the one that wrote it. I run Codex and CodeRabbit alongside Claude. This is the highest-value station in the line: my own tests verify only what I thought to check, while an independent model can catch the class of problem I did not anticipate. 6. An agent verifies whether the phase goal was achieved by re-deriving it from the actual code. “All tasks completed” and “the thing works” are different claims. Treating them as the same is how you ship a green checklist on top of a broken feature. 7. Before anything reaches a client, I run a security and handoff audit in a real browser against a throwaway clone of the production database. I check every page, every button, and every empty and error state. The part that compounds is what happens when a bug reaches me anyway—whether I find it in production or, worse, a client reports it. I log it as an escape, then walk the chain backward and ask each gate why it missed the problem: the planner, plan checker, executor, both reviewers, verifier, security check, and handoff audit. A one-off escape becomes a written rule. A repeat becomes a change to the gate itself. I have 42 logged escapes. That file is the most valuable thing I own because every entry represents a hole that is now closed. The pipeline I run today is mostly shaped by bugs that got past the pipeline I ran a year ago. The results so far: 29 projects, 17,657 commits, and 574 phase folders. I’ve completed six client engagements, with apps live in production and handed off to their owners, as well as mobile apps built and pushed through App Store review—all as one person, with no team. There are real costs and failure modes. A phase with every gate enabled costs meaningfully more tokens than simply asking a model for the code. That is worth it on client work, where a bug can cost me a relationship, but it is overkill for a throwaway script, so I turn the gates off for those. Gates can also be confidently wrong. My most expensive recurring failure is a check that passes on a signal adjacent to the thing it claims to verify—a green light that means nothing. My rule now is that I do not trust a new check until I have watched it fail against known-bad input. A green result you have never seen turn red is not evidence. A green test suite is not the same as a working feature. Nearly every bug that escaped me was covered by a passing test whose mock had quietly pre-satisfied the exact condition under test. Testing the real boundary is the only thing that catches those failures. This process is not hands-off. I deliberately run one phase per session, and I read what comes back. Anyone selling a fully autonomous overnight build is selling a merge conflict plus a confident summary of work that did not happen. If you want to take one idea from this, it is not the framework. The agent that writes the work must never be the one that approves it. Keep a running log of everything that gets through anyway, then fix the checkpoint that let it through instead of only fixing the bug.

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’m retired and in my early 70s. I never got into RPGs growing up, but I decided to try a tabletop RPG with my wife. The game I purchased included a rulebook and a PDF of the book. I wanted my wife and me to play as the player characters without either of us having to be the game master, so I tested whether AI could take on that role. I used ChatGPT to parse the PDF and walk us through the process. It helped us create our characters, Heisenberg and Felicity, and then started the game as the game master. We’ve only just started, but it seems like this is going to work well. The AI can keep secrets to itself, roll the dice when needed, and guide us through the adventure. Step-by-step: 1. I purchased a tabletop RPG that included a rulebook and a PDF of the book. 2. I used ChatGPT to parse the PDF and walk us through the process. 3. ChatGPT helped my wife and me create our player characters, Heisenberg and Felicity. 4. We had ChatGPT start the game as the game master so neither of us had to fill that role. 5. We began playing while ChatGPT kept secrets to itself, rolled the dice when needed, and guided us through the adventure.

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.