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

I built a predictive maintenance workflow in Awish for one of my manufacturing clients. The client had machine telemetry, production data, and maintenance history spread across different systems. The problem wasn’t collecting the data—it was spotting failure risk early enough to act. I built a custom Awish workflow that continuously checks machine telemetry and production signals in Snowflake alongside asset, meter, and maintenance history from MaintainX. When it detects abnormal performance or increasing failure risk, it identifies the affected equipment, estimates the likely operational impact, and prepares a recommended maintenance action. Nothing is scheduled automatically at that point. The recommendation first goes to the maintenance manager in Microsoft Teams for approval. Once approved, Awish creates and assigns the work order in MaintainX, then keeps tracking and updating its status until the maintenance is completed. The useful part is that the system does not wait for a machine to fail before maintenance starts, but it also does not let AI make the maintenance decision on its own. The analysis is automated, while the actual intervention still requires human approval. Step-by-step: 1. I described the maintenance process I wanted in the Awish chat. 2. Awish planned the workflow and selected Snowflake, MaintainX, and Microsoft Teams for the required steps. 3. I connected the client’s accounts and approved the automation plan. 4. Awish continuously analyzed production and telemetry data in Snowflake together with MaintainX asset, meter, and maintenance history. 5. When it detected abnormal behavior or increasing failure risk, it identified the affected equipment and estimated the likely operational impact. 6. It prepared a recommended maintenance action and sent it to the maintenance manager in Microsoft Teams. 7. Once the manager approved the recommendation, Awish created and assigned the work order in MaintainX. 8. The workflow continued tracking the work order and updating its status until the maintenance was completed. Trigger → Analyze → Approval → Action Machine signals → Failure-risk analysis → Teams approval → MaintainX work order

My friend shot a short film and gave me his hard drive to help with post-production. It contained more than 400 clips, with no clear way to tell when each one had been shot. I asked Claude to review the metadata for every clip and group them by timestamp, so they were organized by shoot session instead of sitting in one large folder. Claude also built a spreadsheet listing each clip, its shoot session, the date, runtime, and file size. This saved my friend the hassle of reviewing every clip manually. Step-by-step: 1. I received my friend’s hard drive with more than 400 short-film clips. 2. I asked Claude to review the metadata for every clip. 3. I had Claude group the clips by timestamp and organize them by shoot session. 4. I had Claude create a spreadsheet with each clip’s shoot session, date, runtime, and file size. 5. My friend could avoid going through every clip manually.

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 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 plan travel day trips for CCRC in Portland, Oregon, using a simple model I created. Before using it, planning each trip took me hours. Now, the model generates a day-trip overview in minutes that I can distribute to CCRC staff, travelers, and the bus driver. The prompts cover the destination and visit details, such as a docent tour or special events; the trip date; lunch requirements for a restaurant that can accommodate 20 guests and provide separate checks; bathroom stops every hour; and bus drop-off, parking, and pickup requirements. Step-by-step: 1. I enter the destination and details about the visit, including docent tours or special events. 2. I add the trip date and specify whether lunch is needed at a restaurant that can accommodate 20 guests and provide separate checks. 3. I include the need for bathroom stops every hour, along with the bus drop-off, parking, and pickup requirements. 4. I use the model to generate a day-trip overview in minutes. 5. I distribute the overview to CCRC staff, the travelers, and the bus driver.

I built a workflow to examine complaints I had about a local bureaucratic service and check whether my account of what happened was supported by the written record. I was concerned about delays, incomplete handling, and the way my case progressed after I gave feedback about a harmful aspect of the service and asked for a different person to handle the dossier. That request was refused. Afterwards, I felt that the process had become slower, more confusing, and more prone to mistakes. Rather than asking GPT to confirm that the service had handled things badly, I used it to test my own interpretation against the evidence. I asked GPT to review the relevant emails and dossier communications, reconstruct the chronology, and identify requests, replies, delays, unresolved issues, and changes in how the case was handled over time. We then compared the periods before and after my feedback and request for reassignment. The central questions were deliberately neutral: Were my complaints grounded in the correspondence? Did the handling of the dossier objectively become slower or more incomplete afterwards? Were there concrete errors or unanswered questions in the record? Or was I remembering the experience as worse than the documentation supported? This distinction mattered to me. The workflow was not designed to produce a verdict or turn frustration into evidence after the fact. It was designed to challenge my assumptions and separate what I felt from what could actually be demonstrated. Where the documentation supported a complaint, we could point to the relevant chronology, delays, unanswered questions, or inconsistencies. Where the evidence was incomplete or ambiguous, that was noted too. The result was a more grounded account of the case: not “I know this was handled terribly,” but “these are the parts of my experience that are supported by the written record, these are the parts that remain uncertain, and this is where the timeline changed.” In simple terms, the workflow was: emails and dossier communications → chronology reconstruction → before-and-after comparison → review of delays, errors, and unresolved issues → evidence check against my complaints → a grounded account of what can and cannot be supported. What I liked about this workflow was that it used AI as a reality-checking tool rather than an agreement machine. It helped me test whether my criticism was actually anchored in the record before I relied on it in further communication. Step-by-step: 1. I gathered the relevant emails and dossier communications about my case. 2. I asked GPT to reconstruct the chronology and identify requests, replies, delays, unresolved issues, and changes in how the case was handled. 3. I compared the period before and after my feedback about a harmful aspect of the service and my request for reassignment, which was refused. 4. I examined whether the record showed that the process became slower or more incomplete, and whether it contained concrete errors or unanswered questions. 5. I separated points supported by the documentation from points that remained incomplete or ambiguous. 6. I used the resulting chronology and evidence check to create a grounded account of what my complaints could and could not demonstrate.

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

A while ago, my dad told me he wanted to use AI to analyze World Cup matches. He had never coded before, and his AI experience was mostly limited to occasionally asking Gemini a question. I installed Claude Code for him and gave him a few prompting tips. He ended up building a full football analytics site himself and deploying it on Vercel so he could show it to his friends. Getting started with AI is easier than people assume. Sometimes, you just need a project you genuinely want to make. Now that the Premier League season has kicked off, he’s already reworking the site for it. Step-by-step: 1. I helped my dad choose a football analytics project he genuinely wanted to build for analyzing World Cup matches. 2. I installed Claude Code for him, since he had never coded before. 3. I gave him a few prompting tips and let him use AI to help build the site. 4. He built a full football analytics site himself. 5. He deployed the site on Vercel so he could show it to his friends. 6. After the Premier League season kicked off, he began reworking the site for the new competition.

To stay organized, my daughter used to spend hours entering every assignment from her college syllabi into a Google Sheet to create a semester assignment tracker. To save her that data-entry time, I put all of her downloaded syllabi into a folder on my computer. I then directed Codex to access the folder, read the syllabi, and create a spreadsheet with the course name, assignment, due date, and a completed column with a checkbox. Codex created a beautiful, easy-to-sort-and-filter spreadsheet containing all of the assignments. Now, my daughter only needs to spend a few minutes reviewing the spreadsheet before starting her semester. Step-by-step: 1. I collected all of my daughter’s downloaded college syllabi in a folder on my computer. 2. I directed Codex to access the folder and read the syllabi. 3. I asked Codex to create a spreadsheet with the course name, assignment, due date, and a completed column with a checkbox. 4. I reviewed the resulting spreadsheet, which included all of the assignments and was easy to sort and filter. 5. My daughter now spends a few minutes checking the spreadsheet and is ready for her semester.

As an AI consultant, I need to stay ahead of a landscape that evolves daily by reading dozens of industry articles each week. Manual tech watch quickly becomes a major time sink and pulls me away from client work. I built a specialized AI agent for challenge-focused summarization. Instead of producing generic, passive summaries, it answers two questions for every article: What specific problem, friction, or limitation does the article highlight? What practical solutions, tools, or actionable steps does it provide? The agent strips away marketing hype, introductory fluff, and generic definitions. It identifies the author’s core pain point and produces a quick-read summary focused on actionable technical or business solutions. This turns 15-minute reads into 30-second, high-value digests. By focusing on problem-solving rather than passive reading, the workflow helps me identify practical tools and frameworks I can apply directly to client projects and improve my consulting work. Step-by-step: 1. I provide the agent with a raw article link or the article text. 2. The agent filters out marketing hype, introductory fluff, and generic definitions. 3. It identifies the core pain point, friction, or limitation discussed by the author. 4. It extracts the concrete answers, including practical solutions, tools, and actionable steps. 5. It synthesizes the findings into a quick-read format focused on actionable technical or business solutions. 6. I use the digest to identify tools and frameworks that may apply directly to client projects.

I built an autonomous, end-to-end AI Sales Development Representative (SDR) engine entirely in n8n. On a scheduled trigger, the agent calculates targeting parameters, reads long-term CRM memory to avoid duplicate outreach, searches for and qualifies prospective leads, scrapes company websites for buying signals, drafts tailored outreach emails, writes structured relational data to PostgreSQL, and reports execution summaries through Telegram—with zero manual intervention. The system is currently deployed in production for a B2B agricultural export business, generating qualified international wholesale leads on a recurring schedule. Most AI automations rely on simple linear scripts or break down when handling complex agentic tool workflows. This system addresses three common failure points: - High API costs: Re-sending large system prompts and tool schemas on every agent iteration drains tokens. - Context blindness: Agents without memory of previous contacts can send duplicate outreach. - Database crashes: Agents may hallucinate ENUM values or fail to insert nested one-to-many arrays into relational tables. The workflow uses a Cloudflare-proxied Claude Sonnet 4.6 model with prompt caching, persistent CRM memory reads, and a fault-tolerant parallel database-write architecture. The stack includes n8n as the orchestrator; Claude Sonnet 4.6 through a Cloudflare Worker proxy as the LLM core with ephemeral prompt caching; PostgreSQL for CRM contacts, intelligence, and outreach tables with custom ENUMs; SerpAPI for prospect discovery; Firecrawl for website content extraction; and Telegram for execution reporting. The workflow exposes these tools to the n8n agent: - `read_relationship_memory`: Read-only SQL access to historical contact and outreach data, preventing duplicate prospecting. - `Lead_Finder`: Searches for and identifies target prospects by country and sector. - `Scrape_Website_Content`: Extracts website content, buyer-intent signals, and objections from discovered domains. - `write_relationship_memory`: Writes leads, intelligence facts, and drafted emails to Postgres in one resilient call. Step-by-step: 1. A Schedule Trigger feeds a JavaScript “Country Calculator” node that resolves the day’s targeting parameters—region and industry focus—using ISO week rotation. This cycles outreach across markets automatically. 2. The AI Agent connects to an OpenAI Chat Model node whose Base URL points to a custom Cloudflare Worker. The worker translates OpenAI-formatted requests into Anthropic’s Messages API, enabling Claude Sonnet 4.6 while injecting ephemeral cache-control headers into the system prompt and tool definitions to reduce repeat-token costs. 3. Before researching, the agent calls `read_relationship_memory` to check relationship status and outreach history, preventing duplicate contact attempts. 4. `Lead_Finder` searches target sectors in the day’s region and returns seven filtered candidates. `Scrape_Website_Content` then visits each domain, extracts clean page text, and surfaces offerings, value propositions, and likely objections. 5. The workflow writes nested one-to-many data—multiple facts and one outreach log per contact—without item duplication or ENUM crashes. The tool schema requires a strict JSON array with exact ENUM string choices spelled out in the description. 6. A sub-workflow triggered by “When Executed by Another Workflow” splits the array, then flattens nested `contact.*` fields to root keys using JavaScript. 7. An upsert query, `ON CONFLICT (email) DO UPDATE`, writes the contact, increments `email_count` for repeats, and returns `contact_id`. 8. A “Re-attach Context” node merges `contact_id` back with the original intelligence array and outreach payload because n8n strips extra data through single-row database nodes. 9. Two parallel branches run: one inserts the outreach log with `ON CONFLICT DO NOTHING`, while the other splits and inserts each intelligence fact with defensive ENUM sanitization. This eliminates crashes and duplicate rows during retries. 10. The agent’s final output triggers a Telegram message summarizing the discovered leads, extracted facts, and drafted emails, sent directly to the operator’s phone. The result is a production-grade, self-healing AI outbound pipeline running with zero manual intervention. It maintains CRM data integrity, avoids duplicate outreach, and uses prompt caching to keep LLM costs low at scale.

