Kelly pr review
Agent Skills by mr-kelly
npx -y skills add mr-kelly/skills --skill kelly-pr-reviewAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 3 stars3 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
GitHub pull request review desk using gh CLI, local App-in-Skill UI, AI review notes, human approval, and approved gh pr review execution. Use when the user invokes /kelly-pr-review, asks to review GitHub PRs, generate a PR review batch, approve/comment/request changes through a local UI, or execute approved GitHub reviews.
SKILL.md
6.7 KB, ~1.5k tokens by cl100k_base, as published. Nobody here has run it
Kelly PR Review
App UI Screenshots
<table> <tr> <td width="50%"><img src="assets/screenshots/overview.webp" alt="Kelly PR Review overview"></td> <td width="50%"><img src="assets/screenshots/needs-review.webp" alt="Kelly PR Review needs review"></td> </tr> <tr> <td><strong>Overview</strong><br>Pull request review desk with repository filters, status counts, and reviewer configuration.</td> <td><strong>Needs review</strong><br>Mock pull request review with findings, confidence signals, test notes, and suggested actions.</td> </tr> <tr> <td width="50%"><img src="assets/screenshots/ready.webp" alt="Kelly PR Review ready to approve"></td> <td width="50%"><img src="assets/screenshots/blocked-security.webp" alt="Kelly PR Review blocked review"></td> </tr> <tr> <td><strong>Ready to approve</strong><br>Approval-focused review where checks pass and the final recommendation is ready to send.</td> <td><strong>Blocked review</strong><br>Security-sensitive PR scenario with unresolved risk, blocking rationale, and reviewer handoff details.</td> </tr> <tr> <td width="50%"><img src="assets/screenshots/needs-test.webp" alt="Kelly PR Review merged PR needs test"></td> <td width="50%"><img src="assets/screenshots/tested.webp" alt="Kelly PR Review tested verification"></td> </tr> <tr> <td><strong>Needs test</strong><br>Merged pull request waiting for human verification with a required test note or screenshot evidence.</td> <td><strong>Tested</strong><br>Post-merge verification record showing the local test note that proves a human checked the change.</td> </tr> </table>Overview
Use this skill as a GitHub pull request review desk backed by the gh CLI. The skill gathers PRs, prepares review notes and proposed review actions, writes a local batch, launches the App-in-Skill UI for human approval, then later executes only approved decisions with gh pr review.
Default interaction mode: App UI. Unless the user explicitly asks for chat-only handling, generate or update the local batch, ensure the UI is running, and send the user to the actual local URL, preferring http://127.0.0.1:3001/ and the 3000-4000 port range unless KELLY_PR_REVIEW_UI_PORT is set. Use chat-only review only when the user says "纯聊天", "chat only", "不要打开 UI", or similar.
The app is file-only. It never calls GitHub, submits reviews, merges, closes, comments, or mutates repositories. It reads app/.cache/current_batch.json and writes app/.cache/decisions.json. The skill scripts perform all GitHub reads and approved executions.
Private Configuration
Private config is optional. By default this skill uses the current gh authenticated account and searches open PRs requesting @me across accessible repositories. Use private config only for repo filters, reviewers, default review policy, and risk rules. Do not hardcode personal repositories or tokens into committed files.
Config priority:
KELLY_PR_REVIEW_CONFIG=/absolute/path/to/config.jsonskills/kelly-pr-review/config.local.json~/.config/kelly-pr-review/config.jsonskills/kelly-pr-review/config.example.json
Env priority:
- Existing system environment variables
KELLY_PR_REVIEW_ENV_FILE=/absolute/path/to/.env- repository root
.env skills/kelly-pr-review/.env.local~/.config/kelly-pr-review/.env
Secrets should live in env files only. Usually gh auth login is enough, so this skill does not require a token in config.
Treat config.example.json as a template for optional preferences. If no private config exists, do not block real data; use gh defaults. Use --sample only when the user explicitly wants to preview the UI with fake data. This skill has no npm dependencies; keep runtime config in JSON and do not add YAML parsing packages.
Workflow
- Check
gh auth status. If not authenticated, stop and ask the user to authenticate withgh auth login. - Load optional config through
lib/data-reader/. - Generate a bounded PR batch using
gh search prs --review-requested=@me --state=open; add repository filters only when configured. - For each PR, gather metadata and changed files with
gh pr viewandgh pr diff --name-only. Skip patch excerpts by default for speed; fetch compact patches only wheninclude_patch_excerptis enabled or a specific PR needs deeper review. - Classify status:
needs_review: user or agent needs to inspect before deciding.to_approve: agent proposes a concrete review action.approved: user approved an action in the UI.done: review action already executed or intentionally no-op.blocked: missing access, too risky, failing preconditions, or too large to review safely.
- In App UI mode, write
app/.cache/current_batch.json, start or reuse the UI, then ask the user to review there. - Execute later only when the user asks to execute approved decisions. Default execution script mode is dry-run; live execution requires explicit live mode.
Review Actions
Supported approved actions:
approve:gh pr review <number> --approve -b <body>comment:gh pr review <number> --comment -b <body>request_changes:gh pr review <number> --request-changes -b <body>no_action: write execution report only; no GitHub call.needs_revieworblock: do not execute.
Never merge, close, push, edit branches, rerun workflows, or dismiss reviews from this skill.
Safety Rules
- Require explicit UI or chat approval before any
gh pr reviewcall. - Re-read
decisions.jsonand validate it immediately before execution. - Create
app/.cache/agent.lockduring generation and execution. - Write execution results to
app/.cache/execution_report.json. - Keep review bodies user-editable and quote only necessary source excerpts.
- Mark security, auth, billing, schema migration, destructive data, generated-code-heavy, and large-diff PRs as risky.
- If the review confidence is low, propose
commentorneeds_review, not approval.
Useful Commands
node skills/kelly-pr-review/scripts/generate_review_batch.ts
skills/kelly-pr-review/app/start.sh
node skills/kelly-pr-review/scripts/validate_ui_schema.ts
node skills/kelly-pr-review/scripts/execute_decisions.ts --dry-run
node skills/kelly-pr-review/scripts/execute_decisions.ts --live
In normal use, invoke /kelly-pr-review and let the skill generate the batch and start the UI.
Gives 0 of the 12 instructions most pr commit review skills give in ~1.5k tokens
Counted across 888 of the 1,342 authors here whose files we hold, read 2026-08-06
- use conventional commits formatin 123 of 888, across 110 files
- keep subject line under 72 charactersin 60 of 888, across 46 files
- delete branches after mergein 50 of 888, across 37 files
- use imperative mood in subject linein 50 of 888, across 41 files
- use imperative mood in commit messagesin 45 of 888
- generate a conventional commit messagein 42 of 888
- make atomic commitsin 37 of 888, across 25 files
- run tests before committingin 36 of 888, across 24 files
- run project test suite to verify clean baselinein 35 of 888, across 7 files
- run detected project setup commandsin 34 of 888, across 6 files
- wrap commit body at 72 charactersin 32 of 888, across 25 files
- split unrelated changes into separate commitsin 32 of 888, across 27 files
Said here and by no other author read
- generate open PR batch
- classify each PR status
- write current batch to JSON
- start local UI for human approval
- re-read decisions file before execution
- create lock file during execution
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.