# Merge Request Check Python

> Merge-request / PR review workflow for Python projects (Humanit house ruleset: Clean Architecture, DDD, TDD, CI gates). Resolve a branch or MR number against an integration branch (default main), build a unified diff, run the branch's tests + ruff, and produce a structured review using the session default model and the bundled Python prompt template. Use when the user says merge request check, MR review, /merge-request-check, or wants a diff-based PR review before merge on a Python repo. For iOS/Swift repos use merge-request-check instead.

- Skill: `stefancgillberg/merge-request-check-python` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add stefancgillberg/merge-request-check-python`
- Raw SKILL.md: https://api.skillmd.com/api/skills/stefancgillberg/merge-request-check-python/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: stefancgillberg (https://skillmd.com/u/stefancgillberg)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/stefancgillberg/merge-request-check-python

---


# Merge request check — Python

## Goal

Replicate an **MR review script** flow in **git** for a **Python** codebase: **resolve** the
change (branch name, MR number, or merge commit), **diff against the integration branch**
(default `main`), **verify** the branch (run its tests + `ruff`), feed the diff into the
**Python review prompt** in [references/review-prompt-template.md](references/review-prompt-template.md),
and produce **`code_review.md`-style output** (structured sections, prioritized findings, test
suggestions).

This is the Python sibling of the `merge-request-check` skill. The Swift one targets
iOS/SwiftUI and defaults to `develop`; this one targets Python and defaults to `main`.

**Default reviewer:** the **same in-session AI model** the editor uses for other skills (this
chat/agent). Do **not** assume Ollama.

**This skill is report-only.** Produce the review; never modify the working tree beyond the
checkout needed to run tests. If the user wants the mechanical findings applied, offer it as a
follow-up (or point them at `/code-review --fix`) — do not edit as part of the review.

## Adapting for your repository

- **Prompt / domain:** Edit [references/review-prompt-template.md](references/review-prompt-template.md)
  for project-specific rules. It encodes the Humanit house ruleset (Clean Architecture, Clean
  Code, DDD/ordlista, TDD guardrail tests, CI gates). If a project's `CLAUDE.md` adds rules,
  fold them in.
- **Base branch:** Default `main`. If the project uses `develop`/`trunk`, follow the user or
  `REVIEW_BASE` and state it in **Assumptions**.
- **No `review.sh` assumption:** stay on the in-session path; there is no Ollama fallback here.

## Default — in-session review

1. **Git safety**
   - Require a clean tree (`git status`). If dirty, stop and tell the user to commit, stash, or
     discard — do not clobber uncommitted work.
   - `git fetch --all --prune` before resolving refs.
   - Record the starting branch so you can restore it afterward.

2. **Resolve the target**
   - Local branch → checkout.
   - `origin/<name>` → `git checkout -b <name> origin/<name>`.
   - Numeric only → treat as MR: `git log --merges --grep="Merge request.*<n>"`, checkout that
     commit; fall back to `git log --grep="<n>"`.
   - Further fallbacks: merge commits mentioning the string, partial `git branch -a` match,
     prefix match — explain what you did in **Assumptions**.

3. **Base branch** — default `main` unless the user/project says otherwise; state it in
   **Assumptions**.

4. **Build the diff** — prefer the **full** diff so new files are included:
   - `git diff <base>...<branch>` (three-dot: changes on the branch since it diverged).
   - If HEAD is a merge commit, prefer `git diff --diff-filter=MD <first-parent>..HEAD`.
   - Note which diff form was used in **Assumptions**. Avoid `--diff-filter=MD` alone for a
     full review — it omits new files (a new module + its new test would both vanish).

5. **Verify the branch (bake this in — do not skip)**
   - Check out the branch (tree is clean per step 1).
   - Run the affected tests, then the suite: `pytest -q -m "not integration"` (exclude live/DB
     integration markers). Also run the changed files' tests explicitly.
   - Run the lint gate: `ruff check <changed .py files>`.
   - Report the actual results (pass counts, any failures) in the review — a green suite is what
     lets a phase gate / user story be called "Ready for test" or "Done".

6. **Prompt and review**
   - Read [references/review-prompt-template.md](references/review-prompt-template.md), replace
     `<<<GIT_DIFF>>>` with the unified diff, and, for a real sanity check, **read the full
     changed source files on the branch** — not just the hunks.
   - Perform the review in this session following that template exactly.

7. **Deliverable** — the template's structure (executive summary through action list). Offer to
   write `code_review.md` in the repo if the user wants a saved artifact.

8. **Assumptions section** — state base branch, which diff form was used, that the review was
   produced by the session default model, and the test/lint results.

9. **After checkout** — restore the starting branch (`git checkout -`), warn on detached HEAD,
   and confirm the tree is clean.

## Quality bar

- Follow the template's **OUTPUT REQUIREMENTS** order; use "N/A" briefly for a section that
  does not apply.
- Ground findings in the project's own `CLAUDE.md` where relevant (dependency approval scope,
  guardrail tests, ordlista/ubiquitous language, CI gates) — cite the rule, not a generic
  preference.
- Respect the **Mock / fixture** exceptions in section 3 of the template.
- Never invent functions/types without labeling `[ASSUMED]`.
- Report-only: end without a patch block unless the user explicitly asks for one.

## Improvements over typical scripts (apply when sensible)

| Topic | Suggestion |
|-------|------------|
| Diff completeness | Prefer full `base...branch` so new modules + their tests are included. |
| Verification | Always run `pytest -m "not integration"` + `ruff` and report results. |
| Base branch | Support `REVIEW_BASE` / a user-specified base; do not hardcode only `main`. |
| Sanity check | Read whole changed files on the branch, not only diff hunks. |
| Safety | Clean-tree precondition; restore the starting branch when done. |
| Secrets | Treat the diff as sensitive; never paste secrets into logs or output. |