DEV Community: Swrly

Build a Daily Standup Digest with Swrly

Swrly — Sun, 05 Apr 2026 20:41:14 +0000

Daily standups are useful in theory. In practice, half the team forgets to post, someone copies yesterday's update, and the channel fills with messages nobody reads. The information exists -- it is in your commits and your tickets. The problem is gathering it.

This tutorial builds a Swrly workflow that runs every weekday morning, pulls the last 24 hours of activity from GitHub and Linear, summarizes it into a readable digest, and posts it to Slack. No one has to remember to write anything.

What You Will Build

A 5-node workflow that:

Fires automatically at 8:00 AM on weekdays via a cron trigger
Pulls recent commits from GitHub (last 24 hours)
Pulls completed tickets from Linear (last 24 hours)
Runs an AI agent that combines both data sources into a concise standup digest
Posts the digest to #standup in Slack

The result is a single Slack message every morning that tells the team what shipped yesterday. No meetings, no manual updates, no forgotten standups.

Prerequisites

A Swrly account (Pro plan or higher -- cron triggers require a paid plan)
A GitHub repository (or organization) with recent commit activity
A Linear workspace with completed issues
A Slack workspace with a #standup channel
Your Claude Code session token (Settings > API Keys)
GitHub, Linear, and Slack integrations connected in Settings > Integrations

Step 1: Create the Swirl and Add a Cron Trigger

Create a new swirl from the dashboard and name it "Daily Standup Digest."

Drag a Trigger node onto the canvas. Click it and set the trigger type to Cron. Configure the schedule:

Cron Expression: 0 8 * * 1-5
Timezone: Your team's timezone (e.g., America/New_York)

This expression means "at 08:00, Monday through Friday." The cron scheduler in Swrly uses standard 5-field cron syntax. Here is a quick breakdown:

Build a Customer Support Triage Agent in 15 Minutes

Swrly — Sun, 05 Apr 2026 20:41:10 +0000

Every support team has the same bottleneck: someone reads each incoming ticket, decides how urgent it is, and routes it to the right channel. It is repetitive, time-sensitive, and easy to get wrong at 2am. An AI agent can do this classification in seconds, consistently, around the clock.

In this tutorial, you will build a support triage workflow in Swrly that reads incoming tickets, assigns a priority from P1 to P4, and routes them to the appropriate Slack channel. The whole thing takes about 15 minutes.

What You Will Build

A 5-node workflow that:

Receives support tickets via a webhook from your support form or helpdesk
Runs an AI classifier agent that reads the ticket and assigns a priority (P1-P4)
Evaluates the priority with a condition node
Routes P1/P2 tickets to #urgent-support in Slack
Routes P3/P4 tickets to #support-queue in Slack

By the end, new support tickets will be automatically triaged and routed to the right people without anyone manually reading and sorting them.

Prerequisites

A Swrly account (free plan works)
A Slack workspace with two channels: #urgent-support and #support-queue
Your Claude Code session token (paste it in Settings > API Keys)
Slack integration connected in Settings > Integrations
A support form, helpdesk, or any system that can send webhooks (Typeform, Intercom, Zendesk, or even a simple HTML form with a backend)

Step 1: Create the Swirl and Add a Webhook Trigger

Log into Swrly and click New Swirl from the dashboard. Name it "Support Triage Bot."

You will land on the visual builder with an empty canvas. Drag a Trigger node onto the canvas. Click it to open the configuration panel and set the trigger type to Webhook. Copy the generated webhook URL:

https://swrly.com/api/v1/webhooks/trigger/wh_abc123def456

This URL is what your support form will POST to. The payload should include the ticket details. A typical payload looks like this:

{
  "ticket_id": "TKT-4821",
  "subject": "Cannot access billing dashboard",
  "body": "I have been trying to access the billing page for the last 3 hours. Every time I click on Settings > Billing, the page shows a white screen. I am on the Enterprise plan and this is blocking our team from updating payment details before our renewal tomorrow.",
  "customer_email": "ops@acmecorp.com",
  "plan": "enterprise",
  "submitted_at": "2026-04-03T14:32:00Z"
}

Point your support form's webhook to this URL. If you are using Zendesk, Intercom, or Freshdesk, check their webhook/automation settings to forward new tickets here.

Step 2: Add the Classifier Agent

