원클릭으로 Manus에서 모든 스킬 실행

pr-review

스타2

포크2

업데이트2026년 3월 26일 07:34

Review GitHub pull requests by fetching diffs, analyzing code quality, checking conventions, and optionally posting review comments. Use when user says "review this PR", "check PR #N", or shares a PR URL.

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

OpenAgents-Illinois

OpenAgents-Illinois/personal-finance-agent

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

PR Review Skill

Phase 1: Fetch PR Context

Step 1.1: Extract PR Details

Run in parallel:

gh pr view <number> --json title,body,author,baseRefName,headRefName,files,additions,deletions,labels,reviewDecision
gh pr diff <number>
gh pr checks <number>

Step 1.2: Parse Linked Issues

Check the PR body for issue references (#N, Fixes #N, Closes #N). If found:

gh issue view <N> --json title,body,labels

Step 1.3: Read Project Conventions

Check for:

AGENTS.md — commit format, architectural patterns, test requirements
.github/ — PR templates, contributing guidelines
Language-specific config (Gemfile, package.json, pyproject.toml) to understand the stack

Phase 2: Analyze Changes

Step 2.1: File-by-File Review

For each changed file, assess:

Check	What to Look For
Correctness	Logic errors, off-by-one, null handling, edge cases
Security	Injection, XSS, hardcoded secrets, auth bypasses
Conventions	Naming, file placement, import ordering, project patterns
Tests	New code has tests; key paths are covered
Types	Proper annotations, no unsafe suppressions

Step 2.2: Cross-File Analysis

Do changes maintain consistency across modules?
Are imports and dependencies updated correctly?
Does the change break existing contracts or public APIs?

Step 2.3: Plan Alignment (if linked issue exists)

Question	Action if Failed
Does the PR address the linked issue?	Flag incomplete work
Are there unrelated changes?	Flag scope creep
Is the approach consistent with project architecture?	Note alternatives

Phase 3: Produce Review

Severity Levels

Level	Definition	Action Required
CRITICAL	Breaks functionality, security vulnerability, data loss risk	Must fix before merge
HIGH	Significant bug, major deviation from plan, performance issue	Should fix before merge
MEDIUM	Code smell, minor deviation, maintainability concern	Fix in this PR or follow-up issue
LOW	Style issues, minor improvements, suggestions	Nice to have

Review Report Template

## PR Review: #<number> — <title>

### Overview
- **Author:** <author>
- **Branch:** <head> → <base>
- **Files Changed:** <count> (+<additions>, -<deletions>)
- **CI Status:** <pass/fail/pending>

### What Was Done Well
- [Positive point 1]
- [Positive point 2]

### Issues Found

#### Critical (Must Fix)
[Issues that would cause bugs, security holes, or data loss]

#### High (Should Fix)
[Issues that affect correctness, performance, or maintainability]

#### Medium (Recommended)
[Code quality improvements, missing tests, convention violations]

#### Low (Suggestions)
[Style nits, optional improvements]

### Verdict
- [ ] APPROVE — Ready to merge
- [ ] COMMENT — Non-blocking feedback only
- [ ] REQUEST CHANGES — Must address issues before merge

Phase 4: Post Review to GitHub (MANDATORY)

Always post the review as a GitHub comment. Never skip this phase.

gh pr comment <number> --repo <owner>/<repo> --body "$(cat <<'EOF'
<review body>
EOF
)"

Note: Use gh pr comment (not gh pr review) to avoid the self-review restriction on GitHub.

Quality Rules

ALWAYS:

Fetch the actual diff — never review from memory
Read AGENTS.md and project config for conventions
Lead with positives before listing issues
Classify every issue by severity with file:line references
Post the review as a GitHub comment immediately after completing the analysis

NEVER:

Guess about code you haven't read
Skip posting the GitHub comment
Nitpick style when unresolved logic issues exist
Approve PRs with CRITICAL issues

이 저장소의 다른 Skills

같은 저장소

claudemd-setup

OpenAgents-Illinois/personal-finance-agent

Bootstrap or update a AGENTS.md file that gives Codex persistent project instructions. Use when starting a new project, onboarding Codex to an existing repo, or updating project conventions.

2026-03-262

commit

OpenAgents-Illinois/personal-finance-agent

Create well-structured git commits following Conventional Commits format. Use when user says "commit", "create a commit", or "save these changes".

2026-03-262

create-issue

OpenAgents-Illinois/personal-finance-agent

Create well-structured GitHub issues following a consistent format. Use when user says "create an issue", "draft a task", "log a bug", or "document this feature".

