Skip to content

Conversation

@nickolasclarke
Copy link

@nickolasclarke nickolasclarke commented Oct 17, 2025

Motivation and Context

I've noticed Claude struggling to interact with GitHub PRs via the gh CLI - fetching PR content, posting comments, responding to review threads, etc. This adds focused command references for the two roles that interact with PRs:

  • Code reviewers: fetching PR content, posting findings (with permission)
  • Implementers: reading feedback, responding to comments, requesting re-review

It is broken into two separate reference files to help avoid context pollution, given many commands will not be required, depending on the workflow. I am open to different arrangements here though!

How Has This Been Tested?

I've written and reviewed against the writing-skills standard in this repo. These are reference docs (command lookups), not discipline-enforcing skills, so pressure testing isn't applicable.

I've tested the commands themselves and pointed this PR back at itself!

Breaking Changes

I do not believe so?

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Documentation update

Checklist

  • I have read the MCP Documentation
  • My code follows the repository's style guidelines
  • New and existing tests pass locally
  • I have added appropriate error handling
  • I have added or updated documentation as needed

Additional context

Summary by CodeRabbit

  • Documentation
    • Added comprehensive guides covering GitHub pull request mechanics for both reviewers and implementers
    • Documented workflow procedures for receiving and responding to code review feedback
    • Provided guidance on best practices for requesting and conducting code reviews

✏️ Tip: You can customize this high-level summary in your review settings.

@coderabbitai
Copy link

coderabbitai bot commented Oct 17, 2025

Walkthrough

Added comprehensive documentation for GitHub PR mechanics in both the receiving-code-review and requesting-code-review skill directories. Created two new github-reviews.md files covering feedback handling for implementers and review posting for reviewers. Updated existing SKILL.md files to reference the new GitHub PR Mechanics section and corrected template paths.

Changes

Cohort / File(s) Summary
Receiving Code Review
skills/receiving-code-review/SKILL.md
Added "GitHub PR Mechanics" section with guidance on handling feedback, responding to comments, commit strategy, and forbidden actions
New Receiving Code Review Documentation
skills/receiving-code-review/github-reviews.md
New document outlining GitHub review workflow for implementers, including prerequisites, reading feedback via gh CLI and REST API, responding to comments, editing, commit strategy, re-review requests, and prohibited actions
Requesting Code Review
skills/requesting-code-review/SKILL.md
Replaced old template reference with new "GitHub PR Mechanics" section and updated template path to skills/collaboration/requesting-code-review/code-reviewer.md
New Requesting Code Review Documentation
skills/requesting-code-review/github-reviews.md
New document detailing GitHub review mechanics for reviewers, covering PR content retrieval, discussion retrieval via API, posting findings, and forbidden actions with example gh CLI commands

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

  • All changes are documentation additions and updates with no functional code modifications
  • Straightforward content additions and path corrections
  • Verify accurate gh CLI syntax and API endpoint examples in the new documentation files

Poem

🐰 A rabbit hops through GitHub's halls so bright,
Adding guides for reviews left and right!
Commands and mechanics now crystal and clear,
No more confusion, just pull requests dear!

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title 'add github PR review mechanics' clearly and concisely summarizes the main change: adding new documentation about GitHub PR review workflows for both reviewers and implementers.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
✨ Finishing touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@nickolasclarke
Copy link
Author

sorry, poor form to open this as a draft. Claude got out ahead of its skis. I'll keep it here while I test this though to keep noise low.

@obra
Copy link
Owner

obra commented Oct 17, 2025

Ok, a first couple comments:

  1. Thank you!
  2. we no longer get to use when_to_use - official skills push that into description
  3. this is a perfect example of the kind of stuff that goes in an ancillary document called maybe GITHUB-REVIEWS.md in the skill directory and gets mentioned but not @linked in the SKILL itself

@nickolasclarke
Copy link
Author

Great. Yes this felt perhaps the wrong place to put this, and wanted this very discussion! Happy to move into its own markdown.

@nickolasclarke
Copy link
Author

Getting meta: here is the code review against this PR:

PR: [add github PR review mechanics](https://github.com/obra/superpowers/pull/41/)
Strengths
Excellent role-based separation (reviewer vs implementer) prevents context pollution
Clear prerequisites sections with graceful fallback guidance
Practical, concrete command examples
Comprehensive forbidden actions lists with explanations
Consistent structure between both reference files
Clean integration with existing SKILL.md files
Critical Issues
None
Important Issues
Broken path reference in [SKILL.md:112](vscode-webview://1he4h2aa25pl61lr5av63tvkummm3lgl92ke44bkfamb1gsq5gtb/skills/requesting-code-review/SKILL.md#L112)
Says skills/collaboration/requesting-code-review/code-reviewer.md but path is actually skills/requesting-code-review/code-reviewer.md
Potential API endpoint issue - Both files use gh api repos/{owner}/{repo}/pulls/comments/{comment_id}/replies for thread replies
GitHub API typically uses POST /repos/{owner}/{repo}/pulls/{number}/comments with an in_reply_to parameter instead
Recommend verifying this endpoint works
Missing ABOUTME comments - Per project conventions, markdown reference files should have introductory context
Minor Issues
-f vs -F flag for commit_id in line-specific comments (should be -F)
No guidance on finding your own comment IDs for editing
Command substitution could fail silently without helpful error
Assessment
Ready to merge with fixes - Core implementation is solid. The path fix and API verification are the main items to address.

@nickolasclarke nickolasclarke marked this pull request as ready for review November 25, 2025 23:07
@nickolasclarke
Copy link
Author

@obra I've cleaned this up, but things have changed more since I wrote this. Is this still the correct approach?

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🧹 Nitpick comments (5)
skills/receiving-code-review/github-reviews.md (3)

1-3: Add ABOUTME/introductory context per project conventions.

PR feedback noted that markdown reference files should include introductory ABOUTME comments per project conventions. This file lacks that context.

Consider adding a brief ABOUTME or context block after the title explaining file purpose, similar to:

> **ABOUTME:** This file provides command reference and operational guidance for implementers responding to code review feedback on GitHub PRs. It covers reading feedback, responding appropriately, and workflow details. For conceptual approach to code review reception, see `SKILL.md`.

64-71: Add error handling guidance for command substitution.

Line 65-70 shows command chaining with git api queries that could fail silently if the repository state or query changes. No error handling is shown for this scenario.

Consider adding a note about handling command failures:

**Note:** If the API call fails (e.g., invalid PR number), the command will error. Verify the PR number and that you have push access before running.

78-84: Provide guidance on finding your own comment IDs for editing.

The editing section (line 78-84) assumes users know their comment ID but provides no guidance on finding it.

Add a reference to retrieving your own comment:

**To find your comment ID:** Use the "Reading Review Feedback" section commands to fetch comments and locate your own by author/body text, then extract the `id` field.
skills/requesting-code-review/github-reviews.md (2)

1-3: Add ABOUTME/introductory context per project conventions.

PR feedback noted that markdown reference files should include introductory ABOUTME comments per project conventions. This file lacks that context.

Consider adding brief context after the title explaining file purpose:

> **ABOUTME:** This file provides command reference and operational guidance for code-reviewer agents analyzing PRs hosted on GitHub. It covers fetching PR content, existing discussion, and posting findings. For conceptual approach to code review, see parent `SKILL.md`.

73-89: Add error handling guidance for command substitution.

Line 79 shows a command substitution for the headRefOid that could fail silently if the API call errors or returns empty. No guidance is provided for handling these failures.

Add error handling note:

**Note:** If `gh pr view` fails (invalid PR or insufficient access), the command will error. Verify the PR number exists and you have repository access before running. For debugging, remove the substitution and run `gh pr view <number> --json headRefOid -q .headRefOid` separately first.
📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between c35c5f6 and e3fad1b.

📒 Files selected for processing (4)
  • skills/receiving-code-review/SKILL.md (1 hunks)
  • skills/receiving-code-review/github-reviews.md (1 hunks)
  • skills/requesting-code-review/SKILL.md (1 hunks)
  • skills/requesting-code-review/github-reviews.md (1 hunks)
🧰 Additional context used
🪛 LanguageTool
skills/requesting-code-review/github-reviews.md

[uncategorized] ~8-~8: The official name of this software platform is spelled with a capital “H”.
Context: ...uired:** 1. Repository remote hosted on github.com 2. GitHub CLI (gh) installed and ...

(GITHUB)

skills/receiving-code-review/github-reviews.md

[uncategorized] ~8-~8: The official name of this software platform is spelled with a capital “H”.
Context: ...uired:** 1. Repository remote hosted on github.com 2. GitHub CLI (gh) installed and ...

(GITHUB)

🔇 Additional comments (6)
skills/receiving-code-review/github-reviews.md (2)

1-4: Capitalize "GitHub" per style guidelines.

Line 8 and other instances use lowercase "github.com"; use "GitHub" per official naming.

Apply this diff:

-1. Repository remote hosted on github.com
+1. Repository remote hosted on GitHub.com

Also apply to line 42 in the API endpoint example (contains "github.com" in the URL path).


8-8: I'll help you verify the concerns raised in this review comment about the GitHub reviews documentation file. Let me start by examining the file content and then verify the GitHub API endpoints and CLI flag usage.
<function_calls>

cat -n skills/receiving-code-review/github-reviews.md | head -100

</function_calls>

Let me search for the file first:
<function_calls>

fd "github-reviews.md" --type f

</function_calls>

Let me get a broader search:
<function_calls>

find . -name "github-reviews.md" -type f 2>/dev/null

</function_calls>

Let me check the directory structure:
<function_calls>

find . -type d -name "receiving-code-review" 2>/dev/null | head -5

</function_calls>

Let me list what files exist in skills:
<function_calls>

git ls-files skills/ 2>/dev/null | head -20

</function_calls>

Now let me verify the GitHub API documentation and gh CLI flag usage through web search:
<function_calls>

GitHub API POST /repos/{owner}/{repo}/pulls/comments/{comment_id}/replies endpoint

</function_calls>

<function_calls>

gh cli flag -f vs -F difference numeric parameters

</function_calls>

<function_calls>

gh api POST /repos/pulls/comments reply endpoint documentation

</function_calls>

skills/receiving-code-review/SKILL.md (1)

211-217: LGTM!

The GitHub PR Mechanics section correctly references the new github-reviews.md file and provides clear signposting. The link structure and summary are appropriate.

skills/requesting-code-review/SKILL.md (1)

105-111: LGTM!

The GitHub PR Mechanics section structure and content are clear. After fixing the path reference on line 112, this section will correctly guide reviewers to the appropriate documentation.

skills/requesting-code-review/github-reviews.md (2)

8-8: Capitalize "GitHub" per style guidelines.

Line 8 uses lowercase "github.com"; use "GitHub" per official naming.

Apply this diff:

-1. Repository remote hosted on github.com
+1. Repository remote hosted on GitHub.com

Also applies to: 14-14


8-8: I'll help you verify the technical concerns raised in this review comment. Let me start by examining the file content and then verify the specific issues.
<function_calls>

cat -n skills/requesting-code-review/github-reviews.md

</function_calls>

Now let me verify the GitHub API endpoint and gh CLI flag conventions:
<function_calls>

GitHub API endpoint POST /pulls/{number}/comments line specific review comments

</function_calls>

<function_calls>

gh CLI flag -f vs -F numeric parameters commit_id line

</function_calls>

<function_calls>

"github.com" vs "GitHub" style guide capitalization

</function_calls>

- Posting findings (after parent approval)
- Forbidden actions

See template at: skills/collaboration/requesting-code-review/code-reviewer.md
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical

Fix broken template path reference.

Line 112 references an incorrect path: skills/collaboration/requesting-code-review/code-reviewer.md. The actual template location is skills/requesting-code-review/code-reviewer.md (no collaboration/ directory level).

Apply this diff:

-See template at: skills/collaboration/requesting-code-review/code-reviewer.md
+See template at: skills/requesting-code-review/code-reviewer.md

This path issue was flagged in the PR review and must be corrected before merge.

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
See template at: skills/collaboration/requesting-code-review/code-reviewer.md
See template at: skills/requesting-code-review/code-reviewer.md
🤖 Prompt for AI Agents
In skills/requesting-code-review/SKILL.md around line 112, the template path is
incorrect — update the referenced path from
"skills/collaboration/requesting-code-review/code-reviewer.md" to the correct
path "skills/requesting-code-review/code-reviewer.md" so the link points to the
actual template location; confirm the change and run a quick link check to
ensure it resolves.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants