30 Claude Prompts for Jira

You are a director of product who translates quarterly goals into Jira epics. <context> Leadership handed us a quarterly goal and I need to turn it into an epic the team can plan sprints against. </context> <inputs> - Quarterly goal: [PASTE GOAL STATEMENT] - Success metric: [METRIC AND TARGET NUMBER] - Team: [TEAM NAME] - Known dependencies on other teams: [LIST OR NONE] </inputs> <task> Write an epic with a summary, a problem statement, a success metric section, and a list of 4 to 6 candidate stories that would need to exist under this epic. </task> <constraints> The success metric must be a number with a timeframe, not a vague statement like 'improve engagement'. Candidate stories are placeholders for later grooming, keep each to one line. Do not commit to a delivery date, that belongs in a separate planning step. </constraints> <format> Return as: Epic Summary, Problem Statement, Success Metric, Candidate Stories (bulleted), Dependencies. </format>

You are a product operations lead who writes roadmap status updates from raw epic data. <context> I need to send a roadmap update to stakeholders based on the current state of our epics in Jira. </context> <inputs> - Epic names and status: [LIST EACH EPIC WITH STATUS: ON TRACK, AT RISK, DELAYED] - Reporting period: [MONTH OR QUARTER] - Audience: [EXECUTIVES, SALES, WHOLE COMPANY] - Any scope changes since last update: [DESCRIBE OR NONE] </inputs> <task> Write a roadmap update that groups epics by status, explains the reason behind any 'at risk' or 'delayed' label in one sentence each, and ends with what stakeholders should expect next period. </task> <constraints> Do not bury bad news, state delays plainly with the cause. Match the tone to the audience, executives get brevity, sales gets customer-facing framing. Keep the whole update under 300 words. </constraints> <format> Return as: On Track (bulleted), At Risk (bulleted with reason), Delayed (bulleted with reason), Next Period. </format>

You are a product strategist who scores competing epics for prioritization. <context> I have more epic candidates than we can fund this quarter and need a defensible ranking to bring to leadership. </context> <inputs> - Epic candidates: [LIST EACH EPIC WITH A ONE-LINE DESCRIPTION] - Scoring criteria: [E.G. REVENUE IMPACT, ENGINEERING COST, STRATEGIC FIT] - Team capacity: [NUMBER] engineer-weeks available - Non-negotiable commitments: [LIST OR NONE] </inputs> <task> Score each epic 1 to 5 on each criterion, calculate a total, and produce a ranked list with a one-sentence justification per epic explaining the score. </task> <constraints> Be consistent, apply the same scoring logic across all epics rather than adjusting standards per item. Flag any epic where the estimated cost likely exceeds stated team capacity. Do not let a single high score in one criterion override an otherwise weak epic without saying so. </constraints> <format> Return as a table with columns: Epic, [each criterion], Total, Rank, Justification. </format>

You are a product manager who writes concise one-pagers to pitch epics to leadership. <context> I need to pitch an epic to leadership for funding approval and want a tight one-pager, not the full Jira ticket. </context> <inputs> - Epic title and description: [PASTE FROM JIRA] - Estimated cost: [ENGINEER-WEEKS OR DOLLAR ESTIMATE] - Expected outcome: [METRIC EXPECTED TO MOVE] - Risk if we do not do this: [DESCRIBE] </inputs> <task> Write a one-page pitch with a problem statement, proposed solution, cost, expected outcome, and the risk of inaction, written for an audience with no Jira context. </task> <constraints> No jargon that requires knowing our internal ticket system. Keep it to 200 to 250 words total. Lead with the business problem, not the technical solution. </constraints> <format> Return as: Problem, Proposed Solution, Cost, Expected Outcome, Risk of Inaction. Each section 2 to 3 sentences. </format>

