How to automate your daily standup

Standup asks every engineer to remember and restate what they shipped. The information is already in the repository: yesterday's merged pull requests say what landed and who landed it. A cron trigger hands that job to an agent.

A cron trigger runs an agent on a schedule. Ellipsis registers the schedule when the config syncs from your default branch, and each fire starts a fresh session with the agent's system as its instruction. There is no typed prompt.

Splitshift posts a standup every weekday morning:

ellipsis:
  version: v1
  name: Daily standup
  description: Summarizes yesterday's merged pull requests every weekday morning

claude:
  system: |
    Summarize what merged across splitshift-web and splitshift-api in
    the last 24 hours. Group related pull requests into the themes of
    work they add up to, and lead with what changed for users. Name
    the author of each change. Do not write a pull-request-by-pull-request
    changelog. Call out anything risky to ship and anything open more
    than a week. Return the summary as Slack-ready markdown.

trigger:
  type: cron
  schedule: "0 13 * * 1-5"

sandbox:
  repositories:
    - name: splitshift-web
    - name: splitshift-api
  github:
    permissions: read_only

budget:
  session: 1.00
  day: 2.00

Three parts do the work. The trigger runs the agent at 13:00 UTC every weekday. The system prompt is the interesting part: it pushes the agent past a pull-request-by-pull-request changelog into a themed narrative of what the team accomplished. The budget caps what any single session, and any single day, can spend.

Each weekday at 13:00 UTC this produces a session whose result reads like:

Shift trading got more reliable. priya-shah fixed pending trades
hanging when the counterparty deactivates (#431), and marcus-lee
added rest-period validation on the trade endpoint (#437).

Scheduling: dani-okoro shipped the unfilled-shift digest behind a
flag (#428).

Worth a look: #437 changes trade validation without migrating
existing pending rows.

Plus routine dependency upkeep across both repos.

For a complete, deployable version of this agent, use the Daily Standup template: deploying it opens a pull request that adds the config to your repository, and the agent is live the moment it merges.

Read-only by construction

A standup writer needs to read your pull requests. It has no business writing to them. One line is the whole security posture:

sandbox:
  github:
    permissions: read_only

Each session runs in an isolated sandbox with a short-lived GitHub token minted for that session, and read_only narrows that token at the mint to read access on contents, issues, metadata, and pull requests. GitHub enforces the narrowing, so nothing in the sandbox can exceed it: not a misbehaving tool, not a prompt injection hiding in a pull request description. The token dies with the sandbox.

Because the grant is YAML in git, the agent's blast radius is reviewed like the rest of your code.

Post it to Slack

The agent returns the standup as its answer. With the Slack integration connected, the session has Slack tools in the sandbox, so one line in the prompt makes it post the summary itself:

claude:
  system: |
    Summarize what merged across splitshift-web and splitshift-api in
    the last 24 hours, grouped by theme. Post the summary to the
    #engineering channel.

Either way the session is recorded, so you can open the transcript and see which pull requests it read.

Put another recurring job on a schedule

The trigger is the same for any job that should run on a clock, not an event. Swap the prompt and the schedule. A triage agent that runs an hour later:

claude:
  system: |
    Find open GitHub issues in splitshift-api that need attention.
    Prioritize bugs in shift trading and schedule assignment, stale
    customer reports, and blocked pull requests. Post a concise
    triage summary as a comment on each issue you touch.

trigger:
  type: cron
  schedule: "0 14 * * 1-5"

Schedule syntax

schedule takes a standard five-field cron expression: minute hour day-of-month month day-of-week. All schedules run in UTC.

You cannot restrict both day-of-month and day-of-week in the same expression; leave one as *.

Ellipsis also accepts AWS EventBridge Scheduler expressions verbatim: cron(...), rate(...), or at(...).

trigger:
  type: cron
  schedule: "rate(6 hours)"

Multiple schedules

A config can declare several cron triggers; each fires independently. Editing or removing a trigger updates the schedule on the next sync, and an invalid cron expression fails validation before anything is stored.

Next

Cap what scheduled sessions can spend with budgets, or react to events instead of a clock with How to review every pull request as commits land.