Agent Skills by Damian Galarza — плагин

---
name: team-code-review
description: Review an agent's own code changes or another contributor's pull request by dispatching specialist agents, verifying every finding, and reporting only evidence-backed issues. Use when the user asks for a code review, PR review, review of a diff, or a multi-agent quality audit.
---

# Team Code Review

Run a read-only, static, evidence-driven code review with specialist agents. The main agent owns scope, verification, deduplication, severity, editorial judgment, and the final report. Evidence comes from reading code, not executing it: the review does not run tests, linters, type checkers, or builds — CI owns that feedback loop.

## 1. Establish the review target

Determine whether the target is:

- **Own work:** changes produced by the current agent or agent team.
- **Another contributor's pull request:** a PR authored outside the current agent team.

Read the repository instructions first. Identify the exact review base and head, then inspect the complete diff and relevant surrounding code. Do not silently broaden the review to unrelated working-tree changes. If authorship is unclear, infer it from the conversation and PR metadata when available; ask only when the answer changes the workflow and cannot be discovered.

Detect the application stack from repository evidence such as dependency manifests, framework configuration, and directory structure. Load any matching review profile before dispatching specialists. For a Rails application, read [references/rails.md](references/rails.md) and incorporate its applicable checks into the specialist assignments. Treat profiles as opinionated investigation guidance, not automatic findings; explicit repository instructions and documented architectural decisions take precedence.

Record explicit non-goals and constraints. Keep the review read-only unless the user separately asks for fixes.

Completion criterion: the review target, authorship branch, base/head, repository guidance, changed files, application stack, and applicable review profiles are known.

## 2. Dispatch the review team

Use subagents when the runtime supports them. Give each specialist the same target, base/head, repository instructions, and read-only constraint. Assign non-overlapping primary lenses:

1. **Architecture and code quality** — assess whether responsibilities and abstractions are coherent; identify duplication or misplaced behavior; check for appropriate API clients, service objects, collaborators, boundaries, and reuse without demanding abstractions that the code does not yet need.
2. **Readability** — assess naming, control flow, local complexity, consistency, error handling, and whether intent is easy to recover from the code.
3. **Testing** — trace each changed behavior to meaningful coverage, including success and failure paths, boundary cases, regressions, and integration points. For HTTP behavior, check request construction, headers/authentication, serialization, response parsing, relevant status codes, malformed responses, timeouts, retries/idempotency where applicable, and network failures. Prefer behavioral tests over implementation-coupled assertions.
4. **Maintainability** — assess coupling, extension cost, dependency direction, operational burden, compatibility, observability, and likely future failure modes.
5. **Security** — trace trust boundaries and data flow; assess authentication, authorization, validation, injection, secret exposure, sensitive logging, dependency risk, unsafe defaults, and failure behavior. Do not inflate hypothetical risks beyond what the code supports.
6. **Documentation** — check public interfaces, setup/configuration, migrations, operational changes, examples, changelog/release notes, and repository architecture or runbook documentation affected by the change.

Ask every specialist to return only actionable findings with:

- severity, likelihood, and confidence;
- exact file and tight line range;
- the concrete failure mode or maintenance cost;
- the specific conditions that trigger it, and evidence that a real caller, input, configuration, or schedule can produce those conditions;
- evidence from the diff and relevant surrounding code;
- the reasoning path that validates the claim, grounded in the cited code;
- a concise remediation direction.