Workflow Hub

This mobile app organizes a field service technician’s entire workday in one place. It records departure and arrival times, on-site work, parts purchases, reports, return travel, and mileage. The app automatically identifies missing details, saves unfinished jobs, and allows them to be edited later. Filters make it easy to find a task by store, job number, date, or month. Data can be safely exported, transferred to another device, and downloaded as Excel or PDF files. Step-by-step: 1. Record the technician’s departure and arrival times. 2. Log on-site work, parts purchases, reports, return travel, and mileage. 3. Review the app’s indicators for missing details and complete any unfinished information. 4. Save unfinished jobs and edit them later when needed. 5. Use filters to find tasks by store, job number, date, or month. 6. Export the data safely, transfer it to another device, or download it as an Excel or PDF file.

I had a project that was perplexing me, so I asked an AI for help by simply typing, "I'm a stupid moron." The AI helped me with the issues I was having with my project. 1. I described my project-related difficulties by typing, "I'm a stupid moron." 2. I used the AI's help to address the issues I was having with my project.

Microsoft is retiring Publisher on October 1, 2026. I have many `.PUB` files that I need to convert to PDFs before then, but I did not want to use online converters. I wanted a solution that would run locally on my computer. I worked with Claude to create a lightweight program that searches for `.PUB` files on a drive of my choice and converts them into high-quality PDF files, placing each new PDF in the same folder as its source file. Opening PowerShell manually and managing permissions was too cumbersome, so Claude also created a batch file to make the process easier. For anyone who wants to create their own mini-program, I asked Claude to create a reusable prompt. I posted that prompt at https://mediumseagreen-seal-177480.hostingersite.com/ along with my two files: the batch file and the PowerShell commands. Step-by-step: 1. I identified the `.PUB` files I needed to convert before Microsoft retires Publisher on October 1, 2026. 2. I decided to use a local solution instead of an online converter. 3. I worked with Claude to create a lightweight program that searches a selected drive for `.PUB` files. 4. I set up the program to convert the files into high-quality PDFs and place each PDF in the same folder as its source `.PUB` file. 5. I used a batch file created by Claude so I would not need to open PowerShell manually or manage permissions each time. 6. I asked Claude to create a reusable prompt for others who want to build their own version and posted it with the batch file and PowerShell commands at https://mediumseagreen-seal-177480.hostingersite.com/.

I submit two reports to my directors each month. Both use structured templates, but the updates come from multiple people and sources. Some information is unstructured, such as hallway conversations that are not always captured in email, so I have struggled to get the accuracy I need when using AI to build the reports. I am currently testing CoWork and Copilot Work IQ. These reports used to take me hours, so I am already saving time, but I want to refine the process further. I believe a better way to save and store the source data could improve the final outputs, although I have not worked out the right approach yet. Step-by-step: 1. I collect updates from multiple people and sources for the two monthly reports. 2. I organize the information into the structured templates required by my directors. 3. I use CoWork and Copilot Work IQ to help build the reports. 4. I account for unstructured updates, including information from hallway conversations that may not have been captured in email. 5. I am exploring better ways to save and store the source data so I can improve the accuracy of the reports while continuing to save time.

I created a website lead workflow that researches each company, scores the opportunity, updates my CRM, drafts a personalized reply, and notifies me on WhatsApp. I had previously built similar workflows with Claude Code, but connecting external applications was often the hardest part. I had to manage OAuth setup, credentials, APIs, and different integration requirements for every app. I also found it difficult to monitor and control completed automations from WhatsApp without building additional infrastructure. To solve this, I created Awish, a tool focused on AI-powered automation. Instead of manually designing every workflow, I describe the result I want in chat. Awish’s agents understand the request, plan the automation in the background, determine which applications and steps are required, and prepare the complete workflow for me. When a new lead submits my website form, the workflow researches the company, evaluates the lead against my criteria, assigns a score, and adds the contact and research results to my CRM. It then drafts a personalized response based on the lead’s company and needs before sending me a WhatsApp notification for review. The application connections are handled through a simple sign-in flow. I connect my personal accounts with a click instead of manually working with OAuth code, API keys, or custom authentication logic. Once the workflow is active, I can monitor it, receive updates, and manage its actions directly from WhatsApp without opening the Awish application. Step-by-step: 1. I open the Awish chat and describe the workflow I want: when someone submits my website form, research the company, score the lead, add it to my CRM, draft a personalized response, and notify me on WhatsApp. 2. Awish’s agents analyze the request and create the application and automation plan on my behalf, including the trigger, research steps, lead-scoring logic, CRM fields, response draft, and notification. 3. I review the proposed plan and sign in to the required applications with my personal accounts to connect them to the workflow. 4. Awish builds the automation so each new website submission triggers company research and collects the information needed to evaluate the opportunity. 5. The workflow scores the lead, creates or updates the CRM record, and stores the contact details, company research, and lead score in the appropriate fields. 6. It drafts a personalized response using the information submitted by the lead and the additional company research. 7. I connect WhatsApp from the Awish chat, and the workflow sends me the lead details, score, CRM update, and response draft there. 8. I review and manage the automation directly from WhatsApp without needing to open Awish or build a separate messaging integration. The result is a lead-management workflow I can create through a conversation, connect to my existing applications without manually implementing OAuth, and control from WhatsApp while the agents handle the planning and execution in the background.

