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

I use a Claude skill to reduce the manual work involved in my job search. It searches for the latest roles, assists with my applications, and tracks my application journey. I can fully automate the process with Claude scheduling. I download the SKILL file from my GitHub repository (https://github.com/petehawtree/job-search-tracker-skill) and launch it in Claude Desktop. Alternatively, I can download the entire repository and recreate it in my Claude skills directory. I schedule it to run each day or trigger it manually. Each run summarizes the latest activity and tracks it against previous runs. The workflow includes a dashboard for monitoring roles and applications, along with a daily digest that guides me through the new roles it finds. Step-by-step: 1. I download the SKILL file from https://github.com/petehawtree/job-search-tracker-skill. 2. I launch it in Claude Desktop, or download the entire repository and recreate it in my Claude skills directory. 3. I put the workflow on a schedule or trigger it manually each day. 4. I review the daily summary, which is tracked against previous runs. 5. I use the dashboard to monitor roles and applications. 6. I review the daily digest for guidance on the new roles the workflow finds.

I teach AI in Business at Western Washington University, and I built a free, case-based AI textbook with Claude and GitHub Pages: https://prof-califf.github.io/ai-in-business/ The 11-chapter digital textbook includes seven real company cases—EveryCure, Netflix, Spotify, Uber, Waymo, Airbnb, and Epic—plus chapters on AI’s environmental cost, ethics, regulation, and the future of work. Seven chapters include hands-on Python labs, and Chapter 8 has an interactive calculator that models the energy and water footprint of a reader’s own AI usage. The textbook is free, has no publisher, and costs $0 to host. The problem was that AI textbooks are stale before they ship. An 18-month publishing cycle means students can pay $200 for a book that is already two model generations behind. Textbooks also tend to teach theory first and postpone business relevance until much later. My students do not need to derive backpropagation. They need to understand why Spotify built a recommender, how it works, what broke, and what it cost—then build one themselves. My stack is Claude, GitHub Pages, VS Code, Google Colab for the labs, and n8n for the Chapter 7 agentic lab. The project started when I was assembling a reading list and could not find anything usable—only outdated textbooks and paywalled cases. I already had years of lecture notes scattered across documents. Step-by-step: 1. I locked in a framework first. I use the AI Factory model—Data → Model → Prediction → Decision → Value → loop—and run every company through it. This is the step people skip: it builds transferable skills for students and gives Claude a stable structural contract across every chapter. 2. I set up the repository before writing. I created a new repo, added `index.html`, opened Settings → Pages, and confirmed that the site deployed. Five minutes up front was better than debugging after 40,000 words. 3. I built one chapter completely and used it as the template. Each chapter is a single, self-contained HTML file with no build step or dependencies. Then I prompted Claude: "Here's my finished Chapter 1 as the format reference. Here are my notes on Uber. Draft Chapter 4 in the same structure and voice." A finished exemplar worked better than an abstract description. 4. I started from my existing material instead of using a blank prompt. Claude structured and clarified my notes, but it did not decide what I think. I rewrote anything that did not sound like me. That distinction preserved the resource’s voice and avoided generated filler. 5. I made the labs builds rather than exercises. Students reconstruct each system in Google Colab using Claude as a coding partner, then publish their work to their own GitHub repositories. They finish with artifacts. 6. I shipped an incomplete version and update it like software. I published with fewer chapters, then edit and push updates when regulation changes so students automatically get the current version.

After about 18 months of building software with AI, I realized that reliability wasn't primarily a model problem. Bigger context windows and more clever prompts didn't fix it. What did help was treating the AI like a developer joining an existing team instead of like a chatbot. Real developers don't work from memory. They inspect production, read the documentation, check the tickets, and use proven tools. I built an environment that lets the AI do the same. The workflow is tool-agnostic, so it can be rebuilt with whatever AI client and stack you already use. Step-by-step: 1. I gave the AI a persistent task and history store that it can read from and write to. This is the core of the workflow. Mine lives behind an MCP tool, but any queryable store can work. Every architectural decision, blocker, and progress note gets written there instead of being left in the chat. 2. I open every session with a stand-up. Before writing a single line of code, the AI pulls what was in progress, what's blocked, what changed since the last session, and which architectural decisions still hold. About 30 seconds later, we're both looking at the same project. Then we build. 3. I exposed real operations as MCP tools instead of relying on "write code" prompts. I wrapped specific, tested actions—such as creating a page, defining a data model, wiring an integration, and running a migration—as tools. The AI composes these known-good building blocks into larger solutions instead of regenerating infrastructure every session. I call this wave coding, and it's the biggest reason the output stays consistent. 4. I made verification a rule: before touching anything, the AI reads the live database, API state, logs, and files. It checks ground truth first instead of making assumptions. 5. I made the chat disposable and the log canonical. If it isn't logged, it didn't happen. The task store is the single source of truth, not the conversation. The payoff is that I can stop halfway through a feature, close my laptop, and come back days later. The AI reconstructs the project from its own history, so I don't spend 20 minutes re-explaining it. Full disclosure: I built this into my own platform, WebsitePublisher.ai, which currently has 43 MCP tools and 105 integration building blocks. It's delivered as an add-on that plugs into the AI client I already use over MCP, so there's no new app to learn. Nothing here is locked to that platform, though: the workflow itself works with any MCP client and any store the AI can query. I'm curious whether anyone else is running their AI this way or solving the amnesia problem from a different angle.

I fed Claude my sweat-test data, and it formulated a DIY high-carb cycling mix tuned to my sweat chemistry. It also scaled the batch to match my available supplies and generated print-ready labels and batch sheets. Step-by-step: 1. I provided Claude with my sweat-test data. 2. I used Claude to formulate a DIY high-carb cycling mix tuned to my sweat chemistry. 3. I had Claude scale the batch to match my available supplies. 4. I had Claude generate print-ready labels and batch sheets.

I used Claude Cowork to replace a weekly analysis of closed-end funds for a weekly newsletter. I created a project that uses Claude for Chrome to scrape and download all closed-end pricing information from a CEF website. It adds that information to a weekly dated spreadsheet and calculates changes from the prior week, month, and year. It also updates other data points, including graphs, Top 10 and Bottom 10 rankings, and our own portfolio of funds. Step-by-step: 1. I created a Claude Cowork project for the weekly closed-end fund analysis. 2. I used Claude for Chrome to scrape and download all closed-end pricing information from a CEF website. 3. I added the information to a weekly dated spreadsheet. 4. I calculated changes from the prior week, month, and year. 5. I updated the graphs, Top 10 and Bottom 10 rankings, and our own portfolio of funds. 6. I used the resulting analysis for a weekly newsletter.

As a hobby/non-work-related creative outlet, I've started to write and create YouTube videos about retro football (soccer) stories. Part of the visuals are vintage stickers of the players mentioned. This used to be a time-intensive Google/eBay search when I was looking for 20+ players at a time. So I used Claude to build a local "Sticker Search" tool. It lets me enter the player, season, and team, find their sticker from that year, and download it to my working folder with one click. It's made my hobby way more fun and sped up the tiresome bit. P.S. I used Billy's guide on Manus to create the animated logo for the videos! Step-by-step: 1. I listed the inputs I needed for each search: player, team, and season. 2. I used Claude to build the local Sticker Search interface and search logic. 3. I added recent-search shortcuts so I could repeat or refine searches quickly. 4. I made each result downloadable with one click to my working folder. 5. I used Billy's Manus guide to create the animated logo for the videos.