Skip to main content

Automations

Automations start cloud agents for you — on a schedule or when something happens in your workflow (a new pull request, a failing check, a comment). You write the instruction once; X4RGE runs it whenever the trigger fires.

Think of it as putting a recurring or event-driven task on autopilot: the same teammate in the cloud, same repo and setup, without you clicking "Start run" every time.

When to use automations

ScenarioWhy automate
Nightly or weekly maintenanceTriage issues, refresh docs, scan dependencies while the team is offline
React to CI failuresInvestigate and propose a fix when checks fail — you review the PR
PR hygieneBug-finding pass or review when a pull request opens
On-demand playbooksSave a template and run it with one click when you need it
Team handoffsAnyone with access can see runs and results in Sentinel

Use automations when the job is repeatable and well-defined. For one-off exploration, start a manual cloud run in the Agents workspace instead.

In practice

You want to…Automations help by…
Stop manually re-running the same triageFiring the same prompt every weekday morning
Catch failures fasterStarting a run when a GitHub check fails
Standardize reviewsUsing a template for "find bugs" or "add tests" across repos
Roll out carefullyTesting once manually, then enabling the trigger
Stay in controlLetting you review diffs and PRs before anything merges

Each run uses your cloud setup — repository, install steps, secrets, and network rules — so automated runs behave like manual ones.

How automations work

  1. Pick a trigger

    Choose when the automation runs: a recurring schedule, a GitHub event, or a manual run from a saved template.

  2. Describe the task

    Write what the agent should do each time — scope, severity, and what to do when nothing needs changing (for example, "report no issues" vs. stay silent).

  3. Scope repository and branch

    Point the automation at a repository (and branch) so the agent clones the right code. Event triggers may pass a specific ref, such as a pull request branch.

  4. Test, then enable

    Run once manually, review the output, then turn the automation on. Watch the first few scheduled or event-driven runs in Sentinel before widening scope.

Start in a safe repo

Like Cursor, Devin, and Factory recommend for background agents: try automations on a low-stakes repository first. Confirm prompts and triggers behave as expected before production repos.

Ways to start a run

TriggerFires whenGood for
ScheduleRecurring time you choose (daily, weekly, custom)Triage, doc updates, dependency sweeps
GitHubPull requests, pushes, check results, commentsCI fixes, PR review, post-merge tasks
ManualYou click run on a saved templatePlaybooks you reuse but don't schedule

GitHub must be connected for repository-scoped and webhook-driven automations. Schedule and manual runs still need a repo when the task edits code.

More integrations coming

Slack and other sources may appear as trigger options in the UI. For production automations today, prefer GitHub or schedule triggers. See Troubleshooting if a trigger is listed but not yet connectable.

Starter templates

The Agents workspace includes templates you can customize:

TemplateTypical use
Find bugsReview recent changes for high-severity issues
Scan for vulnerabilitiesScheduled security pass with alerts
Generate docsUpdate developer docs for changed code
Add test coverageAdd tests for high-risk uncovered logic
Incident triageSummarize production signals and suggested next steps
Research changed APIsTrack dependency and API changes

Pick a template, adjust the prompt and trigger, and save. Templates are starting points — tune instructions for your team's standards and approval habits.

Create an automation

  1. Open Automations

    In the Agents workspace, go to Automations (or start from a template).

  2. Choose a trigger

    Schedule (time and timezone), a GitHub event, or manual-only. Confirm the next run time shown in the UI for schedules.

  3. Write the instruction

    Be specific: what to inspect, what "done" looks like, and whether to open a PR or only comment. See Prompting for task-writing tips.

  4. Set repository, model, and approvals

    Select the repo and branch. Choose a model and how strictly the agent must ask before sensitive actions — stricter for automations that open PRs, lighter for read-only triage.

  5. Enable and monitor

    Save, run once by hand, then enable the trigger. Use Sentinel to spot misfires, duplicate PRs, or runaway triggers early.

Best practices

Write idempotent instructions

Prompts should behave safely when run more than once. For example: "If a fix PR already exists for this failure, comment on it instead of opening a duplicate."

  • Scope narrowly at first — one repo, one event type, clear success criteria.
  • Pair with usage limits — use Usage and org budget policy so a noisy trigger cannot exhaust allowance.
  • Review before merge — automations propose work; your team still approves what ships.
  • Reuse cloud setup — keep install steps and secrets aligned with CI so automated runs don't fail on environment drift.