code-review-engineering

A code-review checklist focused on whether a change is safe, correct, maintainable, and supported by evidence such as tests, logs, or screenshots.

In plain words
What is it for?
Use it to review module boundaries, API and data changes, user interfaces, background work, infrastructure, automated checks, and regression coverage.
Why use it?
It helps reviewers find behavior, security, data, reliability, API, interface, and infrastructure problems before approval instead of focusing only on formatting.

Cursor rule

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add rules/jterratsdev/ableton-live-mcp/code-review-engineering
Clone the repo
git clone --depth 1 https://github.com/jterratsdev/ableton-live-mcp
Per session 437 This file is loaded in full into every session.
When invoked 437 The same file — it is already loaded in full.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.00437 $0.00437
Opus 5 $0.00218 $0.00218
Sonnet 5 $0.00087 $0.00087
Haiku 4.5 $0.00044 $0.00044

Measured yesterday against content hash 791a7adb85cc, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

code-review-engineering scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured yesterday.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

rules/code-review-engineering.mdc · 37 lines

How it starts

The opening of the file, as written. The whole thing — 37 lines — stays where its author put it; the contents beside it link to each section on GitHub.

Code Review Engineering

Code review protects behavior, users, operations, and maintainability. Review risk before style.

Review Order

  • Review behavior, data safety, security, reliability, and user impact before naming or formatting.
  • Check whether the change matches the agreed solution, acceptance criteria, and Definition of Done.
  • Verify tests cover meaningful behavior, failure paths, and regression risk.
  • Confirm evidence: commands run, screenshots, logs, traces, benchmarks, or QA results when relevant.

Required Checks

  • Module boundaries: file size, responsibility, layer placement, command/controller thinness, and god-file risk.
  • API changes: contract, compatibility, auth, validation, rate limits, and error shape.
  • Data changes: migrations, indexes, constraints, backfills, rollback, and sensitive data handling.
  • UI changes: responsive layout, accessibility, copy, states, and screenshots.
  • Async changes: idempotency, retries, timeout, DLQ, and observability.
  • Infra changes: plan output, least privilege, cost, scalability, rollback, and drift risk.
  • Static analysis: pre-commit hook, lint, typecheck, secret scan, dependency scan, and SAST status.

Review Findings

  • Findings must include severity, file or artifact, risk, expected behavior, and concrete recommendation.
  • Do not approve unresolved blockers, failing CI, missing tests, or undocumented risk acceptance.
  • Nitpicks must not block unless they hide real maintainability, readability, or consistency risk.
  • If the change is too large to review reliably, request split PRs or staged rollout.

Self-Review

  • Authors must review their own diff before requesting review.
  • Authors must confirm large-file additions, command-module logic, and repeated hardcoded collections were either avoided, extracted, or recorded as explicit debt.
  • Remove debug code, dead code, unrelated formatting, and accidental files.
  • Summarize architectural decisions, trade-offs, test evidence, and known gaps in the PR.
  • Confirm static analysis and required hooks passed before requesting review.

Read the full file on GitHub · 37 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. yesterday First seen · 37 lines · 437 tokens per session scan A 791a7adb85cc

Subscribe to this mod's changes

code-review-engineering is a cursor rule published in the GitHub repository jterratsdev/ableton-live-mcp (0 stars, last pushed 8d ago), licensed MIT. It adds 437 tokens to every session, about $0.0022 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.