You are a program manager who maps cross-team dependencies between epics. <context> We are planning next quarter and I need to surface dependencies between epics owned by different teams before commitments are made. </context> <inputs> - Epics and owning teams: [LIST EACH EPIC WITH ITS TEAM] - Brief description of each epic: [ONE LINE PER EPIC] - Known technical shared systems: [LIST SHARED SERVICES OR DATABASES] </inputs> <task> Identify likely dependencies between the listed epics, including which team would block which, and flag any pair that appears to touch the same shared system without an obvious coordination plan. </task> <constraints> Be explicit that these are inferred dependencies needing confirmation from the owning teams, not confirmed facts. Rank flagged risks by how likely they are to cause a delay. Do not assume dependencies that are not supported by the descriptions given. </constraints> <format> Return as a table: Epic A, Epic B, Suspected Dependency, Confidence (Low, Medium, High). </format>

You are a senior backend engineer who writes clear bug reports from raw logs. <context> I have a stack trace and some context from a production error and need a Jira bug ticket engineers can act on immediately. </context> <inputs> - Stack trace or error log: [PASTE RAW LOG] - Environment: [PRODUCTION, STAGING, LOCAL] - Steps that led to the error, if known: [DESCRIBE OR UNKNOWN] - Frequency: [ALWAYS, INTERMITTENT, ONE-OFF] </inputs> <task> Write a bug ticket with a one-line summary naming the failing component, a description that quotes the key error line, suggested reproduction steps if inferable, and a suggested severity. </task> <constraints> Do not guess at a root cause beyond what the log supports, mark it as unknown if unclear. Keep the summary line under 15 words and name the specific service or file if visible in the trace. Flag if the log looks truncated or missing timestamps. </constraints> <format> Return as: Summary, Environment, Description, Suspected Component, Reproduction Steps (or 'unknown'), Suggested Severity. </format>

You are a QA engineer who turns vague bug reports into precise reproduction steps. <context> Someone reported a bug in a Slack message with almost no detail and I need to turn it into reproducible steps before it can be triaged. </context> <inputs> - Original report text: [PASTE VAGUE REPORT] - Feature area: [FEATURE NAME] - Known user role or account type: [ROLE OR UNKNOWN] - Browser or device, if mentioned: [DEVICE INFO OR UNKNOWN] </inputs> <task> Write a best-guess set of numbered reproduction steps based on the available detail, and a separate list of clarifying questions to send back to the reporter to confirm the gaps. </task> <constraints> Label the reproduction steps as a hypothesis, not a confirmed repro, since detail is missing. Keep clarifying questions specific enough to answer in one sentence each, avoid open-ended questions like 'what happened'. Limit to 5 questions maximum. </constraints> <format> Return as: Hypothesized Steps (numbered), Clarifying Questions (numbered, max 5). </format>

You are an engineering manager who triages bug severity using a consistent rubric. <context> I have a bug ticket and need a defensible severity and priority rating before it goes into the sprint. </context> <inputs> - Bug description: [PASTE DESCRIPTION] - Number of users affected or percentage: [NUMBER OR ESTIMATE] - Is there a workaround: [YES, NO, PARTIAL] - Revenue or compliance impact, if any: [DESCRIBE OR NONE] </inputs> <task> Assess severity (Blocker, Critical, Major, Minor, Trivial) and priority (P0 to P3) with a one-paragraph justification, and state whether this should interrupt the current sprint or wait for the next one. </task> <constraints> Apply the rubric consistently, a bug with a workaround should rarely reach Blocker regardless of user count. Do not inflate severity based on who reported it, only on impact. State the interrupt-or-wait recommendation as a single sentence, not a hedge. </constraints> <format> Return as: Severity, Priority, Justification, Sprint Recommendation. </format>

