An automation earns its place when the time it saves exceeds the time you spend fixing it. Keep the tested steps in one skill, run it when the result is useful, and require a report that shows what happened. Austin Marchese demonstrates the approach with a daily brief that reads messages and emails him a summary.
01Prove one complete run
Test every required step before polishing the output. For a daily brief, that means reading the intended accounts, producing a summary, and delivering it to the intended destination. Verify the delivered result yourself. Claude saying a tool exists does not establish that your account can use it.
Keep the first test small. One missing connection can block the whole workflow; discover that before spending an afternoon on the wording. Automate the step that slows you down covers choosing which recurring task deserves this work.
02Save the steps that worked
A skill is a saved set of instructions. After a successful test, ask Claude to capture the working steps, required connections, output format, and known failure conditions. Have the scheduled task run that skill. Later edits then have one place to live.
Run the skill in a fresh session. Any requirement you have to explain again belongs in the saved instructions. Turn repeated fixes into rules covers saving those corrections for later runs.
The scheduled run must be able to find the skill. Local Claude Code tasks can read local skills. Cloud sessions use skills enabled for your Claude account or project skills committed to the repository they clone. Editing a personal file on your laptop does not update that remote copy. Check the location before relying on the next run. Anthropic’s skills documentation explains which sources each session reads.
03Schedule for when you need it
Send the brief when you will act on it. If mornings are crowded, an evening brief may be more useful. Pick the lowest frequency that still meets the need; each extra run adds usage and another result to review.
| Run location | What to check |
|---|---|
| Local Desktop task | Your computer must be awake and the app open. It can use your local files and tools. |
| Cloud routine | It can run while your computer is off. Test its access to skills, files, and connectors separately. |
Desktop may start one catch-up run after a missed schedule. If a late brief would be misleading, state the permitted time range and what to do outside it. These are the current distinctions in Anthropic’s scheduling documentation.
Use the scheduled task’s Run now control to test the actual setup. A successful interactive chat cannot prove that an unattended run has everything it needs.
04Improve one part at a time
Once the saved task works, choose the change that would make its result more useful. Marchese separates the choices into four kinds:
| Change | Example for a daily brief |
|---|---|
| Refine the selection | Include messages that require a decision; omit routine notices. |
| Add a source | Include calendar events after testing calendar access. |
| Change the format | Use an HTML file when the brief needs a table you can scan. |
| Add checks | Stop when a required connection is missing. |
Test the change, then update the skill. When several automations repeat the same delivery step, move that step into a shared skill they all reference. Fixing the shared step applies the correction to every automation that uses it. Retest those automations after changing the shared step.
05Define when to stop
Check required connections before doing the expensive work. If a source is unavailable, stop and report which source failed. An empty inbox and an inbox you could not read must produce different reports.
Give retry loops a limit and a check they must pass. Loop the agent until the work passes explains the verification step. A useful extension is to stop before repeating a delivery whose outcome is uncertain: a timeout may arrive after the service has already sent the message.
This original prompt applies those rules to a brief. Choose the retry limit for your task; the number below is an example.
Before building the brief, check access to every required source. If access fails, stop and name the source, the failed step, and the action needed from me. Do not report inaccessible data as empty.
Allow at most two retries for a failed read. Stop earlier if the error requires a permission change. If delivery returns an uncertain result, check whether the message was sent before retrying; if you cannot tell, stop and flag it for review.
Finish with the accounts and time range checked, items read per source, missing data, and the output location. Use measured counts. Say when a total is unknown.
06Make missing work visible
Send reports to one place you already check. Each report should identify the work performed and anything skipped. Marchese’s example includes counts for emails, Slack messages, and calendar events, so unexpectedly small results are easier to notice.
“the effort to maintain the system is the most important variable.”
Austin Marchese, “The Easiest Way to Automate Your Life With Claude” · 6:18Counts help you spot omissions; inspect the underlying run when they look wrong. Anthropic documents that a green routine status can mean the session ran without a system error even though the task failed. Check the result and the run record before trusting it.
Review whether you still use the output. Pause automations whose reports go unread or whose maintenance costs more time than they save.