ship-uilisted

# Ship UI The final review before a UI change ships. It assumes the code compiles and passes lint, so it skips the mechanical style a linter enforces, but it still reviews logic, correctness, and security. The skill checks the diff for the design-craft regressions linters miss, then turns that diff into a clean commit message and PR description. ## Core mandate Review the changed code and the minimum surrounding context needed to validate it. Do not audit unrelated parts of the codebase. Catch the regressions a linter cannot detect, such as accessibility, motion, responsive, and visual or UX drift, and flag only what you are sure is a real problem. Then write a commit message and PR description that read as a developer wrote them, with no tooling attribution. ## Severity scale | Level | Meaning | | --- | --- | | **Blocking** | A real bug, a leaked secret, or a shipped accessibility failure. Do not merge. | | **Note** | Worth checking, a likely regression or a quality gap, not always wrong. | A clean diff should pass with an empty list. Do not invent minor findings to lengthen the list, and skip formatting and naming preferences. ## The checklist ### 1. Gather the diff Gather every pending change, so a clean result is trustworthy. Pick the scope that matches the request. - Uncommitted work about to be committed. Run `git diff HEAD` to capture staged and unstaged edits to tracked files. - A whole branch headed for a PR. Run `git diff <base>...HEAD` for committed work,