Making Cursor and GitHub Play Nice: Automate PR Creation and Issue Linking
Efficiently Linking GitHub Issues to PRs with Cursor + GitHub Actions
If you’ve been playing with Cursor’s background agents in Github, you know they’re blessed with speed and will happily spin up branches while you blink. What they aren’t blessed with is creating the PR for you, nor a tidy way to automatically link that PR back to the original GitHub issue. Small thing, big annoyance. Also the kind of absurdity that multiplies when you have a myriad of branches flying around. (Note: I am referring to the Github/Cursor Integration. This integration allows Cursor to create branches directly in GitHub, even if you never clone or open the repo locally).
Let’s fix it with a little shameless duct tape.
The short version
Cursor background agents can create branches automatically, but they don’t currently open or link a PR back to the originating issue.
A small GitHub Action (https://github.com/exvuma/ai-dev-tasks/blob/main/workflows/on_issue_comment.yml):creates the PR and makes sure the original issue gets linked. Which will
watch for Cursor’s PR-intent breadcrumb (a comment with a branch pattern), capture the issue number, and prepare data for the PR creation step
on signal, open the PR and append “fixes #123” to the PR description
Result: Cursor’s work turns into a proper PR that’s connected to the original issue.
The problem
Cursor’s agents triggered from a GitHub issue run asynchronously and don’t have the right runtime context to stamp a future PR with the originating issue. Crucially, Cursor doesn’t actually create the PR for you. You end up with branches that “obviously” belong to Issue #123, but your reviewer (or future you) has to go spelunking to confirm it. We can do better.
The approach
Two workflows, each doing one job well. No heroism. Yes a little YAML spaghetti, but good news is you can copy paste from the source.
On PR comment or branch breadcrumb (Cursor’s bot leaves a clue)
Trigger: issue_comment on an issue or pull_request, or push with a branch-naming pattern
Action: parse the branch name or comment payload for an issue reference
Store: write the issue number somewhere retrievable in the next step
Side note: if someone wants to parse Cursor’s entire comment to add more context to the PR, I’ll buy you coffee. I have zero desire to parse any more HTML using GitHub Actions 😅
Create and annotate the PR
Trigger: either an explicit workflow dispatch or an automation step after step 1
Action: use the stored breadcrumbs to open a PR on the branch
Update: append “Related Issue: #123” (or “fixes #123” if you want auto-closing) to the PR description in a consistent, scannable format
Separating detection from PR creation keeps each workflow simple and readable. Also, if Cursor changes how it comments or names branches, you only touch the first workflow’s parsing logic. This approach leverages standard GitHub Actions such as actions/github-script or peter-evans/create-pull-request to automate PR creation and annotation.
Why bother
Traceability without nagging people (mainly my vibing alter-ego) to “please paste the issue number”
Cleaner reviews and faster context-switching
Transparent audit trail when you’re triaging after a long week and three coffees
No secrets exposed, everything stays inside GitHub’s walls
What this looks like in practice
You open an issue.
You ask Cursor @cursor fix please.
Cursor spins up a branch and drops a breadcrumb in a comment or via branch naming.
GitHub Actions sees the breadcrumb, extracts the issue number, and creates the PR for you.
When the PR officially opens, the description gets a neat little “Related Issue: #123” line. Reviewers nod approvingly. You resist the urge to add confetti.
Caveats and small delights
Your branch naming convention should carry the issue number. If it doesn’t, choose another consistent breadcrumb to parse.
You must enable PR creation for GitHub Action Runners on your workflow and if an organization repo, then at the org level. (This I suspect might be the reason the Cursor team didn’t implement this by default.)
You can get fancy by linking multiple issues, but start with the boring 80 percent case.
Add a label like “linked-to-issue” if you want visual confirmation without opening the description. It’s optional, but can provide instant feedback.
Cursor may expand its GitHub integration features in the future, so some aspects of this workaround could become redundant later.
Wrap
Cursor is great at doing work while you’re not looking. My mind operates on so many tracks with programming using AI. It’s hard to keep up with myself these days. This workflow adds just enough structure to keep your PRs honest. Minimal ceremony. Max payoff. And yes, this is the kind of thing that saves five minutes a day and a handful of gray hairs a quarter.
If you want to further automate Cursor, I toyed with having it automatically run on issue creation. However, with how frequently I’m merging PRs, I learned actually prefer to trigger Cursor manually from an issue. The source code for this is available here (https://github.com/exvuma/ai-dev-tasks/blob/main/workflows/on_issue_comment.yml).
By the way, I’ve implemented this and many other workflows while designing a party planning AI application. If you’re interested in my work, or better yet, have a party you’re planning, please visitpartysprout.ai to be a part of my founding beta! Happy vibing!