git-diff-analysis

name	git-diff-analysis
description	Inspect git history and diffs to identify what changed, which platform layers are affected, and what risk signals to prioritise before applying review checklists.
license	MIT
compatibility	opencode
metadata	{"audience":"code-reviewer","domain":"git"}

What I do

Guide the initial inspection of git changes so the reviewer understands scope and risk before applying layer-specific checklists.

---

Recommended commands

# Working-tree state
git status

# Files changed vs last commit (name list only — good starting overview)
git diff --name-only HEAD

# Full unified diff vs last commit
git diff HEAD

# Files and full diff vs main branch (for PR-style review)
git diff main..HEAD --name-only
git diff main..HEAD

# Diff of a single file
git diff HEAD -- path/to/file.py

# Recent commit history for context
git log --oneline -10

# Blame a specific area for authorship context
git blame -L 10,30 path/to/file.py

# List all tracked files (useful when no diff is available)
git ls-files

---

Grouping files by platform layer

After running git diff --name-only, map each file to its layer:

Layer	Path prefix	Risk level
Raw SQL / DDL	sql/	🔴 High — schema changes affect existing data
dbt models	dbt/	🔴 High — renames break downstream dependencies
Airflow DAGs	dags/	🟠 Medium-High — schedule or task changes affect running pipelines
Python ETL / shared	src/	🟠 Medium — shared code affects every consumer
Backend API	apps/api/	🟡 Medium — contract changes affect frontend
Frontend	apps/web/	🟡 Low-Medium — UI changes affect end users
Infrastructure	docker-compose.yml, .env.example	🟠 Medium — affects the whole local environment
Documentation	docs/, AGENTS.md, README.md	🟡 Low — but missing updates signal drift

Review layers in risk order: sql/ → dbt/ → dags/ → src/ → apps/api/ → apps/web/ → docker-compose.yml → docs/.

---

Risk signals to look for

Schema / DDL (sql/)

• New columns or table renames require migration awareness.
• Changed ON CONFLICT keys may silently break deduplication logic.
• Missing IF NOT EXISTS makes the script non-idempotent.

dbt (dbt/)

• Renamed or deleted models need downstream {{ ref() }} checks.
• Changed grain in a mart model can silently produce wrong aggregates.
• SELECT * additions in staging or marts are a warning sign.

Airflow DAGs (dags/)

• Changed task_id breaks historical run state in the Airflow metadata DB.
• Changed schedule_interval may cause gap or double-run on next deploy.
• Logic moved into the DAG file (instead of src/) violates the architecture rule.

Shared Python (src/)

• Changes here propagate to all consumers — test surface is wide.
• Removed or renamed public functions break imports in dags/ and apps/.

API (apps/api/)

• Response schema changes without a spec update signal contract drift.
• Synchronous DB calls inside async def handlers block the event loop.

Infrastructure (docker-compose.yml, .env.example)

• New env vars not added to .env.example break first-run setup for teammates.
• Removed health checks make startup order unpredictable.

---

Pattern to follow

1. Run git diff --name-only HEAD (or main..HEAD for a branch review) to get the file list.
2. Group files by layer and note the risk level for each layer touched.
3. Check whether docs/specs/ or AGENTS.md were updated alongside code changes.
4. Read the full diff for each file, starting from the highest-risk layer.
5. Note the intent of each change and flag any gap between intent and implementation.
6. Hand off to code-review-checklist for structured per-layer verification.