I built an archery app that uses AI to detect arrows and bullseyes on an archery target. It groups the arrows, measures how tight the groupings are, and calculates each arrow’s distance from the bullseye. It also shows the arrows’ locations and their relationship to the bullseye—for example, whether a shot is too far left, right, high, or low, or is dead on. The app can use targets from competition standings to score a shoot according to different standards. After shooting a set of arrows, the archer takes a photo, and the AI detects the target, identifies one or more bullseyes, predicts which arrows are intended for each target, and completes the measurements and scoring almost instantly. The results can then be sent to a coach, who can provide feedback, tips, and techniques to help improve the archer’s shooting. I trained my own model using 3,000 photographs that I took and hand-labeled with the bullseyes and arrows identified. I ran a series of training sessions over several weeks and refined the model to improve its accuracy. It currently achieves about 95% accuracy for arrows and about 90% accuracy for bullseyes. Step-by-step: 1. I took 3,000 photographs of archery targets. 2. I hand-labeled the arrows and bullseyes in those photographs. 3. I trained my own AI model in a series of sessions over several weeks. 4. I refined the model to improve its detection accuracy. 5. An archer shoots a set of arrows and takes a photo of the target. 6. The app detects the target, one or more bullseyes, and the arrows, then predicts which arrows are intended for each target. 7. The app groups the arrows, measures grouping tightness and distance from the bullseye, identifies each arrow’s position relative to the bullseye, and scores the shoot according to the selected standard. 8. The results are sent to a coach for feedback and advice on improving the archer’s shooting.

I built an open-source fitness tracking app in Flutter, but the core workflow is the AI-agent architecture that designed it, built it, and now coaches from its data. For years, I tracked workouts in OneNote. The records were messy, difficult to search, and inconsistent. Excel went out of date as soon as I skipped a week. When I tried chatting with LLMs about my training, the problem was similar every time: no context, no memory, and no awareness of the weights I was using. Each conversation started from zero. The solution has two layers. Gym Tracker is a Flutter app with a local SQLite database that structures workout data properly. It includes 33 pre-populated exercises across 10 muscle groups, separate strength and hypertrophy records, multiple runs with pace, body stats, and full session history. There are no subscriptions, accounts, or cloud dependencies. The database is a file I own. Deschamps is the AI agent that reads the database and knows my full training history. It is not a chat window that forgets between messages; it is a tactician with long-term recall of my personal bests, progression, and injuries. The app stores the data, and Deschamps turns it into decisions. Step-by-step: 1. I defined the data architecture. Fitness data is operational data, so I gave it a schema, a query layer, and an agent that respects its history. I designed a SQLite schema with five tables, proper constraints, and a 10-category muscle taxonomy enforced by a CHECK constraint. 2. I wrote architectural prompts for AI coding agents. I run a team of specialized AI agents using OpenClaw, an open-source agent framework. I act as the CTO agent: I design the systems and delegate implementation to coding agents, including Forge, Cline, and Claude Code. I provide the vision, and they provide the execution. 3. The coding agents built the Flutter app with clean architecture, the repository pattern, Provider state management, and real-time cross-screen refresh. For each iteration, I review the result, refine the prompt, and ship. 4. I designed the database for dual access. The app writes to it, and the AI agent reads from it. They use the same file and schema. In external database mode, the app opens a `.db` file directly, allowing both the app and Deschamps to read and write simultaneously. This creates the bridge between the data layer and the intelligence layer. 5. I shipped the app across Windows, macOS, Linux, Android, and iOS from one codebase. The Android APK is available as a direct download from GitHub. 6. Deschamps reads the database and programs the next session using the full training history. Every session, weight, and body statistic remains structured data without summarization loss. The data is the context. 7. I made everything open source: the app, the agent prompts, and the architecture documentation. My company, Executive Mind (executivemind.io), uses the same agent-first model with seven AI agents and $40/month in total compute, running real operations 24/7. The result is a fitness tracker that remembers everything, an AI coach that never forgets, and a data layer designed from the start for both humans and machines to read. Links: krisracette.me/gym-tracker · github.com/Roughn3ck/gym_tracker · executivemind.io

