github-pr-review-comments

name	github-pr-review-comments
description	Use when the user asks to review GitHub pull requests, identify concrete risks, and write review comments with `gh`. Focus on actionable findings, not summaries.
metadata	{"author":"friuns2"}

GitHub PR Review Comments

When To Use

Use this skill when the user asks to:

• review open GitHub PRs
• check PRs not opened by the repo owner
• identify bugs, regressions, or missing validation in a PR
• write review comments back to GitHub with gh

Goal

Produce high-signal PR review findings and, when requested, post concise review comments with gh.

Review Standard

Default to a code review mindset:

• prioritize correctness bugs
• prioritize behavioral regressions
• prioritize compatibility and rollout risk
• prioritize missing validation where the blast radius is meaningful
• avoid low-value style commentary unless it masks a real bug

A review comment should only be posted if it says something concrete that could block, regress, or materially weaken the change.

Workflow

1. Identify candidate PRs

• Prefer gh pr list --repo friuns2/codexUI --state open.
• If the user asks for PRs not by owner, filter out PRs whose author matches the repo owner.

2. Gather PR context

• Read PR title, author, body, changed files, and commits:
  • gh pr view <number> --repo friuns2/codexUI --json ...
• Read the diff:
  • gh pr diff <number> --repo friuns2/codexUI
• Narrow attention to risky files and changed contracts.

3. Form findings

• Each finding should answer:
  • what can break
  • why it can break
  • where in the patch it comes from
• Prefer 0-3 real findings over a long weak list.

4. Write comments when requested

• Use gh pr comment <number> --repo friuns2/codexUI --body ...
• Keep comments short, direct, and technical.
• One comment per distinct issue is preferred when the issues are unrelated.

Comment Style

Use a terse, high-conviction review style:

• direct
• unsentimental
• technical
• specific about the failure mode

Good pattern:

1. Name the concern in one sentence.
2. Explain the concrete breakage path.
3. State what needs to be clarified, tested, or fixed before merge.

Avoid:

• excessive hedging
• praise padding
• long summaries of the PR before the issue
• vague “maybe consider” language when the risk is real

Repo-Specific Notes

• Canonical GitHub repo: friuns2/codexUI
• Prefer reviewing non-owner PRs first when the user asks broadly.
• If a finding is platform-related, explicitly call out the platform that should be tested, for example WSL, Linux, macOS, or Windows.
• If you post comments, preserve the user’s requested tone as long as it stays professional and non-abusive.

Output Expectations

When reporting back to the user:

• list findings first
• include PR number
• include the short reason
• mention whether comments were posted

If no real findings are found, say so directly.

---

Source: friuns2/codex-mobile — distributed by TomeVault.