This is a text-to-JQL review workflow. It does not require connecting ChatGPT to Jira, installing an app or letting a model modify work items.
Define what the search should include
This original triage scenario uses Jira Cloud and project key OPS. The reviewer wants items whose status category is not Done and whose due date is earlier than today or empty. Due today is deliberately excluded. Establish the site/user time-zone behavior before relying on a daily boundary.
Treat a known date such as October 24, 2026 as the review day when checking examples. Do not replace “today” with a hidden assumption that overdue means any moment earlier than the current second: Jira due dates and timestamps serve different questions.
The drafted query is:
project = OPS
AND statusCategory != Done
AND (duedate < startOfDay() OR duedate IS EMPTY)
ORDER BY key ASC
The project and status constraints apply to both branches inside the parentheses. Sorting by key gives a simple review order; it does not express urgency among the matched items.
Check the OR branch that can escape the scope
Without parentheses, this shape is different:
project = OPS AND statusCategory != Done
AND duedate < startOfDay() OR duedate IS EMPTY
Atlassian's JQL order-of-operations reference, checked October 24, 2026, places AND ahead of OR. The ungrouped final clause can therefore match any visible item with an empty due date, even if it is outside OPS or already Done.
The mistake can be easy to miss when the first page of results happens to contain only OPS items. Inspect a deliberate out-of-project example rather than relying on a plausible-looking list.
Include empty dates explicitly
A date comparison does not supply the empty-date branch. Atlassian's missing-items guidance explains that inequality conditions can omit empty fields and shows explicit IS EMPTY clauses. The JQL fields reference documents which comparisons each field supports.
For the authored October 24 fixture, use these expected matches:
| Key | Status category | Due date | Include? |
|---|---|---|---|
| OPS-11 | In Progress | October 23 | Yes: overdue |
| OPS-12 | To Do | Empty | Yes: needs a date |
| OPS-13 | Done | Empty | No: completed |
| WEB-14 | To Do | Empty | No: other project |
| OPS-15 | In Progress | October 24 | No: due today |
| OPS-16 | To Do | October 25 | No: future date |
These are invented work-item fixtures with hand-derived expectations. They are not records read from a Jira account or a claim that this query has run in your site.
Give ChatGPT both the rule and the exceptions
Draft a read-only Jira Cloud JQL search.
Project key: OPS.
Include only status categories other than Done.
Within that scope, include due dates earlier than the start of today
OR an empty due date. Exclude due-today and future dates.
Actual site terminology, field names and time-zone settings: [ENTER]
Permitted example keys/fields and expected inclusion: [PASTE]
Explain clause grouping and empty-field handling. Give one query and
walk each example through it, including an undated other-project item
and a Done item. Flag unsupported fields or unresolved date semantics.
Do not invent live matches, connect accounts, create filters, edit
issues, change statuses or send notifications. Keep execution Not run.
OpenAI's prompting documentation supports describing the task, supplying relevant context and setting boundaries. Give approved field values rather than pasting a large export containing information the query does not need.
Review actual results before naming the filter
Run the approved query in your own authorized Jira search. Check the matched keys and the visible fields against the stated inclusion rule. Use real known boundary items where available, and record the search time and effective date basis. Missing matches may also involve access permissions or a mismatched field value; a valid-looking query alone cannot establish that every expected item is visible.
Only save a filter after its actual results fit the rule. A name such as “OPS unfinished: overdue or no due date” preserves the scope better than “urgent tasks,” which would add a priority judgment the query never tested.
The project-management guide covers turning supported source notes into proposed tasks. Here the work already exists; finish by checking the search against that existing tracker and keeping the query's inclusion rule with its saved name.