Workflow Hub

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

I used Claude Code to build a web application that helps a company track Business Development Manager activity end to end. I gathered data from Excel worksheets and organized it in a relational database so the Business Development Managers could share their activity. Step-by-step: 1. I gathered the Business Development Managers’ activity data from Excel worksheets. 2. I organized the data in a relational database. 3. I built a web application with Claude Code to track and share the activity end to end.

The available task apps don’t meet my needs, so I’m building a personal dashboard to manage my tasks from email.

If you have a large jar of pennies or other coins, spread them out and take a picture. Upload the picture to your AI app and ask it to identify any coins that may be valuable. This is much easier than checking them one by one. Step-by-step: 1. Spread the coins out so they are visible. 2. Take a picture of the coins. 3. Upload the picture to your AI app. 4. Ask the app to identify any coins that may be worth more than their face value. 5. Check the identified coins individually to verify their value.

Today's Rundown reported that Anthropic spent the past year consulting religious scholars from different faiths to help shape Claude's morals. I use a different approach for Bible study, research, and writing Bible study books with Claude. I wrote a set of Bible study principles that Claude reads before any work begins and follows throughout the process. The main tenets are: - The Bible is the sole authority. No commentary, tradition, or scholar outranks the text. - Scripture interprets Scripture. When a passage is unclear, the answer comes from another passage, not from a theological system. - First ask what the text actually says before asking what it means. - Ask who is speaking, to whom, and under what circumstances. - Quote every verse word for word. Never paraphrase it. - Separate what the text states from what we infer, and say "I don't know" where the Bible is silent. The difference shows in the outcome. The books contain no man-made doctrines, denominational vocabulary, or creeds—only what the Bible says, with the passage shown for every claim. When a draft goes beyond the text, these principles catch it. My experience is that the moral standard an AI needs is already written down, and an AI can be held to it. The principles, along with 23 free books and studies, are available at noblemind.study. Step-by-step: 1. I wrote a set of Bible study principles for my own Bible study, research, and Bible study books. 2. I have Claude read the principles before any work begins. 3. I require Claude to follow the principles throughout the work. 4. I use the principles to keep claims grounded in the biblical text, quote verses word for word, and distinguish statements from inferences. 5. I review drafts for man-made doctrines, denominational vocabulary, creeds, and claims that go beyond the text.

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

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

I was tired of tracking events across my WhatsApp groups by hand and overcommitting myself, so I built a daily AI assistant that reads the groups and keeps my Google Calendar up to date automatically. I'm in six busy groups: multiple cricket chats, a tournament group, a volunteering rota, a weekly class, and a tennis club. Events arrive as polls, times change, venues are added, fixtures are cancelled, and the same match is often posted in multiple groups. A Claude Cowork scheduled task runs every morning. Using Claude in Chrome, it opens WhatsApp Web and reads only the fixed list of six named groups, starting from where it stopped last time. It turns messages into calendar events based on polls, merges duplicates across groups by matching the event type, date and time, and venue, and emails me a short digest covering what changed, what needs my attention, and which chats I had already read myself. I can reply to that email to steer it—for example, “delete that,” “move to 6pm,” or “why did you create this?”—and the next run acts on or answers my reply. Three small files next to the prompt make the workflow reliable: - `state.json` records where each chat was last read and which events it owns. It never overwrites a field I edited by hand. - `run.log` contains a one-line record for every action and the reason for it, so the assistant can answer questions weeks later without rereading WhatsApp. - `lessons.md` holds rules it writes for itself when something goes wrong, such as “WhatsApp changed its page layout, use this selector instead.” It reads these rules every run and can improve them. The key prompt rules are: “Your sources are exhaustive: these six chats and nothing else. Reading a chat that is not a source is itself the failure.” “Never create a second event for the same occasion. Merge; the first source owns it.” “Fields I changed by hand are locked. Report conflicts, don't overwrite.” “Send the digest every run, even when nothing happened, so silence means the run failed.” The result is that my calendar follows my WhatsApp groups without me doing anything, and each morning’s email flags the two or three things that actually need a decision. Step-by-step: 1. I define a fixed list of six named WhatsApp groups as the only allowed sources. 2. I schedule a Claude Cowork task to run every morning. 3. Using Claude in Chrome, the task opens WhatsApp Web and resumes reading each source from where it stopped last time. 4. It turns messages and polls into Google Calendar events, updating times, venues, and cancellations as needed. 5. It merges duplicate events across groups by matching the event type, date and time, and venue, while keeping the first source as the event owner. 6. It protects fields I edited by hand and reports conflicts instead of overwriting them. 7. It records chat progress and event ownership in `state.json`, logs every action and its reason in `run.log`, and reads `lessons.md` for rules learned from previous problems. 8. It emails me a digest every run, including what changed, what needs my attention, and which chats I had already read myself. 9. I reply to the digest when I want to delete an event, move it, or ask why it was created; the next run acts on or answers my reply.

