Stop staring at the board. Start asking it questions.

A producer’s guide to querying your own project data without touching a single Jira automation rule or query language search syntax.

Apr 13, 2026

How to query Jira without JQL or automation rules
Claude Code Jira integration for game studios
Kanban reporting and flow analysis using AI
Game studio production analytics with Claude Code

Image by Nano Banana and the thousands of woodcut cartoonists who trained it.

I’ve written a lot recently about Vibe Production, the idea that experienced producers are naturally suited to working with Claude Code because the skills are the same ones we’ve always used: clear intent, structured thinking, knowing when to delegate and when to stay in the loop. Most of what I’ve published has been about workflow and philosophy. This post is about something more applied.

Jira. Specifically, what Claude Code can do with yours.

Every studio I’ve encountered is sitting on a surprisingly complete operational picture with almost no practical way to read it. The data is all there: who worked on what, how long tickets sat in queues, which components generated the most bugs, where contractor hours actually went. The record exists. What’s always been missing is a way to query it that doesn’t require a custom reporting layer, a Jira admin with spare time, or someone willing to spend a morning in spreadsheets.

A £20/month Claude Pro account changes that calculation. No plugins. No automation rules. No JQL. Just a prompt written in plain English, pointed at your existing Jira data via the standard API. The prompt describes intent. Claude Code handles the API pagination, error handling, conditional logic, and write-back. You stay at the design level.

What follows is 20 use cases across two audiences: the producers and discipline leads managing flow day to day, and studio leadership reading that flow as a signal about risk, cost, and delivery. Every prompt works against data you already have. None of it requires additional configuration.

Some of these will feel immediately familiar. Others are analyses most studios never run, not because the data doesn’t exist, but because assembling it has never been worth the effort. That’s the part Claude Code changes.

Use Cases

The 20 use cases split into two sections. Studio leads and producers get the operational view: flow, queue health, cycle time, dependency chains, the things that determine whether work moves or stalls. The C-suite get the portfolio view: cost, risk, delivery confidence, and the questions that come up in milestone reviews and quarterly planning. Same underlying data. Different altitude.

Studio Leads

Bulk operations
Intelligent triage and grooming
Dependency graph analysis
Queue health reporting
Release note generation
Cross-project auditing
Ticket creation from external sources
WIP limit enforcement
Cycle time analysis by component
Cross-project ticket mirroring

C-Suite

Headcount utilisation analysis
Budget burn rate against delivery progress
Risk register generation
Cross-project resource conflict detection
Contractor cost exposure report
Delivery slip pattern analysis
Feature cut candidate identification
Studio throughput benchmarking
Third-party dependency exposure
Post-launch quality cost analysis

Bulk operations

Using the Jira API, find every open ticket in project FORGE assigned to departing.dev@studio.com and reassign them to lead.engineer@studio.com. Confirm the count before writing anything.

When a developer leaves mid-production or goes on extended leave, their queue becomes a blind spot fast. This prompt handles the full reassignment in one pass across every issue type and status. The confirmation step means you see the count before anything is touched.

The same pattern applies wherever ownership needs to move at scale:

Reassign all tickets in a given component from one lead to another after a team restructure
Strip assignees from every ticket in the backlog that has been unassigned for more than 60 days and flag them for re-triage
Move all tickets labelled “art” from one discipline queue to another when a contractor’s engagement ends
Bulk-update the “Team” custom field across a project when a squad is renamed or reorganised

Intelligent triage and grooming

Pull all tickets in the FORGE backlog with no acceptance criteria in the description. For each one, generate a draft BDD acceptance criteria block based on the ticket title and description, and post it as a comment flagged for review. Do not edit the description directly.

Active game backlogs accumulate half-formed tickets quickly, especially during crunch. This prompt finds everything missing acceptance criteria and drafts what they should say, working from the existing title and description. It posts as a comment rather than overwriting the description, so the producer decides what gets promoted to official spec.

The same reasoning applies to other backlog quality problems:

