Workflow Hub

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.

MinecraftEdu first launched nearly 15 years ago, but the classroom world we built with it is still growing. Years of students have contributed to the school and town-building project, creating a shared record of their creativity and learning. Getting it running on a modern Mac meant preserving that history and giving the next group of students a way to add their own chapter. Finding the right version of Java—the software MinecraftEdu needs to run—was central to the process. We used OpenAI’s Codex desktop app, powered by GPT-6, to examine the old setup, research compatibility issues, and test what would work. An older Java version launched the client, but resizing its window caused it to crash. ChatGPT read the crash reports and tested a newer Java 8 version, which gave us a setup that could launch the game and handle window resizing successfully. ChatGPT also repaired the server launcher and created standalone apps, using Apple’s Rosetta compatibility layer to run the older software on Apple Silicon. The result is a usable MinecraftEdu setup on modern hardware with the existing worlds preserved. We can now continue teaching and building in a place that successive classes of students have helped create. Step-by-step: 1. We examined the existing MinecraftEdu setup and researched its compatibility requirements on a modern Mac. 2. We used OpenAI’s Codex desktop app, powered by GPT-6, to investigate the old setup and test possible solutions. 3. We tested an older Java version, which launched the client but caused crashes when the window was resized. 4. We had ChatGPT read the crash reports and test a newer Java 8 version. 5. We used the working Java setup to launch MinecraftEdu and handle window resizing successfully. 6. We had ChatGPT repair the server launcher and create standalone apps. 7. We used Apple’s Rosetta compatibility layer to run the older software on Apple Silicon. 8. We preserved the existing worlds so future classes can continue building and learning in them.

I built an Awish workflow that handles a support ticket before anyone on the team opens it. I realized support tickets were not just taking time to answer. Someone still had to understand the problem, decide how urgent it was, search the documentation, route it to the right person, and prepare a response. I wanted that first layer of support work to happen automatically. I opened Awish and wrote: “Whenever a new support ticket comes in, understand the issue, determine its urgency, check our documentation, prepare a response, create a Jira issue if it looks like a product bug, and escalate anything important to the team before taking customer-facing action.” Awish understood the request, planned the workflow, and showed me which applications it needed. Step-by-step: 1. I described the complete support process I wanted in the Awish chat. 2. Awish planned the workflow and selected Zendesk, Notion, Jira, and Slack for the required steps. 3. I connected my accounts and approved the automation plan. 4. When a new Zendesk ticket arrives, the workflow identifies the issue type, urgency, and customer intent. 5. It checks the relevant Notion documentation and prepares a response based on the available information. 6. If the issue looks like a product bug, it creates a Jira ticket with the customer context already attached. 7. Urgent or sensitive cases are escalated to the team instead of being handled automatically. 8. I connected WhatsApp from the Awish chat. I now receive workflow updates there and can manage the automation without opening Awish. Customer-facing actions still stay under my control when approval is needed.

I built SITREP, a self-hosted AI RSS reader that turns roughly 30 articles a day into a single briefing I can act on. It runs in a Docker container on my home NAS, ingests full article text instead of the teasers most feeds provide, and uses OpenAI embeddings to collapse the same story reported by five outlets into one item. Every morning, it writes “The Brief” with the sections Headline, Defense & Aerospace, AI & Tech, and Elsewhere, followed by the two sections I care about most: Implications for my company and Personal Leverage. Each section includes numbered citations linking back to the source articles. SITREP only proposes leverage when the evidence supports it. It also uses a curated, non-sensitive profile of my business lanes and priorities, synced from my Obsidian vault, so its recommendations are specific to my work as a defense-industry VP rather than generic advice. I can select Update Brief at any time during the day to regenerate the briefing in place with a timestamp. Step-by-step: 1. I run SITREP in a Docker container on my home NAS. 2. I have it ingest the full text of roughly 30 articles each day rather than relying on feed teasers. 3. I use OpenAI embeddings to identify and combine the same story when it is reported by multiple outlets, including cases where five outlets cover it. 4. Each morning, SITREP generates “The Brief” with the sections Headline, Defense & Aerospace, AI & Tech, and Elsewhere. 5. It adds Implications for my company and Personal Leverage, using my curated, non-sensitive business profile and priorities synced from Obsidian. 6. It includes numbered citations to the source articles and proposes leverage only when the evidence supports it. 7. I select Update Brief during the day when needed, and SITREP regenerates the briefing in place with a timestamp.

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