Faceplant is a real full-stack app, not a mockup. It uses a FastAPI and PostgreSQL backend, a React and MUI frontend, and the Anthropic API (Claude) to power bot replies. The core is the reaction engine. When a human posts, the backend schedules two timed waves of reaction jobs. A background scheduler built with APScheduler polls for due jobs, calls Claude for an in-persona reply, and writes that bot’s comment and like. The 56 personas are stored as data in a roster file. Adding a voice requires only one new entry, so the crowd can scale without additional code. A subset of the personas are GIF-first bots: they ask the model for a caption and search tag, then pull a matching GIF from Giphy. The part I’m proudest of is the honesty layer. Every Claude call is metered and priced, and “The Meter” rolls the data up live with the cost per post, the dollar-per-minute burn rate, and a “spent on nobody” line for bot-to-bot chatter with no human at either end. A “% human” badge drains toward “dead internet” for each thread. The dead-internet loop—bots posting and replying to one another with no human present—is disabled by default and protected by three guardrails: generation decay, a per-thread cap, and a global spend kill switch. Optional cost controls include the Message Batches API at half price and prompt caching for a shared house-style prompt. The whole project is a working demonstration that manufactured engagement is cheap to produce and expensive to mean anything. Step-by-step: 1. I built the app with a FastAPI and PostgreSQL backend, a React and MUI frontend, and Claude replies powered by the Anthropic API. 2. When a human posts, the backend schedules two timed waves of reaction jobs. 3. APScheduler polls for due jobs and triggers Claude to generate an in-persona reply before writing the bot’s comment and like. 4. I keep the 56 personas in a roster file so adding a voice requires only one new data entry. 5. For GIF-first bots, I have the model generate a caption and search tag, then use that tag to pull a matching GIF from Giphy. 6. I meter and price every Claude call, then display live cost per post, dollar-per-minute burn, “spent on nobody” costs, and the “% human” status for each thread. 7. I keep bot-to-bot activity disabled by default and limit it with generation decay, a per-thread cap, and a global spend kill switch. 8. I can reduce costs further with the Message Batches API at half price and prompt caching on a shared house-style prompt.

Ten days ago, I posted about keeping a `HANDOFF.md` so an AI film project doesn't lose the decisions it has already made. This is the other half, and it turned out to be the expensive one: the decisions that haven't been made yet. Credit where it belongs: Tony Ojeda posted a spec-generator agent that sits between an idea and implementation. The rule I borrowed is his: the agent inspects what already exists before proposing anything. I applied it to film production instead of code. I pointed an agent at my production documents for a short film I hadn't started generating and asked it to identify what was still undecided, what each item affected, and what would break if it were decided late. It came back with ten open decisions. One of them was worth the whole exercise. My environment description is locked verbatim across all 40 shots so the world stays identical. The film is called *The Thaw*. Whether the ice visibly melts during the film is written down nowhere. If I decide that in week three, all 40 keyframes get regenerated at once. I would have found out around shot 12. The counterintuitive part is who writes the list: not me. Asking the person who already has the whole film in their head what's missing gets you very little, because they have all of it—and that's exactly why they can't see the hole. The list has to come from something that only knows what's written down. Step-by-step: 1. I put the open questions in section 0 of the handoff, above everything else, so it's the first thing read and the first thing emptied. 2. I have the agent write that list, not me. It reads every existing document for the project and returns only what it cannot know from them. 3. I have it return three things for each item: what's undecided, which shots it affects, and what breaks if it's decided late. The third column sets the priority. 4. I have it sort by what costs the most to change afterward, not by what's easiest to answer. 5. I keep one hard rule: while an open question affects a shot, that shot doesn't get generated. The question gets decided, or deferred in writing with the cost of being wrong stated. 6. Every answered item leaves section 0 through one of two doors: into the closed canon or into the rejected list. Nothing is simply deleted. 7. I ask specifically about the things that go missing every time: the rule of the world; the physical scale of anything impossible, such as whether the character can touch or climb it; any object appearing in more than one shot; screen direction; how it ends; who speaks and in what voice; and the delivery format. 8. When it finds nothing real, it says so. A list padded to look thorough is worse than an empty one. The version I'd used for a year ran at the end of a session and recorded what got decided. Running it at the start, focused on what hasn't been decided, is the same document pointed the other way—and it's the direction that saves money.

Sometimes a story needs a simple locator map to show where something happened or where something can be found—such as a business facility, a car accident, or the best place to see a sunset. I've worked in media for a long time and understand the power of maps to tell stories. But media cost-cutting and consolidation have reduced the number of available graphic departments, so creating a map is often the last task a reporter or editor wants to take on. I used Perplexity for initial research, Claude Code and Codex to build a web app, and Perplexity and ChatGPT for post-work such as SEO best practices. Step-by-step: 1. I used Perplexity's Deep Research mode to conduct a competitive market analysis. I asked it to analyze the field I was considering entering, identify competitors and growth rates, and explicitly break out feature sets. 2. I revised the research with my own idea and asked Perplexity to run the competitive landscape against it. I also provided desired outcomes, including intended audiences and where competitors were reaching them. I added the constraint, "Do it without syncophancy," so it would stop telling me how good my potential product was. 3. I hand-drew the initial screens and functions I wanted, then used the `/office-hours` skill in the Gstack bundle, available on GitHub, to play devil's advocate, sharpen the ideas, and challenge my assumptions. 4. I wrote a long prompt describing the product, starting broadly with the concept and audience and then narrowing to specific features and benefits. For example, I specified that it should export in 16:9 and 9:16 formats so maps would be ready for mobile vertical presentation. 5. I specified the hosting environment and that the product should be a web app. I also required a planning phase followed by construction phases. I pasted the prompt into Claude Code with this final line: "Use /grill-me to ask me questions to clarify intent." After 147 questions, it started the build. 6. This was in the pre-Fable days, so I specified that Opus 4.8 should act as an orchestrator while less expensive agents, particularly in Codex, handled the actual coding. 7. I used separate phases for technical work such as wiring in mapping providers and getting the UX to work correctly. Other phases included wiring in payment and subscriptions and making sure a subscription triggered an email campaign with instructions. 8. I dedicated an entire phase to building admin tools so I could manage the marketing language on the landing page and publish blog entries. 9. After each phase, I had the Opus/Codex combination perform an adversarial code-review-and-fix cycle. I then ran the `/ai-regression-testing` skill from the ECC repository on GitHub to catch issues the code review missed. 10. After every third phase, I prompted Claude Code: "Act as a senior QA engineer and go through the entire codebase looking for inconsistencies, functions that are in the wrong place, code that is overkill and security vulnerabilities." 11. When I had a product I thought was ready for testing, I prompted Claude Code, again using the Opus/Codex combination: "Act as a senior security engineer. Run this against OWASP standards. Find problems and suggest fixes. Harden this product overall." 12. As I neared the end, I asked Perplexity Deep Research and ChatGPT (Sol/High) to find SEO solutions for the product.

