Engineering review

Purpose

Find concrete risks in the changed behavior before delivery.

When to use

Requested review or the final self-review of a meaningful implementation; not a full-repository audit by default.

Preconditions

Read project instructions, current diff/base, changed functions and relevant callers/tests. Identify pre-existing user changes; do not attribute them to this task.

Workflow

Treat self-review as ownership of the delivered result, not a ceremonial checklist. Scale depth to changed behavior and risk. In implementation work, fix concrete in-scope defects before delivery so the user need not supervise basic correctness; review-only requests still produce findings without edits. Keep the method flexible. Compare against maintained project examples for consistency, but distinguish established conventions from a reviewer's personal taste. For UI changes, also check continuity with the existing theme/brand, reuse of components and whether the actual user flow is complete. Cosmetic novelty is not an improvement by itself.

1. Map each changed file to the requested outcome. Read full affected functions and contracts rather than reviewing isolated diff lines.
2. Trace inputs, validation, null/error states, ownership/auth, side effects and async cleanup. Check shared consumers and backward compatibility.
3. Check architecture boundaries and duplication against nearby implementations. Performance findings require a workload/complexity argument; use architecture-and-performance for deeper investigation.
4. Check that tests prove the changed result and relevant failure cases. Use behavioral-testing or project testing skills for fixes; use design-validation for rendered UI review.
5. Report actionable findings ordered by impact: location, concrete trigger, incorrect behavior, consequence, and minimal remedy. Label uncertainty; do not manufacture findings or make preference-only comments into defects.
6. For a review-only request, report without changing code. For implementation self-review, repair in-scope defects, rerun affected checks and inspect the final diff.

Rules

Avoid unrelated cleanup and hypothetical redesigns. Never claim “no bugs” from a clean lint run. Do not publish review comments externally without authorization.

Common mistakes

Reading only the patch; ignoring callers; conflating style with correctness; claiming security from mocked tests; silently expanding a review into implementation.

Validation

Each finding is traceable to observed code or test evidence. State review scope and checks run/not run. No findings means no actionable defects found within that scope, not proof of correctness.