# Lisa Github Verify

> This skill should be used when verifying that a GitHub Issue meets organizational standards for parent-sub-issue relationships and description quality. It fetches the live issue and delegates the gate checks to github-validate-issue so the bar matches what github-write-issue enforces pre-write. The GitHub counterpart of lisa-jira-verify.

- Skill: `codyswanngt/lisa-github-verify` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add codyswanngt/lisa-github-verify`
- Raw SKILL.md: https://api.skillmd.com/api/skills/codyswanngt/lisa-github-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-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.