I built AllegraMente, a complete, free iOS cognitive training app, solo with Claude Code. It includes 11 exercise areas, 83 articles in five languages, and no tracking. My workflow starts with a new feature or content idea, a new exercise type, or an in-depth article about how memory works. Planning and execution stay separate, and the instruction document serves as the contract. Because everything is specified upfront, Claude Code almost never goes off track. Step-by-step: 1. I plan the feature with Claude in chat, define the data models and UX, and fact-check every scientific claim against primary sources before writing anything. 2. I package the result into one self-contained Markdown instruction document containing file paths, specifications, localization keys for all five languages (IT/EN/ES/FR/DE), edge cases, and acceptance criteria. 3. I create a Git restore point. 4. I give the document to Claude Code, which implements the feature end to end using SwiftUI, SwiftData, and MVVM. 5. A small script sends me a Telegram notification when the task is complete. I review the diff and test the app on a device. 6. I ship by creating an archive with `xcodebuild` and uploading it to the App Store with Transporter. This process is how I shipped 11 exercise areas, 83 articles in five languages, and a complete editorial system as a solo developer.

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.

I’m building an AI travel assistant called SundayAtlas, and I wanted a systematic way to keep learning from what travelers are talking about between individual user conversations. Reddit is useful for this because people are unusually candid about trip-planning frustrations, destinations, bad experiences, and what they wish travel products did better. The problem is volume: I didn’t want to manually read hundreds of posts every week, so I built a Reddit Signal Agent that does the first pass and sends me a weekly travel-insights newsletter. Each week, the workflow collects posts from selected travel subreddits and passes them through an LLM-based classification and analysis pipeline. The report is organized around: - New or intensifying signals - Steady baseline themes - Fading signals - Rising destinations - Competitor mentions - Anomalies unusual enough to warrant attention This week, for example, the agent analyzed 77 posts. It surfaced a spike in discussion around short-term rental restrictions in Tokyo, growing payment friction for travelers in Japan, increased interest in quieter alternatives to heavily touristed Asian destinations, and recurring trust issues involving travel platforms. I use the newsletter as one input into product discovery for SundayAtlas. It gives me a weekly pulse on problems and behaviors that may be worth investigating further, rather than relying purely on my own assumptions about what travelers need. Step-by-step: 1. I collect recent posts from a defined set of travel subreddits. 2. I clean and structure the Reddit data for analysis. 3. I run the posts through an LLM using a defined signal taxonomy. 4. I aggregate the classifications across the weekly sample to identify patterns, changes, and anomalies. 5. I generate the report in a consistent newsletter format. 6. I run the full pipeline automatically with GitHub Actions so a new report is produced each week. I built the agent in Node.js and used Claude Code extensively during development. Evaluation ended up being the most important part. Early outputs looked convincing, but I had no objective way to know whether the classifications were actually good. I manually labeled 91 Reddit posts and created a blind golden dataset, then built a deterministic scorer to compare the agent’s classifications with my labels. The first held-out evaluation scored only 0.23, which gave me something concrete to improve against. I iterated on the classification approach and inspected individual failures. Along the way, I found three separate defects in the data collection pipeline. The held-out score eventually improved to 0.61, while the score across the full dataset increased from 0.33 to 0.67. The finished loop is: Reddit conversations → signal classification → trend analysis → weekly insights newsletter → product discovery for SundayAtlas The golden dataset remains underneath the workflow as a regression test, so when I change the agent, I can measure whether I’ve actually improved it.

