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/`.
backend-code-review is a workflow skill from the Dify project that guides an AI assistant through reviewing or auditing backend Python code living under the repository's `api/` directory. It exists to keep code review focused and evidence-based: it only triggers when a user explicitly asks for a review, and it deliberately excludes implementation-only requests, pure diagnosis, frontend code, and any backend code outside `api/`. The goal is concrete, reproducible defect findings rather than vague or speculative feedback.
The skill defines an evidence-first process (establish scope, read changed lines and their contracts, trace callers and persistence boundaries only when they affect correctness) and routes to bundled rule packs based on what the diff touches. Rule packs cover database schema and migrations, controller/service/core layering and dependency direction, repository access boundaries, and SQLAlchemy session, transaction, tenant-scoping, raw-SQL, and concurrency patterns. Findings are graded by severity from P0 (security exposure, data loss, outage) down to P3 (minor cleanup), and each finding is expected to carry a tight file/line reference, the violated contract or reproduction path, impact, and a concrete fix direction.
It is aimed at backend engineers and maintainers working in the Dify codebase or similar Flask/SQLAlchemy multi-tenant services who want disciplined, severity-ordered reviews. Typical use cases include reviewing a pending change set, auditing a specific file, or evaluating a pasted diff before merge, with particular attention to tenant isolation, transaction correctness, and architectural layering.
Only when a user explicitly requests a review or audit of backend code under `api/`. It supports pending-change reviews, file-focused reviews, and pasted diffs. It should not be used for implementation-only requests, diagnosis without review intent, frontend code, or backend code outside `api/`.
Concrete, reproducible defects tied to an observable failure, violated contract, security or tenant-isolation boundary, data-integrity risk, or demonstrated maintenance problem. It routes to rule packs for DB schema/migrations, architecture/layering, repository boundaries, and SQLAlchemy session/transaction/concurrency patterns.
By severity: P0 for security/privacy exposure, data loss, or production-wide outage; P1 for user-visible regressions or broken authorization/tenant isolation; P2 for concrete correctness/performance/test defects; and P3 for minor cleanup, which is omitted unless a thorough audit was requested.
It only reports. The skill explicitly avoids praise sections, speculative risks, and unsolicited offers to implement fixes; if there are no findings it says so and notes any material verification gap.
It assumes a Python backend using SQLAlchemy with a multi-tenant model (tenant_id scoping) and a controller/service/core layering convention, and that the nearest AGENTS.md owns package-specific facts and commands.
Quick Setup:
.claude/skills/Repository
langgenius/dify