Lisa Github Verify

Verify GitHub Issue: $ARGUMENTS

Verify that the existing GitHub Issue $ARGUMENTS (org/repo#<number> or full URL) meets organizational standards. This skill is a thin post-write wrapper around lisa-github-validate-issue: it fetches the live issue and asks the validator to run the gates against the fetched state.

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

Process

1. Confirm gh auth status succeeds.
2. Parse $ARGUMENTS. Resolve <org>, <repo>, <number>.
3. Fetch the issue via gh issue view <number> --repo <org>/<repo> --json number,title,body,labels,state,milestone,assignees,author,createdAt,updatedAt,closed,closedAt,url.
4. Invoke lisa-github-validate-issue and pass the issue ref. The validator fetches its own copy and runs every gate (Specification + Feasibility) against the live state.
5. Surface the validator's report verbatim to the caller.

Output

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

Comparison semantics — semantic, never byte-exact

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

GitHub 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 issue, posts comments, or changes labels.
• If a gate fails, the recommendation is part of the validator's report; surface it as-is.
• The Validation Journey check (S11) parses the ## Validation Journey markdown section — same parser logic as lisa-github-add-journey and lisa-github-journey.

Comparison is semantic, never byte-exact

Re-run the validator against the live issue. 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-github-validate-issue against the stored item and let the gates decide. Where a single field must be compared directly, normalize both sides first.