I run a small healthcare clinic and needed a monthly performance scoreboard that combined data from three separate sources: Google Analytics (GA4), my booking or appointment system, and a cashflow spreadsheet. Pulling everything manually each month took more than an hour and was prone to errors. I automated the pipeline using Claude-in-Chrome shortcuts and Claude’s analysis capabilities, reducing the process to around 10 minutes of hands-on time. Service businesses often have performance data scattered across a website analytics platform, a booking or practice management system, and a finance tool. Creating a coherent monthly view requires exporting data from each source, cross-referencing it, and manually calculating derived metrics such as rebook rate and conversion rate. This workflow automates data collection and analysis in one step. Step-by-step: 1. I set up two scheduled Claude-in-Chrome shortcuts to run automatically on the 1st of each month. One exports the GA4 Traffic Acquisition CSV, and the other exports the GA4 Pages and Screens CSV. Both save directly to a designated Google Drive folder. 2. On the 1st, I manually trigger a third Claude-in-Chrome shortcut. It logs into my booking system, navigates to the appointments export, and downloads the month’s appointment data. I keep this step manual because most booking systems log users out between sessions. 3. I open my cashflow spreadsheet and note the month’s revenue and profit figures. This takes about 30 seconds to do manually. 4. I open a Claude session and upload all four files together: the two GA4 exports, the appointment data, and the cashflow figures. 5. I prompt Claude to calculate the key metrics: total appointments, new patients, utilisation rate, rebook rate, average spend, online bookings, and website-to-booking conversion rate. The rebook rate is calculated from the appointment data as patients with a future booking divided by total patients seen. 6. Claude produces a formatted monthly scoreboard, flags anything that looks anomalous, and compares the results with the prior-month baseline when I include last month’s scoreboard in the upload. 7. Optionally, I ask Claude to produce individual practitioner breakdowns from the same appointment data, splitting the metrics by staff member for use in one-on-one reviews. The result is a complete, accurate monthly clinic scoreboard in around 10 minutes, with no manual calculations. The rebook rate computation alone, which previously required cross-referencing two separate reports, now takes seconds. The same workflow can adapt to any service business using a booking or practice management system that allows CSV exports. Tools used: Claude (Sonnet 5), Claude-in-Chrome extension, Google Analytics GA4, Google Drive, any booking or appointment system with CSV export capability, and Google Sheets or Excel for cashflow figures.

Commercial vehicle maintenance information is often fragmented across driver reports, warning lights, fault codes, inspections, repair records, and vehicle history. This makes it difficult for smaller fleets to decide whether a vehicle can continue operating, requires scheduled repair, or should be stopped immediately. We built TruckFixr Fleet AI to turn an unstructured driver report into a clear, reviewable maintenance action. The workflow begins when a driver submits symptoms, photos, fault codes, and vehicle information through a mobile-friendly form. AI and optical character recognition extract the relevant details and organize them into a structured maintenance case. The report is then evaluated alongside available vehicle history and previous repairs. The workflow provides decision support through three practical actions: continue operating while monitoring, schedule an inspection or repair, or stop and escalate for immediate professional assessment. Final safety decisions remain with authorized fleet or maintenance personnel. After an inspection or repair, the confirmed cause, work performed, and outcome are recorded, creating a more complete vehicle history for future cases. The general workflow can be recreated using a mobile form, OCR, a vehicle-history database, an AI model, automation software, and a human-review dashboard. Step-by-step: 1. A driver submits symptoms, photos, fault codes, and vehicle information through a mobile-friendly form. 2. AI and optical character recognition extract the relevant details and organize them into a structured maintenance case. 3. The workflow compares the report with available vehicle history and previous repairs. 4. The system provides one of three decision-support actions: continue operating while monitoring, schedule an inspection or repair, or stop and escalate for immediate professional assessment. 5. Authorized fleet or maintenance personnel make the final safety decision. 6. After inspection or repair, the confirmed cause, work performed, and outcome are recorded in the vehicle history. TruckFixr has used this approach to support more than 100 vehicle-issue resolutions in early fleet pilots, helping fleets identify problems earlier, prevent avoidable breakdowns, and keep vehicles moving safely.

