> ## Documentation Index > Fetch the complete documentation index at: https://docs.roomote.dev/llms.txt > Use this file to discover all available pages before exploring further. # Automations > Set up background Roomote work for PR review, conflict resolution, recurring triage, and team updates. Automations let Roomote work without waiting for a teammate to write a new prompt every time. Use them after your first environment, chat connection, and source-control connection are working well. Automations are most useful when your team already trusts the normal task review flow and wants Roomote to keep an eye on repeated work. ## Before you turn them on Make sure the basics are in place: * source control is connected for PR and repository automations * Slack is connected for automations that post updates to channels * Roomote has at least one healthy environment for the repositories it should work in * the team knows where automation output will appear Automations can create useful work quickly. Start with one or two that map to a real team habit, tell the team where output will appear, then expand once the signal is good. Every automation that posts to a chat channel is replyable. Reply in the thread Roomote started and you are talking to the task behind that report, without needing to mention Roomote. That works on Slack, Discord, Teams, and Telegram, and it works after the run has finished. ## Pull request automations These automations react to pull requests, issues, and repository state. | Automation | What it does | Good first use | | ------------------------ | ----------------------------------------------------------------------------------------- | ---------------------------------------------------------------------- | | **Review Code** | Reviews pull requests automatically or on demand | Add an extra reviewer for regressions, risky changes, and missed tests | | **Triage Issues** | Posts an implementation plan when an issue is opened/reopened on GitHub, GitLab, or Gitea | Get a grounded plan on the issue without auto-opening a PR | | **Resolve PR Conflicts** | Looks for merge conflicts and helps fix them on open PRs | Keep long-running branches from getting stuck | For **Review Code**, decide whether Roomote should review new commits automatically and whether draft pull requests should be included. If your team treats drafts as active collaboration, include them. If drafts are noisy or half-formed, keep them out until they are ready. For **Triage Issues**, turn the toggle on once a supported source-control provider is connected (GitHub, GitLab, or Gitea) and the repos you care about have configured Roomote environments. When an issue is opened or reopened, Roomote starts a task immediately, investigates the issue, and posts a concrete plan as a comment on that issue. It does not need a Manager Channel, does not post Slack digests, does not implement the fix, and does not open a pull request automatically. Azure DevOps work items and Bitbucket issues are not covered yet. For **Resolve PR Conflicts**, pick a schedule, PR age cap, and label. The label is the team-controlled opt-in for scheduled scans. Make sure the label exists in your repositories, add it to PRs where you want Roomote to attempt conflict resolution, and remove it when a human should handle the conflict instead. Roomote only tries this on labeled PRs that are still active, and it skips PRs older than the age cap you set. ## Custom automations Create arbitrary scheduled agent runs with: * a clear **name** * the **prompt** Roomote should run * a **cadence** (`every hour`, `every 6 hours`, `daily`, or `weekly`) * one required **environment** * an optional **report destination** channel (Slack, Discord, Teams, or Telegram) On each due tick, Roomote launches a normal task with that prompt in that environment. When a report destination is set, the run is anchored to that channel: Roomote's first message (the final result, or a blocker or question that needs input) starts a thread, later updates continue that same thread, and you can reply in the thread to talk to the task. There is no progress chatter in between. Without a destination, the run happens silently and its results appear only in the task view. Use **Run now** on an enabled automation to test it immediately. Daily and weekly custom automations use the same local-hour window as the other scheduled automations (around 3am in the workspace timezone). Cap is 25 custom automations per deployment. ## Channel automations The channel section starts with **Auto-respond to channels**. Use it to let Roomote start a task from new top-level messages in selected Slack or Discord channels, even when nobody mentions Roomote directly. You can add multiple channels across both providers, and each one can include its own optional instructions and launch criteria. Good first examples: * `#ask-engineering` * `#bugs` * `#support-inbound` * `#ops-requests` For Slack channels, invite Roomote to every auto-respond channel before you save it. For Discord channels, pick from the text and announcement channels the Roomote bot can already see in your server. A few provider-specific behaviors to know: * On Discord, messages from people who have not linked their Discord account to Roomote do not start tasks; Roomote sends them a direct message explaining how to link instead. * Messages posted by other bots or webhooks (for example a deploy or alert feed) can start tasks too. Use launch criteria to keep noisy feeds in check — for example, only launching on new or worsening alerts. Start with a low-risk channel first. Auto-response can feel noisy if the channel mixes casual discussion with requests that should become Roomote tasks. ## Manager automations The manager section controls the shared Manager Channel plus recurring manager-facing updates and suggestions. | Automation | What it posts | Typical cadence | | ---------------------------- | ------------------------------------------------------------------ | ------------------------------------------- | | **Automation output** | The shared Manager Channel destination | Configure once | | **Weekly Manager Stats** | A weekly summary of Roomote activity | Weekly | | **Triage Sentry Issues** | Prioritized Sentry follow-up work | Daily or weekly | | **Triage Dependabot Alerts** | Suggested follow-up tasks for open dependency alerts | Daily or weekly | | **Triage CodeQL Alerts** | Remediation follow-up tasks for open code-scanning / CodeQL alerts | Daily or weekly | | **Security Auditor** | Security follow-up work from recently merged PRs | Every hour, every 6 hours, daily, or weekly | | **Code Quality Auditor** | Code quality follow-up work from recently merged PRs | Every hour, every 6 hours, daily, or weekly | | **Suggest Ideas** | Useful coding work Roomote thinks the team could do | Daily or weekly | | **CI Failure Triage** | Automatic repro-and-fix tasks for failing default-branch CI runs | Immediate via webhook | | **Summarize Merged PRs** | A digest of recently merged pull requests | Daily or weekly | Set **Automation output** first. This is the shared Slack channel for manager-facing posts, suggestions, summaries, and setup alerts. Invite Roomote to that channel before you save it. Each automation card shows a **Reports to** line with the destination the next run will use and which setting produced it. Reports go to the automation's own channel when one is set, otherwise to the shared Manager Channel. When Slack is not connected at all, reports fall back automatically to your primary Microsoft Teams conversation, the configured Telegram chat, or the configured Discord channel (see [Communications](/communications#supported-providers) for connecting those surfaces). **Suggest Ideas** can also report to Teams or Telegram as first-class destinations. When you select Telegram, Roomote creates a sticky **Suggest Ideas** forum topic in your primary Telegram chat (create once, reuse on later runs) and posts digests there. You cannot pick an existing Telegram thread — Roomote owns the recurring topic. When you select Teams, digests go to the primary Teams conversation captured for the deployment. Cards also show capability badges for what each automation supports today: the chat surfaces it can report to and the source-control providers it works with. Triage Dependabot Alerts and Triage CodeQL Alerts are GitHub-only by nature. CI Failure Triage supports GitHub Actions, GitLab Pipelines, Azure DevOps builds, Bitbucket Pipelines, and Gitea Actions. Triage Issues supports GitHub, GitLab, and Gitea issues. Security Auditor, Code Quality Auditor, Weekly Manager Stats, Suggest Ideas, Summarize Merged PRs, and Triage Sentry Issues work with any connected source-control provider. Resolve PR Conflicts supports GitHub, GitLab, Azure DevOps, and Gitea. Bitbucket is not supported because its API does not expose the mergeability and label signals required for an unattended opt-in scan. CI Failure Triage reacts immediately to GitHub Actions, GitLab Pipeline, Azure DevOps `build.complete`, Bitbucket Pipelines commit-status, and Gitea Actions `workflow_run` webhooks rather than running on a daily or weekly schedule. **Code Quality Auditor** inspects recently merged PR diffs and only posts high-confidence maintainability issues worth a real follow-up task. It is meant to catch confusing abstractions, file bloat, brittle branching, and other quality regressions, not correctness bugs or security issues. **Triage Sentry Issues** scans connected Sentry projects and posts the issues that look worth engineering follow-up. Leave project slugs blank to scan everything available to the configured token, or scope it to specific projects. **Triage Dependabot Alerts** scans open GitHub Dependabot alerts across your active repositories and suggests tightly scoped follow-up update tasks. It does not open PRs directly from the scheduled scan. **Triage CodeQL Alerts** scans open GitHub code-scanning alerts (especially CodeQL findings) across your active repositories and launches tightly scoped remediation follow-up tasks. It does not open PRs directly from the scheduled scan. **Security Auditor** reviews recently merged PRs for concrete security issues and secure-by-default gaps that are worth a real follow-up task. **CI Failure Triage** reacts the moment CI fails on a repository's default branch (GitHub Actions workflow runs, GitLab Pipelines, Azure DevOps builds, Bitbucket Pipelines, and Gitea Actions). When a failure persists (it is not already fixed by a newer run and is not a one-off flake), Roomote starts a fix task that reproduces the failing job inside the repository's configured environment, finds the root cause, opens a PR with the fix, and posts one summary to the Manager Channel when it finishes. Only repositories that belong to a configured Roomote environment are triaged. For GitLab, ensure Pipeline Hooks are enabled on the webhook Roomote receives. For Azure DevOps, Roomote ensures the project-scoped `build.complete` service hook when Azure DevOps repositories are synced. For Bitbucket, repository webhooks include `repo:commit_status_created` and `repo:commit_status_updated`, and the OAuth client needs the Pipelines scope. For Gitea, repository webhook resync includes the `workflow_run` event so Actions completions reach Roomote; host matching uses the deployment `GITEA_BASE_URL`. ## Add instructions to reduce noise Several automations include an **Additional instructions** field. Use it to tell Roomote what good signal looks like for your team. Helpful instructions are specific: ```text theme={null} Prioritize changes that reduce repeated support escalations. Skip suggestions that require product approval before engineering can start. For merged PR summaries, call out customer-visible changes first. ``` Avoid broad instructions such as "only send good ideas." Roomote needs to know what your team considers useful, risky, or out of scope. ## Run an automation now Some automations include a **Run now** action. Use it when you want to test the current configuration before waiting for the next scheduled run. After you run one, check the destination channel and the task view. A healthy automation should leave enough context for a reviewer to understand why Roomote posted and what should happen next. If the automation creates a task, review the same evidence you would review for manual work: transcript, logs, diffs, previews, artifacts, and final summary. ## Use Slack workflows for event-driven custom triggers For **scheduled** work with a fixed prompt, prefer **Custom automations** above. For **event-driven** team workflows, use Slack's own workflow builder and end the workflow with a Roomote mention. Good custom event triggers include: * send new bug-channel posts to Roomote for triage * turn operational requests from another system into Roomote tasks * ask Roomote to gather diagnostics when a support escalation arrives This keeps event routing in Slack while still letting Roomote run a normal, reviewable task. ## Possible issues * **Nothing posts to Slack.** Check that Slack is connected, Roomote is invited to the Manager Channel, and the automation is enabled. * **Suggestions are too broad.** Add narrower instructions about what to prioritize and what to ignore. * **Review Code comments on too much.** Turn off draft PR review or adjust when automatic reviews run. * **Conflict resolution starts on the wrong PRs.** Use the configured label as the opt-in boundary and remove it from PRs that need human handling.