I’m a very unsophisticated user—and an older man—so my use of ChatGPT is still fairly basic. But it has changed my life. I use ChatGPT as a research assistant for a book I’m writing. In practice, what I do is not much more than an in-depth search, but ChatGPT has taken me places in this journey that I would have thought impossible just three months ago. We’re now deeply engaged in solid research that will likely last about two years before we reach the writing phase. I’m energized by what we’re doing and wanted to share the experience. I believe AI is going to change the way working historians conduct research. Step-by-step: 1. I use ChatGPT as a research assistant for the book I’m writing. 2. I use it for in-depth searching and research. 3. I continue developing the research with ChatGPT over an expected two-year period before beginning the writing phase. 4. I reflect on how this process is changing my research journey and the way historians may conduct research.

I built an Android mobile app that captures and organizes image photologs. Each photo is automatically saved with its date, time, and GPS location, including a link to Google Maps. I can dictate or type notes about an image, then add to or edit those notes later by typing or dictating. When I finish the notes, I add a tag to the photo. The tag remains persistent until I change it or close the app session. This makes it possible to retrieve all images from a session at a location, event, inspection, or other shared subject—such as a 1957 Ford—within seconds by searching by tag or date. All photos are stored exclusively on the user’s phone. Photos can be shared individually, or an entire set can be exported as a ZIP file. Shared and ZIP images arrive at the recipient’s end with all recorded dates intact. Each ZIP file contains the original raw image, an Excel sheet with one row per image and its date, and a formatted field report with each image and its related date in a single image card. The app works with or without cellular or Wi-Fi service. Step-by-step: 1. I capture an image, and the app automatically records its date, time, and GPS location with a Google Maps link. 2. I dictate or type notes about the image. 3. I add to or edit the notes later by typing or dictating. 4. I add a tag when I finish the notes; the tag remains active until I change it or close the app session. 5. I search for images by tag or date. 6. I share individual photos or export an entire set as a ZIP file containing the original raw images, an Excel date sheet, and a formatted field report.

Most businesses don't need another AI tool. They need to automate the repetitive bottleneck already slowing the team down. A simple example is connecting the tools already in use: Lead → AI qualification → CRM → WhatsApp → follow-up Instead of adding more software, automate the repetitive steps between these tools. The goal isn't more AI; it's less manual work and faster execution. Step-by-step: 1. Identify the repetitive bottleneck slowing the team down. 2. Capture the lead and use AI to qualify it. 3. Send the qualified lead to the CRM. 4. Use WhatsApp for follow-up. 5. Connect the steps so the process requires less manual work and supports faster execution.