You are a site reliability engineer who writes root cause analyses after an incident is resolved. <context> We just fixed a production bug and I need a root cause analysis to attach to the Jira ticket and share with the team. </context> <inputs> - What broke: [DESCRIBE THE FAILURE] - How it was detected: [MONITORING ALERT, CUSTOMER REPORT, INTERNAL TESTING] - Time to detect and time to resolve: [TIMES] - The actual fix applied: [DESCRIBE FIX] </inputs> <task> Write a root cause analysis covering what happened, the root cause distinct from the symptom, the fix applied, and 2 to 3 preventive follow-up actions to avoid recurrence. </task> <constraints> Distinguish clearly between the symptom users saw and the actual root cause. Preventive actions must be concrete and assignable, not vague statements like 'be more careful'. Keep the whole analysis under 350 words. </constraints> <format> Return as: What Happened, Root Cause, Fix Applied, Preventive Follow-ups (bulleted), Time to Detect and Resolve. </format>

You are a support engineer who checks whether a newly filed bug is a duplicate of an existing ticket. <context> A new bug ticket looks similar to an older one and I need a clear comparison before merging or closing it as a duplicate. </context> <inputs> - New ticket description: [PASTE NEW TICKET] - Existing ticket description: [PASTE EXISTING TICKET] - Any difference in environment or reproduction noticed: [DESCRIBE OR NONE NOTICED] </inputs> <task> Compare the two tickets and state whether they appear to be the same underlying issue, a related but distinct issue, or unrelated, with a one-paragraph justification citing the specific similarities or differences. </task> <constraints> Do not default to 'duplicate' just because symptoms sound similar, check the described conditions carefully. If genuinely uncertain, say so and recommend keeping both open pending investigation rather than guessing. Keep the justification to 3 to 4 sentences. </constraints> <format> Return as: Verdict (Same Issue, Related, Unrelated, Uncertain), Justification, Recommendation. </format>

You are a Jira administrator who writes precise JQL queries from plain-English descriptions. <context> I need a JQL query to filter our backlog but I do not remember the exact field syntax. </context> <inputs> - What I want to see, in plain English: [DESCRIBE THE FILTER] - Project key: [PROJECT KEY] - Custom field names in use, if relevant: [LIST OR NONE] - Sort order desired: [DESCRIBE OR NONE] </inputs> <task> Write a JQL query that matches the request exactly, and explain in one sentence per clause what each part of the query does. </task> <constraints> Use standard JQL syntax that runs in Jira Cloud without plugins. If a custom field is needed but its exact internal name is unknown, use a placeholder and say so rather than guessing a name that might not exist. Do not add filters the user did not ask for. </constraints> <format> Return as: JQL Query (in a code block), Clause-by-clause Explanation (bulleted). </format>

You are a Jira power user who debugs broken JQL queries. <context> I wrote a JQL query that should return results but comes back empty, and I need to find the mistake. </context> <inputs> - The JQL query: [PASTE QUERY] - What I expected it to return: [DESCRIBE EXPECTED RESULTS] - Project key: [PROJECT KEY] - Any error message shown: [PASTE OR NONE, JUST EMPTY RESULTS] </inputs> <task> Identify the most likely reasons the query returns no results, ranked by likelihood, and provide a corrected version of the query. </task> <constraints> Check for common causes first: wrong status names, date format issues, quoting problems with multi-word values, and mismatched project keys. State each hypothesis as testable, not as a certainty. Provide only one corrected query, not multiple variants. </constraints> <format> Return as: Likely Causes (ranked bulleted list), Corrected Query (code block). </format>

You are a Jira administrator who designs dashboard filters for team leads. <context> I am setting up a Jira dashboard for a team lead and need a set of JQL filters covering the views they care about most. </context> <inputs> - Team lead's stated priorities: [LIST WHAT THEY WANT TO MONITOR] - Project key: [PROJECT KEY] - Sprint field name if custom: [FIELD NAME OR STANDARD] - Team members' Jira usernames, if filtering by assignee: [LIST OR NOT NEEDED] </inputs> <task> Design 4 to 6 JQL filters that together cover the stated priorities, such as overdue items, unassigned tickets in the active sprint, and blocked tickets, each with a short name and its query. </task> <constraints> Each filter must answer one specific question, do not combine unrelated conditions into one filter. Use relative date functions like startOfWeek() rather than hardcoded dates so filters stay useful over time. Name each filter clearly enough that a non-technical team lead understands its purpose. </constraints> <format> Return as a numbered list: Filter Name, Purpose (one sentence), JQL Query (code block). </format>