I started DialPhone with a simple problem: business communication is fragmented. A typical team may use one tool for phone calls, another for SMS, another for meetings, another for fax, and a separate system for customer support. I wanted to explore what it would look like if those conversations lived in one system, with AI doing more than just transcribing them. I built DialPhone as an AI-native communications platform around that idea. The core is cloud VoIP, while the same platform also handles business SMS, video meetings, online fax, team chat, and contact-center workflows. On top of that, I added AI capabilities such as call transcription and summaries, CRM logging, AI-drafted SMS replies, conversation intelligence, and an AI receptionist that can answer calls, qualify requests, book appointments, and route conversations. The biggest architectural decision was to treat communication data as one connected stream rather than as separate products. A phone call can create CRM context, trigger a follow-up SMS, and become part of a customer-support workflow without someone manually moving information between systems. Along the way, I learned that adding AI to communications is not particularly useful if it only produces transcripts. The more interesting problem is turning conversations into actions: updating records, identifying next steps, helping agents during calls, and automating repetitive work. Step-by-step: 1. I identified the problem of business communication being fragmented across phone, SMS, meetings, fax, and customer-support systems. 2. I built DialPhone as an AI-native communications platform centered on cloud VoIP. 3. I brought business SMS, video meetings, online fax, team chat, and contact-center workflows into the same platform. 4. I added AI features for call transcription and summaries, CRM logging, AI-drafted SMS replies, conversation intelligence, and an AI receptionist. 5. I connected communication data so calls can create CRM context, trigger follow-up SMS messages, and become part of customer-support workflows. 6. I focused the AI capabilities on turning conversations into actions, including updating records, identifying next steps, helping agents during calls, and automating repetitive work.

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.

I built WarrantKit, an open-source (Apache-2.0) kill switch for AI agents. Each agent run receives a Warrant: a typed contract that specifies what the agent may do, for how long, and under which policy. A gateway checks every action before it reaches the outside world. When containment triggers, the runtime’s epoch advances, immediately invalidating every Warrant issued under the old epoch instead of allowing it to linger until a timer expires. Evidence of what happened remains separate from authority, and receipts can be verified offline with a standalone Python script. I designed the architecture and threat model, then used AI coding assistants for most of the implementation. I reviewed everything against an adversarial test suite and a real-host enforcement demo that others can run themselves. Before writing the mechanisms, I wrote tests for the attacks: replayed runtime reports, tampered event sequences, evidence attempting to upgrade itself into authority, and authority carried across execution boundaries. The suite has 202 passing tests, and several core behaviors exist because a test caught the system trusting too much. One example is a recovered runtime carrying a stale report into a new epoch. I then proved enforcement on a real Linux host with a cgroup-v2 real-kill demo before claiming it. The no-root demo is simulated, and the README says so. It also lists what WarrantKit is not. The architecture is layered: WarrantKit owns the authority lifecycle and verification; AgentContainment owns the enforcement boundary; and Warden, DProvenanceKit, and ClaimProofKit record evidence independently. Step-by-step: 1. I defined a Warrant as a typed contract specifying an agent’s permitted actions, duration, and governing policy. 2. I placed a gateway in front of the outside world so it checks every agent action before allowing it through. 3. I made containment advance the runtime’s epoch, invalidating every Warrant issued under the previous epoch immediately. 4. I kept evidence separate from authority and made receipts verifiable offline with a standalone Python script. 5. I wrote adversarial tests for replayed runtime reports, tampered event sequences, evidence attempting to become authority, authority crossing execution boundaries, and stale reports carried into a new epoch. 6. I implemented the system with help from AI coding assistants and reviewed the implementation against the test suite and a real-host enforcement demo. 7. I validated enforcement on a real Linux host with a cgroup-v2 real-kill demo, while clearly labeling the no-root demo as simulated in the README. 8. I kept authority lifecycle, enforcement, and evidence recording in separate architectural layers using WarrantKit, AgentContainment, Warden, DProvenanceKit, and ClaimProofKit.

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