Most people remember the predictions they got right and rationalize the ones they got wrong. This workflow forces every meaningful forecast into a structured record so you can measure not only whether you were right, but also whether your confidence was justified. The objective is not simply to make more correct predictions. It is to make your stated confidence increasingly match reality. For every forecast, record the following: Step-by-step: 1. State exactly what you believe will happen. The claim must be specific enough to resolve later. Bad: “AI stocks look vulnerable.” Better: “The Nasdaq-100 will fall at least 15% from its current level within six months.” 2. Assign a numeric probability from 0–100%. Avoid vague terms such as “likely” or “probably” without attaching a percentage. 3. Define when the prediction should resolve, such as within 30 days, by year-end, or within 12 months. 4. Identify the one to three factors most responsible for the forecast being correct. This makes the causal thesis explicit. 5. Specify what evidence would materially weaken or invalidate the forecast. This prevents moving the goalposts later. 6. Define in advance what counts as correct, incorrect, or ambiguous. Do not wait until the outcome is known to decide how success will be measured. 7. Freeze the forecast by preserving the original forecast exactly. If new information materially changes your view, create a new forecast rather than editing the old one. This preserves the forecasting record. 8. At the end of the time horizon, record what actually happened. Then distinguish between a thesis error, in which the underlying reasoning was wrong; a timing error, in which the thesis may have been right but the forecast horizon was wrong; and a driver error, in which the expected outcome occurred but for different reasons. 9. Review calibration by comparing probability bands with actual results over time. If forecasts assigned 70% confidence are correct about 70% of the time, your confidence is well calibrated. If high-confidence forecasts fail too often, you are overconfident. If lower-confidence forecasts succeed too often, you may be underconfident. Do not overinterpret tiny sample sizes; calibration becomes more meaningful as forecasts accumulate. 10. Periodically review error patterns, including overconfidence, underconfidence, timing errors, weak assumptions, ignored counterevidence, wrong key drivers, poor resolution criteria, and repeated mistakes by forecasting domain. Use those patterns to improve future forecasts. Copy-and-paste prompt Act as a forecasting and calibration analyst. Whenever I make a meaningful prediction, create a forecast record using: CLAIM: PROBABILITY: TIME HORIZON: KEY DRIVERS: DISCONFIRMING SIGNALS: RESOLUTION CRITERIA: Make the prediction specific enough to evaluate later. Require a numeric probability and a defined time horizon. Preserve the original forecast exactly. If new information materially changes the forecast, create a new version rather than rewriting the original. When the forecast resolves, add: OUTCOME: RESULT: THESIS ACCURACY: TIMING ACCURACY: DRIVER ACCURACY: WHAT WAS RIGHT: WHAT WAS WRONG: CALIBRATION REVIEW: LESSON: Periodically review resolved forecasts for: Accuracy by probability band Overconfidence Underconfidence Timing errors Repeated bad assumptions Strongest forecasting domains Weakest forecasting domains Never rewrite history to make an old forecast look better. The objective is not to maximize correct predictions. The objective is to make confidence increasingly match reality.

I built a tool that makes it easy to collect feedback and reviews for digital products, meetings, YouTube channels, and physical items. Display a custom QR code on your screen or at your point of sale so people can scan it and leave feedback or a review. Users do not need a Google account to submit their responses. You can filter the feedback and share it on social media to help promote your service or product. The easy-to-use dashboard also provides sharing tools and widgets for websites. Step-by-step: 1. I created a custom QR code for the product, meeting, channel, or item. 2. I displayed the QR code on a screen or at the point of sale. 3. I let people scan the code and submit feedback or a review without needing a Google account. 4. I filtered the collected feedback in the dashboard. 5. I shared the feedback on social media and used the available website widgets and sharing tools.

I created a skill that helps me submit a garment reimbursement every month. It handles the long forms and the upload of thousands of different documents required for the reimbursement. Step-by-step: 1. I created a skill for submitting my garment reimbursement. 2. I use it every month to complete the required long forms. 3. I upload the different types of documents needed for the submission.

As a Lutheran pastor, I created a Claude skill to shorten sermon preparation. It gathers each of the readings for a Sunday, adds a brief commentary, highlights key words from the original languages, and suggests three different outlines for each reading. Step-by-step: 1. I use the Claude skill to gather each of the readings for a Sunday. 2. It adds a brief commentary to the readings. 3. It highlights key words from the original languages. 4. It suggests three different outlines for each reading.

