Add GitHub PR review comment skill

Author: friuns

.agents/skills/github-pr-review-comments/SKILL.md

@@ -0,0 +1,96 @@
+---
+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.
+---
+
+# 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.