github-pr-review-comments

# 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.