Getting answers from company data usually requires someone who knows SQL, understands the database, and has enough business context to interpret the results. This creates a bottleneck: business users depend on analysts for questions they should be able to explore themselves. I turned Claude Code into a self-service data analyst by giving it direct, read-only database access and configuring its behavior through a `CLAUDE.md` file. The file gives Claude business context, explains which analytical tables contain different types of information, tells it how to investigate questions, and defines how results should be presented. Users can then ask business questions in plain English. Claude determines what data it needs, queries the database, investigates the results, creates visualizations, and explains what it found. Step-by-step: 1. Create a dedicated analysis folder and add a `CLAUDE.md` file that defines how Claude should operate as a data analyst. 2. Give Claude enough business context to understand the company, its terminology, important metrics, and how the business operates. 3. Document which analytical tables or views it should use for different types of questions. Curated analytics tables work particularly well because Claude doesn't need to decipher the entire production database. 4. Give users read-only database permissions and explicitly instruct Claude to perform read-only operations, such as `SELECT` queries only. Never give the agent permission to modify production data. 5. Tell Claude how to use the command line to query the database. Include instructions to help users install or configure it if it isn't available. 6. Define an analytical process for Claude to follow. Rather than simply generating one SQL query, instruct it to investigate the user's question, examine the results, and run additional queries when necessary to understand what is happening. 7. Define the expected output: answer the question, explain the important insights, and create appropriate visualizations to make the findings easy to understand. 8. Open the folder in the Code tab inside the Claude Desktop app, which I find to be the best interface, and ask questions naturally, such as, "Why did revenue decline last month?" Claude handles the investigation from there. Instead of building and maintaining a custom analytics application, you can turn a general-purpose AI coding agent into a capable self-service analyst with access to your existing data warehouse. Users ask questions in plain English while Claude handles the SQL, investigation, visualization, and explanation, giving nontechnical users a more direct way to explore company data.

This Codex-driven workflow takes a software request from problem understanding through implementation, validation, review, and delivery evidence. Instead of asking an AI coding agent to simply “build the feature,” it gives the agent an explicit development lifecycle with defined responsibilities, deterministic validation gates, repair loops, and human checkpoints. The goal is to make AI-assisted development more structured, observable, and recoverable. It can be used for new feature implementation, bug fixing, refactoring, test creation and improvement, code quality and security hardening, and documentation and automation changes. The core principle is simple: Don't give the AI only a coding task. Give it an engineering lifecycle to work on. Step-by-step: 1. Understand the problem. Clarify the request, identify the desired outcome, define the scope, and surface ambiguity before implementation begins. The output is problem understanding and scope. 2. Define constraints. Identify technical, functional, non-functional, compatibility, and out-of-scope constraints. The output is a constraint set. 3. Plan. Analyze implementation options, select an appropriate approach, break the work into tasks, and define acceptance criteria. The output is an implementation plan. 4. Inspect the existing system. Review the relevant codebase, dependencies, current behavior, and affected components before making changes. The output is system context. 5. Implement. Make the smallest appropriate code changes while following the existing project’s conventions and the approved plan. The output is code changes. 6. Run deterministic validation. Run tools that can objectively validate the implementation, including formatting, linting, type checks, builds, unit tests, and other available automated checks. The output is validation results. 7. Review. Evaluate the implementation against the original requirement, the plan, code quality expectations, security considerations, and potential regressions. The output is review findings. 8. Repair and iterate. If validation or review identifies problems, diagnose the issue, make the required correction, and repeat validation. The output is a corrected implementation. 9. Verify. Confirm that the acceptance criteria are satisfied and that the relevant tests and checks provide sufficient evidence for completion. The output is a verification result. 10. Produce delivery evidence and handoff. Summarize what changed, what was tested, what passed, known limitations, and any remaining decisions requiring human attention. The output is delivery evidence and a human handoff. The core loop is: Implement → Validate → Review → Repair → Validate → Verify. Testing and review are treated as part of development rather than activities performed only after coding is “finished.” AI coding agents are increasingly capable of inspecting repositories, writing code, running commands, and responding to failures. The problem is that capability alone does not provide an engineering process. This workflow separates the responsibilities an AI coding agent performs into explicit stages. It applies several principles: - Problem before implementation: Understand what needs to change before writing code. - WHY before HOW: Establish the intent and constraints before choosing an implementation. - Single responsibility per stage: Give each stage a defined purpose and output. - Deterministic validation first: Use tests, linters, type checkers, builds, and other deterministic tools wherever they can establish correctness. - Failure localization: When something fails, identify which stage or assumption needs correction. - Evidence-based completion: Support completion with validation and review evidence rather than an AI declaration that the task is finished. - Human checkpoints: Use automation to accelerate execution without removing human judgment from important decisions. The broader idea is: The AI should participate in the engineering system, not become the engineering system.

