SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsjira-requirement-analyzer

jira-requirement-analyzer

Testing & quality

View repository

Updated 10-16 08:07

About this skill

JIRA Requirement Analyzer

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

  1. Fetch the ticket.
  2. If JIRA MCP or atlassian MCP or ROVO mcp is connected the fetch the ticket via that - https://www.atlassian.com/platform/rovo-mcp
  3. 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.

  1. 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.

  2. Classify findings into three buckets — Gaps (missing info),

  • Ambiguities (two valid readings),
  • Risks (what could ship broken). Rate each by impact.
  1. 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"


Create a light weight HTML page in the /tmp dir, with name jira-analyzed-<ticket-id>.html for all finding as output

Safety & 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.

Anti Hallucination STRICT RULES (MANDATORY)

DO NOT invent features, APIs, error codes, UI elements, or behavior. DO NOT assume default or "typical" system behavior. If information is missing or unclear, respond with: "Insufficient information to determine." Every assertion must be traceable to provided input. If a detail is inferred, label it explicitly as: "Inference (low confidence)". Output must be deterministic and repeatable.