San Diego County is enormous, and its startup scene is growing rapidly. I wanted a better way to see where companies are located, especially because many of them host networking events and there was no central map or repository. I told Claude what I wanted: an alphabetical directory with an industry selector and a way for people to add their own companies. I also asked it to keep the project as simple as possible, use as few tokens as possible, and wait for my approval before taking any action. Claude helped me design the map, create the Google Form for submissions, set up the Google Sheets workflow for hosting and approving companies, and use Netlify to host the main file. It also guided me through linking the map to a page on my own website: https://sdaimap.michelabood.com/. Claude warned me about the legal issues involved in scraping a list wholesale from other sites, so the map is designed to be populated by people submitting their own companies. I just published it, and 10 companies have already been listed, with more on the way. I have also received great comments on LinkedIn. Now I can see at a glance how far I need to go to find a specific company. I also had Claude create a step-by-step guide, which I am happy to share if people want it. Step-by-step: 1. I described the map I wanted to Claude, including an alphabetical directory, an industry selector, and a way for people to add their own companies. 2. I asked Claude to keep the project as simple as possible, use as few tokens as possible, and wait for my approval before taking any action. 3. I used Claude to design the map and create the Google Form for company submissions. 4. I used Google Sheets to host and approve the submitted companies. 5. I followed Claude's guidance to host the main file on Netlify. 6. I linked the map to a page on my own website: https://sdaimap.michelabood.com/. 7. I avoided scraping a wholesale list from other sites because of the legal issues Claude identified. 8. I published the map and began collecting company listings from people directly.

Build a Tiny HTML Research Logger Instead of Fighting a Spreadsheet Turn repeated research measurements into a simple phone-friendly interface instead of making participants wrestle with spreadsheets. Some research data is simple. Collecting it often isn't. Imagine recording pain, energy, mood and a few additional variables several times during a study. A spreadsheet can technically do this. But on a phone? Open the file, find the right row, locate the columns, enter values without accidentally changing something, save and close. That's a ridiculous amount of interface for a tiny measurement. If recording how you feel takes ten seconds mentally but two minutes administratively, the tool has become part of the research burden. So I asked: What is the smallest interface someone actually needs when logging an observation? My answer was a tiny HTML page that works on both phone and desktop. 1. Separate the interface from the dataset Participants shouldn't need to interact with rows, columns or database structures. They should see a few simple fields: Pain, Energy, Mood, Optional Note and Save. Behind the interface, each submission becomes a structured record containing the measurements, a timestamp and any optional context. The researcher gets organised data. The participant gets simple controls. 2. Define the research measures first Before asking AI to build anything, establish what you're measuring. Which variables matter? What does each scale mean? Which values are allowed? Should measurements remain comparable over time? These are research decisions, not interface-design decisions. AI can help implement your measurement system, but shouldn't quietly invent the methodology. 3. Design for repeated use A questionnaire completed once can tolerate some friction. A logger used several times a day cannot. Make controls large enough to tap comfortably. Use readable labels, vertical layouts and obvious actions. Avoid unnecessary navigation, tiny cells and repeated setup. Design for the phone first, then let the interface adapt to larger screens. And test the fifth entry, not just the first. Something that looks elegant during development can become irritating when you're tired, distracted or recording yet another observation. The ideal repeated action is almost boring. That's a compliment. 4. Automate the invisible work Participants shouldn't have to enter information the system already knows. A logger can automatically generate timestamps, record identifiers and technical metadata. Each submission should become one coherent record. Show a clear confirmation when saving succeeds and prevent accidental duplicates. Keep optional notes available without turning every measurement into a diary assignment. Don't make participants do the database's job. 5. Keep the interface neutral A research logger is a measurement instrument. Its colours, labels, ordering and controls shouldn't subtly suggest which answers are desirable. Likewise, the logger doesn't need to interpret someone's measurements or announce that their mood seems lower on Tuesdays. That's analysis, not collection. First gather observations reliably. Interpret them later using appropriate research methods. 6. Decide where the data lives A single HTML file can provide the interface without requiring a full application. But HTML alone doesn't provide persistent storage or synchronisation. Browser storage may work for a local prototype, although it has limitations. For research involving several devices, participants or longer periods, you'll need suitable storage and export options. A phone and laptop displaying the same interface don't automatically share observations. Keep the dataset consistent and exportable, for example as CSV. For sensitive information, include appropriate privacy and security safeguards. 7. Build only what's necessary It's tempting to expand a tiny logger into an entire platform. Dashboards! Charts! Profiles! Notifications! Accounts! Perhaps later. Start with Open → Measure → Save. Test the process repeatedly on phone and desktop. Improve whatever causes genuine friction. You can enlarge buttons or rearrange the layout without changing the study. But changing a measurement scale is a research-design decision, not a cosmetic update. The workflow Define the variables and scales → ask AI to build a responsive HTML logger → add automatic timestamps and structured records → choose suitable storage and export methods → test repeated logging → refine usability without changing the measurements. Why this works A spreadsheet is excellent at displaying a dataset. That doesn't make it the best place to create one. Researchers think in variables, records and analysis. Participants simply need to answer the question in front of them. Those shouldn't have to be the same interface. Sometimes the best research tool isn't a sophisticated platform. It's a tiny page that gets the spreadsheet out of the participant's way.

