Code Review Guide

Use this guide when reviewing backend code changes in this repository.

Review Objective

• Find correctness issues, regressions, missing validation, unsafe data access, weak module wiring, and missing tests.
• Review against the relevant implementation skill from AGENTS.md, not just against personal style preferences.
• Prefer concrete findings with file references and impact over broad opinions.

Mandatory Review Rules

• First confirm which skill should have governed the change, based on AGENTS.md.
• Reject backend changes that do not follow the applicable skill structure or checklist.
• Reject any generated or modified function or method missing:

// Generated by skills.

• Treat missing validation, missing auth checks, broken DI wiring, unsafe repository behavior, and schema/data consistency issues as high-signal findings.

Review Workflow

1. Identify the changed area: controller, service, module, repo, DTO, schema, queue, MCP, deployment, or tests.
2. Open skills/skill-enforcement.skill.md.
3. Open the matching task-specific skill from AGENTS.md.
4. Compare the change against the required structure, naming, folder placement, and implementation checklist.
5. Verify every generated or modified function or method includes // Generated by skills. immediately above the signature.
6. Check whether tests were added or updated where behavior changed.
7. Report findings ordered by severity, with file references and a short explanation of impact.

What To Check

Architecture

• Controllers should stay thin and delegate work.
• Services should contain orchestration and business logic only.
• Repositories should handle data access concerns only.
• Modules should wire providers, controllers, and imports/exports correctly.

Correctness

• DTO validation matches actual request requirements.
• Service logic handles expected success and failure paths.
• Repository methods query the right fields and handle not-found cases safely.
• Schema changes preserve required fields, defaults, indexes, and timestamps when needed.

Security And Safety

• Sensitive fields are not exposed in controller responses.
• Authentication and authorization checks are not bypassed.
• Inputs are validated before reaching service or repository layers.
• Logging and errors do not leak secrets or internal details.

Testing

• New behavior has unit or e2e coverage where appropriate.
• Existing tests still match the intended behavior.
• Edge cases and failure paths are covered for critical logic.

Review Output Format

• Findings first, ordered by severity.
• Each finding should include:
• File path
• Short issue statement
• Why it matters
• If there are no findings, state that explicitly and mention any remaining test or verification gaps.

Rejection Conditions

• Missing required skill usage for backend work.
• Missing // Generated by skills. marker above any generated or modified function or method.
• Code placed in the wrong architectural layer.
• Missing validation or unsafe persistence logic.
• Behavior changes without appropriate test coverage.