Claude Code /schedule Examples: A Cookbook

Goal loops run until a condition is true. Schedule loops run when the clock says so — cron for agents. They're the right shape for work that recurs and never stays done: triage, audits, nightly runs, weekly reports. Nobody "finishes" issue triage; you just do it again tomorrow.

This cookbook gives you the harness once, then eight schedules you can copy, point at your repo, and forget. Browse the full collection at [/type/schedule](/type/schedule).

The harness

Every recipe below is the same three pieces: a cron entry, a prompt file, and a budget. The cron side is ordinary:

# crontab -e
0 9 * * 1-5  cd ~/code/myrepo && ./loops/run.sh triage.md >> ~/loops.log 2>&1

And run.sh is a thin, budgeted wrapper — per-run timeout, isolation, and a handoff note, same rails as any other loop:

#!/usr/bin/env bash
set -euo pipefail
PROMPT="$1"
git fetch origin && git worktree add /tmp/sched-run origin/main
cd /tmp/sched-run
timeout 30m claude -p "$(cat "loops/$PROMPT")" --dangerously-skip-permissions
cd - && git worktree remove --force /tmp/sched-run

Scheduled loops need discipline in the prompt itself, because no exit condition bounds them — the clock starts them and the timeout ends them. Every prompt below therefore states what done looks like for one run and what the agent must not do.

1. Morning issue triage

The classic. Directory: [morning-issue-triage](/loops/morning-issue-triage).

/schedule weekdays 9:00
task: |
  Review all GitHub issues opened since the last run.
  For each: apply labels, check for duplicates against open issues,
  and flag anything that looks like a security report or prod outage.
  Post a one-comment summary on anything you triaged.
done-for-today: every new issue has at least one label or a dedupe comment
never: close an issue, assign a human, or edit issue bodies
budget: 30m per run

2. Issue dedup sweep

Triage's quieter sibling — runs less often, looks deeper. Directory: [issue-dedup-schedule](/loops/issue-dedup-schedule).

/schedule mon,thu 14:00
task: |
  Scan open issues for duplicates using titles, bodies, and stack traces.
  For each candidate pair, comment on the newer issue linking the older one
  with a one-line justification. Confidence below "near-certain" → skip.
done-for-today: dedupe candidates list is empty or commented
never: close issues; a human confirms every dedupe
budget: 20m per run

3. Nightly e2e run with first-pass diagnosis

Directory: [nightly-e2e-run](/loops/nightly-e2e-run).

/schedule daily 02:00
task: |
  Run the full e2e suite against staging. If green, log one line and exit.
  If red: rerun failures once to separate flakes from real breaks, then for
  each real failure write a diagnosis (failing step, likely commit range,
  suspect files) to reports/e2e/<date>.md.
done-for-today: suite ran; failures have diagnoses committed to the reports branch
never: modify test code or application code — diagnose only
budget: 90m per run

Pair it with a goal loop like [kill-flaky-tests](/loops/kill-flaky-tests) when the flake list gets long.

4. Weekly dependency audit

Directory: [weekly-dependency-audit](/loops/weekly-dependency-audit).

/schedule mon 07:00
task: |
  Run `npm audit` and `npm outdated`. For each advisory: severity, whether
  our code hits the vulnerable path, and the upgrade cost. Open one PR
  bumping safe patch-level security fixes (tests must pass). Everything
  else goes in the report with a recommendation.
done-for-today: report committed; at most ONE upgrade PR opened
never: bump majors; merge anything
budget: 45m per run

5. README and docs freshness check

Directory: [readme-freshness-check](/loops/readme-freshness-check) — and see [keep-docs-in-sync](/loops/keep-docs-in-sync) for the continuous version.

/schedule fri 10:00
task: |
  Compare README and docs/ against reality: do the setup steps still work,
  do documented commands exist in package.json, do referenced files exist?
  Fix small drift (renamed script, dead link) in a single docs-only PR.
  Structural rot goes in an issue instead.
done-for-today: one docs PR or one issue, or a "docs clean" log line
never: touch anything outside README* and docs/
budget: 30m per run

6. Weekly tech-debt report

Directory: [weekly-tech-debt-report](/loops/weekly-tech-debt-report).

/schedule fri 16:00
task: |
  Sweep the repo: TODO/FIXME density, files over 500 lines, duplicated
  logic, circular imports, suppression comments added this week.
  Write reports/tech-debt/<date>.md ranked by blast radius, each item
  with file paths and a one-line suggested fix.
done-for-today: report committed and linked from the previous report
never: refactor anything — this loop only observes
budget: 40m per run

Feed its top item to a [/type/goal](/type/goal) loop like [dead-code-elimination](/loops/dead-code-elimination) — observe on a schedule, fix with a goal.

7. Stale branch report

Directory: [stale-branch-report](/loops/stale-branch-report).

/schedule mon 08:00
task: |
  List branches with no commits in 30+ days. For each: last author,
  ahead/behind counts, and whether an associated PR is open, merged,
  or abandoned. Group into "safe to delete", "needs owner decision",
  "active PR". Write the report; delete nothing.
done-for-today: report posted as a GitHub discussion comment
never: delete branches or close PRs
budget: 15m per run

8. Config drift check

Directory: [config-drift-check](/loops/config-drift-check).

/schedule daily 06:00
task: |
  Diff deployed environment config against the committed baseline:
  env var names (never values), service counts, cron entries, feature flags.
  Any drift → write the diff to reports/drift/<date>.md and stop.
done-for-today: drift report written, or "no drift" logged
never: change any config in either direction — report only
budget: 15m per run

Patterns worth stealing

Across all eight recipes, the same rules keep scheduled loops boring (the good kind):

Define "done for today." Without an exit condition, the prompt's definition of a completed run is the only thing standing between you and a loop that free-associates until the timeout.
Separate observing from fixing. Most recipes above *report*; a human or a goal loop *acts*. Loops that do both on a schedule accumulate weird unreviewed changes.
Cap output, not just time. "At most one PR per run" keeps Monday morning from greeting you with fourteen dependency PRs.
Close the notification gap. A scheduled loop that finds something at 2am should tell someone. Wiring your harness to send a real email — report attached, reply-to a human — is a one-liner with ConnectMyEmail, which exists precisely so agents can do email without you babysitting SMTP.

Want one of these tuned to your repo — your test commands, your labels, your cadence? The [loop builder](/builder) takes a recipe and emits the cron entry, prompt file, and budgeted harness in one shot.

Claude Code /schedule Examples: A Cookbook