You are a Jira consultant who automates manual backlog review habits into saved filters. <context> I manually scroll through the backlog every week looking for specific patterns and want to automate that check with a saved JQL filter instead. </context> <inputs> - What I manually look for each week: [DESCRIBE THE PATTERN, E.G. TICKETS WITH NO ESTIMATE OPEN OVER 30 DAYS] - Project key: [PROJECT KEY] - Statuses considered still open: [LIST STATUSES] </inputs> <task> Translate the manual review habit into a single JQL query that surfaces exactly those tickets automatically, and suggest a sensible name for saving it as a filter. </task> <constraints> Use JQL functions for relative time windows rather than absolute dates. If the manual habit as described is ambiguous, state the ambiguity and pick the most literal interpretation rather than guessing broadly. Keep the query to one line if possible. </constraints> <format> Return as: Suggested Filter Name, JQL Query (code block), Note on Interpretation (if any ambiguity existed). </format>

You are a Jira expert who explains complex inherited JQL queries in plain English. <context> I inherited a saved filter with a long JQL query from a former teammate and need to understand exactly what it does before I trust or modify it. </context> <inputs> - The JQL query: [PASTE FULL QUERY] - What I believe it is used for: [YOUR ASSUMPTION] - Anything about the results that seems off: [DESCRIBE OR NOTHING YET] </inputs> <task> Explain what the query does clause by clause in plain English, state whether it matches my stated assumption of its purpose, and flag any part that looks redundant, overly broad, or likely to produce unexpected results. </task> <constraints> Go clause by clause in the order they appear in the query, do not summarize only the overall intent. Point out specifically if any OR or AND grouping looks like it could be a logic error due to missing parentheses. Do not rewrite the query unless asked. </constraints> <format> Return as: Clause-by-Clause Explanation (bulleted), Match to Stated Purpose (yes, no, or partially, with reason), Flags (bulleted, or 'none'). </format>

You are a product marketing writer who converts closed Jira tickets into customer-facing release notes. <context> We closed a batch of tickets this release and I need customer-facing release notes, not the internal engineering summary. </context> <inputs> - Closed ticket titles and brief descriptions: [PASTE LIST] - Release version or date: [VERSION OR DATE] - Audience: [FREE USERS, PAID USERS, ADMINS, ALL] - Tone: [FORMAL, FRIENDLY, TECHNICAL] </inputs> <task> Group the tickets into New Features, Improvements, and Bug Fixes, and rewrite each internal ticket title into a one-sentence customer-facing benefit statement. </task> <constraints> Drop any ticket that is purely internal or has no user-visible effect, note which ones you excluded and why. Do not use internal ticket IDs or engineering terminology in the customer-facing text. Keep each bullet to one sentence. </constraints> <format> Return as: New Features (bulleted), Improvements (bulleted), Bug Fixes (bulleted), Excluded Tickets (bulleted with reason). </format>

You are an engineering lead who writes internal release notes for the on-call and support teams. <context> I need internal release notes that give on-call engineers and support staff the technical detail customer-facing notes leave out. </context> <inputs> - Closed ticket titles and technical detail: [PASTE LIST] - Release version: [VERSION] - Any config or feature flag changes: [DESCRIBE OR NONE] - Known risks or things to watch post-release: [DESCRIBE OR NONE] </inputs> <task> Write internal release notes listing each change with its technical detail, any config or flag changes required, and a dedicated section for things support and on-call should watch for in the hours after release. </task> <constraints> Keep technical detail precise enough that on-call can act on it without pinging the original engineer. Do not soften or omit known risks, that defeats the purpose of internal notes. List config changes separately from feature changes so they are not missed. </constraints> <format> Return as: Changes (bulleted with technical detail), Config or Flag Changes (bulleted), Watch List for On-Call and Support (bulleted). </format>

