We have been exploring the possibility of implementing cursor automations. However, the triggering logic appears to be quite restrictive. Currently, automations can only be set up via linear trigger when they are exclusively created within a specific project. We aim to establish automations within a particular team only in specific triage statuses, with specific priority levels. Additionally, we want to implement an automation to monitor logs from posthog. Unfortunately, it seems that none of these functionalities are currently available. Am I missing any settings? Additionally, when setting it up, even default prompts for automations are displaying warnings about unconfigured integrations due to the information mentioned in the prompt. For example, requesting the automation bot to include a specific title in a PR appears to be unavailable because an automation seems to be missing. It does not specify which one or how to resolve the issue. Consequently, the prompt became nearly useless once I addressed all the multiple warnings about it.
hey @Deni03, thanks for laying this out. You’re not missing a hidden settings screen for most of this (Linear triggers in Automations) are still fairly narrow.
Today the Linear triggers are Issue created, Status changed, and End of cycle, scoped mainly by team/project in the trigger UI, not status or priority pickers. If you need “only these triage statuses / priorities,” the practical workarounds are Linear-side triage rules on the project (Linear integration → Triage rules), or a Status changed trigger plus a prompt rule to exit when status/priority doesn’t match (it’ll still consume a run, same pattern as multi-project setups in this thread).
For PostHog there’s no native trigger yet, use a Webhook automation (PostHog CDP Destination → POST to the automation URL; payload lands at the bottom of your prompt) or enable PostHog MCP as a tool on a repo-less automation. (attach screenshot: trigger = Webhook, Tools = MCP server)
On the default-prompt integration warnings: those usually mean the prompt references a Tool that isn’t enabled or connected (e.g. PR title instructions need Open pull request plus GitHub + a repo on the automation), not a separate missing automation.
Can you share a screenshot of your trigger config and one warning line? Also confirm Linear + GitHub under dashboard → Integrations and whether the automation is Team Owned vs private.
Hope that helps, reply with those screenshots and we can pin down the exact warning.
Hey, point by point:
Linear triggers. Right now you can use Issue created, Status changed, and End of cycle, scoped by team or project. There are no separate pickers for triage status or priority yet. Practical workarounds:
- Use Linear-side triage rules on the project to filter before the trigger fires. See Linear integration → Triage rules: Linear | Cursor Docs
Keep in mind Triage Rules in Linear are only on the Business or Enterprise plan. - Or use the Status changed trigger plus a rule in the prompt like “exit if status or priority doesn’t match”. The run will still count, but the logic will stop.
PostHog. There is no native trigger. Two options:
- Webhook automation using PostHog CDP Destination to POST to the automation URL. The payload will show up at the end of the prompt.
- Or use PostHog MCP as a tool in a repo-less automation.
Warnings about unconfigured integrations. This usually means your prompt references a tool that is not enabled or not connected. Example: instructions about PR titles require Open pull request plus GitHub plus a repo on the automation. It usually does not mean you are missing some separate automation.
To debug your exact warning, please share a screenshot of the trigger config and the warning line. Also confirm that Linear and GitHub are connected in dashboard → Integrations https://cursor.com/dashboard and whether the automation is Team Owned or private.
More granular Linear trigger filtering by status or priority is on the roadmap, but I can’t share an ETA. There is a related request about trigger granularity here: Increase Cursor Automations trigger fidelity
That one is more about path filtering for GitHub push, not exactly your Linear case. It still makes sense to create a separate request specifically for filtering Linear by triage status or priority so your request is tracked directly.