Run any Skill in Manus with one click

code-review

Stars1

Forks0

UpdatedMay 1, 2026 at 05:27

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

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

nuumz

nuumz/vinyan

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software Quality Assurance Analysts and TestersComputer and Mathematical Occupations·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.

More from this repository

same repository

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.