You are a scrum master who writes sprint review demo scripts from closed tickets. <context> We have sprint review coming up and I need a demo script that walks stakeholders through what shipped this sprint. </context> <inputs> - Closed tickets this sprint: [PASTE LIST WITH BRIEF DESCRIPTIONS] - Sprint number or dates: [SPRINT IDENTIFIER] - Which items are demoable live versus explain-only: [SPLIT THE LIST OR SAY UNKNOWN, SUGGEST A SPLIT] - Audience: [INTERNAL STAKEHOLDERS, EXECUTIVES, CUSTOMERS] </inputs> <task> Write a demo script ordered from most impactful to least, with a one-sentence talking point per item and a note on whether it should be shown live or just described. </task> <constraints> Lead with the item stakeholders most care about, not the order tickets were closed in. Keep each talking point to one sentence a presenter can say naturally, not a ticket title read aloud. If the demoable split is unknown, propose one and flag it as a suggestion. </constraints> <format> Return as a numbered list: Item, Talking Point, Live Demo or Describe Only. </format>

You are a developer relations engineer who writes API changelog entries with clear breaking-change warnings. <context> We shipped changes to our API this release and I need a changelog entry that clearly separates breaking changes from safe ones. </context> <inputs> - List of API changes: [DESCRIBE EACH CHANGE] - Version number: [VERSION] - Deprecation timeline, if any: [DATE OR NONE] - Migration guide link, if one exists: [URL OR NONE YET] </inputs> <task> Write a changelog entry that separates Breaking Changes from Non-Breaking Changes, and for each breaking change state exactly what integrators need to do to migrate. </task> <constraints> Any change that alters a response shape, removes a field, or changes required parameters must be listed as breaking, do not soft-pedal it as an improvement. Include the deprecation date prominently if one exists. Do not write a migration guide link if none was provided, say 'migration guide pending' instead. </constraints> <format> Return as: Breaking Changes (bulleted with migration action), Non-Breaking Changes (bulleted), Deprecation Timeline. </format>

You are a release manager who pairs every release note with a rollback plan. <context> We are about to ship a release and I want a rollback plan documented alongside the release notes in case something goes wrong. </context> <inputs> - What is being released: [DESCRIBE RELEASE CONTENTS] - Deployment method: [FEATURE FLAG, FULL DEPLOY, DATABASE MIGRATION INVOLVED] - Any irreversible steps, such as data migrations: [DESCRIBE OR NONE] - Who is on call for this release: [ROLE OR NAME] </inputs> <task> Write a rollback plan that states the exact steps to revert the release, how long rollback is expected to take, and a clear callout of any step that cannot be cleanly reversed. </task> <constraints> If a database migration is involved, address it specifically, do not assume a simple code rollback covers it. State irreversible steps prominently at the top, not buried in the middle. Keep steps numbered and actionable under time pressure, avoid long explanatory paragraphs. </constraints> <format> Return as: Irreversible Steps (bulleted, or 'none'), Rollback Steps (numbered), Estimated Rollback Time, On-Call Contact. </format>

You are a scrum master who prepares focused backlog grooming agendas. <context> I need to prepare the agenda for our next backlog grooming session and want it focused rather than a walk through every ticket. </context> <inputs> - Tickets in the backlog needing attention: [PASTE LIST WITH STATUS, E.G. UNESTIMATED, STALE, MISSING DETAIL] - Session length: [NUMBER] minutes - Number of attendees: [NUMBER] - Sprint start date: [DATE] </inputs> <task> Build a grooming agenda that allocates time proportionally, prioritizing tickets needed for the next sprint over ones with more runway, and flags any ticket that looks too vague to groom without the ticket author present. </task> <constraints> Do not allocate more than the stated session length across all items, show the math. Order items by urgency for the upcoming sprint, not by ticket age. Flag vague tickets clearly rather than including them in the timed agenda. </constraints> <format> Return as: Timed Agenda (numbered with minutes per item), Tickets Needing Author Present (bulleted, or 'none'). </format>

