Review a feature branch
Compare the changes with the agreed base and review both conventions and intended behavior.
Code Review by Matt Pocock
Use Code Review by Matt Pocock to examine a branch against a fixed Git reference. Review repository standards and the originating specification independently, then compare located findings side by side so code quality and requirement coverage remain separate questions in the review.
Install and get started
Choose your agent to see how to get started. In Floatboat, copy a request that asks the agent to read the original instructions. Other options show the Skill installation command or the publisher’s native setup steps.
Choose an agent
Start in Floatboat
Copy the request into a Floatboat conversation
Read the original Code Review instructions at https://github.com/mattpocock/skills/blob/main/skills/engineering/code-review/SKILL.md. Explain its purpose, required tools, and installation options, then help me use it.Let the agent read the original instructions and check how to use them in your environment.
Download Floatboat ↗Try this request
Review this branch against main using Matt Pocock’s Code Review. The specification is docs/specs/import.md. Keep standards and specification findings separate.
About Code Review
Code Review is a two-axis review Skill in Matt Pocock’s engineering collection. It first resolves a comparison reference and checks that the merge-base diff is non-empty, then locates the originating specification and repository standards. Separate subagents review standards and specification coverage, keeping their findings distinct in the final report. The standards axis also uses a labeled code-smell baseline, while documented project conventions take precedence. If no specification exists, that axis is explicitly skipped rather than invented. Use the Skill with an accessible Git history, the intended comparison point, and the collection’s issue-tracker configuration; it is a review workflow, not an automatic approval or correction service.
Use Cases for Code Review
Explore review tasks where both implementation discipline and requirement fidelity matter. Examine a feature branch, check a completed ticket, or compare work against a release baseline while keeping evidence of standards violations separate from missing, partial, or unintended behavior.
Check a ticket implementation
Locate requirements that are missing, partial, or implemented differently from the specification.
Audit a release diff
Use a fixed release reference to keep the review scope reproducible.
How to Review a Branch with Code Review
Provide a resolvable Git comparison point and the originating issue or specification. Let the agent collect standards and establish the diff, run the two review axes independently, and inspect their separate findings before deciding which edits or follow-up checks are needed.
- 01
Pin the comparison point
Supply a commit, branch, tag, or other valid reference. Confirm the merge-base diff covers the intended work.
- 02
Provide standards and specification
Point to repository conventions and the originating requirement. Make any missing specification explicit.
- 03
Review both result sets
Read Standards and Spec findings independently. Decide which changes need correction without treating a pass on one axis as approval of the other.
Explore More Agent Skills
Read another Skill guide and check its original source before using it.
Code Review FAQ
Which Git comparison does the workflow use?
It uses a three-dot comparison between the chosen reference and HEAD, so the review is based on their merge base. Confirm that scope matches your intent.
What happens with an invalid reference or empty diff?
The source checks those conditions before dispatching reviewers. Correct the comparison rather than presenting an empty review as a successful assessment.
Does it require a specification?
It attempts to locate the originating issue or specification. If none is available, it reports that and skips the Spec axis instead of guessing requirements.
Which standards take precedence?
Documented repository standards override the source’s general smell baseline. Smell observations are judgment calls, not automatically hard violations.
Can a host without subagents run the exact workflow?
The original process uses parallel subagents for separate review contexts. Sequential review is an adapted workflow and does not reproduce that same execution pattern.
Why keep the two axes separate?
Conventional code can still miss requirements, and correct behavior can still violate project standards. Separate reporting makes each kind of failure visible.
How is the issue tracker configured?
The collection’s setup Skill records the repository’s issue-tracker workflow. Configure it before engineering use so the reviewer can locate the right sources.