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.