backend-code-reviewlisted

Review backend / server-side code (Express, Node, TypeScript, Mongoose APIs) for correctness, security, convention adherence, and duplication. Use whenever the user asks to review, audit, critique, or sanity-check backend code — "review this service", "code review the auth module", "review my changes / this PR / the diff", "is this production-ready", "check this for issues". It reads ARCHITECTURE.md + MODULE_REGISTRY.md so it reviews against THIS project's conventions and flags code that duplicates existing registry entries (DRY). Standalone and read-only — run anytime, never auto-chained, and it does not modify source unless explicitly asked to apply fixes. Tuned for backend; not for frontend/React review. This is static code review only — it does NOT run the app or confirm a change behaves correctly at runtime; requests like "verify it works", "does it run", or "check that my change actually works" are run/verify intent (/verify or /run), not review.
vipincode/exr-agent-skills · ★ 0 · Code & Development · score 57

Install: claude install-skill vipincode/exr-agent-skills

# backend-code-review Review backend code against the project's own conventions and solid server-side practice, and report findings the user can act on. The thing that makes this more useful than a generic review: it reads the contract, so it reviews against *this* project (its envelope, error model, validation flow, layout, paradigm, import convention) instead of imposing a personal style — and it checks new code against `MODULE_REGISTRY.md` to catch reinvented utilities. Standalone, read-only utility. Run on demand against a file, a module, a set of changed files, or a diff. **Never auto-invoked by other skills, and it does not edit source unless the user explicitly asks for fixes.** ## Step 1 — Establish scope and context **First resolve the project dir** for this (`backend`) domain via `../LAYOUT.md` (read `.claude/workspace.json`; fall back to the repo root if a root `ARCHITECTURE.md` exists with no manifest). The contract files and the code under review are **relative to that project dir** — in a monorepo this also keeps the review scoped to the backend folder rather than a sibling `frontend/`. 1. **Scope** — what to review. Detect from the request: a named file/module, the working changes (`git diff`, staged, or a branch/PR), or "the project". If a repo is git-managed and the user says "my changes"/"this PR", review the diff, not the whole tree. Ask only if scope is genuinely unclear. 2. **Contract** — read `ARCHITECTURE.md` and `MODULE_REGISTRY.md` if present. Re