Kelly Pr Review

Kelly PR Review

App UI Screenshots

Overview

Use this skill as a GitHub pull request review desk backed by the gh CLI and Busabase. scripts/generate_review_batch.mjs gathers PRs with gh, scores risk, proposes a review action, and writes the resulting queue into Busabase; the AirApp shows it for human approval (approve / comment / request changes / block / needs_review); scripts/execute_decisions.mjs later submits only approved decisions with the real gh pr review command.

Default behavior is AirApp-first. Unless the user explicitly asks only for explanation, generate or refresh the batch and give the user the clickable AirApp URL (or the local preview URL when local preview is explicitly requested). Use chat-only mode only when the user says "纯聊天", "chat only", "不要打开 UI", or similar.

The AirApp itself never calls GitHub. It reads and writes Busabase records only — no merge, close, comment, review submission, or repository mutation happens from the browser. Both gh CLI directions (reading PRs in, submitting approved reviews out) are genuinely trusted-process-only, since a browser cannot invoke a local CLI: scripts/generate_review_batch.mjs ingests PR data via gh into Busabase, and scripts/execute_decisions.mjs is the one place that actually calls gh pr review for an approved item.

Mandatory Dependencies

1. Read and follow $kelly-app-skill-creator for product behavior, visual quality, responsive layout, and the complete canonical content/kelly-pr-review-app/ artifact.
2. Read and follow $busabase for connection, target Space, node discovery, ChangeRequests, review, and merge behavior.
3. Read and follow $busabase-app-creator for resource modeling, AirApp runtime limits, security, validation, and deployment.

If a dependency is unavailable, preserve this skill's local artifact and product contracts, stop before the unavailable Busabase operation, and report the exact missing dependency. Do not invent a second data backend.

Private Configuration

Private config is optional and consumed only by the trusted scripts (never by the AirApp browser). By default scripts/generate_review_batch.mjs 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:

1. KELLY_PR_REVIEW_CONFIG=/absolute/path/to/config.json
2. skills/kelly-pr-review/config.local.json
3. ~/.config/kelly-pr-review/config.json
4. gh defaults (no config found)

Env priority:

1. Existing system environment variables
2. KELLY_PR_REVIEW_ENV_FILE=/absolute/path/to/.env
3. repository root .env
4. skills/kelly-pr-review/.env.local
5. ~/.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. The resolved config is also written to Busabase's kelly-pr-review-profile settings row (see references/ui-schema.md) so the AirApp can display it — the AirApp never writes that row itself.

Busabase Resources

Two Bases under one application Folder (kelly-pr-review), declared in content/kelly-pr-review-app/app/js/config.js and the generated template sidecars under content/:

• reviews: the pull request review queue — GitHub PR metadata, risk, proposed action, workflow status, editable review-body, the human verdict fields (decision-action/decision-note/decided-at), execution result (execution-status/execution-detail), and post-merge test verification (tested/test-note/test-evidence).
• settings: one row per kind — kelly-pr-review-profile (reviewer, repos, query, review policy, style, written only by scripts/generate_review_batch.mjs --apply) and kelly-pr-review-lock.

Resources provision lazily through an idempotent Busabase ChangeRequest the first time the app runs in a Space; see references/ui-schema.md for exact field shapes. Workflow-status bucketing and the review-ref numbering are computed client-side from the reviews Base on every read — they are never stored.

Workflow

1. Check gh auth status. If not authenticated, stop and ask the user to authenticate with gh auth login.
2. Run node scripts/generate_review_batch.mjs --apply to gather PRs with gh and write/refresh the review queue in Busabase. Use --sample instead of a real gh read only when the user explicitly wants to preview the UI with fake data. Omit --apply to see a dry-run preview first.
3. Classify status (assigned by the generator, refined by the human in the UI):
   • 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.
4. Give the user the AirApp URL (or local preview URL) to review the queue.
5. For an item moved to a different status by the human, no re-drafting is needed here — the agent may still edit review-body before the next decision if asked.
6. On "execute" / "submit approved reviews": run node scripts/execute_decisions.mjs --apply to re-read approved items from Busabase and submit the real gh pr review call for each, one item at a time. Omit --apply first to see the dry-run command list.

Review Actions

Supported approved actions, submitted by scripts/execute_decisions.mjs:

• approve: gh pr review <number> --approve --body-file <tmp>
• comment: gh pr review <number> --comment --body-file <tmp>
• request_changes: gh pr review <number> --request-changes --body-file <tmp>
• no_action: write execution detail only; no GitHub call.
• needs_review or block: never execute (status stays out of approved).

Never merge, close, push, edit branches, rerun workflows, or dismiss reviews from this skill.

Safety Rules

• Require explicit AirApp (or chat) approval — writing status: "approved" onto a review record — before any gh pr review call.
• scripts/execute_decisions.mjs re-reads each record immediately before executing it, so a revoked approval or an already-executed item is never submitted to GitHub twice.
• Keep review bodies human-editable in the UI 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 comment or needs_review, not approval.
• Treat GitHub tokens and Busabase credentials as secrets; never commit them. The trusted scripts read BUSABASE_BASE_URL/BUSABASE_API_KEY/ BUSABASE_SPACE_ID from the environment, never the AirApp's session.

Useful Commands

node skills/kelly-pr-review/scripts/generate_review_batch.mjs --apply
node skills/kelly-pr-review/scripts/generate_review_batch.mjs --sample
node skills/kelly-pr-review/scripts/execute_decisions.mjs
node skills/kelly-pr-review/scripts/execute_decisions.mjs --apply
pnpm --dir skills/kelly-pr-review/content/kelly-pr-review-app dev

In normal use, invoke /kelly-pr-review, let the skill generate/refresh the batch, and open the AirApp.