Github Pr Review Checklist

GitHub PR Review Checklist

Post a structured review checklist comment on GitHub pull requests.

Prerequisites

Before executing this skill, ensure:

1. Code review findings are available in context
2. The GitHub connection is configured with repository access
3. The repository {{config.repo_owner}}/{{config.repo_name}} exists and is accessible
4. The PR number is known from the review context

Setup

Source the GitHub helper functions:

source ./_skills/connections/github/github/scripts/github_helpers.sh

Workflow

Step 1: Get PR Information

gh pr view $PR_NUMBER --repo {{config.repo_owner}}/{{config.repo_name}} --json number,title,changedFiles,additions,deletions

Retrieve the PR metadata to include in the checklist header.

Step 2: Analyze Review Findings

From the code review context, categorize each finding into one of these sections:

Step 3: Build the Checklist Comment

Format the review checklist using GitHub-flavored Markdown:

## Code Review Checklist

**PR:** #{pr_number} - {pr_title}
**Files Changed:** {changed_files} | **+{additions}** / **-{deletions}**
**Reviewed by:** CloudThinker Code Review

---

### Critical Issues
> These must be resolved before merging.

- [ ] **{file_path}:{line}** - {finding_title}
  {brief description of the issue and why it is critical}

- [ ] **{file_path}:{line}** - {finding_title}
  {brief description}

---

### Bugs & Logic Errors

- [ ] **{file_path}:{line}** - {finding_title}
  {description of the bug or logic error}

---

### Performance

- [ ] **{file_path}:{line}** - {finding_title}
  {description of the performance concern}

---

### Security

- [ ] **{file_path}:{line}** - {finding_title}
  {description of the security concern}

---

### Code Quality

- [ ] **{file_path}:{line}** - {finding_title}
  {description of the quality improvement}

---

### Testing

- [ ] **{file_path}:{line}** - {finding_title}
  {description of testing gaps}

---

### Suggestions
> Optional improvements that are not blockers.

- [ ] **{file_path}:{line}** - {finding_title}
  {description of the suggestion}

---

### Summary

| Category | Count |
|----------|-------|
| Critical | {n} |
| Bugs | {n} |
| Performance | {n} |
| Security | {n} |
| Code Quality | {n} |
| Testing | {n} |
| Suggestions | {n} |
| **Total** | **{total}** |

**Verdict:** {APPROVE / REQUEST_CHANGES / COMMENT}
{1-2 sentence overall assessment}

Step 4: Post the Checklist Comment

github_create_pr_discussion {{config.repo_owner}} {{config.repo_name}} $PR_NUMBER \
  '${formatted_checklist}'

Step 5: Post Inline Comments for Critical Findings

For critical and high-severity findings, also post inline comments on the specific lines:

github_create_pr_comment {{config.repo_owner}} {{config.repo_name}} $PR_NUMBER \
  "${file_path}" ${line_number} '${inline_comment}' "RIGHT"

This provides both a high-level checklist and targeted inline feedback.

Checklist Rules

Section Inclusion

• Only include sections that have findings (omit empty sections)
• Always include the Summary table
• Critical Issues section always appears first when present
• Suggestions section always appears last

Finding Format

Each checklist item follows this structure:

• - [ ] checkbox for tracking resolution
• **file:line** bold file reference for navigation
• {title} concise finding title on the same line
• Indented description on the next line (1-2 sentences max)

Verdict Logic

Output

After posting the checklist, report:

1. Confirmation that the checklist was posted on PR #{pr_number}
2. Total number of findings by category
3. The verdict (APPROVE / REQUEST_CHANGES / COMMENT)
4. Number of inline comments posted
5. Link to the PR

Error Handling

Guidelines

• Keep finding descriptions concise (1-2 sentences per item)
• Use file:line references that GitHub auto-links to the diff
• Group related findings under the most relevant category
• Do not duplicate findings across categories
• Use checkboxes (- [ ]) so PR authors can track their fixes
• Include the verdict clearly at the bottom
• Post inline comments only for Critical and High severity items to avoid noise

Counter-Rationalizations