feat(pr-manager): post deferred items as GitHub PR review comments#816
Conversation
Adds phase 7b instructing the pr-manager agent to post any deferred / disagree / question / standards items it flags back to the PR as inline review comments via `gh api`, so they surface as unresolved threads on the PR instead of only living in the final chat report.
📝 WalkthroughWalkthroughDocumentation update to the PR manager agent specification that mandates posting non-fixed review items as inline GitHub comments, introduces a workflow phase for creating pending reviews via the GitHub API, and adds reporting fields for review metadata. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.claude/agents/pr-manager.md:
- Line 149: The fenced code block containing the shell snippet that sets
HEAD_SHA (e.g., the line "HEAD_SHA=$(gh api repos/<owner>/<repo>/pulls/<PR> --jq
'.head.sha')") must include a language identifier; update the opening fence to
```bash (or ```shell) so markdownlint passes and syntax highlighting works,
leaving the block contents unchanged.
- Line 159: The example currently hardcodes -f event="REQUEST_CHANGES" which is
misleading; update the example to show conditional selection between
"REQUEST_CHANGES" and "COMMENT" (or use a placeholder like -f
event="${REVIEW_EVENT}") and/or add an inline comment explaining the decision
logic so readers know to choose REQUEST_CHANGES only when items block merge and
otherwise use COMMENT; locate the occurrence of event="REQUEST_CHANGES" in the
example and replace it with the conditional/placeholder and accompanying
explanatory comment.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 98b25705-3655-41ad-8aa4-806c558d9571
📒 Files selected for processing (1)
.claude/agents/pr-manager.md
|
|
||
| Use `gh api` to create a pending review with inline comments, then submit it as `REQUEST_CHANGES` (or `COMMENT` if none of the items block merge). Inline comments land on specific file:line and show up as unresolved threads until a maintainer resolves them. | ||
|
|
||
| ``` |
There was a problem hiding this comment.
Add language identifier to the fenced code block.
The code block should specify bash or shell as the language identifier for proper syntax highlighting and to satisfy the markdownlint rule.
📝 Proposed fix
-```
+```bash
# 1. Look up the commit sha the review anchors to (the PR head after your pushes)
HEAD_SHA=$(gh api repos/<owner>/<repo>/pulls/<PR> --jq '.head.sha')📝 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.
| ``` |
🧰 Tools
🪛 markdownlint-cli2 (0.22.0)
[warning] 149-149: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.claude/agents/pr-manager.md at line 149, The fenced code block containing
the shell snippet that sets HEAD_SHA (e.g., the line "HEAD_SHA=$(gh api
repos/<owner>/<repo>/pulls/<PR> --jq '.head.sha')") must include a language
identifier; update the opening fence to ```bash (or ```shell) so markdownlint
passes and syntax highlighting works, leaving the block contents unchanged.
| gh api repos/<owner>/<repo>/pulls/<PR>/reviews \ | ||
| -X POST \ | ||
| -f commit_id="$HEAD_SHA" \ | ||
| -f event="REQUEST_CHANGES" \ |
There was a problem hiding this comment.
The example hardcodes REQUEST_CHANGES but should show conditional logic.
Line 172 correctly states that REQUEST_CHANGES should only be used when items genuinely block merge, otherwise use COMMENT. However, the example at line 159 hardcodes event="REQUEST_CHANGES", which could mislead users copying this code.
💡 Suggested improvement
Either use a placeholder or show the conditional logic:
- -f event="REQUEST_CHANGES" \
+ -f event="<REQUEST_CHANGES or COMMENT based on whether items block merge>" \Or better, add a comment showing the decision logic:
+# Use REQUEST_CHANGES if any item blocks merge, otherwise COMMENT
gh api repos/<owner>/<repo>/pulls/<PR>/reviews \
-X POST \
-f commit_id="$HEAD_SHA" \
- -f event="REQUEST_CHANGES" \
+ -f event="$EVENT_TYPE" \🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.claude/agents/pr-manager.md at line 159, The example currently hardcodes -f
event="REQUEST_CHANGES" which is misleading; update the example to show
conditional selection between "REQUEST_CHANGES" and "COMMENT" (or use a
placeholder like -f event="${REVIEW_EVENT}") and/or add an inline comment
explaining the decision logic so readers know to choose REQUEST_CHANGES only
when items block merge and otherwise use COMMENT; locate the occurrence of
event="REQUEST_CHANGES" in the example and replace it with the
conditional/placeholder and accompanying explanatory comment.
Summary
pr-manageragent that instructs it to post any deferred / disagree / question / standards items it flags back to the PR as inline review comments viagh api, so they surface as unresolved threads on the PR instead of living only in the final chat report.Test plan
pr-managerruns on a PR with items it would defer, verify it creates a PR review viaPOST /repos/{owner}/{repo}/pulls/{pr}/reviewswith one inline comment per deferred item.**Deferred:** / **Disagree:** / **Question:** / **Standards:**prefix.Summary by CodeRabbit
Note: This release contains only internal process documentation updates with no user-facing changes.