You are a product owner who refreshes stale backlog tickets before they go back into grooming. <context> Several tickets have sat in the backlog for months and the context has likely changed, so I need them rewritten before we regroom them. </context> <inputs> - Old ticket title and description: [PASTE ORIGINAL] - How old the ticket is: [TIME PERIOD] - What has changed since it was written, if known: [DESCRIBE OR UNKNOWN, FLAG FOR REVIEW] - Current product priorities: [BRIEF DESCRIPTION] </inputs> <task> Rewrite the ticket to reflect current context, or if too much is unknown, state plainly that the ticket needs a conversation with a current stakeholder before it can be safely regroomed. </task> <constraints> Do not silently update assumptions that might no longer hold, call them out. If the ticket's original goal seems to conflict with current priorities, say so directly rather than rewriting around the conflict. Keep the rewritten version the same length or shorter than the original. </constraints> <format> Return as: Rewritten Ticket (Title, Description) or Needs Stakeholder Review (with reason), Flagged Assumptions (bulleted). </format>

You are a product owner who periodically prunes a bloated backlog. <context> Our backlog has grown too large and I need to identify which tickets are safe candidates to close as won't-fix rather than groom forever. </context> <inputs> - Backlog tickets with title, age, and last activity: [PASTE LIST] - Current product strategy in one or two sentences: [DESCRIBE] - Any tickets explicitly protected from closure: [LIST OR NONE] </inputs> <task> Identify tickets that no longer align with current strategy, have had no activity in a long time, or duplicate other open work, and recommend them for closure with a one-sentence reason each. </task> <constraints> Never recommend closing a protected ticket, exclude those from consideration entirely. Distinguish between 'no longer relevant' and 'still relevant but low priority', only recommend closure for the former. Keep the reason for each recommendation specific enough that the original requester would understand it. </constraints> <format> Return as a table: Ticket, Age, Reason for Closure Recommendation, Confidence (Low, Medium, High). </format>

You are a tech lead who provides first-pass estimates for ungroomed tickets ahead of a grooming session. <context> I have a batch of tickets with no estimates and want a first-pass sizing to speed up the actual grooming conversation. </context> <inputs> - Tickets with title and description: [PASTE LIST] - Story point scale in use: [E.G. FIBONACCI 1,2,3,5,8,13] - Team's typical velocity per sprint: [NUMBER] points - Any tickets with unusually high uncertainty: [LIST OR NONE FLAGGED YET] </inputs> <task> Provide a first-pass point estimate for each ticket with a one-sentence rationale, and flag any ticket whose description is too thin to estimate confidently. </task> <constraints> Treat these as a starting point for team discussion, not a final estimate, state that explicitly. If a ticket's estimate would exceed roughly a third of the team's typical sprint velocity, flag it as needing a split. Do not estimate a ticket that has no description at all, list it as unestimable instead. </constraints> <format> Return as a table: Ticket, Estimate, Rationale, Flag (Needs Split, Needs More Detail, or none). </format>

You are a program manager who reports on backlog health to leadership. <context> Leadership asked for a quick read on our backlog health and I need a summary that is honest without being alarmist. </context> <inputs> - Total open tickets: [NUMBER] - Tickets older than 90 days: [NUMBER] - Percentage unestimated: [PERCENTAGE] - Recent trend, growing or shrinking: [DESCRIBE OR GIVE NUMBERS OVER TIME] </inputs> <task> Write a short backlog health summary stating the current state, whether the trend is improving or worsening, and one concrete recommendation to address the biggest issue found. </task> <constraints> Use the actual numbers given, do not round in a way that hides a concerning trend. Give exactly one recommendation, not a list, so it is actionable. Keep the whole summary under 150 words. </constraints> <format> Return as: Current State (2 to 3 sentences), Trend, Recommendation (1 sentence). </format>