Skip to main content
The fastest way to understand automations is to build one. This page walks through two, end to end. The first uses the simplest trigger there is — a schedule — and you’ll build it by hand so you see every moving part. The second reacts to a real GitHub event and uses a compound filter, which is the shape most production automations take — and for that one you can hand the wiring to Advisor, with the manual steps included if you’d rather do it yourself.

​
Before You Start

Both automations need two integrations connected. Open the Integrations settings page and confirm:
  • GitHub — the Expert reads your PRs through the connected GitHub App.
  • Slack — the Expert delivers its nudges through the connected Slack app.
If either shows as not connected, run its connect flow first — it takes a minute each.

​
Automation 1: A Personal Daily PR Nudger

Every weekday morning, an Expert checks which open PRs are waiting on your review and sends you a Slack DM with the list. No PRs waiting — no message.

​
1. Create the Expert

From the Experts page, click Create an expert and pick Custom Expert:
  • Name — something like My PR Nudger.
  • Environment — the default environment is fine; this Expert only needs GitHub and Slack access, no repo checkout.
  • Tools — enable GitHub and Slack in the integrations list.
  • System Prompt — paste something like this, filling in your own GitHub username and email:
You are my personal PR review nudger. Each time you run:
1. Find open GitHub pull requests where my review is requested
   (my GitHub username: YOUR_GITHUB_USERNAME).
2. Drop drafts and anything I've already reviewed since its last push.
3. If any remain, send me a Slack DM (look me up by email:
   you@company.com) with one line per PR: title, link, author,
   and how long it's been waiting.
4. If nothing needs my attention, finish without sending anything.
Save the Expert. New Experts are visible only to you until you share them — exactly right for a personal nudger.

​
2. Test it before wiring the trigger

Open the Expert from the home page and send it a message: run. Watch it work — it should query GitHub, and either DM you or report that nothing needs attention. If the DM lands in the wrong place or the list includes drafts, tune the instructions and run it again. This is the cheapest place to iterate: nothing fires automatically yet.

​
3. Add the schedule

Open Automations in the sidebar and click Create automation. In the panel that opens, pick your nudger Expert from the Expert dropdown, then under New triggers click Add trigger and pick Scheduled from the Choose trigger type picker:
  • Trigger name — daily-nudge.
  • Frequency — pick Custom cron and enter 0 9 * * 1-5 (9:00 every weekday). The daily/weekly presets work too if you’d rather not write cron.
  • Timezone — pick yours; the schedule fires in this timezone, DST-aware.
  • Leave Auto-archive sessions created by this trigger on — these are fire-and-forget runs you don’t need to revisit.
Save. That’s the whole automation: tomorrow at 9:00 it runs without you.

​
4. Confirm it fired

The next morning, open Automations in the sidebar, open your automation row’s ⋯ menu, and choose Run history (the same view lives under Run History in the sidebar). You should see a session started by the trigger. Click into it to read exactly what the Expert did.

​
Automation 2: A Team-Wide Review Nudger

Now the event-driven version: whenever review is requested on a non-draft PR targeting main, an Expert posts a heads-up in the team’s review channel — PR link, author, who’s on the hook. Same building blocks, but the trigger listens to GitHub instead of a clock, and a payload filter decides which events matter.

​
The Fast Way: Ask Advisor

You already know the moving parts from Automation 1 — Expert, trigger, filter. This time, let Advisor do the wiring. Open Advisor — the “Describe your workflow and an agent will set it up” banner on the Experts or Automations page, or pick Cosmos Advisor from the home page — and describe the outcome:
Set up a team-wide PR review nudger: whenever review is requested on a non-draft pull request targeting main, post one message to our #code-review Slack channel with the PR title, link, author, and requested reviewers. It should not review the PR itself.
Advisor creates the Expert, writes the GitHub trigger and its payload filter, and stages the rollout — the Expert deploys with the trigger off, you try it against a real PR, and the trigger goes live only when you say so. See Setting Up Automations with Advisor for the full flow.

​
The Manual Way (Optional)

Prefer to build it by hand — or want to see exactly what Advisor wired up? The same automation, step by step.

​
1. Create the Expert

Same flow as before, with two differences:
  • Sharing — after saving, click Share expert in the Sharing section so the team can use it.
  • System Prompt — the Expert now reacts to an event payload instead of running a search:
You are the team's review nudger. You wake up when review is
requested on a pull request. The event payload is your first message.
1. Read the PR title, URL, author, and requested reviewers from
   the payload.
2. Post ONE message to the #code-review Slack channel: PR title
   and link, author, who's requested, and a one-line summary of
   what the PR changes.
3. Do not review the PR yourself. Do not post more than one message.

​
2. Add the GitHub trigger with a filter

Back on the Automations page, click Create automation, pick the team nudger Expert, then under New triggers click Add trigger and pick GitHub from the Choose trigger type picker:
  • Trigger name — on-review-requested.
  • Event — pull_request.
  • Filter — this is where the trigger earns its keep. GitHub sends a pull_request event for every open, close, sync, label, and edit; the filter narrows it to exactly the ones you want:
{"and": [
  {"==": [{"var": "action"}, "review_requested"]},
  {"==": [{"var": "pull_request.base.ref"}, "main"]},
  {"==": [{"var": "pull_request.draft"}, false]}
]}
Three clauses: only review-request events, only PRs targeting main, never drafts. Events that fail the filter cost nothing — no session is created.

​
3. Validate the filter against real events

Before trusting a filter, check it against payloads GitHub has actually sent. Open Event Log under the Automations group in the sidebar. Filter by source GitHub, then open the Advanced Filter dialog: set the event type to pull_request and paste your JSONLogic expression into the payload filter — the log narrows to the captured events that match. Click any row to inspect the raw payload if a field path isn’t what you expected.

​
4. Turn it on and try it

Save the trigger, then request review on a test PR targeting main. Within moments the event shows up in the events log, the trigger fires, and the message lands in the channel. If it fires too often or too rarely, adjust the filter — the trigger keeps its type and event type; only the expression changes. To pause the automation later without losing the configuration, expand its row on the Automations page and flip the trigger’s enable toggle off. To retire it, delete the trigger — the Expert itself stays usable from the home page.

​
Where To Go Next