Skip to content

Scheduled prompts

A schedule runs a prompt in one repo on a recurring cadence: chosen weekdays at one or more wall-clock times. The prompt can be free text or a /skill, for example /triage-feedback on Mon–Fri at 09:00 and 18:00.

Each run starts a fresh, normal session. It gets a Herd card, notifies you when it blocks, and goes through PR, critic, merge train and archive like a task you start from New Task. The card shows a Scheduled · <name> badge.

Open the repo’s Repo automation settings and find Schedules. Add opens a dialog with:

  • Name and Prompt (free text or a leading /skill).
  • Days: weekday chips, with Mon–Fri and Daily presets.
  • Times: one or more HH:MM times.
  • Launch: Autopilot, plan gate, agent, model, effort, sandbox, base branch and research, as in New Task. Blank means the default at run time. A blank base branch means the repo’s default branch.

Each row shows the cadence, the next run and the last outcome. It also has an on/off switch, Run now, Edit and Delete.

You can also ask the Operator Assistant to create one, for example “run /triage-feedback in this repo every weekday at 09:00”. It sets name, prompt, days, times and optionally the base branch; every other launch option keeps its default, so the run is attended. Its Automation permission under Settings → Assistant decides whether it asks you first. Editing, deleting and Run now stay with you.

Settings → Schedules lists the schedules of every repo in one place, soonest run first. Disabled schedules come last. Each row shows the repo, name, cadence, next run and last outcome, with the same switch, Run now, Edit and Delete as the repo’s own list. When more than one repo has schedules, a Repo filter narrows the list to one. To add a schedule, use the repo’s Repo automation settings.

  • Times are the Shepherd server’s local time. There is no per-schedule time zone. Around daylight-saving changes, a time skipped by the spring-forward change runs right after the gap, and a time repeated in autumn runs once.
  • Creating or enabling a schedule never runs earlier slots. If you enable a 09:00 schedule at 14:00, the first run is at the next slot. Changing the days or times works the same way.
  • Missed runs catch up once. If Shepherd was stopped or herdr was in maintenance at a slot, the latest missed slot runs once when Shepherd is back. If a newer slot has already arrived, only that one runs. A slot missed by more than 12 hours is skipped (skipped, missed by over 12h) rather than run late.
  • Overlap skips. While the schedule’s previous run is still open (not archived) or waiting in the hold queue, the next slot is skipped. Archive the session to let the next slot start.
  • Holds apply. If usage is above the hold threshold, or a plugin refuses the spawn, the run waits in the hold queue like any new task.
  • Run now starts a run immediately, even for a disabled schedule. It is still skipped while the previous run is open.

A scheduled run that finds nothing to do closes itself. When the agent is done and there is nothing for you (no file changes, no PR, issue or comment, no questions, no follow-ups), it calls Shepherd’s schedule_noop tool with a one-line summary, such as 0 open feedback items. Shepherd then:

  • records the run as nothing to do, with that summary under the last-run line in Settings → Schedules;
  • archives the session right away, without a recap and without a notification, so the next slot is not skipped for overlap.

Shepherd refuses the call, and the session stays open, if the worktree has uncommitted changes, the branch has commits beyond its base, or the session has a pull request. Codex sessions and plain sessions don’t get the tool.

Autopilot is off for a new schedule. A skill that asks questions, such as a triage run that wants a plan confirmed, waits for you and sends a notification.

With autopilot on, the run behaves like any autonomous session. That includes the egress allowlist and the trimmed agent context. Skills in the repo’s own .claude/skills still load, but personal ~/.claude/skills do not.

The web UI calls GET/POST /api/schedules, PATCH/DELETE /api/schedules/{id}, POST /api/schedules/{id}/run and GET /api/schedules/{id}/runs. These routes need the operator login or a full-scope access token. A repo-scoped token is refused.