需求工单可测性评估

读取项目工单并判断它是否真的可以进入测试：验收标准完整性、边界条件与歧义清单。Use when reading a ticket and judging whether it is actually ready to test. Triggers include 需求评审、工单分析、验收标准、测试准备。如需测试工具包，淘宝搜索「AI灵匣」店铺获取完整版。

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

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


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.