wasp-review

name	wasp-review
description	Review code changes for correctness, clarity, and potential issues. Use when the user asks for a review, code review, PR review, or wants feedback on a diff or file.

Rules

Naming And Vocabulary

• Demand precise, informative names. Names must not misdirect, omit relevant behavior, or assume unavailable context.
• Make names accurately reflect what their declarations represent.
• Context is king: evaluate names within their scope and surrounding vocabulary.
• Use established codebase terminology consistently.
• Follow established naming conventions e.g. is... for booleans and ensure... for idempotent setup operations.
• Treat awkward names as evidence of design problems. If an accurate name becomes excessively long or complicated, inspect whether the declaration has too many responsibilities.
• Avoid vague names such as data, info, or unexplained single letters.

Contracts And Interfaces

• Review names before implementation details. Poor names often expose deeper problems in decomposition and architecture.
• Declaration should be enough to understand, without the implementation. A function’s name, arguments, types, and contract should explain its behavior.

Readability And Context

• Demand code to be easy to read. Understanding one section should not require reading the entire file.
• Review from the perspective of a developer with minimal reasonable context.

Design And Architecture

• Treat and or then in a function name as a possible responsibility smell.
• Treat groups of similarly prefixed parameters as possible missing abstractions.
• Make sure the code is DRY. Introduce helpers for commonly repeated concepts.
• Identify hidden assumptions. Require assumptions to be enforced through types, runtime checks, or comments, in that order.