Flag all tickets missing a component assignment and suggest the most likely component based on description content
Identify tickets whose titles are too vague to act on (”Fix bug”, “Update UI”) and draft clearer alternatives
Find duplicate tickets by semantic similarity and list candidate pairs for a producer to review and merge
Detect tickets that have been in the backlog unmodified for more than 90 days and mark them for staleness review

Dependency graph analysis

Traverse all issue links for tickets currently in active columns in project FORGE. Build a dependency graph, identify any circular dependencies, and list every ticket that is blocking three or more others. Output a ranked list with ticket keys and summaries.

On a board with 40-plus tickets moving across engineering, art, and design columns, dependency chains become invisible to any single discipline lead. This prompt surfaces the tickets that take the most other work down with them if they slip. The circular dependency check catches logical deadlocks that typically only come up in standup once it is already too late.

Other dependency-adjacent prompts worth running regularly:

List all tickets marked as blocked that have had no update from the blocker ticket in more than 3 days
Find tickets with external dependency links (platform, middleware) that are currently in an active column
Generate a plain-text critical path from a given epic to its end state, showing every linked ticket in sequence
Identify tickets with no links at all that are sitting in columns beyond “To Do”, which suggests missing dependency documentation

Queue health reporting

For project FORGE, calculate: total tickets per column, tickets that have not moved column in more than 5 days, tickets added to the board in the last 7 days, and current throughput rate. Post the summary as a comment on FORGE-001 and print it to the console.

Queue depth and stalled tickets are the two most reliable signals that flow is breaking down. This prompt produces a health snapshot any producer can read in 30 seconds, posted directly to the board’s anchor ticket. Run it every Monday and you have an early warning system that requires no dashboard to build.

Variations that serve the same purpose at different cadences or scopes:

Generate a daily digest of tickets that changed column in the last 24 hours, grouped by discipline
Compare queue depth across the last four weeks and flag any column that is consistently growing
Produce a per-assignee view of how many tickets each person has in each column, to surface hidden overload
Alert when any single column exceeds a set ticket count threshold, posting a warning to the team’s Slack via webhook

Release note generation

Pull all tickets resolved under fix version "Season 3 - Update 2" in project FORGE. Group them by issue type, exclude anything labelled "internal" or "chore", and write a player-facing release notes document in Confluence under the FORGE Release Notes space.

Release notes always fall to whoever has the least time to write them. This prompt reads the resolved ticket set, strips internal work players do not need to see, groups the remainder by type, and produces the document. It needs an editorial pass, but the structure and first draft are done.

The same generation logic works across other documentation needs:

Write an internal patch summary for the QA team covering all bug fixes in a given version, including steps to verify
Generate a “what changed” document for platform submission covering only tickets tagged with the cert-relevant label
Produce a milestone changelog grouped by feature area rather than issue type
Create a known issues list from all open bugs above a given priority threshold at the point of a release build

Cross-project auditing

Compare the workflow configurations of projects FORGE and ATLAS. List any column states that exist in one but not the other, and flag any tickets currently sitting in a non-matching state. Output as a plain text report.

Studios running multiple projects in the same Jira instance let configurations drift. FORGE might have an “Awaiting Cert” column that ATLAS never needed; ATLAS might develop a “Peer Review” step that never gets back-ported. This prompt surfaces that drift before it causes reporting confusion or breaks cross-project tooling that assumes consistent workflow state.

Similar audits worth running across a multi-project instance:

Check that all projects are using the same set of priority labels and flag any custom values that have crept in
Identify projects missing required custom fields (such as “Discipline” or “Milestone”) and list the affected tickets
Find tickets across all projects that reference a deprecated component name and list them for bulk update
Compare permission schemes across projects and flag any that allow edit access to roles that should be read-only

Ticket creation from external sources

Read the attached CSV of QA test failures from the FORGE 0.9.4 regression pass. For each row, create a Bug ticket in project FORGE with the component set from the "module" column, priority from the "severity" column, and a structured description using the 
steps_to_reproduce and expected_result columns. Confirm the list before writing.

After a large regression pass, a QA lead can easily be sitting on 60 failures that each need to become a properly structured ticket. Doing that by hand is an hour of repetitive work with a high error rate. This prompt converts the entire sheet in one pass. The confirmation step gives the QA lead a final review before anything lands in the backlog.

