Claude Code /schedule Examples: A Cookbook

A schedule loop runs when the clock says so, not when a condition is met. It fits work that recurs and never stays done: issue triage, nightly test runs, dependency audits, drift checks. This cookbook gives you the harness once, then eight prompts to copy, point at your repo, and forget. The full collection lives at /type/schedule.

Schedule loops are the easiest type to under-specify: the clock starts a run, nothing in the mechanism ends it, and nothing limits what it may touch. Every recipe below fixes that with three fields: done-for-today, never, and budget.

The harness

Every recipe 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

run.sh is a thin wrapper: per-run timeout, throwaway worktree, no dirty checkout.

#!/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

A schedule loop has no exit condition: the clock starts it and the timeout kills it. The prompt governs everything in between, so each recipe states what done looks like for one run and what the agent must never do.

The recipes at a glance:

1. Morning issue triage

The classic. Directory: 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

Runs less often than triage and looks deeper. Directory: 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.

/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

When the flake list gets long, hand it to a goal loop like kill-flaky-tests.

4. Weekly dependency audit

Directory: 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; the continuous version is keep-docs-in-sync.

/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.

/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 loop like dead-code-elimination: observe on a schedule, fix with a goal.

7. Stale branch report

Directory: 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.

/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

Four rules the recipes share

• State done-for-today. The run's definition of done is the only bound short of the timeout; leave it out and the agent drifts.
• Separate observing from fixing. Most recipes here only report; a human or a goal loop acts. A loop that observes and fixes on the same schedule accumulates unreviewed changes.
• Cap output, not just time. "At most one PR per run" is the difference between a normal Monday and fourteen dependency PRs.
• Close the notification gap. A run that finds drift at 2am should tell someone. Sending a real email from the harness, report attached, human on reply-to, is one call with ConnectMyEmail, email infrastructure built for agents.

Tune one to your repo

The Builder takes any recipe here and emits the cron entry, prompt file, and budgeted wrapper with your test commands, labels, and cadence filled in.