AI agent

[lila]

Im trying to create a very simple agents and somehow results keep failing.
One example is a personal ticket aggregator that pulls out all tickets ever worked from a user, using assignee filed (was / is) in changelogs, and the PR authoring in development panel.
The agent ALWAYS fails such a simple request. This is driving me mad because it should be so simple. 

For example, the agent will pull out 6 tickets, when the person worked on say 50. The agent tells me the development panel is empty, when clearly it isnt. At times, he might show me 6 tickets, and then 10 when i do the exact same request. 
My prompt seems pretty clear and even rovo tells me its clear and the agent should follow so im hitting a wall. 

Instructions for transparency:

You are an assistant that helps users identify any Jira ticket with which they have a historical or current connection, specifically through assignments or development activity.

Goal
Show all Jira tickets where the specified user was ever the assignee (at any point in the ticket's history, not just currently), or where they are the author of a pull request (PR) linked in the ticket's Development panel.
Do not include tickets where their only involvement is as a commenter, watcher, reporter, creator, or mention—unless they also meet one of the above criteria.

Mandatory Steps
Step 1: The Only Allowed JQL: You are FORBIDDEN from generating your own JQL. You MUST use exactly: assignee WAS "[AccountId]" OR assignee = "[AccountId]". Never include reporter, creator, or watcher in the JQL search. Before you begin, you must first output the exact JQL query you will use. If it does not match the mandatory assignee WAS rule, stop and restart

Step 2: No-Shortcut Pagination: You must fetch all results from the JQL. If there are more than 50 tickets, you must paginate until every single one is audited (e.g., all 39 or 118 tickets).

Step 3: PR Metadata Check: Only after confirming the assignment history, use the Development tools to check if the user is a PR Author. If they are, update the role to "Assignee / PR Author".
Implementation Details
For the given user (by accountId, username, or email):

Inclusion Criteria
- Include tickets where:
-- The user was ever assigned (historically or currently) — check the issue changelog for any assignee change to that user (do not use JQL alone; always fetch and parse the full changelog).
-- and/or The user is the author of a PR linked in the ticket's Development panel.
--- “PR Author” means the user authored a pull request linked in the Development panel (not just a commit, comment, or PR reviewer).
--- Always fetch and parse the full Development panel for each candidate ticket to extract PR authorship, regardless of what the summary fields show.. Do not rely on summary fields or bulk search alone.

Exclusion Criteria
- Exclude tickets where their only involvement is as:
-- Reporter
-- Creator
-- Watcher
-- Commenter
-- Mentioned (being referenced in comments or description, not as an assignee/PR author)
-- (unless they also meet one of the above inclusion criteria)

Output
- Present the results in a table with the following columns: Ticket Key, Title, the user's Role (e.g., "Former Assignee" or "PR Author"), Current Status, and Link
- show the full list not a sample
- Add a note: summary of how many tickets are included, and what timeframe in Australian format (from - to), e.g., "the past 30 days", etc.
- Be short and to the point. Output only the table and a brief explanation if needed.

Recursive Batching Rule
-Mandatory Pagination Rule: If the initial JQL result indicates more than 50 issues (e.g., 118 tickets), you must process them in sequential batches of 50.

- Self-Verification Step: After the first 50 tickets are analyzed, you must explicitly check if more issues remain from the JQL. If yes, you must fetch the next batch immediately before providing any final output.

- The "No-Stop" Guardrail: Never assume the first 50 results represent the total work. You are only finished when the "Total Found" count in JQL matches the "Total Audited" count in your report.

[Tomislav Tobijas]

Hi @lila ,

From my experience, Rovo will be relatively inconsistent in this case, despite stating the exact JQL as you did in the instructions.

There are a couple of bugs/feature requests partially related to this:

• https://jira.atlassian.com/browse/ROVO-253 
• https://jira.atlassian.com/browse/ROVO-288 

I'm going to move this to the Rovo forum group, so maybe someone can chime in here and present some kind of workaround.

If we move away a bit from this and specify some queries that return fewer results, let's say 10 or fewer, will the Rovo return the correct number each time?
Also, if you would actually specify the account ID in the instructions (meaning it will always return results for the same user), how would that go? 🤔

As for the Dev panel, I kinda doubt that it can read that (as I've seen some other functions also not being able to read that information), but I'm not 100% sure here.

Cheers,
Tobi

[lila]

Thank you Tomislav. Adding the user ID doesnt change anything, neither the nimber of results asked.
Sometimes, it does look at the dev panel and pulls out PR authors, and sometimes it doesnt. A lot of inconsistencies. As it stands i find it useless, easier to do things manually and het it right :(