Workflow Hub

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

Every day, we feature the community's top-voted AI workflow in The Rundown newsletter.

Automate a Weekly Workout Log with Claude and Hevy

Every Friday at 10 a.m. ET, a scheduled Claude agent refreshes a living "Hevy Workout Log" document with that week's strength-training data, body measurements, and a progress photo. The automation runs fully unattended, with no human in the loop after the owner sets it up. The agent pulls information from three independent systems: the Hevy fitness-tracking API, a Google Drive photo folder, and the living document. It reconciles those sources against a date range, determines what's new versus already recorded, and writes structured, formatted updates in the correct places. This requires more judgment than a simple script or webhook. The scheduled task starts a fresh agent session every Friday at 10 a.m. ET with the full task specification and API key included in the prompt. The Hevy API is the source of truth for workouts from `GET /v1/workouts` and body measurements from `GET /v1/body_measurements`; both endpoints are paginated. Google Drive holds the "Progress Pics" folder, which the agent searches by file timestamp. Claude Docs, through a Claude Artifact, is the living document: it has one tab for each weekday and a Weekly Summary tab, and the agent edits it in place with structured operations rather than full rewrites. To embed a photo, the agent downloads the Drive file locally, uploads it to the Claude Artifact asset store, converts it to a document-native blob, and references it as a Markdown image. There is no custom backend, database, or glue code. The agent calls each system's API directly and keeps the orchestration logic in its reasoning for that run. Step-by-step: 1. Read the document's current state and find the most recent week already recorded in the Weekly Summary tab. 2. Call the Hevy API and determine which Monday–Friday week has just ended, making sure today's date is past that week's Friday. 3. Check whether that week's row is already in the Weekly Summary table, fully populated, and contains the latest matching photo. If everything is already recorded, there may be nothing to update, but the agent still checks for a newer photo that may have appeared in Drive after the data was written. 4. Pull per-set details for every workout that week, including the exercise, weight, and reps. Compute total daily lifted volume by summing weight × reps for each set on each day. 5. Search the Google Drive photos folder for images timestamped within that Monday–Sunday window. Select the single most recent image, replacing any older photo already embedded for that week. 6. Pull body measurements from the same week and calculate weekly averages for weight and body fat, along with the week's waist reading. Convert units as needed from kilograms to pounds and centimeters to inches. 7. Update the Weekly Summary tab with one row per week, including daily volumes, weekly averages, and the progress photo. 8. Update each weekday tab with a dated section containing the workout name, a per-exercise set-by-set table, and a Total row for summed volume and reps. If no workout was logged, add a note instead. 9. Send the human a plain-language summary every time, describing what changed or confirming that nothing changed, because nobody is watching the scheduled run live. The workflow is idempotent without a database. There is no job-tracking table; on each run, the agent reads the live document, compares dates, and checks whether cells are filled before deciding what to write. Progress photos are not tagged by week, so the agent matches them only by whether their Drive timestamp falls within the Monday–Sunday window. It explicitly selects the most recent match, allowing a better photo taken later in the week to replace an earlier embedded photo. The workflow also handles the multi-hop process required to embed an image in a live document: Drive file to local download, artifact asset upload, document-native blob conversion, and Markdown image reference. If the Hevy API key is revoked, the task stops cleanly and tells the owner to generate a new key and provide it, rather than failing silently or looping. Because the workflow runs on a schedule without anyone watching, its specification requires a notification every time, including when nothing changed. This keeps the automation auditable even when it performs no updates.

Bridget Overson 3D AGO

Govern AI-Built Prototypes Before Adding Features

Let AI build your prototype, but don’t let your prototype own you. A working preview makes it tempting to keep asking for features. But the first screen tells you little about who controls the database, how the application is structured, or what the next prompt might change. I developed this workflow by putting my best-practices guides to work on a client project, then separating the reusable process from that project’s architecture. This workflow is for AI app-building platforms, often called vibe-coding platforms, where you describe an application and the platform generates and runs a working prototype. It focuses on keeping control of the code, repository, backend, and platform connections. It is not a general guide to coding agents or AI-assisted editors. Anyone who has watched a code generator slowly degrade a clean codebase knows why the starting conditions matter. Before asking for features, establish what you own, what the tool may change, and how you will check its work. Step-by-step: 1. Set ownership before the first build prompt. Decide what the application needs and who controls it. If it needs a new database or backend, provision it in an account you control before asking the builder to create the app. An existing API is another option, not a requirement; some prototypes need neither. Confirm the repository destination, integration permissions, and recovery access. Keep production behind a reviewed release process. 2. Give each tool readable rules. Establish one authoritative set of architecture, coding, and design standards. Identify which files each tool may change and which it may only read. Naming a rules file in a prompt does nothing if the tool cannot access it. Assign responsibility for data, authentication, application logic, deployment, and recovery. One person can hold several roles, but a UI task does not grant permission to redesign the backend. 3. Build the framework before the features. Use the opening prompt to establish the framework, runtime, routes, layout, and state ownership. Ask for empty page shells first. Check that navigation uses real routes and that shared elements have a defined home. Keep design values in one designated place. Any temporary authentication placeholder must be clearly labeled and isolated from protected data. Real users require real authentication and authorization. 4. Inspect and preserve the foundation. Read the generated files and inspect the running scaffold. Check for unrequested services, dependencies, and structural changes. A green build alone does not tell you whether the tool followed your instructions. Once accepted, protect the foundation files from routine UI prompts. Record the accepted commit and preserve a recovery copy beyond the integration’s ability to modify or delete. 5. Set up a prompt factory. A prompt factory is an assistant configured to turn a plain-language request into a bounded implementation prompt. Give it the project rules, file map, technical references, and current capabilities. It checks whether the requested behavior is supported before producing instructions. If something is missing, it prepares a prerequisite request for the responsible owner instead of inventing data or behavior to make the screen look finished. Each prompt names the tool, permitted files, protected files, applicable standards, relevant data and interfaces, exact change, what must be preserved, and observable checks. The factory prepares instructions; it does not approve architecture or release changes. 6. Build one governed feature. Where data is involved, establish correct data behavior first. Follow with a separate placement and styling task. Inspect the changes and test the affected behavior. Apply the One Fix Rule: one repair prompt, one attempt. If it fails, the generator is done with that file. Move the repair to manual maintenance rather than feeding another round of guesses into the codebase. After acceptance, save the next recovery point and update the working rules. Preserve the reason behind each rule so a later cleanup does not remove the safeguard. The point is to make the next feature less likely to undo the work you already accepted. Your database, where needed. Your code. Your standards. You control the tether. Part 2 will cover cutover: leaving the development platform with a controlled release, verification, and a recovery plan.

Henry Alfano 2H AGO