JiraGPT Next: AI Copilot for Jira
- JiraGPT Next is a natural-language interface that transforms project queries into JQL, reducing reliance on manual dashboard creation.
- It employs a three-phase processing pipeline—JQL generation, field selection, and answer synthesis—ensuring retrieval-grounded responses.
- Evaluation shows improved accuracy with detailed prompt engineering, while also highlighting challenges in reliability, token cost, and data privacy.
JiraGPT Next is a prototype copilot for Jira that uses GPT models to let project managers ask questions about project data in natural language and to transform those questions into concrete Jira Query Language (JQL) queries and, when needed, natural-language analytical answers. It is conceived as an add-on for Jira, implemented as a web application sitting next to a Jira instance, and evaluated primarily as a natural-language interface for Spanish-language Jira environments in public administration contexts associated with LKS Next GobTech. In a broader technical framing, it belongs to the class of next-generation information retrieval assistants that move beyond document finding toward semantic interpretation, synthesis, and task-oriented assistance, while remaining constrained by concerns around hallucination, efficiency, privacy, and interpretability (Garcia-Escribano et al., 30 Sep 2025, Huang et al., 2024).
1. Definition, motivation, and operational scope
JiraGPT Next addresses a familiar difficulty in project management: Jira environments accumulate large volumes of issues, epics, sprints, assignees, priorities, dates, and status transitions, but effective access to that information often depends on command of JQL or on predesigned dashboards. The prototype is intended to reduce that dependency by allowing questions such as “How many issues were closed last month?”, “How many high-priority bugs are assigned to Alice and still open?”, or “How many tasks created this month are in progress?” to be expressed directly in natural language rather than through explicit query syntax (Garcia-Escribano et al., 30 Sep 2025).
The system is designed to hide the complexity of Jira’s data model and JQL syntax while supporting both basic retrieval and more complex reasoning. “Basic retrieval” denotes queries whose answer can be obtained by executing a JQL filter and showing the resulting issues. “Complex reasoning” denotes questions that require aggregation, counting, distinct-value analysis, or other post-retrieval interpretation over Jira’s JSON output. This distinction is fundamental to the prototype’s workflow and to its cost model, because complex questions require multiple GPT calls rather than only one.
Its conceptual relevance extends beyond query convenience. The broader literature on ChatGPT in information retrieval characterizes GPT-4-class systems as shifting IR from “retrieve documents” to “understand, synthesize, and act on information.” In that sense, JiraGPT Next is not merely a natural-language front-end for JQL; it is an instance of a task-oriented assistant that interprets user intent, produces structured tool calls, and returns explanatory answers grounded in retrieved enterprise data (Huang et al., 2024).
2. System architecture and three-phase processing pipeline
JiraGPT Next is implemented as a web application with a Streamlit front-end and a Python back-end. It communicates with a Jira instance through the Jira API and with OpenAI’s GPT models through the public API; the experiments reported for the prototype use GPT-3.5 during September and October 2023. The architecture is explicitly multi-step: GPT is not used once as a monolithic oracle, but three times for distinct subtasks—JQL generation, field selection, and answer generation (Garcia-Escribano et al., 30 Sep 2025).
The first phase translates a user’s natural-language question into JQL. The second phase inspects the user’s question and selects only the Jira JSON fields necessary to answer it. The third phase combines the reduced JSON and the original question to generate a concise natural-language answer. Functionally, the mapping is described as
Here, denotes the user query, the Jira result set, the selected fields, and the final answer.
This pipeline produces two distinct operational modes. In basic mode, only Phase 1 is used: a JQL query is generated, executed, and the resulting issues are displayed directly, along with the JQL statement, the Jira fields involved, and token and cost information. In complex mode, all three phases are invoked. A typical example is the question “¿Cuántas personas tienen asignadas tareas en el proyecto GPT4?”, for which Phase 1 produces assignee is not empty AND project = GPT4, Phase 2 selects assignee, and Phase 3 derives a count of distinct assignees from the retrieved JSON.
Grounding is a central architectural property. The prototype does not answer Jira-specific questions directly from model parameters; it generates JQL, executes that JQL against the live Jira instance, and uses the returned JSON as explicit evidence for the final answer. This places the system within the family of tool-augmented or retrieval-grounded assistants, even though the prototype does not implement the broader retrieval-augmented generation stack envisioned in next-generation IR research (Huang et al., 2024).
3. Prompt engineering, language localization, and user interaction
The core engineering work in JiraGPT Next lies in prompt design. Phase 1 uses a prompt composed of four blocks. The first block defines the role and constrains output to the JQL query itself. The second block localizes status names to Spanish, instructing the model to use “Abierto”, “En Progreso”, “Resuelto”, “Aprobada”, “Entregado”, “Reabierto”, and “Cerrado” instead of English equivalents. The third block prevents project-name hallucination by instructing the model not to invent a project name when one is absent and provides a positive example involving project = GPT4. The fourth block adds another example involving assignee and priority, turning the prompt into a few-shot prompt (Garcia-Escribano et al., 30 Sep 2025).
This prompt structure is directly tied to observed failure modes. Without explicit localization, GPT may generate English status names for a Spanish Jira instance. Without negative guidance, it may hallucinate a project identifier not present in the question. Without an example for assignee and priority, it performs less reliably on those fields. The prompt therefore operates both as task instruction and as a domain-specific constraint layer.
Phase 2 uses a narrower prompt that requests only the Jira JSON fields necessary for answering the user’s question, separated by commas and without additional explanation. Before this step, the system manually prunes each issue JSON to 21 generic fields in order to limit noise and token usage. Phase 3 then uses a prompt describing the overall application flow and instructs GPT to answer the user’s question from the provided reduced JSON. The answer is produced in Spanish in the prototype.
The interface reflects this architecture. The central panel is intended for project managers and includes example queries, a text area for natural-language input, a toggle marking the question as basic or complex, and a submit button. The left panel exposes developer-oriented controls such as temperature, prompt template, and model selection; it is visible in the prototype but intended to be hidden in production. The interface also displays the exact JQL used, which gives the system a secondary pedagogical function by gradually exposing users to JQL patterns.
4. Task classes, evaluation methodology, and empirical performance
The evaluation reported for JiraGPT Next focuses solely on Phase 1, the translation from natural language to JQL, because errors in that phase invalidate all downstream processing. The evaluation environment uses a test Jira project with 2 users and 20 issues. The issue states are distributed as follows: Abierto (14 issues), En progreso (1), Resuelto (1), Validado (1), Entregado (1), Cerrado (1), and Reabierto (1). The question set consists of 70 Spanish natural-language questions derived from staff experience at LKS Next, divided into Type 1 (34%), Type 2 (34%), and Type 3 (32%) questions (Garcia-Escribano et al., 30 Sep 2025).
A generated answer is counted as correct if the JQL produced by GPT returns exactly the set of issues expected by the question. Equivalent JQL formulations are accepted; exact string match is not required. The implied metric is
The most important quantitative result is the effect of increasingly rich prompt structures on Phase 1 accuracy and token usage.
| Prompt blocks | Accuracy | Required tokens |
|---|---|---|
| 1 | 17.14% | 44 |
| 1 and 2 | 22.86% | 136 |
| 1, 2 and 3 | 37.14% | 219 |
| Full | 48.57% | 272 |
These results show that moving from a minimal zero-shot prompt to the full few-shot prompt increases accuracy from 17.14% to 48.57%, while increasing token usage from 44 to 272. The paper interprets Block 2 as primarily improving status handling, Block 3 as fixing project-name hallucinations and introducing positive and negative examples, and Block 4 as improving priority-related questions.
Temperature is also evaluated with the full prompt over values from 0.0 to 1.0 in steps of 0.1. Temperature 0.0 yields the best accuracy, and accuracy degrades as temperature increases, with around 0.8 performing worst. This is consistent with the structured nature of JQL generation, where deterministic output is preferable to creative variation.
The reported costs remain low at prototype scale. The entire project’s development and evaluation used 493,955 tokens with GPT-3.5 pricing at the time, costing around $1. That result is specific to the prototype and its scale; the paper explicitly notes that larger deployments or GPT-4-class models would change the cost profile.
5. Limitations, risks, and governance constraints
JiraGPT Next is explicitly not presented as a guaranteed-correct oracle. Even with the best prompt, accuracy remains 48.57% over the 70 test questions, which means that more than half of the evaluated queries produce an incorrect result set in the reported setting (Garcia-Escribano et al., 30 Sep 2025). The prototype is therefore better understood as a decision-support system or query assistant than as an autonomous reporting layer.
Several limitations follow directly from the architecture. Prompt improvements increase token cost and latency. Complex questions require up to three GPT calls. Phase 2 may over-select fields, which does not alter correctness but increases prompt size and expense. Phase 3 is grounded in retrieved Jira JSON, but its answer quality is not rigorously evaluated and may still include misinterpretations or overconfident wording.
Privacy and security are prominent constraints. Jira data is sent to the OpenAI API, at least in reduced form, which raises data sovereignty, compliance, and legal concerns for public administrations and enterprises. The prototype does not describe a detailed mitigation strategy such as anonymization or on-premise deployment, though it notes the issue explicitly. Permissions are also only lightly discussed: the prototype assumes API access to project data, and production behavior would depend on Jira’s permission checks as enforced through the API.
A broader next-generation IR perspective adds further risks. ChatGPT-based assistants introduce challenges around hallucination, ethics, bias, efficiency, and interpretability. In enterprise contexts, these concerns translate into risks such as fabricated explanations, biased assignment suggestions, opaque reasoning chains, and excessive token or latency costs. The literature on ChatGPT for IR argues that retrieval-enhanced workflows, source attribution, and interpretability mechanisms are important mitigations; a plausible implication is that a more mature JiraGPT Next would need stronger evidence-linking, verification passes, and auditable output traces than the current prototype provides (Huang et al., 2024).
6. Comparative position and future research directions
JiraGPT Next is positioned against three main alternatives: JQL itself, Jira dashboards and reporting tools, and other AI-based project-management assistants. Relative to JQL, its main distinction is that it accepts free-form natural-language queries while still exposing the generated JQL for verification. Relative to dashboards, it is intended for ad hoc questions rather than recurring standardized reports. Relative to other assistants, the paper discusses Kubiya.ai, Microsoft 365 Copilot, and Albus as products with broader integrations, pricing structures, or Slack- and Microsoft-centric deployment models, whereas JiraGPT Next is a Jira-centric prototype tailored to Spanish public administrations and focused on querying and explanation over Jira data (Garcia-Escribano et al., 30 Sep 2025).
The future directions described for the prototype include experimenting with other LLMs such as Google Gemini and Meta Llama, adding or refining few-shot examples, introducing retrieval-augmented generation over Jira documentation, project conventions, or historical queries, improving the balance between accuracy and token cost, and integrating more deeply with Jira as a plugin. Productization paths include support for creating or updating issues, richer time-related analysis, larger user studies, and more systematic evaluation of the natural-language answer phase.
An adjacent line of work extends the Jira-centered paradigm from querying toward software quality assurance. Research on private GPTs for LLM-driven testing treats epics, stories, and acceptance criteria as first-class artifacts from which executable tests can be generated. In that setting, structured Given–When–Then acceptance criteria and Gherkin-style formulations produce higher-quality pytest outputs than vague natural-language requirements, and private, RAG-enabled models are used to keep code and project data inside organizational boundaries (Jagielski et al., 6 Jun 2025). This suggests a broader JiraGPT Next trajectory in which Jira issues are not only queried semantically but also transformed into downstream engineering artifacts such as Gherkin scenarios, test code, or CI-facing validation assets.
In that expanded interpretation, JiraGPT Next exemplifies a wider transition in enterprise information systems: from rigid query interfaces and static dashboards toward conversational, tool-using assistants that mediate between natural-language intent, structured project data, and task-level outputs. The current prototype demonstrates that the transition is technically feasible but still accuracy-limited, prompt-sensitive, and governance-heavy. Its significance lies less in raw retrieval performance than in making Jira’s underlying data model queryable and interpretable through natural language while exposing, rather than eliminating, the unresolved problems of reliability, privacy, and controlled deployment.