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

My mum’s 80th birthday is next week, and my dad, sister, and I wanted to create a photobook of her life. My dad scanned hundreds of photos from over the years and sent them to me to clean up. Because we were working to a tight deadline and I was away on holiday, I didn’t have time to open and edit each image individually in Photoshop. I asked ChatGPT to build a tool that accepts a folder of scanned images in various formats, including scans containing single or multiple photos, overlapping photos, and photos cut off by the scanner. The tool processed each scan, cropped and straightened the individual photos, and provided a UI where I could review the results and make manual adjustments to the cropping and orientation before saving the changes to new files. I then had the tool upload the images to Google Drive and create a spreadsheet with thumbnails of every image, along with a rating system. I shared the spreadsheet with my dad and sister so we could use it as a central place to rate the photos we wanted to include in the final book. This saved me hours of work and meant we could complete the photobook in time for my mum’s birthday. Step-by-step: 1. My dad scanned hundreds of photos and sent them to me as image files in various formats. 2. I asked ChatGPT to build a tool that could process scans containing single or multiple photos, overlapping photos, and photos cut off by the scanner. 3. I used the tool to crop and straighten each individual photo. 4. I reviewed the results in the tool’s UI and made manual adjustments to the cropping and orientation where needed. 5. I saved the adjusted photos as new files and had the tool upload them to Google Drive. 6. I had the tool create a spreadsheet containing thumbnails of all the images and a rating system for each photo. 7. I shared the spreadsheet with my dad and sister so we could rate the photos and choose which ones to include in the final photobook.

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.

Management pushed for an AI workflow to handle a massive daily headache: staff were manually searching for, copy-pasting, and moving hundreds of files listed in Excel. I was assigned to train the team to use the AI workflow. As soon as training started, though, it became clear that this was the wrong tool for the job. Forcing non-technical staff through a lengthy process of opening browsers, writing prompts, uploading spreadsheets, and dealing with token friction created more work than the manual process. It also introduced token costs, speed bottlenecks, and hallucination risks involving local file paths. The data was already structured. It did not need semantic intelligence; it needed deterministic speed. So AI got fired from running the task. Instead, I used AI as the developer. In less time than it would have taken to train one person, I had Gemini code a standalone Python desktop app and compile it into a simple executable. Now, with zero training required, staff drag and drop their Excel list into the app, choose a destination folder, and click Run. The app executes the transfers for hundreds of files, verifies every arrival on disk, and logs missing files in seconds. The result: $0 in API tokens, two hours recovered each day, zero path errors, and 100% team adoption. A two-second drag-and-drop will always beat a multi-step prompt-engineering exercise. As a side effect, the experience also supported AI adoption. Staff are now seeing more ways AI can help rather than hinder their work. Step-by-step: 1. I evaluated the proposed AI workflow for manually searching, copy-pasting, and moving hundreds of files from Excel lists. 2. I identified that training non-technical staff to open browsers, write prompts, upload spreadsheets, and manage token friction added more work, costs, bottlenecks, and local-file-path hallucination risks. 3. I used Gemini as the developer to create a standalone Python desktop app and compile it into a simple executable. 4. I had staff drag and drop their Excel list into the app, select a destination folder, and click Run. 5. The app transferred hundreds of files, verified each arrival on disk, and logged missing files in seconds. 6. I measured the results: $0 in API tokens, two hours recovered daily, zero path errors, and 100% team adoption.

I had a bad workplace experience, so I built Doris: a saucy but loving anonymous AI aunt who remembers the tea, protects storytellers, and warns others. I built Spill Tea with Doris, an anonymous AI workplace confessional for conversations people cannot really have on LinkedIn: the bad manager, the inexplicable reorg, the coworker who somehow survives every layoff, and the meeting that should probably be entered into evidence. Doris does something more interesting than simply listen. She remembers the tea—and, carefully, spills it. The problem I wanted to solve was not really “chat with an AI.” Most AI conversations are disposable, but workplace stories are not. They accumulate companies, people, reorganizations, layoffs, recurring behaviors, management decisions, and institutional weirdness. At the same time, people are understandably reluctant to talk openly about their employers because a sufficiently specific story can identify its author. I designed Doris around a different idea: retain the knowledge without retaining the storyteller’s identity. Someone visits [spillteawithdoris.com](https://spillteawithdoris.com) and tells Doris what happened at work. The application is built in Next.js and deployed through Vercel. The conversation goes to an AI model with Doris’s personality and behavioral rules. Redis handles temporary conversational context, while Neon Postgres and Prisma maintain the structured, longer-lived pieces of the story—companies, people, events, and their relationships. Rather than treating every conversation as one giant transcript, the application extracts useful information and connects it to the larger story of a company. That creates the second half of the experience. When another visitor asks Doris, “Have you heard anything about working at Company X?”, she can draw upon what previous visitors have told her. But she does not simply retrieve someone’s confession and repeat it. The system separates what is useful about a story from what could identify the person who told it. Names, exact teams, precise dates, unusual job titles, and other unnecessarily identifying details do not need to travel with the underlying observation. Doris can instead recognize that she has heard several stories involving reorganizations, unusual management turnover, or a particular cultural complaint. Then Doris tells the story herself, in Doris’s voice. She might say that she’s “heard some tea” about a company, explain the general pattern, distinguish something she’s heard once from something that appears repeatedly, and avoid pretending anonymous reports are established facts. Visitors get useful institutional memory without being handed the breadcrumbs needed to identify an individual employee. Public information can provide a second layer of context. If appropriate, Doris can search for publicly available information about a company and compare it with what people have privately described. Those sources remain conceptually separate: what Doris can verify publicly, what Doris has heard privately, and what Doris herself infers should never become the same thing. The result is deliberately a little strange. It is an anti-LinkedIn. LinkedIn is where thousands of individual experiences are polished until every company sounds wonderful and every departure is an exciting new chapter. Doris works in the opposite direction. One anonymous story may just be a story. Ten people independently telling Doris versions of the same story start to describe a workplace. And Doris remembers. She just doesn’t need to remember who told her. Step-by-step: 1. I built a Next.js application and deployed it through Vercel at spillteawithdoris.com. 2. I defined Doris’s personality and behavioral rules for the AI model. 3. I added Redis to manage temporary conversational context. 4. I created a Neon Postgres database and used Prisma to model Company, Person, Story, and Event relationships. 5. I built an extraction layer that converts conversations into structured observations, removes unnecessary identifying information, and associates the knowledge with the appropriate company. 6. I built retrieval so Doris can find relevant prior observations when someone asks about a company. 7. I had the AI synthesize those observations in Doris’s voice instead of quoting or exposing the original submissions. 8. When appropriate, I let Doris search publicly available company information while keeping public sources, private reports, and Doris’s inferences conceptually separate.

A chocolate factory client had a simple but expensive sales problem: good conversations with buyers sometimes went quiet because nobody followed up at the right time. Some opportunities were waiting on sample feedback, pricing, private-label details, minimum order quantities (MOQs), packaging, or distributor discussions. The opportunities were still active, but they were easy to lose track of. I built a follow-up workflow for the client in Awish. Step-by-step: 1. I opened the Awish chat and wrote: “Track our open sales opportunities from Microsoft Teams and Google Sheets. Every business day, review the latest customer conversation, sales stage, planned follow-up date, customer interest, and how long we’ve been out of touch. Find opportunities that need follow-up around samples, quotations, private label, MOQ, packaging, or distribution. Explain why each customer should be contacted, recommend the next action, and prepare a personalized Teams follow-up message based on the real conversation history. Never send anything without the salesperson’s approval. When the customer replies, close the old follow-up action and update the Sales Master record.” 2. Awish understood the request, planned the workflow, and selected Microsoft Teams and Google Sheets for the process. 3. I connected the client’s accounts, reviewed the plan, and approved the automation. 4. When a new customer conversation takes place in Teams, Awish updates the related sales record. 5. Every business day, it reviews open opportunities and finds deals that are overdue, at risk, or ready for the next follow-up. 6. For each opportunity, it explains why follow-up is needed and what the salesperson should do next. 7. Awish prepares a personalized Teams message using the actual conversation history, but waits for the salesperson’s approval before sending anything. 8. When the customer responds, the previous follow-up is closed and the opportunity status in Google Sheets is updated automatically. Now the sales team gets a prioritized daily list of who needs attention, why they need attention, and what the next message should be—without manually reviewing every old conversation. I want to keep building more workflows like this for real businesses. If you have a complex, repetitive process in your company that you think should be automated but you’re not sure how to build it, send it to me. I’d be happy to see if I can turn it into a working automation with Awish.

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 am 65 and recently retired, and I have been asking AI for advice to keep my plants alive. It tells me whether they need more or less water, more or less light, or soil amendments such as perlite or coconut.

I changed my iPhone’s Action Button from mute/unmute to a menu of shortcuts. When I press it, I can select a shortcut I created called “Expense AI.” Expense AI records my voice, appends the transcript to a prompt, and sends it to ChatGPT. ChatGPT returns a JSON object containing the time, amount, expense description, payment method, and category. The data is then saved to a live Google Sheet. Step-by-step: 1. I changed the iPhone Action Button to display a menu of shortcuts instead of controlling mute/unmute. 2. I selected the “Expense AI” shortcut from that menu. 3. Expense AI recorded my voice and appended the transcript to a prompt. 4. It sent the prompt to ChatGPT, which returned JSON with the time, amount, expense description, payment method, and category. 5. The resulting data was saved to my live Google Sheet.

I’m creating a master plan in Google Docs that documents my file structure and naming conventions for different file types, including insurance documents, receipts, contracts, and others. I’ll give Claude access to my file server through a file-sharing link and have it create a Markdown file with guidelines for how I want my files organized. To define those guidelines, I can have Claude interview me about my business and what I want the system to do. I’ll then copy and paste a file path into Claude Code and ask it to organize the files according to the master plan. Eventually, I plan to create a folder on all my employees’ desktops that Claude can scan regularly, naming and filing everything placed there. That way, I won’t have to worry about files being misfiled or named incorrectly. Step-by-step: 1. I’ll create a master plan in Google Docs that lists the file structure and naming conventions for each file type, such as insurance documents, receipts, and contracts. 2. I’ll give Claude access to my file server through a file-sharing link. 3. I’ll have Claude create a Markdown file with guidelines for the organization system, using an interview about my business and requirements to define what it should do. 4. I’ll copy and paste a file path into Claude Code and ask it to organize the files according to the master plan. 5. Eventually, I’ll create a folder on each employee’s desktop for regular scanning, so files placed there can be named and filed automatically.

I built Timelanes so you can type any topic into one text box, such as “The Space Race” or “my grandfather's war years,” and generate a visually engaging, sourced, shareable timeline in seconds. Step-by-step: 1. Type a topic into the text box. 2. Let AI generate the timeline with dated events, short descriptions, and source links. 3. Review citation coverage for each event to see what's verified at a glance. 4. Edit and reorder events, add images and milestones, and choose a theme. 5. Publish the timeline with one click to create a shareable page and embeds that auto-render in Substack and Notion. 6. Export the timeline as a PDF, Markdown file, or CSV. Bonus: Compare mode places two or more timelines on one shared axis so overlaps stand out.

For years, my family has run a shared birthday fund: five of us contribute a fixed amount for each birthday, while the person whose immediate family is celebrating that month is exempt from paying. Tracking everything in a payment app and a chat thread meant nobody knew the balance, who was behind, or what the next gift would cost. I rebuilt the fund as a small web app with Claude. The app itself isn't the only reason I'm writing this up. The same build is also the demo I use to teach clients and students how AI-assisted product development actually works, including the parts that go wrong. Step-by-step: 1. I described the real rules instead of presenting Claude with a generic app idea: the contributors, the fixed amount per person, the family-exemption rule, and birthdays with birth years so ages could be calculated automatically. Claude built the app as a single, self-contained HTML file with no build step or server, so it opens in any browser. 2. I worked in phases and asked Claude to explain its reasoning at each stage. Instead of using one giant prompt, I added one layer per session: the calculation engine, the setup screen, then reports and CSV export. The explanations made the sessions reusable as teaching material. 3. I required the app to be configured through its own interface rather than by editing code. This was the turning point. Claude removed the hardcoded demo family and added a full setup screen for the group name, contributors, deposits, birthdays, amounts, and alerts. I can now build a family from scratch live in front of a class in about [X] minutes without showing a line of code. 4. I let a data-loss incident shape the next phase. I entered the real family data, then the browser tab closed and the download link I had been using to open the file broke. The data was stored in browser storage tied to that exact URL, and I had no backup. Nothing was recoverable at the time. 5. I turned that failure into features. Claude added CSV export for both reports, CSV import that automatically detects which file it is reading, and a backup reminder that appears in the app's alert banner when the data has never been backed up or has not been backed up for seven days. We also discovered that birth year was missing from the export, which meant a re-import would have silently lost everyone's age. 6. I had Claude test its own work. Before each handoff, it ran a jsdom test suite in a sandbox. By the end, the suite had 46 tests covering the exemption math, empty states, CSV round-trips, and backup logic. Several real bugs surfaced there instead of in front of a class. 7. I made a second version for a different audience. One prompt produced a fully English, left-to-right translation with flipped directional CSS, Latin typography, US date formatting, dollars instead of shekels, and Venmo and Zelle instead of local payment apps. It was a genuinely different build, not a find-and-replace translation. The project took 14 sessions over one week and six hours total. It had no hosting cost, dependencies, or accounts. The data still lives in the browser's local storage on each device. Opening the file on my phone and laptop creates two unrelated pools, so CSV import is the manual bridge between them. There is no authentication or sync; this is a personal record-keeper, not shared infrastructure. The data-loss incident was not a Claude failure. I failed to build a backup path before entering real data. If I did it again, I would add export before adding a single feature. The highest-leverage prompt in the whole project was not a feature request. It was: "let me configure this through the interface instead of the code." That shift turned a static demo into something my family actually uses and my students can watch being built from an empty screen. The broader point is that the failure was the most useful part of the project. A polished demo teaches people that AI makes building easy. Losing the data and rebuilding the safety net around it teaches them what building actually involves—and that is the lesson that survives the workshop.

I created an iPhone bookmark that looks and works like an app, using Claude. It includes massages, habits, and stretches targeting the shoulders, neck, jaw, and temples for when I feel a tension headache coming on. I took screenshots from a Gemini conversation about preventing and treating tension headaches, then uploaded them to Claude. I asked Fable to create a simple, accessible app I could use when I noticed my shoulders starting to rise or felt a headache coming on. Some stretches and massages include timers and tell me how many repetitions to do. It also reminds me to stop clenching my teeth and frowning while I’m working. Step-by-step: 1. I took screenshots from a Gemini conversation about preventing and treating tension headaches. 2. I uploaded the screenshots to Claude. 3. I asked Fable to create a simple, accessible app based on that information. 4. I saved the result as an iPhone bookmark that looks like an app. 5. I use the stretches, massages, and habits when I notice shoulder tension or a headache coming on. 6. I follow the built-in timers and repetition guidance, while using the reminders to stop clenching my teeth and frowning when I’m working.

We built an evidence-driven Agentic AI workflow for extracting trustworthy investment intelligence from messy real-estate documents. The problem wasn't simply getting an LLM to read PDFs. Real-estate investment information can be distributed across reports, underwriting documents, valuation materials, rent schedules, spreadsheets, tables, and multiple versions of the same information. A metric such as IRR can also appear several times with different scenarios, dates, classifications, or meanings. Instead of building another "chat with your documents" agent, we designed a controlled agentic workflow around one principle: Don't make the agent smarter. Make the workflow harder to fool. Step-by-step: 1. I start with the business question. The agent receives a request for a specific investment metric for an asset and determines the business context instead of immediately searching for matching words. 2. I resolve the entity by normalizing the asset or entity using aliases, identifiers, relationships, and hierarchy information. This prevents ambiguous names from sending retrieval in the wrong direction. 3. I build a metric-specific plan using governed definitions for important metrics. A definition can include the metric's business meaning, terminology, preferred sources, classifier information, negative cues, and extraction rules. The agent starts with a contextualized retrieval and extraction plan rather than a vague instruction such as "find IRR." 4. I discover the right documents by narrowing candidate source documents with metadata and path-level information before searching the entire corpus semantically. The goal is: Find the right document before finding the right chunk. 5. I retrieve evidence within the selected documents. Only when scoped retrieval is insufficient does the workflow fall back to broader semantic retrieval, keeping the agent's search controlled and auditable. 6. I inspect structured information when necessary. Important investment information frequently lives in tables rather than paragraphs, so the workflow escalates to table-aware processing to inspect rows, columns, schedules, and structured financial evidence. 7. I extract a structured result instead of a long free-form answer. The result preserves the metric, value, unit or context, source document, page or location, and citation information. 8. I validate the evidence by checking the extracted value against the metric definition and relevant validation rules. Depending on the metric, these checks can include unit, scenario, chronology, plausibility, and table-to-text consistency. 9. I resolve conflicts explicitly. If multiple plausible values are found, the agent does not simply select the first result. The workflow applies rules for source precedence, chronology, scenario classification, and evidence strength. If a conflict cannot be safely resolved, the ambiguity is preserved rather than hidden. 10. I produce an evidence-backed result containing the selected metric, supporting evidence, context, and lineage. The result can then become a structured business artifact for downstream analytics, reporting, or decision-support workflows. This is not simply Question → RAG → Answer. The workflow is Question → Understand → Ground → Plan → Retrieve → Inspect → Extract → Validate → Resolve → Evidence-backed output. Retrieval is one capability inside the workflow. The agent coordinates the process, chooses the appropriate tools, follows the retrieval policy, handles structured evidence, and moves the result through validation and resolution. The biggest improvement did not come from giving the model more freedom. It came from giving the model better boundaries, better domain knowledge, better tools, and explicit decision rules. This pattern can be applied beyond real estate to financial research, insurance, compliance, legal documents, due diligence, and other enterprise workflows where an answer needs to be not only useful, but defensible and traceable.

I wanted a way to turn my meeting and call notes into a to-do list while also surfacing the themes I had been discussing over the weeks and months. That helps me see where my priorities really lie and who I have been discussing them with. I use the free Granola app to record meetings. Claude Code then connects through MCP, pulls in each meeting summary, and creates a web page that runs on my machine. The workflow also creates an `.md` file for each meeting using a standard set of formatting instructions. Now I can track actions, review recurring themes, and stay on top of my to-do list. Step-by-step: 1. I record my meetings and calls in the free Granola app. 2. I use Claude Code to connect through MCP and pull in the meeting summaries. 3. Claude Code creates an `.md` file for each meeting using a standard set of formatting instructions. 4. It creates a web page that runs on my machine and organizes the meeting information into a to-do list and themes. 5. I use the page to track actions, review themes over time, and stay on top of my to-do list.

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.

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.

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

I run operations for my husband’s residential architecture firm, and I have no coding background. After every site visit, dozens of photos landed in Google Drive named `IMG_8834.JPG`. Renaming and filing them took about an hour per visit, when it happened at all. When it didn’t, the photos sat unnamed and unfindable. For an architecture firm, that creates a professional liability gap because the photos document site conditions on a specific date, as well as lost portfolio material and a hole in the firm’s permanent project archive. I solved this by building a Claude skill: a saved set of instructions that runs the same way every time with one command. I trained it to examine each photo through the eye of a residential architect, describe what the image actually shows using our professional vocabulary, and rename the file in a consistent format. `IMG_8834.JPG` becomes `2026-07-17_03_side-elevation-porch-brick-piers.JPG`—searchable, legible, and filed. Because it’s a skill rather than a one-off chat, it’s a file I can hand to anyone in the office. Everyone runs the same process and gets identical output. Step-by-step: 1. I gathered the raw photos into one “unsorted” folder in Google Drive. 2. In Claude’s desktop app, I used Cowork mode, which handles actual files, and connected only that folder—not my whole Drive. This is the safety practice I’d urge anyone to follow: the skill can see and touch only what you connect, so connect the narrowest folder that does the job. 3. I created a skill that tells Claude to read each photo, identify what it shows using the industry’s vocabulary, and rename each file in a standard format. I wrote mine for residential architecture, but the approach also works for real estate, inspections, insurance, and other field work. My format is `date_sequence_description`. 4. I ran the skill with one command, and Claude worked through the folder photo by photo. 5. The renamed photos were filed into a dated site-visit folder, ready to reference by number in reports. 6. I handed the skill file to teammates so they could run it on their machines and get the same result. One caveat for anyone using this on business files: check your client confidentiality obligations and your AI vendor’s data policy before pointing any tool at project files. We did. I wrote up the full build, including how to decide when something should be a skill versus a regular Claude conversation, at The 2040 Studio: https://the2040studio.substack.com/p/every-img_8834jpg-is-snitching-on

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.