Monty Code Review Skill (Backend)

Overview

Hyper-pedantic Django code review with correctness-first, multi-tenant-safe, harness-aware review style.

This skill ships inside the Monty Code Review plugin and can be installed through the Claude Code marketplace or directly in Codex from its skill path.

Parent Surface

Parent docs: Monty Code Review

Related wrapper commands from the parent plugin:

When to Use This Skill

dashboardapp/, survey/, optimo_*, pulse_iq/, utils/).

time dimensions, exports, or Django migrations / schema changes where downtime-safety matters.

“what would a careful, correctness-obsessed senior engineer do?”

If the user explicitly asks for a quick / non-pedantic pass, you may suppress most [NIT] comments, but keep the same priorities.

• Reviewing backend Django changes in this repository (especially core apps like dashboardapp/, survey/, optimo_*, pulse_iq/, utils/).
• Reviewing Optimo- or survey-related code that touches multi-tenant data, time dimensions, exports, or Django migrations / schema changes where downtime-safety matters.
• Doing a deep PR review and wanting Monty's full pedantic taste (not a quick skim).
• Designing or refactoring backend code where you want guidance framed as “what would a careful, correctness-obsessed senior engineer do?”

Core Taste & Priorities

Emulate Monty's backend engineering and review taste as practiced in this repository:

buys performance, safety, or significantly clearer modeling.

security rules as hard invariants.

invariants; misaligned or cross-tenant data is “wrong” even if nothing crashes.

its immediate dependencies.

without clear intent.

if tests pass.

edge cases, and regressions.

in tribal knowledge, weak docs and weak guardrails are part of the defect.

Always prioritize issues in this order:

Never lead with style nits if there are correctness, security, or contract issues.

• Business-first, correctness-first: simple, obviously-correct code beats clever abstractions.
• Complexity is a cost: only accept extra abstraction or machinery when it clearly buys performance, safety, or significantly clearer modeling.
• Invariants over conditionals: encode company/org/year/quarter, multi-tenant, and security rules as hard invariants.
• Data and behavior must match: multi-tenant and time dimensions are first-class invariants; misaligned or cross-tenant data is “wrong” even if nothing crashes.
• Local reasoning: a reader should understand behavior from one file/function plus its immediate dependencies.
• Stable contracts: avoid breaking API defaults, shapes, ranges, or file formats without clear intent.
• Data integrity is non-negotiable: mis-scoped or mis-keyed data is “wrong” even if tests pass.
• Testing as contracts: tests should capture business promises, realistic data, edge cases, and regressions.
• Agent legibility matters: when a non-obvious invariant or workflow only lives in tribal knowledge, weak docs and weak guardrails are part of the defect.

Pedantic Review Workflow

When this skill is active and you are asked to review a change or diff, follow this workflow:

the code is supposed to do.

architecture, invariants, or quality gates for the changed area.

this code should align with.

multi-tenant and time-dimension invariants, performance or scaling constraints.

behavior is.

Optimo, exports).

or chore.

contracts, performance, tests).

checkers, and pre-commit hooks) for the changed files.

at least [SHOULD_FIX], and often [BLOCKING].

documented reason.

to fix them, ideally with concrete code suggestions or minimal diffs.

integrity, contract stability).

“needs tests”).

• Read the PR description, ticket, design doc, or docstrings that explain what the code is supposed to do.
• Read AGENTS.md and any linked repo-local docs/specs/runbooks that define architecture, invariants, or quality gates for the changed area.
• Scan nearby modules/functions to understand existing patterns and helpers that this code should align with.
• Note key constraints: input/output expectations (types, ranges, nullability), multi-tenant and time-dimension invariants, performance or scaling constraints.
• Restate in your own words what problem is being solved and what the desired behavior is.
• Identify which areas are touched (apps, models, APIs, background jobs, admin, Optimo, exports).
• Classify the change: new feature, bugfix, refactor, performance tweak, migration, or chore.
• Decide which dimensions matter most for this change (invariants, security, contracts, performance, tests).
• Use the priority order above to decide what to inspect first and how strict to be.
• For each touched file or logical area:
• Run through the lenses in the “Per-Lens Micro-Checklist” section.
• Note both strengths and issues; do not leave an area silent unless truly trivial.
• Where possible, run or mentally simulate relevant tooling (e.g., ruff, type checkers, and pre-commit hooks) for the changed files.
• Detect Python type checker in this order unless repo docs/CI differ:
• ty, then pyright, then mypy.
• If ty is configured in the repo, treat it as mandatory and blocking.
• Treat any violations that indicate correctness, security, or contract issues as at least [SHOULD_FIX], and often [BLOCKING].
• Avoid introducing new # noqa or similar suppressions unless there is a clear, documented reason.
• Be direct but respectful: correctness is non-negotiable, but tone is collaborative.
• Use specific, actionable comments that point to exact lines/blocks and show how to fix them, ideally with concrete code suggestions or minimal diffs.
• Tie important comments back to principles (e.g., multi-tenant safety, data integrity, contract stability).
• Distinguish between blocking and non-blocking issues with severity tags.
• Give an overall assessment (e.g., “solid idea but correctness issues”, “mostly nits”, “needs tests”).
• State whether you would “approve after nits”, “request changes”, or “approve as-is”.

Pytest Test-Hardening Lane

Use this lane when changed files include pytest tests (test_.py, _test.py, tests/*/.py, conftest.py) or when the user asks for pytest hardening.

Lane contract:

If it does not, stop and tell the user the repo has not adopted the pytest hardening lane yet.

Detection and review strategy:

proof (for example raw sum( / len( and raw monkeypatch.setattr().

For this lane, focus especially on silent-pass patterns and include wrong/correct snippet suggestions in findings.

Required output columns for pytest hardening findings:

For pattern definitions and canonical wrong/correct snippets, load:

• First, verify .bin/pytest-file-selector exists in the target repo. If it does not, stop and tell the user the repo has not adopted the pytest hardening lane yet.
• Use .bin/pytest-file-selector to build the file set (single source of truth).
• Default (no args): changed-files-only (branch diff + staged + unstaged + untracked).
• --all flag: full-repo scan (opt-in only).
• --base : override base branch (strict — exits 1 if ref is invalid, no fallback).
• Exit 1 on unresolvable base or branch-diff failure (fail-closed).
• If the script outputs zero files, return out-of-scope and stop.
• Do NOT build your own file list — always delegate to this script.
• Primary detection should be structural (ast-grep patterns) where possible.
• Use rg as fallback/triage heuristics only.
• Do not emit high-noise heuristic matches as standalone findings without context proof (for example raw sum( / len( and raw monkeypatch.setattr().
• Severity ([BLOCKING], [SHOULD_FIX], [NIT])
• Pattern
• File:Line
• Detector
• Risk
• Safe Fix
• references/pytest-dangerous-patterns.md

Resources

Declared allowed tools:

Installation

Switch between Claude Code and Codex, then copy the install command for the runtime you use.

claude plugin marketplace add DiversioTeam/agent-skills-marketplace
claude plugin install monty-code-review@diversiotech

CODEX_HOME="${CODEX_HOME:-$HOME/.codex}"
python3 "$CODEX_HOME/skills/.system/skill-installer/scripts/install-skill-from-github.py" \
  --repo DiversioTeam/agent-skills-marketplace \
  --path plugins/monty-code-review/skills/monty-code-review

Invocation:

/monty-code-review:code-review
/monty-code-review:test-hardening

name: monty-code-review