I’m a nurse with no tech experience, but I’m curious and have many creative ideas. I used Claude to build a website that helps people plan which vegetables to grow based on their location, available space, and the time they have. Veggiegrowguide.com Step-by-step: 1. I identified an idea for helping people choose vegetables to grow based on their location, available space, and available time. 2. I used Claude to help me build a website for the idea. 3. I created Veggiegrowguide.com as a resource for people planning their vegetable gardens.

AI agents such as Claude Code, Codex, and Gemini can install skills, plugins, and CLI tools in seconds. That is convenient, but each add-on runs with access to files, passwords, and accounts. A malicious add-on could steal API keys, read private data, or quietly take control of the agent. I use `agent-guard` to make “check first, install after” the default. Before installation, it examines AI agent skills, MCP servers, and CLI tools for malware, prompt injection, and credential theft using professional, open-source security scanners from NVIDIA, Cisco, Datadog, and the Open Source Security Foundation. The tool returns a clear verdict: safe to install or blocked, with the exact reason. It then installs only the verified version, preventing a different version from being swapped in between. A single check can also cover multiple AI agents, installing the approved add-on into every agent on the machine. Free and open source: https://github.com/elliottwaves-20/agent-guard Step-by-step: 1. I select the AI agent skill, MCP server, or CLI tool I want to install. 2. I run `agent-guard` to scan it for malware, prompt injection, and credential theft. 3. I review the verdict and the reason if the add-on is blocked. 4. I install the exact version that was checked rather than an unverified replacement. 5. If I use several AI agents, I install the approved add-on into all of them at once.

AI coding tools can build quickly, but they can also build the wrong thing quickly. Starting implementation from a vague feature request leaves important decisions about scope, architecture, edge cases, success criteria, and expected behavior to be made implicitly during coding. I created a spec-generator agent that sits between an idea and implementation. I give it a feature request, product vision, or rough description of what I want to build. It investigates the existing project, identifies missing decisions and constraints, researches external dependencies when necessary, and turns the request into a detailed specification that another AI agent can implement without having to guess what I meant. The finished specification becomes the source of truth for the rest of the development workflow. Step-by-step: 1. I give the spec-generator the feature or product idea I want to build, along with any existing requirements, vision documents, or constraints. 2. I have it inspect the existing project before proposing a solution. It needs to understand the current architecture, conventions, capabilities, and relevant prior decisions rather than designing the feature in isolation. 3. I have it identify ambiguities and missing decisions, including questions about users, behavior, scope, dependencies, edge cases, data requirements, integrations, and what is explicitly out of scope. 4. I have it research external technologies, APIs, libraries, or platform capabilities when the design depends on facts that cannot be determined from the repository alone. 5. I have it translate the idea into a layered specification: first the product purpose and desired outcomes, then the technical architecture, and finally the detailed implementation requirements. 6. I have it define measurable success criteria and acceptance tests so that “done” means something concrete rather than simply “the code was written.” 7. I have it persist the finished specification in the project so developers or coding agents can treat it as the source of truth during implementation. 8. I pass the specification through a separate review or validation step before coding begins, resolving gaps or contradictions in the spec rather than discovering them halfway through implementation. Instead of asking an AI coding agent to interpret a rough idea while it writes code, I separate figuring out what should be built from building it.

Whenever a user wants to install a Skill, an MCP, or a CLI, the guard scans it for malware before installing it on all agent systems. Step-by-step: 1. Detect the user’s request to install a Skill, an MCP, or a CLI. 2. Scan the requested item for malware. 3. Install it on all agent systems.

I built a fantasy hockey assistant with Claude Code for my Yahoo league. It supports two parts of the league: running our in-person draft and managing my team during the season. For the draft, it runs on my laptop as a live draft board. I enter each pick as it is announced, and the assistant re-ranks the remaining players based on what my roster still needs. The rankings combine projection sources with three seasons of NHL statistics, and each player is scored according to how much they would help in each of our ten categories. The board flags players who will likely be selected before my next pick, identifies injury and regression risks, and opens a detail card for any player with projections, historical data, and a short plain-English assessment. A separate display goes on the TV for the room, showing the pick clock, the next player on deck, and recent picks. After the final pick, the view switches to projected standings for every team, color-coded by category. During the season, I paste in my roster, and the assistant pulls the NHL schedule, starting-goalie reports, and injury news. It suggests the best lineup for each day, ranks free agents by value and by games played that week, and projects my weekly head-to-head matchup category by category. It can also ask Claude to propose a lineup and explain its recommendations, which costs about ten cents per run in API credits. Yahoo’s API is read-only. If it supported write access, I would probably have the app manage my team autonomously. Step-by-step: 1. I built the fantasy hockey assistant with Claude Code for my Yahoo league. 2. During the in-person draft, I run the assistant on my laptop as a live draft board and enter each pick as it is announced. 3. The assistant re-ranks the remaining players based on my roster’s needs, using projection sources, three seasons of NHL statistics, and each player’s value across our ten categories. 4. I use the board’s flags and player detail cards to evaluate likely pre-next-pick selections, injury and regression risks, projections, historical data, and plain-English player assessments. 5. I display the pick clock, next player on deck, and recent picks on a separate TV view, then switch that view to color-coded projected standings by category after the final pick. 6. During the season, I paste in my roster so the assistant can pull the NHL schedule, starting-goalie reports, and injury news. 7. I use that information to set daily lineups, rank free agents by value and weekly games played, and project my head-to-head matchup category by category. 8. When needed, I ask Claude to propose a lineup and explain its recommendations, at a cost of about ten cents per run in API credits. 9. Because Yahoo’s API is read-only, I currently use the assistant for recommendations rather than autonomous team management.

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

