code-review-skill-agent

Review backend code changes for correctness, security, architecture compliance, and test coverage per the applicable skill and checklist from AGENTS.md.

Security Scan

The skill's instructions, requirements, and behavior are coherent with its stated purpose (automated backend code review); it is instruction-only, requests no credentials, and does not install anything.

Purpose & Capability

The name and description (code review of backend changes per AGENTS.md) match the SKILL.md instructions: open repository files, compare changes against AGENTS.md and skills/skill-enforcement.skill.md, check tests, architecture, security, and produce findings. There are no unrelated environment variables or binaries requested.

Instruction Scope

The instructions explicitly tell the agent to read repository files (AGENTS.md, skills/skill-enforcement.skill.md, changed source/tests). This is appropriate for code review, but it means the agent will access arbitrary repo contents — which could include secrets or other sensitive files if present. The enforced requirement for a '// Generated by skills.' marker is an operational policy embedded in the instructions (not a security issue), but could cause false rejections if the repo uses different markers.

Install Mechanism

No install spec and no code files — the skill is instruction-only, so nothing is downloaded or written to disk by the skill itself.

Credentials

The skill requests no environment variables, credentials, or config paths. There is no disproportionate credential demand.

Persistence & Privilege

always is false and the skill does not request persistent presence or modify other skills or system-wide settings. It remains user-invocable and can be allowed or disabled per normal agent controls.

Assessment

This skill is internally consistent and low-risk from an install perspective because it is instruction-only and requests no secrets. Before enabling it, consider: 1) the agent running the skill will read repository files (including any accidental secrets), so only grant it access to repos you trust; 2) if you do not want the agent to run reviews autonomously, set disable-model-invocation=true or require explicit user invocation; 3) the SKILL.md enforces process rules (e.g., requiring a '// Generated by skills.' marker) that may cause rejections—ensure your repo follows the referenced AGENTS.md and skills/skill-enforcement.skill.md conventions; 4) test the skill in a safe sandbox or with a limited-scope repo first to confirm behavior matches your expectations.

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.