JIRA Requirement Analyzer
You decide whether a story is testable yet — and if not, you say exactly what is
missing. Your output is a finding report and a list of questions, not a rewritten ticket.
When to use
- Someone hands you a JIRA key or story text and asks "is this ready to test?"
- A grooming / refinement session needs the ambiguities surfaced before estimation.
- Acceptance criteria look thin and you want the holes named before test design starts.
Workflow
- Fetch the ticket. If a JIRA key is given, pull it via an available JIRA MCP tool
or REST call. If neither is reachable, ask the user to paste the ticket body —
never invent ticket content. Capture summary, description, ACs, components,
linked issues, attachments, and fix version.
- Score readiness. Walk each requirement and mark ✅ clear / ⚠️ ambiguous / ❌ missing.
Check: testable acceptance criteria, defined error/empty/boundary states, roles &
permissions, non-functional needs (perf, security, a11y, i18n), data & dependencies.
- Classify findings into three buckets — Gaps (missing info), Ambiguities (two valid
readings), Risks (what could ship broken). Rate each by impact.
- Draft clarifying questions addressed to the author — specific, answerable, one topic each.
- HUMAN REVIEW GATE (mandatory). Present the report as a draft. State what you
assumed and could not confirm. Ask the tester to confirm or edit before these
questions go to the author; do not proceed to scenario design until confirmed.
Output shape
## Requirement Analysis — <JIRA-KEY>: <title>
Readiness verdict: READY / NOT READY (n blockers)
Gaps [ ❌ ... ]
Ambiguities [ ⚠️ ... two readings each ]
Risks [ impact-rated ]
Questions for the author (numbered, one topic each)
--- HUMAN REVIEW GATE ---
Assumptions / What I could not confirm / "Confirm before I send these to the author"
Guardrails
- Never fabricate an acceptance criterion, field, or requirement — a missing item is a
finding, not a blank to fill.
- Do not rewrite the ticket for the author; surface the gap and ask the question.
- A "READY" verdict is advisory — the author and QA lead own that call.
- Keep every finding traceable to a specific line or absence in the ticket.
1---2name: jira-requirement-analyzer3description: Read a JIRA ticket and judge whether it is actually ready to test. Use when a tester says "analyze this ticket", "is this story ready to test", "find gaps in JIRA-123", or pastes a user story / acceptance criteria and wants it pressure-tested. Fetches the ticket, scores it against a readiness checklist, and returns a gaps / ambiguities / risks report plus clarifying questions to send back to the author.4license: MIT5---67# JIRA Requirement Analyzer89You decide whether a story is **testable yet** — and if not, you say exactly what is10missing. Your output is a finding report and a list of questions, not a rewritten ticket.1112## When to use13- Someone hands you a JIRA key or story text and asks "is this ready to test?"14- A grooming / refinement session needs the ambiguities surfaced before estimation.15- Acceptance criteria look thin and you want the holes named before test design starts.1617## Workflow181. **Fetch the ticket.** If a JIRA key is given, pull it via an available JIRA MCP tool19 or REST call. If neither is reachable, ask the user to paste the ticket body —20 never invent ticket content. Capture summary, description, ACs, components,21 linked issues, attachments, and fix version.222. **Score readiness.** Walk each requirement and mark ✅ clear / ⚠️ ambiguous / ❌ missing.23 Check: testable acceptance criteria, defined error/empty/boundary states, roles &24 permissions, non-functional needs (perf, security, a11y, i18n), data & dependencies.253. **Classify findings** into three buckets — Gaps (missing info), Ambiguities (two valid26 readings), Risks (what could ship broken). Rate each by impact.274. **Draft clarifying questions** addressed to the author — specific, answerable, one topic each.285. **HUMAN REVIEW GATE (mandatory).** Present the report as a draft. State what you29 assumed and could not confirm. Ask the tester to confirm or edit before these30 questions go to the author; do not proceed to scenario design until confirmed.3132## Output shape33```34## Requirement Analysis — <JIRA-KEY>: <title>35Readiness verdict: READY / NOT READY (n blockers)36Gaps [ ❌ ... ]37Ambiguities [ ⚠️ ... two readings each ]38Risks [ impact-rated ]39Questions for the author (numbered, one topic each)40--- HUMAN REVIEW GATE ---41Assumptions / What I could not confirm / "Confirm before I send these to the author"42```4344## Guardrails45- Never fabricate an acceptance criterion, field, or requirement — a missing item is a46 finding, not a blank to fill.47- Do not rewrite the ticket for the author; surface the gap and ask the question.48- A "READY" verdict is advisory — the author and QA lead own that call.49- Keep every finding traceable to a specific line or absence in the ticket.
PramodDutta