My company takes cybersecurity seriously, and part of our new-hire onboarding process is a tour of the IT department to meet the team. Our walls have several screens displaying metrics and information from our security tools, firewalls, and other systems. It looks like a scene from a movie. By far, the most popular display is our custom-made Cyber Threat Map, which shows real-time attempts to infiltrate our network, malicious emails, and other security threats we're blocking. The map drives home the reality of what we're facing 24/7 while protecting our employees, vendors, and customers. I built it using Claude Code. It polls a range of devices and systems through APIs, aggregates the data on one screen, and displays attack vectors, location information, and other details from the last 30 days. Step-by-step: 1. I identified the security tools, firewalls, devices, and systems that provide relevant threat data. 2. I used Claude Code to build a custom Cyber Threat Map. 3. I connected the map to the devices and systems through their APIs. 4. I aggregated the data on a single screen, including attack vectors, location information, and other details from the last 30 days. 5. I displayed the map during IT department tours so new hires could see the real-time threats our company is blocking.

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 love playing poker, both online and live. One month, I performed poorly. Although it felt like the cards were running badly, I wondered whether I had developed a problem in my game and was blaming my losses on bad luck. I asked around, including asking AI, whether a tool existed that could measure luck from poker hand histories. The unwelcome answer was that it did not. I'm not a coder, but after doing some research into vibe coding, I started building a luck-detection app in a Claude chat. Claude built the UI directly in the chat window and advised me on the formulas I was using to calculate luck for the cards dealt, my performance on the flop, and my performance when I went all in. All three metrics have strong averages, and luck is what varies them. I used a bell curve to model hand outcomes and a Monte Carlo simulator, which Claude suggested and executed, to evaluate all possible outcomes. The result astonished me because it was so useful. I immediately fixed two major leaks in my game and felt better knowing that bad luck really was the main problem affecting my results. I liked the tool so much that I decided to turn it into a full web app with Claude Code, and now an iPhone app that I may let other people use for free. I also had a lot of fun building it—except for learning how to use Xcode. That was a pain, even with step-by-step guidance from Claude. Step-by-step: 1. I reviewed a month of poor poker results and questioned whether bad luck or problems in my game were causing the losses. 2. I researched whether a tool existed that could measure luck from poker hand histories and learned that I would need to build one myself. 3. I used vibe coding to start building a luck-detection app in a Claude chat. 4. I had Claude create the UI and advise on formulas for evaluating cards dealt, flop performance, and all-in performance. 5. I used a bell curve to model hand outcomes and a Monte Carlo simulator to evaluate possible outcomes. 6. I used the results to identify and fix two major leaks in my game and confirm that bad luck was also affecting my results. 7. I expanded the project into a full web app with Claude Code and then began building an iPhone app, working through the added challenge of learning Xcode.

I connected Claude Code to Apify's API to scrape high-performing content from IG/TikTok for ad creative inspiration, and to ElevenLabs' API to automatically transcribe videos — so I can analyze not just visuals, but the exact hooks, pacing, and language top creators are using. From there, I developed a scriptwriting system that takes rough thoughts on a hook and angle and turns them into ad scripts, drawing inspiration from winners and applying proven copywriting principles. After generating, it also grades itself against a 12-point rubric. If it doesn't score at least 90%, it rewrites until it does. I then feed it back in and say, "This is the final version." It analyzes the changes I made and updates its understanding of my style. Step-by-step: 1. I connected Claude Code to Apify’s API for collecting high-performing Instagram and TikTok content. 2. I connected ElevenLabs’ API so the workflow could automatically transcribe each video. 3. I analyzed the winning examples for their hooks, pacing, visual patterns, and exact language. 4. I fed the system a rough hook and angle and had it draft ad scripts using those proven patterns. 5. I created a 12-point grading rubric and required a rewrite whenever a script scored below 90%. 6. After making my own final edits, I fed the approved version back into the system so it could learn my style.