The same import pattern applies to other common input sources:

Parse a user research report and create Task tickets for each identified friction point, tagged by research session
Convert a game designer’s feature list document into draft Feature tickets with placeholder acceptance criteria
Import a list of platform certification failures from a submission report into Bug tickets with the cert label applied
Read a crash analytics export and create one Bug ticket per unique crash signature, grouped by affected build version

WIP limit enforcement

Find every column in project FORGE that is currently exceeding its WIP limit. For each one, list the tickets in breach, their age in that column, and the assignee. Post a comment on each over-age ticket tagging the assignee and summarising how long it has been stuck.

WIP limits only work if someone is watching them. On a busy board, breaches accumulate quietly until a column is so congested that flow stops entirely. This prompt automates the nudge that a producer would otherwise deliver manually, per ticket, by trawling the board and sending individual messages.

Related enforcement prompts that reinforce flow discipline:

List all tickets that have been in “In Review” for more than 3 days and have received no comment activity
Find tickets that moved backward in the workflow (from a later column to an earlier one) in the last 7 days and summarise why
Identify assignees who currently hold more than their agreed personal WIP limit across all active columns
Flag any ticket that has changed assignee more than twice without advancing a column, which typically signals unclear ownership

Cycle time analysis by component

Query all tickets resolved in project FORGE in the last 3 months. Calculate the average cycle time from "In Progress" to "Done" grouped by component and by assignee. Identify the top 3 components with the longest average cycle time and output a summary with ticket counts.

Cycle time by component is one of the most honest signals of where flow problems are actually living in a project. Consistently long cycle times in a specific component point to unclear acceptance criteria, an ownership gap, or technical debt being patched rather than resolved. This prompt produces that analysis from real data, in a form concrete enough to bring to a leads meeting.

Other flow metric analyses worth running on the same data set:

Calculate lead time (from ticket creation to Done) alongside cycle time, to understand how much waiting happens before work starts
Plot cycle time trends over the last 6 months to show whether flow is improving or degrading over time
Compare cycle times between ticket types to identify whether bugs consistently take longer to close than features
Find the tickets with the longest individual cycle times in the last quarter and produce a short summary of each

Cross-project ticket mirroring

Find all tickets in ATLAS labelled "shared-pipeline" that have moved to Done in the last 7 days. For each one, check whether a linked ticket exists in FORGE. If it does, update its status to match. If it does not, create a new FORGE ticket referencing the ATLAS key and flag it for triage.

When a tools or pipeline project ships something that unblocks the main game project, that information needs to propagate without relying on someone remembering to do it. This prompt keeps the two projects in sync on shared work, surfacing the connection as a proper linked ticket rather than a Slack message that gets buried.

Other synchronisation scenarios that follow the same logic:

When a bug is marked as a duplicate in FORGE, automatically close any linked ticket in ATLAS that references the same issue
Mirror priority changes on FORGE tickets tagged “engine-dependency” across to the corresponding ATLAS ticket
When a BEACON ticket is promoted from pre-production to active development, create a corresponding FORGE ticket and link the two
Sync the “Target Version” field across linked tickets in FORGE and ATLAS to ensure milestone alignment is visible in both projects

Headcount utilisation analysis

Query all tickets across projects FORGE, ATLAS, and BEACON for the last quarter. Calculate actual time logged per team member against their assigned capacity. Identify anyone consistently over 100% allocation or under 60%, and output a summary table by discipline and project.

Most studios operate with an incomplete picture of where their people actually are versus where the plan says they should be. This prompt pulls real logged data and surfaces allocation drift across the whole portfolio. The kind of view that normally requires a producer pulling spreadsheets for half a day before a quarterly review.

Related workforce visibility prompts at the portfolio level:

Show which disciplines are carrying the highest ticket load relative to their headcount across all active projects
Identify team members who have logged no time in the last two weeks but have open tickets assigned to them
Calculate the ratio of reactive work (bugs, support) to planned work (features, tasks) per discipline across the quarter
Produce a bench report listing everyone with no active ticket assignments, grouped by discipline and availability

Budget burn rate against delivery progress

