Jira + Cursor Agent Workflow — Achievable in Production Today?

Question

Looking to validate a Jira + Cursor agent workflow

We're mapping out the workflow below and want to sanity-check it against what others have actually gotten working in production :

Current setup: Jira only — no Confluence, and we're on SVN today while evaluating a move to Git specifically to unlock this.

Questions for anyone who's built something similar:

* Is this end-to-end flow realistic to achieve, or does it break down at a specific stage in practice?
* What actually has to be configured/integrated to get from "spec generation" to "agent triggered" reliably (MCP setup, automation rules, webhooks, etc.)?
* How efficient is the generated code in practice — how much rework typically happens at the human review stage?
* What's the cost/credit impact of running this at scale (Rovo credits, agent usage, CI minutes)?
* Has anyone made this work without Bitbucket/GitHub — i.e., is SVN a hard blocker, or have you seen workarounds?
* Is it possible with out confluence & Rovo

Appreciate any real-world experience — especially where the diagram above doesn't match reality.

Glad to have your suggestions or experience!

Thank you.

Mahanth Prudhvi P · Answer

Hi @Nikola Perisic

Thank you for the detailed response and suggestions — really helpful info.

May I know if you're using a similar AI-driven workflow yourself, or if this is based on personal/team experience implementing something like this in production? Would be great to hear how it's held up in practice.

Also, how good is this approach at taking a basic requirement doc and improvising it into a well-structured, clearly explained requirement doc — and then attaching that back to the Jira ticket? We're currently using Google Docs for this, so curious how well that fits into the flow, or if there's a better way to handle it.

And from that same structured doc, can the flow continue on into spec generation and code building — i.e., does it stay as one continuous pipeline from raw requirement to working code, or does it break anywhere?

Thanks again!

Nikola Perisic · Answer

Hi @Mahanth Prudhvi P Yes, the high-level workflow shown in the image is sound and reflects modern "spec-driven agentic engineering," but your current infrastructure stack (Jira-only + SVN) will block several key automated links. 1. Is this end-to-end flow realistic, or does it break down? The concept is realistic and widely deployed, but it typically breaks down at two specific boundaries: * Spec Generation $\rightarrow$ Agent Execution: If the generated specs (spec.md, plan.md, tasks.md) live solely inside a Jira issue description/comment, the agent needs a seamless way to pull them into its workspace. * Agent Execution $\rightarrow$ Headless PR/MR: Cursor Cloud Agents require native Git remote integration (GitHub/GitLab/Bitbucket) to pull the codebase, spin up a headless sandbox, execute changes, run tests, and programmatically open a PR. 2. Is it possible without Confluence & Rovo? Yes, absolutely. Neither Confluence nor Rovo is required. * Confluence alternative: Markdown files placed directly in the repository (e.g., inside .cursor/specs/ or .github/specs/), or structuring the spec generation directly inside the Jira ticket body/custom fields using Jira Automation, works just as well—and often better, as git-versioned specs prevent context drift. * Rovo alternative: You do not need Atlassian Rovo credits or native Rovo agents. You can use Jira Webhooks + Jira Automation or the Atlassian Model Context Protocol (MCP) server locally/headlessly to feed Jira ticket details directly into Cursor. 3. Is Subversion (SVN) a hard blocker? Yes, for automated cloud agent execution, SVN is a functional blocker. * Why: Cursor Cloud Agents and standard CI/CD PR/MR triggers rely explicitly on Git concepts (branches, pull request events, Git webhooks, and git clone/git push). * Workarounds (if you stay on SVN): You would have to abandon the automated/headless agent step. Instead, developers would need to open Cursor locally, manually run an local agent/script that fetches the Jira issue over API, execute the changes on their local SVN working copy, and manually run svn commit. Moving to Git is strongly recommended if you want the automated flow pictured in the diagram. 4. What must be configured to get from "Spec Generation" to "Agent Triggered"? To automate the transition between teal (agent) and gray (human/process) steps reliably, set up the following setup: A. Webhook & Automation Trigger * Jira Automation Rule: Create a trigger on status change (e.g., when a ticket moves to In Dev or Ready for AI). * Jira Webhook / MCP Server:* Option A (Cloud / Headless): Jira Automation sends an HTTP POST webhook to a proxy or fires the Cursor Cloud Agent API, passing the Jira Ticket Key, requirements, and target Git repository. * Option B (Local / Developer Machine): Configure the Atlassian MCP Server in Cursor. When a developer triggers Cursor, the agent calls get_jira_issue via MCP to retrieve requirements instantly. B. Repo-Level Agent Configuration * System Rules (.cursorrules or AGENTS.md): Place project rules in the repository root so the triggered agent automatically understands coding standards, linting, and build commands. * Cursor Agent Hooks (.cursor/hooks.json): Configure pre/post tool hooks to run linter checks, formatters, or local tests inside the agent's sandbox before it completes execution. 5. How efficient is generated code & rework at Human Review? * Rework expectations: Expect 20% to 40% rework initially. * Where agents succeed: Boilerplate, CRUD endpoints, unit tests, refactoring, and well-scoped bug fixes with clear acceptance criteria. * Where agents fail (rework spikes):* Undocumented legacy codebase patterns. * Incomplete acceptance criteria (agents will hallucinate missing requirements). * Complex multi-file architecture changes without an explicit plan.md. * Key to reducing rework: The quality of the Spec Generation step. If plan.md and tasks.md clearly break down file-by-file changes before code generation starts, human rework drops significantly. 6. What is the cost/credit impact at scale? * AI / Cursor Credits:* Headless agent runs consume significantly more tokens than simple inline auto-complete because the agent iterates through read/write/test loops autonomously. * On Cursor Business/Enterprise usage-based billing, budget roughly $0.20 to $1.50 per automated ticket attempt, depending on codebase context size and the underlying LLM (e.g., Claude 3.5 Sonnet / O3-mini). * Atlassian / Rovo: $0 if you bypass Rovo and use custom Jira Automation webhooks + standard Jira Cloud API/Atlassian MCP. * CI/CD Minutes (GitHub Actions / GitLab CI):* Expect a minor increase (~15-20%). Because the agent runs tests locally inside its sandbox before opening a PR/MR, the PR opened in CI is usually pre-tested and rarely fails on trivial syntax/lint errors, saving wasted CI retries.