A tighter contract for AI code review
review-pr tells an agent to review changed code for correctness, security, lifecycle, error handling, tests, and demonstrated performance risks. It also defines what does not count: speculative warnings, style commentary, untouched code that the change did not make unsafe, and test requests that merely repeat an already-covered behaviour.
Every retained finding needs a repository-relative path, an exact changed line when possible, a concrete failure mode, and a fix direction. Critical and important findings can block approval; suggestions and nits cannot. The skill can return readable prose or a strict JSON shape for CI and other tooling.
That makes it useful after the normal test suite passes. The agent still traces callers, state changes, cleanup paths, and related tests, but it has to explain the exact input, timing, or transition that breaks before the warning survives.
Reproduce important findings
Give the skill a real branch, pull request, commit range, or working-tree diff. Ask it to review only that change and the unchanged call sites needed to prove a finding. For every critical or important result, reproduce the failure or add a targeted test before requesting changes from someone else.
The source skill is a single Markdown instruction file in the Hubble repository. It does not require the Hubble desktop app, a service account, or a separate scanner. Its effectiveness depends on the host agent having access to the diff, the relevant code, and the repository’s test commands.
Limits of an instruction-only review
A stricter format reduces noisy reviews but cannot prove the absence of bugs. The agent can misunderstand runtime behaviour, miss relationships outside the repository, or write a convincing failure story that does not reproduce.
Use the severity and verdict as triage, not authority. Keep human review for security boundaries, migrations, destructive operations, and changes where the real environment cannot be represented by local tests.