Build1 publisher2 min readPublished
A Claude routine wrote a README into a pull request from Anthropic's own infrastructure
A routine is a prompt, a repository and a trigger saved in Claude's web console and executed on Anthropic's machines. Switching one on means installing a GitHub app on the repository you choose.
The Engineer · Build desk

What happened
- Anthropic's docs describe routines as putting Claude Code on autopilot, defining jobs that run on a schedule, trigger on API calls, or react to GitHub events from cloud infrastructure.
- In a dev.to walkthrough, a pull request opened from GitHub's web interface came back a short time later carrying a new section titled "Add comprehensive Readme".
- The GitHub event trigger ships with four event types out of the box: pull request, PR merged, release published and issue opened.
- The first run can report that the GitHub app is not installed, at which point the user follows a link, grants permissions, selects a repository and installs the integration.
- Notifications default to push messages in the Claude mobile and desktop apps, email to the address on the account, and Slack if Slack has been connected.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- decision Teams picking routines over Actions move the reviewable artifact from a YAML file in the repository to a prompt in a vendor console, so a change to what fires on every pull request no longer arrives as a diff.
- exposure The install grants a GitHub app permissions on the repositories you select, so anyone who can edit the routine's prompt can change what happens to those repositories.
- capability Unattended scheduled work no longer needs a hosted runner or a machine left switched on, because Anthropic runs the job while the developer's own Claude instance is off.
- constraint The record of a run lives in the routine's panel in Claude, not in the CI system the rest of the team already watches, so debugging a failed automation starts somewhere new.
When a pull request opens, GitHub hands the event to Anthropic. The routine executes there, against whichever repositories you connected to it, and the pull request is what comes back changed [2].
The definition of that automation is four fields on the routines page of the Claude web interface: a name, a prompt, a repository and a trigger [3][4]. The prompt in the dev.to walkthrough told Claude what to do with the README [4]. The commit that set it off was a one-line comment on the shell script that starts python's http.server for a browser game [11].
Three trigger types exist [5]. Schedule runs at the time you set, on Anthropic's infrastructure, including when your own instance of Claude is not running [6]. The GitHub event trigger is the one the walkthrough used. The API trigger issues a URL and a token and fires on a POST, so another service or an external orchestrator can call it [7].
The author wrote that he started by asking himself "could I get rid of actions entirely?" [13] On this evidence the answer turns on what the job tolerates. The unit of configuration here is a prompt, where an Actions workflow would pin a step, and the task under test was writing documentation that a human then reads in the pull request. A release gate or a test matrix has less slack for a differently worded result each run.
The post does not cover pricing, concurrency limits or retry behaviour. Those are the numbers a platform team would need before moving anything a build depends on off its own runners. The path exists and takes about five clicks to wire up, which is a lower adoption cost than any self-hosted runner I have stood up.
What to watch
- Whether the out-of-the-box GitHub event catalogue grows past four types, which decides how much of an Actions workflow can actually leave.
- Whether Anthropic ships org-scoped routines with shared ownership, instead of one account holding the prompt and the notification address.
- Whether run logs become exportable in a form an existing CI dashboard can ingest.