2026-03-262

create-pr

OpenAgents-Illinois/personal-finance-agent

Create a GitHub pull request from the current branch or fork. Use when user says "create a PR", "open a PR", "make a pull request", or "PR these changes".

2026-03-262

issue-fix

OpenAgents-Illinois/personal-finance-agent

Triage and fix GitHub issues end-to-end. Fetches the issue, explores relevant code, plans the fix, implements with TDD, and verifies. Use when user says "fix issue #N", "work on this issue", or references a GitHub issue number.

2026-03-262

build

OpenAgents-Illinois/personal-finance-agent

Begin or continue implementing the project from TASKS.md. Reads the spec, finds the next incomplete task, implements it incrementally, and stops. Use when user says "start building", "implement the next task", "continue", or "build this".

2026-03-262

name	pr-review
description	Review GitHub pull requests by fetching diffs, analyzing code quality, checking conventions, and optionally posting review comments. Use when user says "review this PR", "check PR #N", or shares a PR URL.

PR Review Skill

Phase 1: Fetch PR Context

Step 1.1: Extract PR Details

Run in parallel:

gh pr view <number> --json title,body,author,baseRefName,headRefName,files,additions,deletions,labels,reviewDecision
gh pr diff <number>
gh pr checks <number>

Step 1.2: Parse Linked Issues

Check the PR body for issue references (#N, Fixes #N, Closes #N). If found:

gh issue view <N> --json title,body,labels

Step 1.3: Read Project Conventions

Check for:

AGENTS.md — commit format, architectural patterns, test requirements
.github/ — PR templates, contributing guidelines
Language-specific config (Gemfile, package.json, pyproject.toml) to understand the stack

Phase 2: Analyze Changes

Step 2.1: File-by-File Review

For each changed file, assess:

Check	What to Look For
Correctness	Logic errors, off-by-one, null handling, edge cases
Security	Injection, XSS, hardcoded secrets, auth bypasses
Conventions	Naming, file placement, import ordering, project patterns
Tests	New code has tests; key paths are covered
Types	Proper annotations, no unsafe suppressions

Step 2.2: Cross-File Analysis

Do changes maintain consistency across modules?
Are imports and dependencies updated correctly?
Does the change break existing contracts or public APIs?

Step 2.3: Plan Alignment (if linked issue exists)

Question	Action if Failed
Does the PR address the linked issue?	Flag incomplete work
Are there unrelated changes?	Flag scope creep
Is the approach consistent with project architecture?	Note alternatives

Phase 3: Produce Review

Severity Levels

Level	Definition	Action Required
CRITICAL	Breaks functionality, security vulnerability, data loss risk	Must fix before merge
HIGH	Significant bug, major deviation from plan, performance issue	Should fix before merge
MEDIUM	Code smell, minor deviation, maintainability concern	Fix in this PR or follow-up issue
LOW	Style issues, minor improvements, suggestions	Nice to have

Review Report Template

## PR Review: #<number> — <title>

### Overview
- **Author:** <author>
- **Branch:** <head> → <base>
- **Files Changed:** <count> (+<additions>, -<deletions>)
- **CI Status:** <pass/fail/pending>

### What Was Done Well
- [Positive point 1]
- [Positive point 2]

### Issues Found

#### Critical (Must Fix)
[Issues that would cause bugs, security holes, or data loss]

#### High (Should Fix)
[Issues that affect correctness, performance, or maintainability]

#### Medium (Recommended)
[Code quality improvements, missing tests, convention violations]

#### Low (Suggestions)
[Style nits, optional improvements]

### Verdict
- [ ] APPROVE — Ready to merge
- [ ] COMMENT — Non-blocking feedback only
- [ ] REQUEST CHANGES — Must address issues before merge

Phase 4: Post Review to GitHub (MANDATORY)

Always post the review as a GitHub comment. Never skip this phase.

gh pr comment <number> --repo <owner>/<repo> --body "$(cat <<'EOF'
<review body>
EOF
)"

Note: Use gh pr comment (not gh pr review) to avoid the self-review restriction on GitHub.

Quality Rules

ALWAYS:

Fetch the actual diff — never review from memory
Read AGENTS.md and project config for conventions
Lead with positives before listing issues
Classify every issue by severity with file:line references
Post the review as a GitHub comment immediately after completing the analysis

NEVER:

Guess about code you haven't read
Skip posting the GitHub comment
Nitpick style when unresolved logic issues exist
Approve PRs with CRITICAL issues