Guidelines for posting pull request review comments via GitHub CLI, including suggested edits format, handling unresolved comments, etiquette, and report/issue tracking. Load this skill when reviewing a PR via GitHub and posting inline comments.
Load this skill when posting review comments on a GitHub pull request.
When analyzing a PR diff, Always record exact file paths and line numbers for every finding as
you go. Each finding must include the precise path and line (and start_line for multi-line
ranges) in the new file (right side of the diff) needed to post a review comment. Do not defer
line number resolution to a later step.
When the review is performed by a sub-agent, the agent's returned findings must include these fields per finding so the caller can post comments immediately:
path: file path relative to repo rootline: line number in the new file (end line for multi-line)start_line (optional): start line for multi-line commentsbody: the comment text, ready to postWhen asked to review a pull request, you may use the GitHub CLI tool to post inline comments on the PR with specific feedback for each issue you identify. You can suggest specific code changes in your comments. reference specific lines of code in your comments for clarity.
When providing feedback on a pull request:
When the fix for an issue is obvious and localized (e.g., a typo, a missing annotation, a wrong type, a simple rename), include a GitHub suggested edit block in your review comment so the author can apply it with one click. Use this format:
```suggestion
corrected line(s) of code here
```
Guidelines for suggested edits:
override/[[nodiscard]]/constexpr, wrong types, simple renames, small bug fixes where the correct code is unambiguous.When reviewing a PR, always check prior review comments (from any reviewer) that have been marked as resolved. If the current code still exhibits the issue described in a resolved comment, flag it as a finding with a reference to the original comment. Use this format:
Do not flag resolved comments where the concern has been legitimately addressed, even if addressed differently than the reviewer suggested.
When reviewing PRs, be aware of CI jobs that are expected to fail for certain contributors:
internal-build: Requires Cloudflare internal access. Always fails for external
contributors — this is not indicative of a build or code problem. Do not flag CI failures from
this job as issues on PRs from external contributors.Before attributing a CI failure to a code problem, check whether the PR author is an external contributor (not a Cloudflare org member). If so, check whether the failing job is access-gated.
For interaction with GitHub, use the GitHub CLI (gh) tool or git as appropriate.