ship-ui
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.