Ejecuta cualquier Skill en Manus
con un clic

Ejecuta cualquier Skill en Manus con un clic

code-review

Estrellas1

Forks0

Actualizado1 de mayo de 2026 a las 05:27

Review code changes for correctness, error handling, scope creep, and style. Use when the goal mentions reviewing a PR, diff, or file.

Instalación

Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.

Ejecutar en Manus

Fuente

nuumz

nuumz/vinyan

Abrir repositorio de GitHub Ver repositorios del creador

Descarga

Ejecutar en Manus

Ocupaciones relacionadasSOC

Basado en la clasificación ocupacional SOC

Analistas de garantía de calidad de software y probadoresOcupaciones informáticas y matemáticas·SOC 15-1253

SKILL.md

readonly

name	code-review
description	Review code changes for correctness, error handling, scope creep, and style. Use when the goal mentions reviewing a PR, diff, or file.

Code Review

Approach a review like a senior engineer who has to live with the consequences of merging this code.

When to use

The user asks to review, audit, critique, or sanity-check a code change.
A PR description, diff, or file path is in the task.
The user wants to know whether a patch is safe to merge.

Procedure

Read the diff end-to-end before commenting. Skim the full change first — don't react to line 1 before understanding line 200. Form a mental model of what the change is trying to do.
Match against the stated intent. Does the diff actually accomplish what the PR says? Note unrelated edits as separate items, not approval blockers.
Walk error and edge paths. Null/undefined, empty arrays, off-by-one, timeout, partial failure, concurrent access. Identify the worst-case input and ask: does the code handle it cleanly?
Check scope. Refactor mixed with feature work? Stylistic noise? Drive-by renames? Call out scope creep — bug fixes don't need surrounding cleanup.
Verify tests follow the change. New behavior → new test. Bug fix → regression test that fails without the fix. Test quality matters: a passing assertion that doesn't actually test the change is worse than no test.
Look for the failing invariant. When something feels wrong, name what specifically would break. "This is wrong" is unhelpful; "this overwrites the cache during concurrent writes" is actionable.

Output

Group findings by severity: must-fix → should-fix → nit.
For each finding, cite file:line and name the failing invariant.
End with an explicit verdict: ready to merge / needs changes / needs discussion.
Don't quote the diff back to the author — they wrote it.

Más de este repositorio

mismo repositorio

debug-trace

nuumz/vinyan

Walk through a stack trace or error log to find the root cause. Use when the goal mentions debugging, investigating an error, or tracking down a bug.

2026-05-011

git-commit-message

nuumz/vinyan

Write a Conventional Commits message describing a code change. Use when the goal mentions creating a commit, writing commit message, or committing changes.

2026-05-011

unit-test-plan

nuumz/vinyan

Outline unit tests for a function or module before writing them. Use when the goal mentions writing tests, test plan, or test coverage.

2026-05-011

budget-and-scope

nuumz/vinyan

Keep effort proportional to risk — prefer the cheapest sufficient workflow, escalate only on evidence, refuse over-analysis on simple tasks. Use when choosing depth, level, or workflow shape.

2026-05-011

capability-mapping

nuumz/vinyan

Map required capabilities to persona roles and available skills. Detect missing skill coverage and decide whether to acquire a skill, request one, or proceed generically. Use when scoping a workflow.

2026-05-011

collaboration-room

nuumz/vinyan

Coordinate multi-persona work with a shared blackboard, role boundaries, hand-off contract, conflict resolution, and final synthesis. Use when a task benefits from more than one persona.

2026-05-011

name	code-review
description	Review code changes for correctness, error handling, scope creep, and style. Use when the goal mentions reviewing a PR, diff, or file.

Code Review

Approach a review like a senior engineer who has to live with the consequences of merging this code.

When to use

The user asks to review, audit, critique, or sanity-check a code change.
A PR description, diff, or file path is in the task.
The user wants to know whether a patch is safe to merge.

Procedure

Read the diff end-to-end before commenting. Skim the full change first — don't react to line 1 before understanding line 200. Form a mental model of what the change is trying to do.
Match against the stated intent. Does the diff actually accomplish what the PR says? Note unrelated edits as separate items, not approval blockers.
Walk error and edge paths. Null/undefined, empty arrays, off-by-one, timeout, partial failure, concurrent access. Identify the worst-case input and ask: does the code handle it cleanly?
Check scope. Refactor mixed with feature work? Stylistic noise? Drive-by renames? Call out scope creep — bug fixes don't need surrounding cleanup.
Verify tests follow the change. New behavior → new test. Bug fix → regression test that fails without the fix. Test quality matters: a passing assertion that doesn't actually test the change is worse than no test.
Look for the failing invariant. When something feels wrong, name what specifically would break. "This is wrong" is unhelpful; "this overwrites the cache during concurrent writes" is actionable.

Output

Group findings by severity: must-fix → should-fix → nit.
For each finding, cite file:line and name the failing invariant.
End with an explicit verdict: ready to merge / needs changes / needs discussion.
Don't quote the diff back to the author — they wrote it.