Vibeset

Review the diff

Reviews what you changed before you push it, and separates what breaks from what is just taste.

Cuándo se usa

Before any meaningful commit or before opening a pull request.

SKILL.md

# Review the diff

Review the changes in the given branch or range. With no argument, review what is
uncommitted. Read the whole file around each change, not just the diff hunk: half
the real defects live in how the change fits what was already there.

## Look for, in this order

1. **Correctness.** Uncovered edge cases: empty list, null value, network error,
   double click, response that arrives late.
2. **State and effects.** Effects without cleanup, listeners never removed,
   wrongly declared dependencies, writes to an unmounted component.
3. **User data.** Anything coming from outside is validated before use. No keys
   or tokens in the code.
4. **Broken contract.** Signatures changed without updating callers, fields
   renamed without a migration.
5. **Repetition that weighs.** A pattern copied three times is a function. Twice,
   not yet.

## How to answer

One finding per line, most to least severe, with file, line and the concrete
failing scenario ("if the user clicks twice in a row, the request fires twice").
If there is nothing to say, say it in one line.

Always separate what breaks from what is preference, and mark the latter as
optional. Do not rewrite the author's style.