routine-writer

Routine Writer

Turn an unattended, repeatable task into a Claude Code routine: a saved prompt plus repositories, connectors, and triggers that runs on Anthropic cloud infrastructure without needing a local machine. Output is a self-contained prompt plus the artifacts to wire it up (a /schedule CLI command when available, a curl template for the /fire endpoint, or a web-UI walkthrough).

Why routines differ from chat prompts. A routine runs as a full autonomous Claude Code cloud session. There is no permission-mode picker, no approval prompts, and no human to answer clarifying questions mid-run. A prompt that works fine in a conversation can stall or misfire silently inside a routine because the model has no one to ask. Every routine prompt must be self-contained, state its success criteria, and declare where output goes.

Research preview context (May 2026 recheck): routines ship under the beta header experimental-cc-routine-2026-04-01. Behavior, limits, and the API surface can change. Pin any beta header references to that value and date so staleness is detectable.

When to use

• User wants to turn a recurring task into a routine ("every night", "when a PR opens", "after each deploy")
• User says "make this a routine", "schedule this", "run this on autopilot", "put this on cloud"
• Refining an existing routine prompt that is firing but producing poor output
• Wiring an alerting tool, CD pipeline, or webhook to fire a routine via HTTP
• Picking between a schedule, API, GitHub event trigger, or a combination
• Writing the /schedule invocation for a scheduled routine from inside Claude Code
• Generating a curl template for an existing routine's API trigger

When NOT to use

• Structuring a one-off prompt for chat or documentation (use prompt-generator)
• Polling or waiting inside an open CLI session (that's /loop, see the built-in scheduled-tasks docs)
• Desktop scheduled tasks that run on the user's machine with local file access (that's a different product surface)
• Writing the skill file itself rather than the prompt (use skill-creator)
• Code review, bug review, or security audit of the routine's target repo (use code-review, security-audit)
• CI pipeline design (use ci-cd) - routines can be triggered from CI but don't replace it
• GitHub Actions workflows (use ci-cd) - routines complement them, the routine is called from an Action
• Tasks that inherently need mid-run human judgment (design decisions, scope calls, UX review). Routines cannot pause to ask. If the task's right answer depends on context only a human can supply at run time, it is not a routine - push back and suggest /loop or an interactive session instead.

AI Self-Check

Routines are high-stakes: they run unattended, consume daily allowance, and can open PRs or post to Slack without review. Before returning any routine prompt, verify:

• [ ] Self-contained: no "ask me" / "clarify with the user" / "if unclear" instructions. The routine cannot ask anything.
• [ ] Trigger-aware context: the prompt names how it was triggered and what input it receives (a scheduled wakeup with no args; an API call with a text payload; a GitHub event with a PR number). Scheduled routines especially need a "work since last run" framing.
• [ ] Explicit success criteria: the prompt states what "done" looks like for this run. Not "improve the code" but "open one PR with passing tests" or "post a one-line summary to #releases".
• [ ] Idempotent no-op: handles "nothing to do" cleanly. A nightly docs sweep with no stale docs should exit quietly, not invent work.
• [ ] Output destination named: where results land is stated explicitly (PR against main, Slack message in #eng-bot, Linear issue with label auto-triage, a summary comment on the PR).
• [ ] Scope declared in config: repositories, connectors, environment variables, and branch policy match what the prompt actually uses. Nothing extra.
• [ ] Branch policy matches intent: default is claude/* prefix only. If the prompt expects to push to other branches, Allow unrestricted branch pushes is documented as a required toggle.
• [ ] Safety rail present: what the routine should NOT do (no force-push, no protected-branch changes, no destructive ops, no new connectors, no credential exfil).
• [ ] No injected slop: no "certainly", "I'd be happy to", "great question", no ALL CAPS emphasis, no filler preamble. Calm imperatives only.
• [ ] Cron interval >= 1 hour: scheduled triggers under one hour are rejected by the platform.
• [ ] Beta header pinned with date: prose mentions of experimental-cc-routine-2026-04-01 carry the header date so future readers can scan for staleness. Inside code blocks the header string itself carries the date, so no parenthetical is needed.
• [ ] No tokens in output: environment variable placeholders only. Never paste a real sk-ant-oat01-... value.
• [ ] Current source checked: dated versions, CLI flags, API names, and support windows are verified against primary docs before repeating them
• [ ] Hidden state identified: local config, credentials, caches, contexts, branches, cluster targets, or previous runs are made explicit before acting
• [ ] Verification is real: final checks exercise the actual runtime, parser, service, or integration point instead of only linting prose or happy paths
• [ ] Routing overlap checked: overlapping skills, trigger terms, and "When NOT to use" boundaries are checked before returning guidance
• [ ] Spec claims verified: claims about tool behavior, output contracts, or repo conventions are checked against current docs, scripts, or skill files
• [ ] API surface checked: routine headers, beta names, schedule syntax, and event payloads match current official docs
• [ ] Unattended risk bounded: permissions, spending, mutation scope, and notification paths are explicit

Performance

• Keep scheduled jobs narrow; split broad routines into independently observable tasks.
• Set output contracts so downstream automation reads small structured results instead of transcripts.
• Throttle polling and retries to avoid unnecessary API or CI load.

Best Practices

• Use least-privilege tokens and separate credentials per routine.
• Make failure modes visible with logs, alerts, and idempotent retry behavior.
• Pin beta headers with dates and revisit them during maintenance refreshes.

Workflow

Step 1: Capture the unattended task

Parse the user's description for:

• Trigger intent: "every night", "on each PR", "after deploy", "when Sentry fires", "weekly on Fridays"
• Input to the run: scheduled (nothing; compute "since last run"), API (freeform text payload, up to 65,536 chars), GitHub (event metadata for the matching PR/push/issue)
• Action: concrete verbs - read, scan, label, open PR, post, port, correlate
• Output destination: PR, comment, Slack channel, Linear issue, release-channel message
• Scope: repositories touched, connectors needed (Slack, Linear, Asana, Google Drive), env vars required
• Safety boundaries: what should never happen (no pushes to main, no force pushes, no destructive ops)

If the user is already inside a Claude Code session and says "make this a routine", extract the task from the conversation context. Do not invent fields they did not imply.

Step 2: Pick trigger(s)

A single routine can combine trigger types. Use this table to route:

| Intent | Trigger | Notes | |---|---|---| | Recurring time-based work | Schedule | 1-hour minimum interval; presets (hourly, daily, weekdays, weekly) or custom cron via /schedule update | | Fired from an external system (alert, deploy, CI failure) | API | Per-routine bearer token, beta header required, 65,536-char text payload | | React to repository activity (PR opened, issue created, push) | GitHub | Needs Claude GitHub App installed; supports fil