“A good engineer knows when not to use AI.” I built a semi-automated workflow to summarize my live streams. With it, I can record and edit a stream in just one day of work. Not everyone has time to watch an entire stream, so creating a summary of the main moments is important for people who want to watch it later. Many tools create Shorts from videos by analyzing transcripts, but they are expensive and do not work well for visually heavy content such as gameplay. Gemini can analyze both video and audio and has a long context window, so I decided to use Google AI Studio to identify important moments. I also created scripts to automate parts of the video-editing process. Some of the scripts can be executed by an agent, and the prompts can be turned into Skills when using the API. Step-by-step: 1. I record the video with separate tracks for the microphone and background audio. I keep the microphone on the first track so the LLM does not identify only the background audio. 2. I compress and cut the video with `ffmpeg`, then extract the audio tracks. Google AI Studio has implicit video requirements: files must be under 400MB and under one hour long. The AI analyzes only one frame per second, so I can also lower the FPS to save space. I use the audio tracks later in the workflow. 3. I upload the processed videos to Google Drive, which makes them easier to use in Google AI Studio. 4. I use Gemini with temperature 1 and a high thinking level to select the important moments. I add the system prompt and specify which part of the video I am uploading: "The video is part X of the stream. Please make a structured script according to the system instructions." This helps Gemini understand what types of moments may appear in the video. The system prompt was created for gameplay presentations but can be adapted for other content. 5. I use Gemini Pro with temperature 1 and a high thinking level to find the timestamps for the selected moments. I keep timestamp generation separate from moment selection so Gemini has more thinking time for each task. Gemini Pro works better than Flash when handling time. I add the system prompt along with a copy of the response from the previous step. - As an extra check, after execution I continue the conversation with: "Check if the analysis was cut off too early (context truncation), ignoring that the video continued and generating false positives for timestamps. Check the last events especially." 6. I send the data to Blender. I create a JSON file containing the AI’s response and use a script to add the original video, the microphone track, and the background audio track. The script cuts and marks the important moments based on the JSON. Because it is not possible to send multiple audio tracks from a single video, I send the tracks separately. I also make sure to use the correct FPS, either 30 or 60. 7. I edit the video manually. The AI’s timestamps are not perfect, so I may add or remove sections, or correct a position that the AI identified incorrectly. I then render the video. 8. As an extra, I can automate standardized edits. For example, I use three different camera positions, so I add clips to three different tracks depending on the position I want. I use a script to change the position and scale of the clips on those tracks. 9. As another extra, I transcribe the audio. I mute the background audio and save only the microphone audio as an MP3, then use Whisper to transcribe it. I can use the transcript as YouTube subtitles or embed it directly into the video. I use Whisper-WebUI with Log probability Threshold -0.5, No Speech Threshold 0.5, Patience 2, and Hotwords `\u003cmy name and terms in other languages I usually use\u003e`. I use an LLM to translate the transcript into other languages. 10. Finally, I create tags and titles. I upload the transcript to Google Drive and use it in Google AI Studio with a system prompt to generate tags and titles for the video. I also use the assistant in Google AI Studio to analyze and summarize my channel for use in LLMs. This helps me choose better titles and tags.