Pull all tickets in project FORGE associated with the "Beta Milestone" epic. Calculate percentage complete by ticket count and throughput rate. Cross-reference with the planned completion date and flag any workstreams where current flow rate suggests the milestone will be missed by more than two weeks. Output as an executive summary.

The question every studio head asks before a milestone review is whether the schedule is real. This prompt answers it from actual ticket flow data rather than the optimistic status reports that tend to travel up the chain. The two-week threshold is adjustable: tighten it for a hard external deadline, loosen it for internal targets.

Other delivery confidence prompts suited to executive review:

Compare planned ticket completion dates across all active epics against current throughput and produce a RAG status for each
Show how many tickets have been added to a milestone epic after its start date, as a measure of scope creep
Calculate the ratio of completed to remaining work per workstream and flag any that are more than 20% behind plan
Produce a one-page milestone readiness report covering open blockers, WIP breaches, and projected completion date

Risk register generation

Analyse all open tickets in projects FORGE and BEACON flagged as blockers or with priority set to Critical or Highest. Group them by risk category (technical, dependency, resource, external). For each, summarise the potential impact and generate a draft mitigation note. Output as a risk register document in Confluence.

Risk registers are universally agreed to be important and universally neglected because building them is tedious. This prompt generates a living version from real blocker and critical ticket data, grouped into the categories a COO or executive producer actually thinks in. It needs an editorial pass, but the raw material is there.

Other risk-oriented prompts useful at the leadership level:

List all tickets with no assignee that are currently on the critical path across any active project
Find every ticket marked as a blocker that has had no activity in more than 5 days and escalate with a summary
Identify epics with no open tickets remaining but not yet marked as complete, which may indicate tracking failures
Generate a weekly risk delta report showing which new blockers appeared and which were resolved since the last review

Cross-project resource conflict detection

Find all team members assigned to tickets in both FORGE and BEACON that are due in the same two-week window. List the conflicts by person, showing ticket keys, estimates, and due dates. Flag anyone with more than 3 days of overlap.

Splitting senior staff across a live title and a new production is one of the most reliable ways to underserve both. This prompt makes the conflict concrete and quantified rather than anecdotal — useful for a conversation with a department head about whether a hire needs to be made or a timeline needs to move.

Related resource conflict scenarios worth surfacing at a portfolio level:

Identify any discipline where total assigned work across all projects exceeds available capacity for the next 4 weeks
Flag team members who are the sole assignee for critical-path tickets in more than one project simultaneously
List all upcoming milestone dates across FORGE, ATLAS, and BEACON and flag any that fall within the same 2-week window
Produce a capacity forecast for the next quarter showing projected demand versus current headcount by discipline

Contractor cost exposure report

Pull all tickets in project FORGE assigned to users tagged with the "contractor" label. Sum the logged hours for the current quarter, group by contractor, and calculate estimated cost using the day rate stored in each user's custom field. Output a spend summary with a projection to end of quarter.

Contractor spend is often the fastest-moving line in a studio’s budget and the least visible to leadership until an invoice arrives. This prompt turns Jira’s time-logging data into a real-time spend tracker with a projection that gives finance enough lead time to act if burn is running hot.

Other cost visibility prompts that serve the same function:

Compare contractor hours logged this quarter against the same period last year, broken down by discipline
Calculate the cost per ticket closed for contractor versus staff, to inform make-or-buy decisions on future work
List all contractors whose logged hours in the current month are tracking above their agreed monthly cap
Produce a cost-by-component breakdown showing which areas of the game are consuming the most external resource

Delivery slip pattern analysis

Query all tickets moved to Done in project FORGE for the last 12 months. For each, 
calculate the delta between the original due date and the actual completion date. 
Identify which disciplines and which workstream owners are associated with the longest 
average slips. Output a ranked summary.

Where does delivery slip actually originate? This prompt produces the data to have that conversation objectively, by discipline and by ownership, rather than by reputation and recollection. It is the question that sounds uncomfortable in the room but needs answering before a studio can improve its forecasting.

Other retrospective analysis prompts that serve planning decisions:

Calculate estimate accuracy by discipline over the last 6 months, comparing original time estimates to actual logged hours
Identify which epic owners have the strongest track record of on-time delivery, to inform assignment decisions on BEACON
Show how slip rates correlate with team size changes, contractor ratios, or milestone pressure periods
Compare delivery performance across the three projects to identify whether slip patterns are project-specific or studio-wide

Feature cut candidate identification

Find all tickets in the BEACON backlog that have not changed column in 30 days, are 
not linked to any active workstream, and carry a time estimate above 3 days. List them 
with summaries, original priority, and last activity date. Flag any assigned to leads 
who currently have full queues.

Scope management on a pre-production project is largely about knowing which features are being quietly deprioritised by inactivity rather than by decision. This prompt surfaces the tickets that have effectively been cut without anyone saying so, giving the executive producer the information needed to make those cuts formal before they become missed assumptions at greenlight.

Similar scope hygiene prompts useful before a greenlight or milestone gate:

List all tickets in BEACON that were created more than 6 months ago and have never moved beyond “To Do”
Identify features that appear in the backlog but have no corresponding design documentation linked
Find tickets whose combined estimates exceed the remaining capacity before the next milestone, ranked by priority
Generate a scope delta report comparing the current BEACON backlog against the original pre-production brief

Studio throughput benchmarking

Calculate the average number of tickets completed per week for project FORGE across 
the last 8 weeks. Break throughput down by discipline. Compare it against the ticket 
count remaining in each active workstream and output a projected completion date range 
with a best-case and worst-case scenario.

Throughput data exists in every Jira instance and gets looked at by almost nobody in leadership. This prompt converts it into the projection a studio head actually needs: not how many tickets per week, but what date the current trajectory implies, and what the range looks like if flow varies. That is the number that drives the conversation about whether team size, scope, or deadline needs to change.

Other throughput views useful at a portfolio level:

Compare weekly throughput across FORGE, ATLAS, and BEACON to identify which project is absorbing disproportionate capacity
Track throughput before and after a team size change to measure whether the headcount adjustment had the expected impact
Show the ratio of bug tickets closed to feature tickets closed per week over the last quarter, as a health indicator
Calculate throughput per discipline lead and use it to model the impact of a proposed reallocation of resource

Third-party dependency exposure

Find all tickets in projects FORGE and ATLAS that reference external dependencies — 
middleware vendors, platform holders, or licensed technology — in their description 
or linked to an "External" label. List them by dependency name, associated workstream, 
current column, and assigned owner. Flag any on the critical path.

External dependencies are where studios get blindsided because nobody owns the view across all of them at once. A middleware SDK update, a platform certification requirement, or a licensed asset delivery can each slip without the studio noticing until it is blocking flow. This prompt produces the consolidated view that typically lives nowhere.

Other dependency visibility prompts suited to leadership review:

Find all tickets blocked by an external party that have been waiting for more than 10 days with no update
List every ticket tagged with a platform holder label (first-party, cert, submission) and their current status across all projects
Calculate the total estimated work blocked by external dependencies and express it as a percentage of remaining milestone scope
Generate a vendor dependency timeline showing when each external input is needed and which milestone it sits on

Post-launch quality cost analysis

Pull all Bug tickets in project FORGE created after the launch date of "Season 2". 
Group them by severity, component, and which board column they were in when first 
reported pre-launch. Calculate the total remediation hours logged. Output a quality 
cost report showing where defects originated and what they cost to fix post-ship.

The data to calculate quality cost exists in every Jira instance. Nobody ever assembles it. This prompt connects where bugs originated in the flow, when they were caught, and what the fix cost after launch — the kind of analysis that directly informs decisions about QA investment, test coverage, and release criteria on the next project.

Other post-launch analysis prompts that feed into the next production cycle:

Calculate the average time to resolve a live bug by severity tier, to benchmark against internal SLAs
Compare bug volume in the first 30 days post-launch across all previous FORGE seasons to identify trend lines
Identify which components have generated the most post-launch bugs historically, to inform test coverage decisions on BEACON
Produce a player-impact report estimating how many users were affected by each high-severity post-launch issue, based on platform data linked in ticket comments

Discussion about this post

Ready for more?