I used Claude to build an automated patient scheduler for my husband, who is the Director of Rehab at a skilled nursing facility. Each week, he takes a patient list in Excel and schedules each patient for the types of therapy they need—speech, physical therapy, or occupational therapy—based on therapist availability. The variables change from week to week, making the process time-consuming and error-prone. Automating it saves him at least an hour each week, usually on Sundays when he creates the schedule for the coming week. He uploads the patient spreadsheet and clicks “Generate schedule.” Under the hood, the app uses Google’s OR-Tools CP-SAT solver to optimize the schedule against hard constraints and weighted priorities. Hard constraints include never exceeding a therapist’s daily capacity or a patient’s maximum weekly visits. Weighted priorities include giving higher-acuity patients preference when capacity is tight, providing every patient with daily contact when possible, and balancing the workload across the week instead of simply sorting patients by who fits first. I wrote zero code. I gave Claude all the features in plain English, and it wrote the app in Python and created a test suite of approximately 35 tests. One test was added after we found and diagnosed a bug in production. I also had Claude walk me through creating a `.exe` file that I could send directly to my husband so it would open on his PC. Patient data never leaves his machine. New versions are easily compiled in GitHub, where patient data never touches the process, and enhancements only require sending a new file. Step-by-step: 1. I described the scheduling requirements and features to Claude in plain English. 2. Claude wrote the scheduling app in Python and created a test suite of approximately 35 tests. 3. I provided an Excel spreadsheet containing the weekly patient list. 4. My husband uploads the spreadsheet and clicks “Generate schedule.” 5. The app uses Google’s OR-Tools CP-SAT solver to schedule speech, physical therapy, and occupational therapy according to therapist availability and patient needs. 6. The solver enforces therapist daily-capacity limits and patient maximum-weekly-visit limits. 7. It also applies weighted priorities: higher-acuity patients receive preference when capacity is tight, every patient receives daily contact when possible, and the workload is balanced across the week. 8. After finding and diagnosing a production bug, we added a corresponding test to the suite. 9. I used Claude’s guidance to create a `.exe` file that opens on my husband’s PC, keeping patient data on his machine. 10. I compile new versions in GitHub without patient data entering that process, then send the updated file when enhancements are needed.

I made an orchestration skill to help me build faster while using my expensive Astra and Fable tokens carefully. The skill plugs into Astra or Fable and delegates tasks that can happen in parallel to multiple subagents running cheaper models suited to the work. This is especially useful for researching or finding data on the web or on my computer, analyzing code, collecting context, and indexing. The most expensive, newest models focus on maintaining delegation control, doing the difficult reasoning and strategic planning, and judging whether everything is coming together correctly. The cheaper agents handle the lighter-weight work, especially implementing code from the plans. The core idea is simple: the expensive model plans, briefs, and judges; cheaper agents do the reading and building. When I ask Claude or GPT to build the skill, I specify five things: Step-by-step: 1. I define a triage ladder: work can happen inline, with one agent, through a parallel fan-out, or in a multi-stage workflow. I choose the approach based on the task shape and include examples from my domain. 2. I define parallel versus sequential execution based on data dependencies. Independent pieces run in parallel, while anything that needs another piece’s output runs afterward. I never split one change into separate planner, coder, and tester roles. 3. I define model routing with a mandatory model pin: judgment work goes to the mid-tier model, mechanical bulk work goes to the cheap model, and every agent call names its model so nothing silently uses premium billing. 4. I define a brief template and a return-envelope cap. Every delegation includes the goal, inputs, output file path, definition of done, and constraints. Every agent returns a 250-word summary instead of raw files. 5. I define a cost gate with specific numbers. Below N agents, the workflow proceeds automatically; above N agents, it states the estimate and waits for approval.

