Event Triggers

Run a custom prompt in response to GitHub and Linear events — automated audits, triage, summaries, and more.

Overview

Event triggers turn Cygent into a reactive agent. When something happens in GitHub or Linear, an event fires, and Cygent runs a prompt you wrote. The prompt can do anything Cygent can do — run an audit, triage an issue, post a summary, open a PR — so an event trigger is essentially a chain: "when X happens, run this workflow."

Think of it as the bridge between passive automation (auto-review on PR open, which is built in) and scheduled tasks (time-driven). Event triggers are event-driven.

Event catalog

Creating a trigger

Example — Auto-audit on push

The goal: every time something lands on main, kick off a full CARA audit. Catch the regression the moment it gets merged, not next Monday.

Trigger config:

• Event: Push
• Project scope: your-protocol-repo
• Branch filter: main
• Prompt:

  Run a full security audit on the latest commit to main.
  Compare findings to the previous audit — highlight anything new or newly resolved.
  If any Critical or High finding is new, tag @security-oncall in the channel summary.
  

• Notifications: On → #cygent-reviews

What the user sees: Within a minute of a merge to main, the review channel shows a "New audit running on my-repo @ abc1234" message. Progress ticks live. When it completes, the summary lands in the channel with "2 new High findings since last audit" called out in bold and @security-oncall pinged if the prompt logic hit.

Example — Triage new Linear issues

The goal: when a new Linear issue gets filed, have Cygent decide whether it's security-related, add appropriate labels, and either escalate or quietly close spam.

Trigger config:

• Event: Linear → Issue created
• Project scope: All projects
• Prompt:

  A new Linear issue was created: \{\{issue.title\}\}.
  Read the description.
  If it describes a security vulnerability: add the `security` label, set priority to High, and post a summary to #security.
  If it's unrelated to security: leave it alone.
  If it reads like spam or an AI-generated bug bounty report that duplicates a known finding: add the `spam` label and close it with a short reason.
  

• Notifications: On → #security (only fires when the issue is security-related)

What the user sees: A new Linear issue lands. Within ~30 seconds the issue has labels applied, priority set, and either gets closed (if spam) or surfaces in #security with a one-paragraph summary Cygent wrote. Humans only look at the ones that made it to #security.

Managing bug bounty and issue inflows is a real cost center for protocol teams — especially with the recent flood of AI-generated low-quality submissions. Cygent has enough protocol context to spot spam and invalid reports instantly, and enough judgment to not close real issues.

Example — Merged PR digest

The goal: every time a PR merges, generate a one-paragraph summary of what changed and post it to the team channel so people who weren't in the review still have context.

Trigger config:

• Event: PR closed (merged = true)
• Project scope: Your main protocol repos
• Prompt:

  PR #\{\{pr.number\}\} (\{\{pr.title\}\}) just merged on \{\{project.name\}\}.
  Write a one-paragraph summary of what changed from a security and architecture standpoint.
  Include: what was added, what was removed, any state variables touched, any access-control changes.
  If the PR resolved any Cygent findings, list them.
  Keep it under 6 lines.
  

• Notifications: On → #engineering

What the user sees: A PR merges. A minute later #engineering gets a Cygent message like:

PR #142 — Add WBTC collateral support merged on ghostlend. Added addSupportedToken call in Vault.sol with onlyOwner modifier. Registered WBTC with its 8-decimal Chainlink feed; decimal normalization added to getCollateralValue. Liquidation threshold for WBTC set to 70% (vs 80% for WETH) to account for volatility. Resolves findings M-4, M-5.

Everyone on the team knows what shipped without having to open the PR.

Patterns and anti-patterns

Debugging triggers

Every trigger run is recorded in the Activity tab with the event that fired it, the prompt that ran, and the output. If a trigger seems to be missing events:

• Check the event filter — a "PR closed" trigger only fires on close, not open.
• Check the project scope — repos added after the trigger was created aren't automatically included.
• Check GitHub webhook delivery in the GitHub App settings — if webhooks are failing, Cygent never saw the event.

Related