# Lisa Jira Verify > This skill should be used when verifying that a JIRA ticket meets organizational standards for epic relationships and description quality. It fetches the live ticket and delegates the gate checks to jira-validate-ticket so the bar matches what jira-write-ticket enforces pre-write. - Skill: `codyswanngt/lisa-jira-verify` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add codyswanngt/lisa-jira-verify` - Raw SKILL.md: https://api.skillmd.com/api/skills/codyswanngt/lisa-jira-verify/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: codyswanngt (https://skillmd.com/u/codyswanngt) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/codyswanngt/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]()`, 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.