Lisa Jira Verify

Verify JIRA Ticket: $ARGUMENTS

All Atlassian operations in this skill go through lisa-atlassian-access. Do not call MCP tools or acli directly.

Verify that the existing JIRA ticket $ARGUMENTS meets organizational standards. This skill is a thin post-write wrapper around lisa-jira-validate-ticket: it fetches the live ticket and asks lisa-jira-validate-ticket to run the gates against the fetched state.

This indirection exists so the gate definitions live in exactly one place (lisa-jira-validate-ticket). When the bar changes, change it there — lisa-jira-verify, lisa-jira-write-ticket (Phase 5.5 pre-write), and lisa-notion-to-tracker (PRD dry-run) all pick it up.

Process

1. Invoke lisa-atlassian-access via the Skill tool with operation: list-sites to confirm the configured site is reachable (the access skill enforces connection match against .lisa.config.json).
2. Fetch the ticket via lisa-atlassian-access operation: read-ticket key: $ARGUMENTS. Pull issue type, summary, description, parent, links, labels, components, and any custom fields needed.
3. Invoke lisa-jira-validate-ticket and pass the ticket key. The validator fetches its own copy if needed and runs every gate (Specification + Feasibility) against the live state.
4. Surface the validator's report verbatim to the caller.

Output

Pass through lisa-jira-validate-ticket's structured output unchanged. Do not summarize or paraphrase — downstream callers (e.g. lisa-jira-agent's pre-flight gate) parse the gate lines.

Comparison semantics — semantic, never byte-exact

Verification here re-runs lisa-jira-validate-ticket against the live ticket. It does not compare the stored body against the sent body byte for byte, and it must never drift to doing so.

JIRA normalizes markdown on write. Observed normalizations include rewriting - bullets as *, wrapping a bare URL as an explicit link, and re-segmenting bold emphasis around inline code spans — all lossless, all rendering-identical. A byte-exact comparator cannot distinguish vendor markdown normalization from corruption, so it reports failure on perfectly healthy writes and trains its reader to ignore it (CodySwannGT/lisa#3663).

Any comparison of tracker-normalized rich text is therefore semantic, or normalize-then-compare. Byte-exact comparison of such text is forbidden.

Notes

• This skill is read-only. It never edits the ticket, posts comments, or changes status.
• If a gate fails, the recommendation is part of the validator's report; surface it as-is.
• Validation Journey checks (S11) historically required a parser script (parse-plan.py); the parser logic now lives inside lisa-jira-validate-ticket so this skill no longer shells out to it.

Comparison is semantic, never byte-exact

Re-run the validator against the live ticket. Do NOT compare the stored body against what was sent byte for byte.

The reason is measured rather than theoretical. Trackers normalize markdown on write: - bullets become *, a bare URL is wrapped as [url](<url>), bold emphasis is re-segmented around inline code spans. All lossless, all rendering-identical, and all of it makes a byte comparator report failure on a write that was completely fine. A comparator that cannot tell vendor normalization from corruption fails on healthy writes and trains its reader to ignore it, which costs more than the check was ever worth.

Compare meaning: run lisa-jira-validate-ticket against the stored item and let the gates decide. Where a single field must be compared directly, normalize both sides first.