code-review-giving

Guide pull request reviews with severity-tiered comments and triage ordering.

Updated Aug 23, 2026
One-click install
npx skills add https://github.com/ohsonerdy/openclaw-frontier-stack --skill code-review-giving
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: code-review-giving
Source: https://github.com/ohsonerdy/openclaw-frontier-stack/tree/main/skills/code-review-giving
Command: npx skills add https://github.com/ohsonerdy/openclaw-frontier-stack --skill code-review-giving

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) and references (resource) and assets (resource) components.

What problem does it solve?

This Skill helps reviewers give high-signal PR feedback that prevents correctness, security, and contract regressions while avoiding style nits and low-value commentary.

Core Features & Use Cases

  • Structured review comments: Uses severity tiers (Blocking, Suggestion, Nit, Question) to clearly communicate what must change versus what is optional.
  • Triage-first review process: Prioritizes correctness, security, and compatibility before tests, maintainability, and style.
  • Fail-safe guidance: Identifies fail-open patterns (e.g., catch-and-ignore) and treats them as high-priority issues.
  • Review-role handling: Covers named reviews, drive-by reviews, and approvals with comments without creating “phantom approval” contradictions.
  • Blast-radius awareness: Adjusts review strictness when changes exceed the diff (e.g., dependency bumps, public API contracts).

Quick Start

Use the code-review-giving skill to review the pull request and produce blocking, suggestion, question, and nit comments in an order that prioritizes correctness and security.

Frequently Asked Questions about code-review-giving

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I structure pull request feedback to prevent bugs without drowning the author in nits?

Use severity tiers (Blocking, Suggestion, Nit, Question) to frame PR review comments, prioritizing correctness and security issues over style nits. This triage-first process prevents real regressions while avoiding low-value commentary that drowns pull requests.

What is the best way to prioritize issues during a GitHub code review?

Prioritize code review issues using a triage-first process: correctness, security, and public API compatibility first, then tests, maintainability, and style. This ensures high-signal PR feedback catches critical contract regressions before low-impact style nits.

How do I catch fail-open error handling patterns when reviewing pull requests?

Detect fail-open error handling patterns like catch-and-ignore blocks during PR reviews and treat them as high-priority blocking issues. This fail-safe guidance catches silent error swallowing that causes runtime failures and security gaps.

When should I adjust code review strictness for dependency bumps and public API changes?

Adjust review strictness when changes exceed the diff's blast radius, such as dependency bumps or public API contract modifications. These high-impact changes demand stricter scrutiny to prevent compatibility regressions across the broader system.

How do I avoid phantom approval contradictions when leaving comments on a pull request?

Avoid phantom approval contradictions by using review-role handling for named reviews, drive-by reviews, and approvals with comments. This ensures your approval status aligns with your feedback, preventing contradictory signals to the PR author.