Why-What-How Review

Review a change as a tech lead: first its value and product contract (WHY), then the solution it should have (WHAT), and only then the implementation (HOW). Do not substitute a retelling of the diff for the review. Do not edit code unless the user explicitly asked to fix the findings. Do not limit yourself to the checklist: if you see a risk outside it, check it. Do not treat formal correctness as sufficient: code without an obvious bug can still be a finding if it implements a harmful product decision or an objectively worse architecture.

Project review profile

A project can complement this skill with a review profile: REVIEW.md at the repository root with review checks that neither this skill nor the general project documentation covers. Apply its checks in addition to this skill. The profile adds checks and project context; it does not replace the process or the report format.

Follow Project profile when the user asks to set up a profile. During a review, only offer it: if the project has no profile and the review relied on project-specific checks worth recording, add the offer to To discuss.

Process