code-reviewer

Reviews implementation source, API/E2E test changes, and failure origins with structured reports.

2|1|Updated Mar 7, 2026
One-click install
npx skills add https://github.com/AutoByteus/autobyteus-agents --skill code-reviewer-autobyteus
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: code-reviewer
Source: https://github.com/AutoByteus/autobyteus-agents/tree/main/agent-teams/software-engineering-team/agents/code-reviewer/skills/code-reviewer
Command: npx skills add https://github.com/AutoByteus/autobyteus-agents --skill code-reviewer-autobyteus

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? It enforces consistent, evidence-grounded code review inside a multi-agent software engineering workflow, covering implementation source review before API/E2E, proportional test-code review after successful runs, and failure-origin classification after failed runs. ## Core Features & Use Cases - Three review entry points: full implementation-source and structural review, lightweight durable test-code review, and focused API/E2E failure-origin analysis, each with distinct standards. - Canonical report templates: produces code-review-report.md, api-e2e-test-review-report.md, and a chronological code-review-revision-record.md with CRR-* entries tracking every review round. - Classification and routing: classifies outcomes as Local Fix, Design Impact, Requirement Gap, or Unclear and routes handoffs to implementation, API/E2E, or solution design owners. - Use Case: After an implementation engineer hands off a feature change, the reviewer traces the production behavior path, applies structural and design checks, scores ten quality categories, and either passes the package to API/E2E testing or routes classified findings back to the owning specialist. ## Quick Start Review the implementation handoff in the task workspace against the design spec and produce the code review report with findings, scorecard, and routing decision.

Frequently Asked Questions about code-reviewer

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I review implementation code before running API/E2E tests?▼

Trace the approved behavior and production path first, then apply structural checks from data-flow spine down to file responsibility and naming. Complete the mandatory scorecard across ten categories and record findings in the canonical code review report before any handoff.

How should test code be reviewed after a successful API/E2E run?▼

Review only durable test files that were added, updated, or removed, checking scenario clarity, assertion quality, fixture reuse, isolation, and staleness. Do not apply source-file size thresholds to tests, and record the result in the separate API/E2E test review report.

What happens when an API/E2E test fails during review?▼

A failed run triggers focused failure-origin review, not a full source re-audit. Confirm the failing scenario reflects approved behavior, verify production reachability, then classify the cause as implementation defect, stale test, environment issue, design impact, or requirement gap.

Do source file size limits apply to test files?▼

No. The 500-line hard limit and 220-line delta check apply only to changed implementation source files. Large test files are acceptable when they cover one coherent behavior or surface and remain navigable.

When should a code review finding be classified as Design Impact?▼

Classify Design Impact when the structural issue originates in the reviewed design itself or an earlier design artifact was weak, incomplete, or wrong. These findings route to the solution designer rather than the implementation engineer.