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.
Identify a fixed comparison point and the requirements the change must satisfy. Prepare a review request that separates convention from missing behavior, with findings linked to relevant diffs and evidence rather than broad impressions about code quality.
Name the base branch, requirement file, and changes excluded from review.
Copy the request into a new Floatboat conversation and provide the required material.
Download FloatboatPreview and copy the request. It is not sent automatically from this page.
Reference: Code Review https://github.com/mattpocock/skills/blob/main/skills/engineering/code-review/SKILL.md Read the original documentation and check the current environment and dependencies. Propose any new installation or tool connection before proceeding. My task: Review this branch against main using Matt Pocock’s Code Review. The specification is docs/specs/import.md. Keep standards and specification findings separate. Expected deliverable: Separate standards and specification findings, tied to the relevant changed lines.
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.
Feature branches, ticket implementations, and release diffs require different review boundaries. Compare conventions and acceptance requirements against a fixed revision, keeping each finding tied to the code and evidence that establish its impact.
Review a feature branch against an agreed base, the project's rules, and the behavior it is intended to deliver. Keep standards findings distinct from missing or incorrect requirements, with each issue tied to relevant changed lines. That separation helps the author understand both convention and functional consequences.
A ticket implementation can be checked criterion by criterion against its diff and relevant tests. Locate requirements that are absent, partially covered, or implemented differently from the specification, and attach evidence to each status. A general impression that the branch looks complete cannot replace this comparison.
A release audit needs a fixed release tag, target commit, and explicit exclusions. Keep that reference stable while inspecting the diff so another reviewer can reproduce the same scope. Leave later unreleased changes out of the findings rather than allowing a moving branch to enlarge the review silently.
A repository change may have a clear comparison point but no originating specification to inspect. Review it against documented project standards and state explicitly that the specification axis was skipped. Do not invent acceptance criteria to fill the gap; record which conclusions are supported by conventions and which requirements remain unavailable for assessment.
A code review needs resolvable Git comparison points and the original requirements. Establish the diff scope and project conventions, examine the separate review axes, and confirm each finding before choosing repairs or additional tests for the implementation.
Supply a commit, branch, tag, or other valid reference. Confirm the merge-base diff covers the intended work.
Point to repository conventions and the originating requirement. Make any missing specification explicit.
Read Standards and Spec findings independently. Decide which changes need correction without treating a pass on one axis as approval of the other.
Read another Skill guide and check its original source before using it.
