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:
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.
1---2name: cursor-review3description: 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.4---56# Cursor Review78A Bugbot-style review pass. This does not replace the built-in `/review` and9`/security-review` commands; it runs their general checks **and** adds an10overlay for the realities of supporting law firms and professional-services11clients.1213## Workflow1415### 1. Determine scope16Establish exactly what to review with git:1718```bash19git diff # unstaged20git diff --staged # staged21git diff <base>..HEAD # whole branch vs base22```2324If scope is ambiguous, default to staged + unstaged changes and state that25assumption.2627### 2. General review (native categories)28Assess correctness, edge cases, error handling, performance, readability, and29test coverage, the same dimensions `/review` and `/security-review` cover.3031### 3. DP3 overlay (always apply)32Check each item explicitly:3334| Area | What to flag |35|---|---|36| Secrets | Any credential, token, key, connection string, or password committed or logged. Hard fail. |37| Client / PII data | Sensitive or privileged data written to logs, telemetry, temp files, or third parties. Confirm data minimization. |38| Least privilege | Over-broad IAM/M365/AD scopes, wildcard permissions, service accounts with more rights than needed. |39| Input validation | Untrusted input (user, web, MCP/tool output) used without validation; injection surfaces. |40| Supply chain | New or bumped dependencies; unpinned versions; unexpected transitive additions. |41| Error handling | Swallowed exceptions, failures that leave systems in an inconsistent state, missing rollback. |42| Idempotency | Automation/scripts safe to re-run? Destructive operations gated and reversible? |43| PowerShell / scripts | Commented, safe-by-default, no implicit destructive actions, explicit paths, `-WhatIf`/`-Confirm` where relevant. |44| Blast radius | Changes that could disrupt client workflows or cause downtime; note rollback path. |4546### 4. Output47Report findings as a severity-tagged list, highest first. For each:4849- **Severity:** Critical / High / Medium / Low / Nit50- **Location:** `path:line`51- **Issue:** what is wrong52- **Fix:** concrete suggested change5354End with a one-line verdict: **Block**, **Approve with required changes**, or55**Approve**. If nothing is wrong, say so plainly, do not invent issues to seem56thorough.5758## Rules59- Be specific. "Consider error handling" is useless; point at the line and the60 failure mode.61- Distinguish must-fix (Critical/High) from optional (Nit) clearly.62- Read the actual changed code before commenting; never review from the diff63 summary alone.
jambot24