Gentlybot docs

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 …). Optionally filter the event text with keywords.

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

Slack

When a new root message lands in a channel Gentlybot is watching — a bug report, a question, a request. Optionally filter message text and attached-file metadata with keywords.

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

Jira

On issue or comment events. Narrow a trigger by project, issue type, or keywords matched against the summary, description, and comment text. In early access.

Reproduce a filed bugAdd context to a new ticketDraft an implementation plan

Linear

When an issue or comment is created, updated, or deleted. Narrow a trigger by team or keywords matched against the identifier, title, description, and comment text.

Triage a new issueInvestigate a status changeRespond to a customer-impact comment

Notion

When a page is created, edited, moved, locked, restored, or deleted. Scope the trigger to a page or database. In early access.

Review a changed specTurn a new brief into a planCheck a runbook update
  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 schedule or an event from GitHub, Slack, Jira, Linear, or Notion.
  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.

For GitHub, Slack messages, Jira, and Linear, keyword filters are optional. Separate phrases with commas, such as “checkout, urgent”. Every non-empty phrase must appear somewhere in the provider’s searchable text, regardless of capitalization or phrase order.

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.
Linear
An issue is created for the Support team
Check the report against the product, add likely causes, and propose the next diagnostic step.
Notion
A product brief is updated
Compare the brief with the current app and open a planning thread for the gaps that are ready to build.

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

Event triggers only fire once their GitHub, Slack, Jira, Linear, or Notion integration is connected to your workspace. Set up the source first, then choose which events should start a run.

Integrations setup