I wanted to see what Awish would automate first if I gave it a real client business instead of a predefined workflow. I used Martolia Marble, one of my previous clients, and gave Awish the website. I asked it to analyze the business, suggest automations that could support growth, and build them only after I approved them. Awish analyzed the website and proposed several opportunities. I chose two: a lead generation and email outreach workflow, and an Instagram workflow that tracks relevant trends, plans content, creates posts, and publishes them. Step-by-step: 1. I gave Awish the Martolia Marble website and asked it to analyze the business. 2. Awish identified areas where automation could support growth and suggested workflows. 3. I approved a lead generation workflow that finds relevant prospects and prepares personalized email outreach. 4. Awish selected the required apps, I connected the accounts, and the agents built the workflow. 5. I also approved an Instagram workflow that analyzes relevant trends, plans upcoming content, creates the posts, and publishes them. 6. Once the accounts were connected, both automations were ready to run without me manually building each step. What I liked most was starting with the business rather than with an automation idea. I gave Awish the website, reviewed its suggestions, and approved only the workflows that made sense for the client.

I configured Claude to review my calendar every two weeks for scheduled VIP meetings. 1. I configured Claude to review the calendar biweekly. 2. I set it to identify scheduled VIP meetings.

I conducted a workflow experiment with Awish, the product I built, and the results surprised me. I think this approach could be useful for anyone who wants to automate more of their business but is not sure where to start. I gave Awish my website, and it identified the automations my business was missing. The difficult part was not always building a workflow; it was figuring out which tasks were worth automating first. I opened Awish and asked: “Analyze my business from awish.ai, suggest automations that could improve how I work, and only build them after I approve.” Awish’s agents analyzed the website to understand what the business does, how customers interact with it, and where repetitive work could be automated. Instead of asking me to design a workflow from scratch, Awish suggested several automations based on the business. One suggestion was a lead workflow that finds relevant prospects and automatically prepares and sends personalized outreach emails. Another was a website inquiry workflow that analyzes new customer requests, identifies what they need, and sends me the important details as a WhatsApp notification. It also suggested a content workflow that creates and publishes posts for Instagram, X, and LinkedIn based on the business and its content strategy. I chose the lead generation and automated email workflow. Step-by-step: 1. I opened the Awish chat and asked it to analyze my business from awish.ai, suggest automations that could improve it, and only build something after I approved it. 2. Awish’s agents analyzed the website and identified repetitive sales, customer communication, and content tasks that could be automated. 3. Awish suggested a lead generation and email outreach workflow, a website inquiry analysis and WhatsApp notification workflow, and a social content workflow for Instagram, X, and LinkedIn. 4. I selected the lead generation and automated email workflow. 5. Awish’s agents understood the request and created the workflow plan, including how leads should be found, what information should be collected, and how personalized outreach should be prepared. 6. Awish selected the applications needed for the workflow and showed me the connections before anything was built. 7. I approved the plan and connected my personal accounts to the required applications through the sign-in flow instead of manually setting up each integration. 8. Awish built the automation within minutes, so new leads could be identified, researched, and contacted through the workflow without me having to design each step manually. What I like about this approach is that I do not need to know the exact automation I want before I start. I can begin with the business itself, let the agents identify useful opportunities, choose the one that makes sense to me, and then approve the build.

I built an Opportunity Intelligence app with Claude Code for our sales team. Team members select the state and industry they want to target, and the app pulls live signals, such as whether a company is hiring for a specific role or opening a new facility, among others. The app then produces a top 10 list for further research, including a company overview, how our products work within that organization, battlecards, a custom LinkedIn introduction message, and a custom email message. From there, the team can research specific people at each organization. The app produces a top 10 list of targets with their LinkedIn profiles, phone numbers, and email addresses. Step-by-step: 1. I built an Opportunity Intelligence app with Claude Code for our sales team. 2. Team members select the state and industry they want to target. 3. The app pulls live signals, including whether companies are hiring for specific roles or opening new facilities. 4. The app generates a top 10 list of companies to research, with a company overview, how our products work within each organization, battlecards, a custom LinkedIn introduction message, and a custom email message. 5. Team members use that information to research specific people at each organization. 6. The app generates a top 10 list of targets with their LinkedIn profiles, phone numbers, and email addresses.

