ship-this
Ship this
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. Then write a commit message and PR description that read as a developer wrote them, with no tooling attribution.
Every result you report comes from a command that ran or a source that was read. Never claim a secret scan passed without running a scanner, never report a commit or push that git did not confirm, and never invent findings to lengthen the review. When you can only partially verify something, say so rather than implying a clean result.
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.