pr-review

星标13

分支0

更新时间2026年7月15日 10:18

Code review a pull request — summarize changes, flag issues, suggest improvements.

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

来源

daanielcruz

daanielcruz/otherside-cli

打开 GitHub 仓库查看创作者相关仓库

下载

相关职业SOC

基于 SOC 职业分类

软件质量保证分析师与测试员计算机与数学类职业·SOC 15-1253

SKILL.md

readonly

name	pr-review
description	Code review a pull request — summarize changes, flag issues, suggest improvements.
context	fork

You are reviewing a pull request. Follow these steps:

If no PR number is provided in the args, run gh pr list to show open PRs.
If a PR number is provided, run gh pr view <number> to get the PR body + metadata.
Run gh pr diff <number> to get the diff.
Analyze the changes and produce a concise review with:
- Overview — one or two sentences on what the PR does.
- Quality — code quality + adherence to project conventions.
- Suggestions — specific, line-referenced improvements.
- Risks — correctness, performance, security, or backwards compatibility concerns.
Write the full review to {{REPORTS_DIR}}/pr-review-{{REPORT_TIMESTAMP}}.md via the Write tool. Use the structure above (Overview / Quality / Suggestions / Risks). This is the canonical artifact — do not dump the full review into your final assistant message.
Return a short summary (2-4 lines): PR number, one-line verdict, path to the written report file. Example: Reviewed #42 — 3 suggestions, 2 risks flagged. Report: <path>.
Post the review via gh pr review <number> --comment when the user confirms.

Focus

Correctness (off-by-one, null handling, concurrency).
Security (auth, input validation, secret handling).
Performance (N+1 queries, unnecessary allocations, hot-path regressions).
Test coverage (does a test actually exercise the new code path).
Project conventions (commit style, file layout, naming — read OTHERSIDE.md for the rules).

Arguments

Optional PR number. If empty, list open PRs and ask which one.

同仓库更多 Skills

同仓库

loop

daanielcruz/otherside-cli

Run a prompt or slash command on a recurring interval (e.g. /loop 5m /foo). Omit the interval to let the model self-pace.

2026-07-1713

code-review

daanielcruz/otherside-cli

Deep code review of a diff. Launches the code-review workflow — finder agents scan each review angle, an independent verifier judges every candidate, then a ranked, capped findings report. Read-only; it reviews, it does not edit.

2026-07-1513

deep-security-review

daanielcruz/otherside-cli

Deep whole-repo security audit. Launches the deep-security-review workflow — a prep agent maps the attack surface, specialized auditors scan each vulnerability class, candidates are debated for-and-against reachability, survivors are proven and chained, then a strict report is rendered and independently re-verified. OWASP Top 10, CWE Top 25, NIST SP 800-53/SSDF; target repo is read-only while report artifacts are written under the configured reports directory.

2026-07-1513

dream

daanielcruz/otherside-cli

Reflective memory consolidation — review recent activity, synthesize learnings into the memory directory, and prune stale entries. Use when the user says "dream", "learn", "consolidate memories", "organize your memories", or asks Otherside to reflect on what it has learned.

2026-07-1513

grill-me

daanielcruz/otherside-cli

Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".

2026-07-1513

init

daanielcruz/otherside-cli

Initialize new OTHERSIDE.md file(s) and optional skills/hooks with codebase documentation

2026-07-1513

name	pr-review
description	Code review a pull request — summarize changes, flag issues, suggest improvements.
context	fork

You are reviewing a pull request. Follow these steps:

If no PR number is provided in the args, run gh pr list to show open PRs.
If a PR number is provided, run gh pr view <number> to get the PR body + metadata.
Run gh pr diff <number> to get the diff.
Analyze the changes and produce a concise review with:
- Overview — one or two sentences on what the PR does.
- Quality — code quality + adherence to project conventions.
- Suggestions — specific, line-referenced improvements.
- Risks — correctness, performance, security, or backwards compatibility concerns.
Write the full review to {{REPORTS_DIR}}/pr-review-{{REPORT_TIMESTAMP}}.md via the Write tool. Use the structure above (Overview / Quality / Suggestions / Risks). This is the canonical artifact — do not dump the full review into your final assistant message.
Return a short summary (2-4 lines): PR number, one-line verdict, path to the written report file. Example: Reviewed #42 — 3 suggestions, 2 risks flagged. Report: <path>.
Post the review via gh pr review <number> --comment when the user confirms.

Focus

Correctness (off-by-one, null handling, concurrency).
Security (auth, input validation, secret handling).
Performance (N+1 queries, unnecessary allocations, hot-path regressions).
Test coverage (does a test actually exercise the new code path).
Project conventions (commit style, file layout, naming — read OTHERSIDE.md for the rules).

Arguments

Optional PR number. If empty, list open PRs and ask which one.