# HOW TO AUTOMATE YOUR LIFE (full course):
**作者**: hoeem
**日期**: 2026-03-26T20:08:23.000Z
**来源**: [https://x.com/hooeem/status/2044796878446002227](https://x.com/hooeem/status/2044796878446002227)
---
“Delegation is buying back your highest value hours with someone else's lower cost ones. Automation is building back your highest value hours with a machine's lower cost ones.” - Alex Hormozi
welcome to the complete guide to claude routines.
> who this is for: anyone. whether you've never written a line of code in your life, or you're a developer who just wants to know what claude routines can actually do... this guide takes you from zero to running personalised automations. no server required. no workflow builder required. no degree required.
## table of contents
what are claude routines?
how routines actually think and work
the three ways to trigger a routine
step-by-step setup guide
writing prompts that don't fail
the skills architecture: your secret weapon
use case library: ideas by persona
building compounding memory
connectors and integrations
debugging when runs fail
security and permissions
limits, quotas and planning
the discovery framework: let claude design your routines
## 1. what are claude routines?
the simple version
write a task. hand it to claude. it runs itself every day on its own server, without your laptop open, without you paying for hosting, without you checking in.
that's it. that's the whole pitch.
the problem they solve
before routines existed, automating an AI-powered task meant choosing between bad options:
routines eliminate every single one of those constraints.
runs on anthropic's cloud. included with your subscription. brings full claude intelligence to every automated run.
claude routines can reason through problems. it notices when something is missing. it tries alternative approaches. it catches its own mistakes. it decides what to do next.
this is the difference between a robot that follows a script and an agent that actually thinks.
## 2. how routines actually think and work
the execution cycle
this is the most important thing to understand before you set anything up. every single run follows this cycle:
every run is stateless. the container starts from zero and ends at zero.
the only things that survive a run are what claude writes back to your github repo, or sends via a connector like slack or email.
what this means for you
the good news:
- no server to maintain
- no environment drift over time
- runs are clean and reproducible
- you never pay for idle compute
the things to design around:
- any "memory" between runs must be stored in the github repo
- local files on your computer don't exist from the routine's perspective
- API keys must be passed as environment variables, not as .env files (those are git-ignored and never get cloned)
the agentic capability inside each run
during a run, claude has its full intelligence:
- workflows: step-by-step processes it can execute
- agents: sub-tasks it can delegate to itself
- tools: actions it can take (read a file, call an API, write output, use connectors)
one routine can fetch data from five different APIs, compare the results, make a decision, write a report, and post a summary to slack. all in one run. no human in the loop.
the autonomy trade-off
routines run fully autonomous, acting as you, with no ability to pause and ask for permission.
this is intentional. a routine that stops and waits for your input is no better than doing it yourself.
the implication: your prompt must be complete and unambiguous. claude cannot ask you to clarify. vague instructions get vague results. this is why section 5 on prompt writing is the most important section in this guide.
## 3. the three ways to trigger a routine
you can stack multiple trigger types on a single routine. most people start with schedules, then add API triggers as they get more advanced.
trigger 1: schedules
set a routine to run at regular intervals using plain english or cron syntax.
examples:
- every weekday at 7:00 am
- every monday at 9:00 am
- every day at midnight
- 0 9 * * 1-5 (cron syntax for weekdays at 9 am)
the key constraint: minimum interval is one hour. you can't run a routine every 5 minutes.
best for: daily digests, weekly reports, morning briefings, recurring data pulls, scheduled content generation.
one thing most people miss: anthropic's infrastructure runs in UTC by default. if you want your report ready at 7 am london time, account for that when setting the schedule.
trigger 2: API calls
every routine automatically generates a dedicated HTTP endpoint and a bearer token. any external system can trigger your routine by sending a POST request to that URL.
what this unlocks:
- a new sale in your CRM triggers a routine that drafts a personalised onboarding email
- a deployment completes, triggering a routine that writes release notes
- a form submission triggers a routine that researches and drafts a response
- a webhook from stripe, shopify, typeform... whatever you use, it fires your routine
passing context: you can include a text payload in the POST request. claude appends it to the prompt as additional context, so you can send dynamic information (customer name, order details, a question) at trigger time.
best for: event-driven automations, connecting claude to services that support webhooks, building lightweight pipelines without a dedicated backend.
trigger 3: github events
routines can fire automatically in response to activity in a github repository, but only after you install the claude github app on that repo first.
supported events:
- new pull request opened
- code pushed to a branch
- new issue created
- PR review requested
- issue comment added
what this unlocks:
- every PR automatically gets a code review from claude
- every new issue gets a response suggesting related docs or solutions
- every push triggers a routine that updates a changelog or checks for breaking changes
- a new issue labelled bug triggers a routine that attempts to reproduce and diagnose it
installation note: install the claude github app via your repository settings first. once installed, select which events fire which routines directly from the claude routines UI.
best for: developer workflows, open source project management, automated code quality checks, documentation maintenance.
## 4. step-by-step setup guide
where to set up routines
you can create routines via the CLI using /schedule, but the recommended path for most people is the visual interface:
claude.ai/code/routines or via the claude desktop app
claude desktop app: click "new task" then "new remote task." note: "new local task" creates a different thing, a local scheduled task that runs on your machine, not in the cloud.
CLI via /schedule: useful for quick scheduled routines, but with one important limitation: the /schedule command can only create scheduled triggers. if you want to add an API trigger or a github event trigger, you must do that via the web UI afterward. you can manage existing routines with /schedule list, /schedule update, and /schedule run.
step 1: write your prompt
this is the most important step. your prompt is the complete brief for what claude does on every single run.
because claude cannot ask clarifying questions during a run, your prompt must be a self-contained, one-shot instruction.
more on writing great prompts in section 5. for now, know this: the best approach for complex routines is a short "launcher prompt" in the UI that tells claude to run a specific skill file from the repo.
like this:
> "run the daily-analytics-report skill located at /skills/daily-analytics-report.md. read all API keys from environment variables, not from any .env file."
everything detailed lives in the skill file. the prompt stays clean.
step 2: connect a github repository
you must connect a github repository. this is where claude will:
- clone the files it needs (skills, templates, reference documents)
- write and commit its outputs
- store memory files between runs
choosing the right repo:
- use a dedicated, lean repository for your routines: not a giant monorepo
- claude reads the entire repo's file structure on every run; a massive repo wastes your context window
- keep skill files, output folders, and memory folders clearly named and organised
what to include in your repo:
critical: any files claude needs must be committed to the repo. files that only exist on your local machine do not exist in the cloud container.
step 3: configure cloud environment variables
your .env file is git-ignored (and should be). claude in the cloud cannot read it.
instead, you pass API keys via the cloud environment section in the routines UI. each key-value pair you add here gets injected into the container as an environment variable at runtime.
how to set this up:
in the routine editor, find "cloud environment" or "environment variables"
add each key-value pair (e.g., OPENAI_API_KEY → sk-..., SLACK_TOKEN → xoxb-...)
in your prompt or skill file, explicitly instruct claude: "read all API keys from environment variables, not from any .env file"
why the explicit instruction matters: claude's default behaviour when looking for credentials is to check for a .env file first. skip the instruction and it looks for a .env file that doesn't exist, and fails the run silently.
step 4: set network access
routines run on "trusted" network access by default. this means claude can only reach anthropic-vetted domains.
if your routine needs to access a custom domain, a niche API, or scrape a specific website, change the network setting:
step 5: manage connectors
when you create a routine, all of your connected MCP connectors are included by default. the job here is to remove the ones the routine doesn't need and not to add them.
a routine that writes a daily report has no business touching your gmail or linear connector. every connector you leave attached is another surface area for accidental actions.
go through the connectors list and remove anything the routine won't use. if you need to add a connector that isn't connected yet, you can do that from settings > connectors on claude.ai.
step 6: understand branch permissions
by default, claude can only push to branches prefixed with claude/. this is a safety guardrail. it prevents routines from accidentally modifying your main, develop, or any other protected branch.
if your routine needs to push to other branches (e.g. a PR routine that needs to push to a feature branch), you can enable "allow unrestricted branch pushes" for that specific repository in the routine's settings.
start with the default restriction in place until you understand exactly what your routine is writing and where.
step 7: test before scheduling
before you rely on a scheduled trigger, always hit "run now" and watch the execution logs in real time.
look for:
- ✅ claude finding the right skill files
- ✅ API keys loading from environment variables
- ✅ claude completing all steps and writing outputs
- ❌ "file not found" errors: skills not committed to repo
- ❌ "credentials not found" errors: env variables not set, or wrong variable name
- ❌ "network blocked" errors: need to switch to full or custom network
- ❌ partial completion: prompt too vague; claude ran out of context
a routine that fails silently every day is worse than no routine at all. fix issues before enabling the schedule.
## 5. writing prompts that don't fail
this is where most people go wrong. routines are only as reliable as the prompt driving them.
write for a smart colleague who just started
imagine briefing a brilliant but brand-new colleague. they know nothing about your context, your preferences, or your tools. they will do exactly what you say, no more, no less. they will not improvise and they will not assume.
that's how you write for claude routines.
the anatomy of a reliable routine prompt
a good routine prompt has six components.
1. role and context
tell claude who it is and what world it's operating in.
> "you are an analytics assistant for a DeFi content creator. you have access to the coingecko API and a github repository containing previous daily reports."
2. the specific task
one clear, unambiguous objective.
> "your task is to generate the daily market briefing for the top 10 DeFi tokens by TVL."
3. data sources and where to find them
be explicit about where information comes from.
> "fetch TVL data from the coingecko API. read the API key from the environment variable COINGECKO_API_KEY. do not look for a .env file."
4. step-by-step process
if the task has multiple steps, list them in order.
> "1. fetch the top 10 DeFi tokens by TVL. 2. for each token, retrieve the 24-hour price change. 3. compare to yesterday's figures in /memory/yesterday-tvl.json. 4. write the report to /outputs/reports/YYYY-MM-DD-briefing.md. 5. update /memory/yesterday-tvl.json with today's figures."
5. output format
define exactly what the output should look like.
> "format the report as a markdown file with: a one-paragraph summary at the top, a table of all 10 tokens, and a section titled 'notable movements' for any token with >5% TVL change."
6. failure instructions
tell claude what to do if something goes wrong.
> "if any API call fails, log the error to /outputs/errors/YYYY-MM-DD-error.md and send a slack message to #alerts with the error details."
btw, if you copy and paste the above into claude and then explain you want to create a prompt that follows the above instructions alongside the prompt (tagged below in this article) then you can make them perfect every time...
common mistakes and how to fix them:
the launcher prompt pattern (recommended)
for anything complex, use a short launcher prompt that delegates to a skill file:
this keeps your UI prompt minimal and maintainable. all the complexity lives in the versioned skill file.
## 6. the skills architecture: your secret weapon
a "skill" in claude routines is a markdown (.md) file stored in your github repository that contains detailed instructions for a specific task.
think of it as a standard operating procedure (SOP) that claude follows every time it runs that task.
why skills beat long prompts
anatomy of a good skill file
here is a template you can adapt and use immediately:
CLAUDE.md: your global instructions file
CLAUDE.md lives at the root of your repository. claude reads it at the start of every run. use it for:
- tone and voice guidelines: your brand voice, preferred writing style
- global rules: "always use british english", "never suggest irreversible actions without confirmation"
- repo structure orientation: where to find skills, outputs, memory files
- standing context: who you are, what your project is, your audience
here's a starter template:
## 7. use case library: ideas by persona
most people get stuck here. not because they lack tasks worth automating, but because they're too close to their own work to see the patterns.
here is a library of ideas organised by who you are. use these as a starting point, then personalise.
content creators and solopreneurs
crypto and DeFi researchers
developers and engineers
healthcare and regulated professionals
small business owners
students and researchers
## 8. building compounding memory
this is the most underused feature in claude routines.
most people build routines that snapshot the present. the real power is building routines that learn from the past.
because the github repo persists between runs, anything claude writes to the repo can be read by the next run. this turns a series of isolated snapshots into a living intelligence system.
pattern 1: delta tracking (yesterday vs today)
claude writes the current state to a memory file at the end of each run. the next run reads that file first, computes the difference, and reports only what changed.
example structure:
in your skill:
> "before generating the report, read /memory/tvl-snapshot.json. calculate the percentage change for each protocol since the last run. after generating the report, overwrite /memory/tvl-snapshot.json with today's figures."
best for: portfolio trackers, engagement metrics, any data where change matters more than absolute value.
pattern 2: cumulative log (building a history)
each run appends a new entry to a log file rather than overwriting it. over time, this builds a rich historical dataset.
example structure:
in your skill:
> "read the existing /memory/weekly-metrics-log.json. append today's metrics as a new entry. do not overwrite previous entries. save the updated file."
best for: trend analysis, pattern recognition over time, showing growth.
pattern 3: rolling context window (last N runs)
keep only the last N entries. each run reads the recent history, uses it as context, then adds today's entry and drops the oldest one.
in your skill:
> "read /memory/last-7-days.json. use the last 7 days as context. add today's entry. remove the oldest entry if there are more than 7. save the updated file."
best for: content briefs (avoid repeating topics), sentiment analysis, streak tracking.
what to store in memory files:
good candidates:
- daily metrics snapshots (numbers, percentages, counts)
- topics already covered (to avoid repetition)
- recent output summaries
- baseline states (for delta comparison)
- accumulated lists (curated swipe file, flagged items)
avoid storing:
- full content of previous reports: store file paths instead
- real-time data: memory files are only as fresh as the last run
- credentials or API keys: never store in the repo
## 9. connectors and integrations
connectors let claude interact with third-party services without you needing to handle API authentication manually.
available connector types
communication:
- slack: post messages, read channels, create threads
- gmail: draft, send, or read emails
- microsoft teams: post to channels
productivity:
- notion: create or update pages and databases
- clickup: create tasks, update statuses
- asana: manage projects and tasks
- google calendar: create or read events
data and files:
- google drive: read or write files
- github: commit files, manage issues and PRs
- airtable: read and write records
connector best practices
scope your connectors tightly. if a routine writes to slack but reads nothing from gmail, don't attach the gmail connector. extra connectors add initialisation overhead and increase the blast radius if claude makes a mistake.
use specific channels and destinations. don't tell claude to "post to slack." tell it to post to #daily-reports. don't tell it to "send an email." give it an exact address.
test connector permissions before relying on them. run the routine manually and watch for authentication errors. a connector that appears connected in the UI can still fail if the OAuth token has expired.
create dedicated channels for routine outputs. a #claude-routines slack channel keeps all automated outputs in one place, not polluting your main channels.
for sensitive integrations, start in read-only mode. build your routine to draft and write to a file first. manually review for at least a week before adding send permissions.
## 10. debugging when runs fail
runs will fail sometimes. here is how to systematically diagnose and fix them.
the failure diagnostic tree:
common errors and fixes:
adding self-reporting to every routine
the best way to avoid debugging is making your routines tell you when something breaks. add this to every skill file:
you get a slack ping when something breaks, rather than discovering the failure three days later.
## 11. security and permissions
autonomous agents with access to your APIs, inboxes, and accounts require taking security seriously. these are not optional practices.
API key hygiene
do this:
- use dedicated API keys for claude routines. not your personal development keys
- give each key the minimum permissions needed (read-only where possible)
- rotate keys regularly
- use environment variables in the routines UI. never hardcode keys in skill files or CLAUDE.md
- monitor API usage dashboards for anomalous activity
never do this:
- commit API keys to your github repo
- reuse the same key across multiple routines
- give broad admin/write permissions when read-only is sufficient
- store keys in memory files that get committed to the repo
scope creep and blast radius
claude routines run as you, with your permissions, autonomously. the blast radius of a mistake is limited only by what you've given claude access to.
minimise blast radius by:
- attaching only the connectors each routine actually needs
- using dedicated slack channels for outputs rather than posting to #general
- starting new routines in write-to-file-only mode, then adding send/post permissions after a manual review period
- for email or calendar routines, use a "draft" mode first and review before enabling "send"
the github repository as a security boundary
your repo is cloned on every run. be clear about what lives there:
- ✅ skill files, templates, output files, memory files. fine
- ✅ non-sensitive configuration (column names, preference settings). fine
- ❌ API keys, tokens, passwords. never (use env variables)
- ❌ personal data or sensitive client information. avoid it
- ❌ executable scripts that run on import. be cautious
make your repo private. there is no reason a routines repo should be public.
reviewing "god mode" actions before enabling them
some connector actions are reversible (posting to slack, writing a file, creating a draft email). others are not (sending an email, deleting a record, making a financial transaction).
for irreversible actions:
build and test the routine in write-to-file mode first
manually review outputs for at least a week
only add send/delete/execute permissions after you trust the output quality
add an explicit instruction in the skill: "if the output does not meet the quality criteria in the template, write to file but do NOT send. post to #claude-alerts that manual review is needed."
## 12. limits, quotas and planning
daily run caps
two things worth knowing here:
first, routines belong to your individual claude.ai account. they are not shared with teammates, each person on a team plan has their own 25-run daily allowance, and routines they create run under their own account identity.
second, if you hit the daily cap or your subscription usage limit, anthropic offers extra usage for organisations that need it, this runs continue on metered overage rather than hard-stopping. enable it from settings > billing on claude.ai.
hardware per run
anthropic has not published specific hardware specs for routine containers in the research preview documentation. what is confirmed: each run executes in an isolated cloud container with enough compute for the vast majority of automation tasks, API calls, data processing, file writes, report generation.
if you're planning to run genuinely heavy computation or process very large files, test first with the "run now" button and watch for timeout or memory errors.
token limits
routines draw from your standard claude subscription token quota. there is no separate pool.
a token-heavy routine (large repo, long skill files, verbose outputs) competes with your regular claude usage. monitor your token usage and adjust repo and skill file sizes if you're hitting limits.
planning your run budget
with 5 runs per day on pro (or 15 on max), you need to be intentional.
high-value daily routines, run every day, high signal:
- morning briefing, daily metrics, content brief
medium-value daily routines, consider batching:
- multiple daily reports that could be combined into one
lower-frequency routines, weekly or API-triggered:
- reports that don't change meaningfully day-to-day
API-triggered routines: don't count against daily cap unless triggered:
- event-driven tasks that only run when something actually happens
combine multiple tasks into a single routine where possible. one routine that generates a briefing, updates a memory file, and posts to slack counts as one run, not three.
scaling up
if you find yourself needing more than your plan's daily run cap:
- API triggers don't count against the daily schedule cap unless triggered
- batching multiple tasks into single runs stretches your quota further
- upgrading plans gives significantly more headroom. max at 15/day vs pro at 5/day is a meaningful jump
- team plans make sense if you're managing automations for multiple people
## 13. the discovery framework: let claude design your routines
this section is the unique centrepiece of this guide.
most people don't know what to automate, not because they lack tasks worth automating, but because they're too close to their own work to see the patterns.
the solution: use claude itself to discover, design, and spec your ideal routines. then hand those specs off for implementation.
the discovery process
run through this in a fresh claude conversation (claude.ai, not routines, you're having a conversation here, not an automated run). use the prompts below as your starting point.
step 1: the time audit prompt
start here. this helps claude understand how you actually spend your time.
copy and paste this:
step 2: the deep dive prompt
once you have your shortlist, pick the routine you want to build first and use this to generate a full spec:
step 3: the persona prompt (if you're not sure where to start)
if you're drawing a blank on what to automate, start here:
this is the guided discovery mode. claude asks you questions, you answer, and together you arrive at your ideal routines. useful if you feel overwhelmed by options.
step 4: the routine review prompt (for refining what's already running)
once a routine has been running for a while and producing output, use this to improve it:
step 5: the routine stack prompt (building a system)
once you have 2-3 routines working, think about how they work together:
## the bottom line
routines are the shift from using claude reactively to deploying it proactively.
most people open claude, ask something, get an answer, close the tab. that's one tool call. routines multiply that into a system that runs 365 days a year, learns from its own outputs, and reports back to you without being asked.
here's what matters most:
the prompt is everything: a vague brief gets vague results; treat every launcher prompt like a brief for a new colleague who has zero context
skills architecture scales you: stop putting complex instructions in the UI; put them in versioned markdown files in your repo and you can maintain, improve, and reuse them indefinitely
memory turns snapshots into intelligence: build delta tracking, cumulative logs, or rolling context from day one and your routines compound in value over time
start with one routine. run it for a week. then build the next one.
which automation are you building first (or what are you already running)? please leave a reply brother!
## 相关链接
- [hoeem](https://x.com/hooeem)
- [@hooeem](https://x.com/hooeem)
- [6.9K](https://x.com/hooeem/status/2044796878446002227/analytics)
- [Mar 27](https://x.com/AlexHormozi/status/2037260397917724956)
- [40K](https://x.com/AlexHormozi/status/2037260397917724956/analytics)
- [claude.ai/code/routines](https://claude.ai/code/routines)
- [claude.ai](https://claude.ai/)
- [#alerts](https://x.com/search?q=%23alerts&src=hashtag_click)
- [Jan 29](https://x.com/hooeem/status/2016861597436645415)
- [132K](https://x.com/hooeem/status/2016861597436645415/analytics)
- [#daily](https://x.com/search?q=%23daily&src=hashtag_click)
- [#claude](https://x.com/search?q=%23claude&src=hashtag_click)
- [#general](https://x.com/search?q=%23general&src=hashtag_click)
- [#claude](https://x.com/search?q=%23claude&src=hashtag_click)
- [claude.ai](https://claude.ai/)
- [claude.ai](https://claude.ai/)
- [claude.ai](https://claude.ai/)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [11:15 PM · Apr 16, 2026](https://x.com/hooeem/status/2044796878446002227)
- [6,900 Views](https://x.com/hooeem/status/2044796878446002227/analytics)
- [View quotes](https://x.com/hooeem/status/2044796878446002227/quotes)
---
*导出时间: 2026/4/17 00:28:04*