yishan-io/yishan-mono/requesting-code-review

Requesting Code Review

Use this skill to request a focused review before changes continue or ship.

Core Principle

Review early enough to catch issues before they compound, and review with concrete scope.

When to Use This Skill

Use this skill:

• After completing a substantial task or feature
• Before merging or handing work off
• After a complex bug fix or refactor
• At natural checkpoints in multi-step work
• When a fresh set of eyes would reduce risk

For tiny mechanical edits, a separate review pass is optional.

What To Review

Prepare a tight review scope:

• What changed
• What behavior was intended
• What files or diff range matter
• What risks deserve attention

Good review requests are specific. Avoid asking for a vague review of the entire project when only one change matters.

How to Request Review

1. Identify the review scope

Prefer one of these:

• Current uncommitted diff
• A specific commit range
• A completed task's touched files

If using commits, gather the relevant base and head SHAs.

2. Dispatch a review pass

Use the code-reviewer agent for read-only code review.

Include:

• A short summary of the change
• The intended behavior or requirements
• Any known risks or areas you are unsure about
• The files or diff range to inspect

Example request contents:

Review this change for bugs, regressions, missing tests, and risky assumptions.
 
Summary: Added a new retry path for transient API failures.
Expected behavior: Requests retry once on network timeout, but not on validation errors.
Scope: diff between <base> and <head>.
Focus: error handling, duplicate side effects, and test coverage.

3. Act on the findings

• Fix blocking issues that are within the stated review scope before continuing or shipping
• Record non-blocking or out-of-scope findings as follow-up work instead of extending the current work
• If a finding seems wrong, verify it against the code and push back with evidence

Bounded Review

Keep every review bounded by its concrete scope and intended behavior. After fixing findings, request at most one follow-up review to verify those fixes.

If the user explicitly requests review rounds beyond the initial review and one follow-up, stop before dispatching more reviews. Create a new review brief with a finite review budget that states the additional scope, intended behavior, and exact number of additional rounds. Do not run an open-ended "review until clean" loop.

Review does not close a tracked task. The user controls task closure.

Review Cadence

For larger efforts:

• Review after meaningful checkpoints instead of waiting until the very end
• Avoid stacking multiple risky changes without feedback in between

For smaller efforts:

• One review near completion is usually enough

Red Flags

Do not:

• Skip review just because the change feels simple
• Ask for review without stating the intended behavior
• Ignore serious findings and continue anyway
• Treat review as a formality instead of a real risk check

Bottom Line

Request review with concrete scope, clear expectations, and enough context for someone to find real issues quickly.