Automations & triggers

Not every run needs a person to start it. Automations fire from a schedule or an event and deliver as a normal thread — same sandbox, same evidence, same review trail — so recurring work happens without anyone babysitting it.

Schedule

On a cron schedule you set — hourly, daily, weekday mornings, whatever cadence the job needs.

Post a morning digestRun a weekly dependency auditDraft a release changelog

GitHub

On repository events: CI failing on an open PR, a Dependabot PR opening, or a slash command in a PR comment (@gentlybot …).

Auto-fix a failing checkSmoke-test a dependency bumpAnswer a review question inline

Slack

When a message lands in a channel or thread Gentlybot is watching — a bug report, a question, a request.

Triage a #bug-triage reportAnswer a product questionKick off a repro from a screenshot

Jira

On issue events — created or updated. In early access.

Reproduce a filed bugAdd context to a new ticketDraft an implementation plan
  1. 1 Create a trigger from Automations and choose which project it runs against — that sets the repos and context it works from.
  2. 2 Pick the trigger type and its condition: a cron schedule, a GitHub event, a Slack channel, or a Jira event.
  3. 3 Choose the mode. Start with Ask or Plan so the automation posts findings for review; move to Implement only once you trust it on that job.
  4. 4 Write the prompt exactly as if a person asked it — outcome, context, and where to post the result. This is the whole behavior of the automation.

A trigger plus a prompt. Start from one of these and adapt the channel, cadence, and scope to your team.

Schedule
Every weekday at 7:00
Review yesterday’s merges for risky changes and post a digest to #engineering.
GitHub
CI fails on an open PR
Reproduce the failure in a sandbox, fix it, and push to the same branch.
Slack
New report lands in #bug-triage
Try to reproduce it, find the likely cause, and reply in the Slack thread with findings.
GitHub
Dependabot opens a PR
Boot the app in a sandbox, click through the affected flows, and flag anything broken.
Schedule
Every Monday at 9:00
Audit dependencies for known advisories and open a plan for the upgrades worth doing.
Schedule
The day before each release
Draft a changelog from the merged PRs since the last tag and post it to #releases for review.

Write it like you mean it every day

An automation runs unattended, so it can’t be steered mid-run the way a live thread can. Bake the context and the guardrails into the prompt: which channel to post to, what’s out of scope, what a good result looks like.

Bound the work

Keep automated prompts specific and finite — “review yesterday’s merges,” not “keep the codebase healthy.” A tightly bounded job produces a predictable result you can trust to run without you watching.

Earn autonomy gradually

Start automations in Ask or Plan so they post findings for a human to act on. Promote a job to Implement only after you’ve watched it get that job right a few times.

Every run is still reviewable

An automation delivers as a normal thread with the same sandbox, evidence, and review trail. Nothing merges on its own — a fix pushed to a branch still waits for your engineers, and you can open any run to see exactly what it did.

Connect the sources first

GitHub, Slack, and Jira triggers only fire once those integrations are connected to your workspace. Set them up, then point an automation at the events they emit.

Integrations setup