Backend Code Review

by langgenius2b65f0e89309No license157K starsListed Oct 8, 2026Updated Oct 8, 2026Repository updated today

Use only when the user explicitly requests a review or audit of backend code under `api/`. Supports pending-change, file-focused, and pasted-diff reviews. Do not use for implementation-only requests, diagnosis without review intent, frontend code, or backend code outside `api/`.

Instructions onlySoftware Development
AI-generated overview

Reviews backend code under api/ for concrete defects, routing to bundled rule packs by change type.

What it does
Reviews a requested backend scope under api/ — pending changes, specific files, or a pasted diff — and reports only findings tied to observable failures, violated contracts, security boundaries, data integrity risks, or demonstrated maintenance problems. It routes the review to bundled rule packs for database schema, architecture, repositories, and SQLAlchemy when the diff matches. Findings are ordered by severity from P0 to P3 with file and line references, impact, and a concrete fix direction.
When to use it
Use when the user explicitly asks for a review or audit of backend code under api/. It is not intended for implementation-only requests, diagnosis without review intent, frontend code, or backend code outside api/.
Requirements
No scripts; instructions and reference rule packs only. It relies on the nearest AGENTS.md for package facts and commands, and may consult current official documentation when local code and contracts do not settle framework or library behavior.

Backend Code Review

Review the requested scope for concrete, reproducible defects. The nearest AGENTS.md owns package facts and commands; this skill owns the review workflow and routes to its bundled rule packs.

Evidence First

  1. Establish the requested review scope and inspect the relevant diff or files.
  2. Read the changed lines, their behavior owner, nearby tests, and local docstrings or comments that define contracts.
  3. Trace callers, persistence boundaries, authorization, generated schemas, or external I/O only when they decide correctness.
  4. Report only findings tied to an observable failure, violated contract, security boundary, data integrity risk, or demonstrated maintenance problem.

Rule Routing

Read only the packs matched by the diff:

  • Models or migrations: references/db-schema-rule.md [blocked]
  • Controller, service, core/domain, library, or model dependency direction: references/architecture-rule.md [blocked]
  • Table access outside an established repository boundary: references/repositories-rule.md [blocked]
  • SQLAlchemy sessions, queries, transactions, CRUD, concurrency, or raw SQL: references/sqlalchemy-rule.md [blocked]

When no pack applies, review correctness, security, behavior changes, and test evidence directly. Check current official documentation only when local code and contracts do not settle framework or library behavior.

Severity And Output

  • P0: security or privacy exposure, data loss, or a production-wide outage.
  • P1: user-visible regression, broken authorization or tenant isolation, invalid public contract, or failed primary workflow.
  • P2: concrete correctness, performance, maintainability, or test defect likely to cause incorrect behavior.
  • P3: minor actionable cleanup; omit unless the user requested a thorough audit.

Lead with findings ordered by severity. Include a tight file and line reference, the failing contract or reproduction path, impact, and a concrete fix direction. If there are no findings, say No issues found. and state any material verification gap. Do not add praise sections, speculative risks, or an unsolicited offer to implement fixes.

Source and attribution

Source:langgenius/difyin.agents/skills/backend-code-reviewat commit2b65f0e

License: No license

Content belongs to its original authors. SourceWeft indexes it from a public repository.

Report or request removal