# Cursor Review

> Structured, severity-tagged code review of a diff or set of changes, tuned for an MSP / professional-services environment (client data, secrets, least privilege). Use this whenever the user asks to "review", "check", "audit", or "look over" code, before a merge or PR, or after a batch of edits. Layers a DP3-specific security and reliability checklist on top of Claude Code's native /review and /security-review. Do not rubber-stamp. Invokable as /cursor-review.

- Skill: `jambot24/cursor-review` (Agent Skill)
- Install (CLI): `npx skillmds@latest add jambot24/cursor-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/jambot24/cursor-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: jambot24 (https://skillmd.com/u/jambot24)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/jambot24/cursor-review

---


# Cursor Review

A Bugbot-style review pass. This does not replace the built-in `/review` and
`/security-review` commands; it runs their general checks **and** adds an
overlay for the realities of supporting law firms and professional-services
clients.

## Workflow

### 1. Determine scope
Establish exactly what to review with git:

```bash
git diff                 # unstaged
git diff --staged        # staged
git diff <base>..HEAD    # whole branch vs base
```

If scope is ambiguous, default to staged + unstaged changes and state that
assumption.

### 2. General review (native categories)
Assess correctness, edge cases, error handling, performance, readability, and
test coverage, the same dimensions `/review` and `/security-review` cover.

### 3. DP3 overlay (always apply)
Check each item explicitly:

| Area | What to flag |
|---|---|
| Secrets | Any credential, token, key, connection string, or password committed or logged. Hard fail. |
| Client / PII data | Sensitive or privileged data written to logs, telemetry, temp files, or third parties. Confirm data minimization. |
| Least privilege | Over-broad IAM/M365/AD scopes, wildcard permissions, service accounts with more rights than needed. |
| Input validation | Untrusted input (user, web, MCP/tool output) used without validation; injection surfaces. |
| Supply chain | New or bumped dependencies; unpinned versions; unexpected transitive additions. |
| Error handling | Swallowed exceptions, failures that leave systems in an inconsistent state, missing rollback. |
| Idempotency | Automation/scripts safe to re-run? Destructive operations gated and reversible? |
| PowerShell / scripts | Commented, safe-by-default, no implicit destructive actions, explicit paths, `-WhatIf`/`-Confirm` where relevant. |
| Blast radius | Changes that could disrupt client workflows or cause downtime; note rollback path. |

### 4. Output
Report findings as a severity-tagged list, highest first. For each:

- **Severity:** Critical / High / Medium / Low / Nit
- **Location:** `path:line`
- **Issue:** what is wrong
- **Fix:** concrete suggested change

End with a one-line verdict: **Block**, **Approve with required changes**, or
**Approve**. If nothing is wrong, say so plainly, do not invent issues to seem
thorough.

## Rules
- Be specific. "Consider error handling" is useless; point at the line and the
  failure mode.
- Distinguish must-fix (Critical/High) from optional (Nit) clearly.
- Read the actual changed code before commenting; never review from the diff
  summary alone.