Most days, I want one capable general AI agent. The failure mode appears with higher-stakes questions in security, finance, law, or medicine: my main chat is already full of project context, the agent may answer confidently outside its depth, and a “specialist” prompt in the same thread still inherits the assumptions and tools that session has already loaded. I set up Hermes Agent with a consultation workflow that cold-starts an isolated specialist profile for a one-shot answer. I keep four advisors ready: security, financial, legal, and medical. Each call starts a separate process with its own model, tools, and skills. The specialist has no access to my parent conversation, so I have to write a self-contained prompt. It takes anywhere from a few seconds to a couple of minutes—not instantly—which is fine because I only use it when the stakes justify the wait. The gate is the part I care about most. Nothing runs until I explicitly name the profile, approve the exact prompt, and confirm. There is no silent auto-routing. When I want a second opinion, I draft my own take first, send the same question to the specialist, and compare where we agree and differ. This keeps the general agent honest and prevents specialty advice from becoming the default for routine work. I also keep the scope tight. I limit the medical profile to personal or educational questions, or fully de-identified material—not identifiable patient care. Routine work that my main agent already handles well never goes through consultation. I reserve the specialist profiles for deliberate second opinions or questions I do not want the default session answering alone. Step-by-step: 1. I work through the problem in my main Hermes session and write my own answer first when I want a second opinion. 2. If the question is high-stakes in security, finance, law, or medicine—or I simply want a deliberate second look—I choose the specialist profile to use. 3. I write a self-contained prompt with every fact and constraint the specialist needs because it cannot see the parent chat. 4. I name the profile, approve the prompt, and confirm before anything runs. 5. I let Hermes cold-start that profile as a separate process and return a one-shot answer. 6. I compare my draft with the specialist’s response: where we agree, where we differ, and what still needs a human professional. 7. I skip consultation for routine work and keep medical use limited to personal, educational, or de-identified material.

I built an AI meeting-intelligence workflow that turns my meetings, emails, chats, and handwritten notes into one living action tracker. Every action stays linked to its original source, and the workflow automatically generates a prep sheet for each meeting. Two problems drove me to build it. First, provenance: action lists are often disconnected from their sources. A line such as “follow up with vendor on pricing” is much less useful when I can’t open the Teams message or email it came from to review the details or reply. The context disappears as soon as the action is recorded. Second, I take most of my notes by hand because I think better on paper. Those notes used to be a dead end: they never entered any system, so the follow-ups disappeared. The workflow runs on a morning schedule or on demand before a meeting. I use Claude in Cowork with MCP connectors for email, chat, and calendar. It pulls recent messages and upcoming meetings while capturing the deep link or ID for each source item, so every action can be traced back to the exact email or Teams thread. For handwritten notes, I photograph the pages into a OneDrive folder and tag them. The workflow uses OCR and vision to extract the text and action items. Quick shorthand tags—`action`, `prep`, and `done`—on messages and photos tell it what to track or close. A Python layer then deduplicates the actions, assigns each one a stable ID, applies the tags, and updates the master tracker while preserving the source links. The result is one self-maintaining action list. I can click any item to return to its original artifact to reference the details or reply, and my paper notes finally flow into the same system. To recreate it, connect an AI assistant to your mail, chat, and calendar through MCP and store each source link with its action. Add a OneDrive photo drop with OCR for handwritten notes, use a simple tag vocabulary, and separate the responsibilities: let the AI handle capture and OCR, while plain code handles deduplication, IDs, and status updates. Step-by-step: 1. I scheduled the workflow to run each morning and added an option to run it on demand before a meeting. 2. I connected Claude in Cowork to my email, chat, and calendar through MCP so it could gather recent messages and upcoming meetings. 3. I captured the deep link or ID for every source item, allowing each action to trace back to the exact email or Teams thread. 4. I photographed handwritten notes into a tagged OneDrive folder and used OCR and vision to extract their text and action items. 5. I used the shorthand tags `action`, `prep`, and `done` on messages and photos to indicate what to track or close. 6. I used a Python layer to deduplicate actions, assign stable IDs, apply tags, and update the master tracker without removing source links. 7. I used the resulting tracker to return to the original artifact for each action and to bring paper-note follow-ups into the same system.