Having a team of specialized AI agents creates a new problem: someone still needs to decide which agents should work on a project, what order they should work in, what each one needs from the others, and whether the project is actually finished. Without coordination, the human becomes the project manager, manually moving context and outputs between agents. I created a project-manager agent that acts as the orchestrator for my AI team. I give it an objective, and it determines what work needs to happen, selects the appropriate specialist agents, sequences their work based on dependencies, and presents the execution plan to me before anything starts. Once I approve the plan, it coordinates the agents, manages their handoffs, tracks project state, and maintains enough persistent context for the work to continue across sessions. Step-by-step: 1. I create several specialized agents with clearly defined responsibilities, capabilities, and expected outputs. 2. I create a project-manager agent that knows what each specialist does and is instructed to orchestrate the work rather than perform specialist work itself. 3. I give the project manager a high-level objective. It analyzes the goal, inspects the project context, identifies the required work, and selects the appropriate agents. 4. I have it create an execution plan showing which agents will be used, what each one will do, their dependencies, and the order of execution. 5. I require human approval before execution begins. I can approve the plan, narrow the scope, change the sequence, or redirect the project as needed. 6. Once the plan is approved, I let the project manager delegate each task to the appropriate specialist and pass relevant context and prior outputs between agents through structured handoffs. 7. I track progress and project state as the agents complete their assignments. If an agent uncovers new work, fails review, or changes the project assumptions, the project manager updates the plan and routes the next work accordingly. 8. At the end of the session, I save the current state, completed work, important decisions, and next actions so another session can continue without reconstructing the project from scratch. Instead of personally coordinating every AI agent, I manage the project at a higher level: I define the objective, approve the plan, review important decisions, and evaluate the result. The AI project manager handles the coordination layer, turning a collection of specialized agents into a team that can execute complex, multistep projects coherently.

I kept forgetting who I had lent books to, and spreadsheets felt like overkill. So I built Runo, a book-lending app for friends, without traditional coding. Runo (runo.club) is a web app where I can catalog my home library, get a unique shareable link, and let friends browse my books and request to borrow them. I can approve or decline each request with one click. Step-by-step: 1. I used Claude to think through the feature set, data model, and UX flow before writing a single prompt. This helped me avoid building the wrong thing first and gave me a clear blueprint for the Lovable prompts that followed. 2. I used Claude to create precise, narrowly scoped prompts for Lovable, with each prompt focused on a single change so existing functionality would be less likely to break. This significantly conserved Lovable credits. The React, TypeScript, and Supabase stack came out of the box. 3. I added two ways to scan books instead of requiring users to type titles manually: - Barcode scanner: Point the camera at an ISBN barcode to autofill the title, author, and cover using the Open Library API. - Cover photo scanner: Photograph the cover so Gemini 2.5 Flash can extract the title and author in under 2 seconds. 4. I routed the cover scanner through a Supabase Edge Function using Lovable’s AI Gateway, so the API key never touches the client bundle. 5. For every bug fix and feature, I followed the same iteration loop: describe the problem to Claude, get a precise Lovable prompt, push the changes to GitHub, and let Lovable auto-sync them. Claude and Lovable’s bidirectional GitHub sync made the process feel like pair programming. Tools used: Lovable, Claude (Sonnet), Gemini 2.5 Flash (via Lovable AI Gateway), Supabase, and GitHub. Live at: runo.club — public beta and free to use. Feedback welcome. #appbuilding #vibecoding #buildinpublic #lovable #nocode

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