Recurring automation magnifies both good instructions and bad ones. Start with a task that has stable inputs, clear stop conditions and a safe review path. Do not begin with production deploys or open-ended “fix everything” prompts.
1. Choose a recurring task whose input changes but workflow stays stable
Pick work whose inputs change but whose procedure is stable: dependency audits, issue triage, report generation or recurring test sweeps. If humans still change the procedure every run, it is too early to schedule it.
2. Write the routine prompt with repository, trigger, stop condition and allowed actions
Define the repository scope, trigger, allowed writes, required tests and explicit stop conditions. A routine should know when to produce a draft, when to ask for help and when to do nothing.
3. Start with draft outputs or draft PRs instead of automatic merges
Start with a low-consequence output such as a report, issue or draft PR. This lets you evaluate false positives and permissions before the routine is allowed to modify protected branches or production systems.
4. Run it manually once and inspect logs, artifacts and permissions before scheduling
Run the routine manually once and read the full log. Verify which files changed, what credentials or tools were requested, whether tests actually ran and whether the produced artifact matches the intended scope.
5. Set a cadence or event trigger, then review failed or surprising runs regularly
Only then schedule it. Review failed and surprising runs periodically, because repository structure, dependencies and permissions change over time even when the routine definition does not.
Create a Claude Code routine for [recurring task]. Trigger: [schedule/event]. Repository: [repo]. Allowed actions: [read/test/draft PR]. Stop if [condition]. Never merge, deploy, change secrets or broaden permissions automatically. For every run, produce a short evidence log and link to the draft output.
Automating a workflow before running it manually; no stop condition; letting the routine merge its own fixes; allowing broad connectors by default; never reviewing failures because most runs succeed.
Finish check
A manual test run is understood, recurring runs produce reviewable drafts and evidence, and the routine cannot silently cross the actions you deliberately reserved for humans.