Execute qualquer Skill no Manus
com um clique

Execute qualquer Skill no Manus com um clique

code-review

Estrelas1

Forks0

Atualizado1 de maio de 2026 às 05:27

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

Instalação

Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.

Executar no Manus

Fonte

nuumz

nuumz/vinyan

Abrir repositório GitHub Ver repositórios do creator

Download

Executar no Manus

Ocupações relacionadasSOC

Baseado na classificação ocupacional SOC

Analistas de garantia de qualidade de software e testadoresInformática e Matemática·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.

Mais deste repositório

mesmo repositório

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.