code-review

Skill — Code Review

This skill defines how to perform a code review on a project using Lytos. An agent loaded with this skill knows exactly what to check, in what order, and how to formulate feedback.

---

When to invoke this skill

• After each PR before merge
• At the human's explicit request on a file or module
• At the end of a sprint, for a global quality audit

---

Procedure

0. Self-review (before requesting review)

Before requesting a review from others:

• Re-read your own diff as if you were the reviewer
• Check for forgotten debug code, TODOs, commented-out code
• Verify the PR description explains the "why"
• Confirm all tests pass locally

1. Gather context

Before starting the review:

• Read the project manifest — understand the fundamental constraints
• Read the memory — check for relevant architectural decisions
• Read the active rules — these are the quality criteria to apply
• Read the linked issue — understand the "why" behind the change

2. Review checklist

Apply each point of this checklist to the submitted code:

PR size

• The PR is under 400 lines of meaningful changes (excluding generated files, lock files)
• If larger, the PR is split into logical, reviewable chunks
• Each PR has a single focus — one feature, one fix, one refactoring

Readability

• The code reads top to bottom effortlessly
• Variable, function, and class names are explicit
• No obscure abbreviations (except established project conventions)
• Logical blocks are visually separated

Structure

• Each file is under 300 lines
• One function = one responsibility
• No excessive nesting (max 3 levels)
• Imports are organized and sorted

Naming

• Functions describe what they do (verb + noun)
• Variables describe what they contain
• Constants are in UPPER_SNAKE_CASE
• Naming is consistent with the rest of the project

Duplication

• No copy-paste — if a pattern repeats 3+ times, it must be factored out
• Existing utility functions are reused
• No reinventing what already exists in dependencies