Drag an Agent node onto the canvas and connect it to the trigger node by drawing an edge from the trigger's output port to the agent's input port. Name this agent Ticket Classifier.

Click the agent node to configure it. The system prompt is the core of this workflow. Here is one that works well:

You are a customer support triage specialist. You receive incoming
support tickets and classify them by priority.

Read the ticket subject, body, customer plan, and any other context
provided. Assign exactly one priority level:

- P1 (Critical): Service is down, data loss, security incident, or
  billing blocked for Enterprise customers. Immediate action required.
- P2 (High): Major feature broken, significant degradation, or
  billing issues for any paid plan. Response within 1 hour.
- P3 (Medium): Feature not working as expected, minor bugs, how-to
  questions from paid customers. Response within 4 hours.
- P4 (Low): General questions, feature requests, feedback, free-tier
  how-to questions. Response within 24 hours.

Consider the customer's plan when classifying. An Enterprise customer
reporting a broken feature is P2, not P3. A free-tier user asking a
how-to question is P4, not P3.

You MUST end your response with exactly one of these lines:
- "PRIORITY: P1"
- "PRIORITY: P2"
- "PRIORITY: P3"
- "PRIORITY: P4"

Before the priority line, write 2-3 sentences explaining your
reasoning. Reference specific details from the ticket.

Under Agent Settings, configure:

Max Turns: 3 -- this agent does not need tools, it is doing pure classification based on the input text. Three turns is plenty of headroom.
Accumulate Context: enabled -- ensures the agent sees the full trigger payload.
Output Format: text -- the condition node will parse the output text for the priority string.

This agent does not need any MCP tools. It is a reasoning-only agent that reads the ticket content from the trigger payload and produces a classification. No external API calls required.

For the example ticket above (enterprise customer, billing page broken, renewal tomorrow), the agent would produce something like:

This is an Enterprise customer reporting that the billing dashboard
is completely inaccessible, with a renewal deadline tomorrow. The
combination of a broken core feature and time-sensitive business
impact for a top-tier customer makes this critical.

PRIORITY: P1

Step 3: Add the Condition Node

Drag a Condition node onto the canvas and connect it to the Ticket Classifier's output. This node decides which Slack channel receives the ticket.

Click the condition node and configure the rule:

Field: output (the classifier agent's text output)
Operator: contains
Value: PRIORITY: P1

Wait -- that only catches P1. You need P2 as well. Here is the approach: set the condition to check if the output contains PRIORITY: P1 or PRIORITY: P2.

Since condition nodes evaluate a single rule, use the contains operator with the value PRIORITY: P1. Then add a second condition rule with PRIORITY: P2 and set the rule logic to OR.

Alternatively, you can use a simpler approach. Structure your agent prompt so that high-priority tickets output a specific keyword. Update the classifier prompt to also include this line:

After the PRIORITY line, add "ROUTE: URGENT" for P1/P2 or
"ROUTE: STANDARD" for P3/P4.

Then configure the condition node as:

Field: output
Operator: contains
Value: ROUTE: URGENT

If the output contains "ROUTE: URGENT," the workflow follows the true branch (P1/P2). Otherwise, it follows the false branch (P3/P4). Clean and reliable.

Step 4: Add the Slack Integration Nodes

Now add two Integration nodes, one for each branch.

Urgent branch (true): Drag a Slack integration node and connect it to the condition's true output port. Configure it:

Integration: Slack
Action: slack_send_message
Channel: #urgent-support
Message template:

:rotating_light: *P1/P2 Support Ticket*

*Ticket:* {{trigger.ticket_id}}
*Subject:* {{trigger.subject}}
*Customer:* {{trigger.customer_email}} ({{trigger.plan}} plan)

*AI Triage Summary:*
{{ticket_classifier.output}}

_Please respond within 1 hour. Triage powered by Swrly._

Standard branch (false): Drag another Slack integration node and connect it to the condition's false output port. Configure it:

Integration: Slack
Action: slack_send_message
Channel: #support-queue
Message template:

*P3/P4 Support Ticket*

*Ticket:* {{trigger.ticket_id}}
*Subject:* {{trigger.subject}}
*Customer:* {{trigger.customer_email}} ({{trigger.plan}} plan)

*AI Triage Summary:*
{{ticket_classifier.output}}

_Triage powered by Swrly._

Notice that {{trigger.*}} pulls fields from the webhook payload, while {{ticket_classifier.output}} pulls the AI agent's classification output. The template resolver handles the variable substitution at runtime using slugified node labels.

Step 5: Test the Workflow

Click Save in the top bar. Before connecting real ticket sources, test the workflow end-to-end.

Click Save and Run and provide a test payload. Try a P1 scenario first:

{
  "ticket_id": "TEST-001",
  "subject": "Production API returning 500 errors",
  "body": "All API endpoints have been returning 500 errors for the past 20 minutes. Our entire application is down. We are on the Enterprise plan and this is affecting thousands of users.",
  "customer_email": "cto@bigcorp.com",
  "plan": "enterprise",
  "submitted_at": "2026-04-03T15:00:00Z"
}

Watch the execution overlay on the canvas. The trigger fires, the classifier agent thinks for a few seconds, the condition evaluates to true, and a message appears in #urgent-support. The whole run should complete in under 15 seconds.

Now test a P4 scenario:

{
  "ticket_id": "TEST-002",
  "subject": "How do I export my data?",
  "body": "Hi, I am on the free plan and was wondering if there is a way to export my project data to CSV.",
  "customer_email": "user@example.com",
  "plan": "free",
  "submitted_at": "2026-04-03T15:01:00Z"
}

This time the condition should evaluate to false, and the message lands in #support-queue. Check both channels to confirm the messages look correct and the template variables resolved properly.

Next Steps

Once the basic triage is working, here are some ways to extend it.

Add a database logging step. Insert an integration node before the Slack notifications that writes the ticket ID, priority, and timestamp to a Postgres or Airtable table. This gives you a triage audit trail.

Wire it to your ticketing system. Add integration nodes that call the Zendesk or Linear API to automatically set the priority field on the ticket. The AI classified it -- now the classification is reflected in your actual helpdesk.

Add an approval node for P1 tickets. For critical incidents, insert an Approval node between the classifier and the Slack notification. A team lead confirms the P1 classification before the urgent alert fires. This prevents false alarms from waking someone up at 3am.

Build a feedback loop. Track cases where a human overrides the AI's classification. Over time, refine your system prompt based on the patterns. If the agent consistently over-classifies free-tier issues as P3, tighten the prompt guidance for that case.

Add sentiment analysis. Extend the classifier prompt to also detect customer sentiment (frustrated, neutral, satisfied). Route frustrated customers to a senior support rep regardless of technical priority.

The core pattern here -- webhook in, AI classification, conditional routing, notification out -- applies to far more than support tickets. Use it for lead scoring, content moderation, alert triage, or any workflow where you need fast, consistent categorization at scale.

Build a PR Reviewer Workflow in 10 Minutes

Swrly — Sun, 05 Apr 2026 15:39:30 +0000

One of the most common tasks engineering teams automate with Swrly is PR review. Not replacing human reviewers — augmenting them. An AI agent reads the diff, flags potential issues, and routes the result to the right Slack channel. The human reviewer gets a head start. The team gets notified instantly.

In this tutorial, you will build this workflow from scratch. It takes about 10 minutes.

What You Will Build

A 5-node workflow that:

Triggers automatically when a PR is opened on GitHub
Runs an AI code reviewer that analyzes the diff
Checks whether the reviewer approved or flagged issues
Posts to #shipped if approved, or #reviews if changes are needed

By the end, you will have a fully automated PR review pipeline running on your own Claude Code subscription.

Prerequisites

A Swrly account (free plan works)
A GitHub repository you own or have admin access to
A Slack workspace with two channels: #shipped and #reviews
Your Claude Code session token (paste it in Settings > API Keys)
GitHub and Slack integrations connected in Settings > Integrations

Step 1: Create a New Swirl and Add a Webhook Trigger

Log into Swrly and click New Swirl from the dashboard. Name it "PR Review Bot."

You will land on the visual builder — an empty canvas with a sidebar on the left showing available node types.

Drag a Trigger node onto the canvas. Click it to open the configuration panel. Set the trigger type to Webhook and copy the generated webhook URL. It will look something like:

https://swrly.com/api/v1/webhooks/trigger/wh_abc123def456

Now go to your GitHub repository. Navigate to Settings > Webhooks > Add webhook. Paste the Swrly webhook URL. Set the content type to application/json. Under "Which events would you like to trigger this webhook?", select Pull requests only. Save the webhook.

Back in Swrly, your trigger node is now listening. Every time a PR is opened, reopened, or synchronized on that repo, this workflow will fire.

Step 2: Add a Code Reviewer Agent

Drag an Agent node onto the canvas and connect it to the trigger node by drawing an edge from the trigger's output port to the agent's input port.

Click the agent node to configure it. Set the name to Code Reviewer. Now write the system prompt — this is the most important part. Here is a prompt that works well:

You are a senior code reviewer specializing in TypeScript and React
applications. When given a pull request, you must:

1. Fetch the list of changed files using the github_list_pr_files tool
2. For each changed file, fetch its content using github_get_content
3. Analyze the changes for:
   - Security vulnerabilities (SQL injection, XSS, credential exposure)
   - Performance issues (unnecessary re-renders, missing memoization, N+1 queries)
   - Error handling gaps (uncaught promises, missing try/catch blocks)
   - Code style violations (inconsistent naming, dead code, missing types)
4. Write a concise review summary

IMPORTANT: End your review with exactly one of these two lines:
- "VERDICT: APPROVED" if the code is ready to merge
- "VERDICT: NEEDS_REVISION" if changes are required

After the verdict, include a brief summary paragraph explaining your decision.

Under Agent Settings, configure:

Max Turns: 15 — complex PRs may require multiple tool calls to fetch all files
Accumulate Context: enabled — the agent retains context from the trigger payload, which includes the PR number and repository information
Tools: Enable github_list_pr_files, github_get_content, and github_get_pull_request

The maxTurns setting is important here. A PR with 8 changed files requires at least 9 tool calls (one to list files, one per file). Setting it too low will cut the agent off mid-review. Setting it too high wastes tokens on edge cases. 15 is a good default for most review workflows.

Step 3: Understanding the GitHub Integration

When the Code Reviewer agent runs, it has access to GitHub MCP tools. Here is what each one does in this workflow:

github_list_pr_files — Returns the list of files changed in the PR, including the filename, status (added/modified/removed), and the number of additions and deletions. The agent uses this to know which files to inspect.

github_get_content — Fetches the full content of a specific file from the repository. The agent calls this for each changed file to read the actual code.

github_get_pull_request — Retrieves PR metadata: title, description, author, base branch, head branch, and labels. Useful for context about what the PR is supposed to do.

You do not need to write any code to use these tools. The agent calls them automatically based on its system prompt. Swrly handles authentication using your connected GitHub integration — the agent uses your GitHub token, scoped to the repositories you have authorized.

Step 4: Add a Condition Node for Branching

This is where the workflow gets interesting. Drag a Condition node onto the canvas and connect it to the Code Reviewer's output.

Click the condition node and configure the rule:

Field: output (the agent's text output)
Operator: contains
Value: VERDICT: APPROVED

The condition node evaluates this rule against the Code Reviewer's output. If the output contains "VERDICT: APPROVED," the workflow follows the true branch. Otherwise, it follows the false branch.

Swrly condition nodes support six operators:

Operator	Use case
`equals`	Exact string match
`not_equals`	Inverted exact match
`contains`	Substring search (what we are using)
`not_contains`	Inverted substring search
`greater_than`	Numeric comparison
`less_than`	Numeric comparison

For this workflow, contains is the right choice. The agent's output is free-form text, and we are looking for a specific verdict string within it. Using equals would fail because the output contains much more than just the verdict line.

Step 5: Add Slack Notifications on Both Branches

Now add two Integration nodes — one for each branch of the condition.

Approved branch (true): Drag a Slack integration node and connect it to the condition's true output port. Configure it:

Integration: Slack
Action: slack_send_message
Channel: #shipped
Message template:

:white_check_mark: *PR Auto-Review: APPROVED*

*Repository:* {{trigger.repository.full_name}}
*PR:* #{{trigger.pull_request.number}} — {{trigger.pull_request.title}}
*Author:* {{trigger.pull_request.user.login}}

The automated code review found no significant issues. This PR is ready for human review and merge.

_Review powered by Swrly_

Needs revision branch (false): Drag another Slack integration node and connect it to the condition's false output port. Configure it:

Integration: Slack
Action: slack_send_message
Channel: #reviews
Message template:

:warning: *PR Auto-Review: NEEDS REVISION*

*Repository:* {{trigger.repository.full_name}}
*PR:* #{{trigger.pull_request.number}} — {{trigger.pull_request.title}}
*Author:* {{trigger.pull_request.user.login}}

*Review Summary:*
{{steps.code_reviewer.output}}

_Review powered by Swrly_

Notice the template syntax: {{trigger.*}} references the webhook payload from step 1, and {{steps.code_reviewer.output}} references the Code Reviewer agent's output. Swrly's template resolver handles the variable substitution at runtime.

Step 6: Save, Test, and Deploy

Click Save in the top bar (or press Cmd+S). Your workflow is now persisted.

Before connecting it to real PRs, test it with a single node. Click the Code Reviewer agent node, then click the Test button in the configuration panel. Swrly will run just that node with a sample payload. Verify that it fetches files, analyzes them, and produces a verdict.

You can also use Save and Run to execute the entire workflow end-to-end with a test payload. The execution overlay will light up each node as it runs — you can watch the trigger fire, the agent think, the condition evaluate, and the Slack message send, all in real time on the canvas.

Once you are satisfied, open a real PR on the connected repository. The webhook will fire, the workflow will run, and within 30-60 seconds you will see a message in the appropriate Slack channel.

Tips for Production Use

Tune maxTurns based on your codebase. If your PRs typically touch 15+ files, increase it to 20-25. Monitor token usage in the run history to find the sweet spot.

Use accumulateContext for multi-agent chains. If you add a second agent after the Code Reviewer (for example, a "Documentation Checker" that verifies README updates), enable context accumulation so the second agent can see the first agent's findings.

Add an approval node for critical repos. For production repositories, insert an Approval node before the Slack notification. A team lead reviews the AI's verdict before it is posted. This adds a human checkpoint without losing the automation benefit.

Create separate workflows for different event types. Rather than one workflow that handles opened, synchronize, and closed events, create focused workflows for each. A review workflow for opened, a re-review workflow for synchronize, and a cleanup workflow for closed.

Monitor with run history. Every execution is logged with timestamps, token usage, and full input/output for each node. If the reviewer starts producing inconsistent verdicts, check the run history to see what changed in the PR payloads.

What You Built

In about 10 minutes, you built an automated PR review pipeline that:

Triggers on real GitHub events with no polling
Runs an AI code reviewer with access to your repository
Branches based on the review outcome
Notifies the right people in the right channel

No Python scripts. No cron jobs. No infrastructure to manage. Just a visual workflow running on your own Claude Code subscription.

Try It Yourself

Sign up free at swrly.com and build your first workflow. The PR reviewer is a great starting point, but teams are using Swrly for bug triage, documentation generation, deployment pipelines, customer support routing, and much more.

Questions about this tutorial? Reach out at hello@swrly.com or open a discussion on GitHub.

Introducing Swrly — Visual AI Agent Orchestration for Dev Teams

Swrly — Sun, 05 Apr 2026 15:38:31 +0000

Hey Dev.to community!

Excited to share Swrly — an AI agent orchestration platform for engineering teams.

The problem

Building AI agent workflows usually means a tangle of Python scripts, each agent in its own cron job, no visibility into what is happening, and debugging means reading logs line by line.

What Swrly does

Swrly gives you a visual drag-and-drop builder where you create named AI agent teams (we call them swirls). Each agent has a clear role — Code Reviewer, PR Summarizer, Incident Responder — and you wire them together with conditions, triggers, and integrations.

What makes it different:

Visual builder — drag agents onto a canvas, connect them, set triggers
47+ connectors — GitHub, Slack, Linear, Jira, Notion, Sentry, PagerDuty, databases, and more
BYOK (Bring Your Own Key) — use your own AI subscription. No per-token markup.
Full observability — watch every agent think in real time
Smart triggers — manual, webhook, cron, API, or event-based

Free to start

Starter plan is genuinely free — 50 runs/month, 5 agents, 5 swirls. No credit card required.

We are just getting started and would love feedback. If you are automating anything with AI — PR reviews, incident triage, deploy notifications — I would love to hear what problems you are running into.

Check it out at swrly.com

I will be sharing tutorials here on building specific workflows. First up: building a PR review pipeline in 10 minutes.

Happy building!