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, 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 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, 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)