Review a merge request or branch diff as a senior developer and data scientist. Produces a structured review report with findings, severity levels, and a merge verdict.
Purpose: Independent code review before merging to main.
"Every change to main should be reviewed by someone who didn't write it — even if that someone is an AI."
This skill performs a structured code review of a branch diff (or staged changes) against main. It checks for correctness, data science rigor, security, compliance, and convention adherence. It produces a review report with actionable findings and a clear merge verdict.
The review is presented directly in the conversation as a structured report. No file artifacts are created — the review lives in the MR discussion, not in the repo.
Based on the argument provided:
main.
git log --oneline main..HEAD
git diff main...HEAD
main.
git log --oneline main..<branch>
git diff main...<branch>
staged: Review only staged changes.
git diff --cached
If there are no changes to review, report that and stop.
Before reviewing code, understand the intent:
feature/ or bugfix/ conventions?For each changed file, review systematically:
.py)eval()/exec(), no hardcoded secrets, parameterized SQL.ipynb)PROJECT_ROOT pattern, no hardcoded relative paths{task_number}-{descriptive-name}.ipynb convention.md in docs/crisp-dm/)A{task}-{n})Q{task}-{n})data/processed/.env files committedAfter reviewing individual files, check:
Present the review in this format:
# Code Review Report
**Branch:** `<branch name>`
**Commits reviewed:** <N> commits (<first>..<last>)
**Files changed:** <N>
**CRISP-DM Phase:** <phase>
**Reviewer:** Code Review Agent (Senior DS/SWE)
**Date:** <date>
---
## Summary
<2-3 sentence summary of what the changes do and the overall quality assessment.>
---
## Findings
### CRITICAL
| # | File | Line(s) | Finding | Recommendation |
|---|------|---------|---------|----------------|
| 1 | `path/to/file.py` | L42-45 | <description> | <what to do> |
### HIGH
| # | File | Line(s) | Finding | Recommendation |
|---|------|---------|---------|----------------|
### MEDIUM
| # | File | Line(s) | Finding | Recommendation |
|---|------|---------|---------|----------------|
### LOW
| # | File | Line(s) | Finding | Recommendation |
|---|------|---------|---------|----------------|
### INFO (Positive Observations)
- <things done well — acknowledge good practices>
---
## Checklist Summary
| Category | Status | Notes |
|----------|--------|-------|
| Correctness | Pass/Fail | |
| Data Science Rigor | Pass/Fail/N/A | |
| Security | Pass/Fail | |
| Compliance (GDPR/PII) | Pass/Fail | |
| Coding Standards | Pass/Fail | |
| Notebook Standards | Pass/Fail/N/A | |
| CRISP-DM Conventions | Pass/Fail/N/A | |
| Git Conventions | Pass/Fail | |
| Documentation | Pass/Fail | |
---
## Verdict
**<APPROVE / REQUEST CHANGES / DISCUSS>**
<Justification for the verdict. If requesting changes, list the blocking items (CRITICAL and HIGH findings) that must be resolved before merge.>
After the report:
| Severity | Definition | Examples |
|---|---|---|
| CRITICAL | Will cause incorrect results, data loss, or security breach | Data leakage, PII exposure, logic bug affecting predictions, hardcoded secrets |
| HIGH | Violates methodology or compliance requirements | Preprocessing fit on test data, unlogged experiment, missing model card, GDPR violation |
| MEDIUM | Reduces maintainability or violates conventions | Poor naming, missing docstring on public API, hardcoded magic numbers, convention violations |
| LOW | Minor improvement opportunity | Slightly better variable name, optional refactor, style suggestion |
| INFO | Positive observation or neutral note | Good test coverage, clean notebook narrative, well-structured commit messages |
Before finalizing the review: