Sc:code Review

Code Review — senior-engineer pass over a diff/PR

Find what matters and say it clearly. A good review surfaces real defects with evidence, not a list of style opinions. Default to reviewing the changed lines and their blast radius.

Step 0 — orient

• What is this change trying to do? (Read the PR description / commit messages / the diff intent.)
• What's the blast radius — what calls this, what does it call, what data does it touch?
• Get the actual diff (git diff), don't review from memory.

Review dimensions (in priority order)

1. Correctness & edge cases — does it do what it claims? Off-by-one, null/empty/None, error paths,

async races, unhandled rejections, boundary inputs, wrong default. This is most of the value.

1. Security — input validation, injection (SQL/command/path traversal), authn/authz checks,

secrets in code/logs, unsafe deserialization, XSS/CSRF for web, SSRF for fetchers.

1. Resource & performance — N+1 queries, unbounded loops/memory, missing pagination, blocking I/O

on a hot path, leaks (listeners, handles), needless re-renders.

1. API & data contracts — backward compatibility, migration safety, nullable changes, error shapes.
2. Readability & maintainability — names, dead code, duplication, function size, matches the

surrounding style. Flag, don't bikeshed.

1. Tests — is the new behavior covered? Are the tests meaningful (assert real outcomes) or hollow?

How to report findings

For each finding:

• Severity: blocker / major / minor / nit.
• Location: file:line (clickable).
• What & why: the concrete problem and the failure it causes — quote the code.
• Fix: a specific suggestion (or a diff), not "consider improving this".

Group by severity; lead with blockers. Example: > [blocker] auth.ts:42 — token compared with ==, so an empty token matches when the stored > value is also falsy. Use a constant-time compare and reject empty tokens.

Discipline

• Verify before asserting. Trace the data flow; don't claim a bug you didn't confirm in the code.

If you're unsure, say "possible issue — verify X", don't state it as fact.

• Separate must-fix (correctness/security) from nice-to-have (style). Don't drown blockers in nits.
• Praise genuinely good choices briefly — it calibrates the rest.
• If the diff is large, review in passes (correctness → security → the rest) rather than skimming once.
• RTL/Hebrew web code: check for physical-CSS leftovers (left/right/ml-/mr-) that break RTL —

prefer logical properties.

Output shape

A short summary verdict (approve / approve-with-changes / request-changes), then findings grouped by severity, then a one-line note on test coverage.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: squadcodercom
• Source: squadcodercom/squadcoder
• License: MIT
• Homepage: https://squadcoder.com

Install and usage instructions live in the source repository linked above.