Walkthrough

The changes restructure the AI-assisted review command workflow to introduce a triage phase that classifies comments into MUST-FIX, DISCUSS, and SKIPPED categories, followed by selective todo creation from MUST-FIX items only, user presentation of triage results, and post-reply thread resolution via GraphQL. Comment filtering is enhanced with bot comment deduplication and granular classification rules.

Changes

Sequence Diagram(s)

sequenceDiagram
    participant User
    participant AIAssistant as AI Assistant
    participant GraphQLAPI as GraphQL API

    User->>AIAssistant: Submit review for triage
    AIAssistant->>AIAssistant: Classify comments into<br/>MUST-FIX, DISCUSS, SKIPPED
    AIAssistant->>AIAssistant: Deduplicate bot comments
    AIAssistant->>AIAssistant: Create todos from MUST-FIX only
    AIAssistant->>User: Present triage results<br/>(categorized items & counts)
    User->>AIAssistant: Approve triage & provide direction
    AIAssistant->>AIAssistant: Address selected items,<br/>generate replies
    AIAssistant->>GraphQLAPI: Resolve review threads<br/>(when addressed & thread ID available)
    GraphQLAPI-->>AIAssistant: Thread resolution confirmed
    AIAssistant->>User: Summary of addressed items

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

Poem

🐰 A triage tale of threads so grand,
We sort and sift with careful hand,
MUST-FIX first, the rest deferred,
Then GraphQL whispers each resolved word!
New workflows bloom, efficient and bright! 🌿✨

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.

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

Review: Improve address-review command

Overall this is a solid improvement. The triage system (MUST-FIX / DISCUSS / SKIPPED) is well-designed and will meaningfully reduce noise, and the thread-resolution flow closes an important feedback loop that was previously missing. A few issues worth addressing:

Critical gap: thread IDs are not available from the REST API

The PR instructs Step 4 to "preserve the original review comment ID and thread ID when available," and Step 7 then uses that thread ID in the resolveReviewThread GraphQL mutation. However, the REST endpoint used in Step 3 (GET /pulls/{PR_NUMBER}/comments) does not return thread IDs — it only returns comment database IDs. Thread IDs are GraphQL node IDs and must be retrieved separately via a GraphQL query.

Without a mechanism to fetch thread IDs, the "preserve thread ID" instruction in Step 4 is a no-op, and the resolveReviewThread mutation will never have a valid threadId to work with. A GraphQL query like the one below should be added (probably alongside the REST fetch in Step 3):

gh api graphql -f query='query($owner:String!,$name:String!,$number:Int!){
  repository(owner:$owner,name:$name){
    pullRequest(number:$number){
      reviewThreads(first:100){
        nodes{
          id isResolved
          comments(first:1){ nodes{ databaseId } }
        }
      }
    }
  }
}' -f owner="$OWNER" -f name="$NAME" -F number="$PR_NUMBER"

This maps each comment's databaseId (which matches the REST API id) to its parent thread's GraphQL node ID.

Pagination limitation silently removed

The previous "Known Limitations" section included:

Large PRs: PRs with many comments may require pagination (not currently handled)

This bullet was deleted in this PR without adding pagination support. Since both the REST API and the GraphQL reviewThreads query above default to limited page sizes, the limitation still exists. The note should be retained (or pagination actually implemented).

Minor: triage criteria for MUST-FIX vs DISCUSS overlaps

"clear inconsistencies with adjacent code" appears in the MUST-FIX definition, but identical wording also appears in the Step 3 filtering rules as "actionable by default." This duplication is harmless but slightly confusing; a brief cross-reference ("see Step 4 triage rules") in Step 3 would keep the definitions as the single source of truth.

Positive highlights

• Deduplicating bot feedback rather than discarding it wholesale is the right call for this repo.
• The conditions guarding thread resolution (pending fix, user approval, already-resolved check) are appropriately conservative.
• The example output is clear and immediately actionable.

Greptile Summary

This PR improves the address-review slash command by replacing the blanket "skip all bot comments" rule with a smarter triage system (MUST-FIX / DISCUSS / SKIPPED), and adds a GraphQL resolveReviewThread mutation to mark threads as resolved after they are addressed. The direction is clearly right, but two gaps remain that will prevent the new thread-resolution feature from working in practice.

Key changes:

• Bot comments are now deduplicated and triaged rather than unconditionally discarded
• A structured three-category triage workflow (Steps 4–6) replaces the old single "Create Todo" step
• The GraphQL resolveReviewThread mutation is documented in Step 7 for post-reply thread closure

Issues found:

• Thread ID unavailable at resolution time: The Step 3 REST API fetch (jq filter) never extracts node_id from comments, and there is no instruction to perform a GraphQL query to map comments to their parent PullRequestReviewThread.id. Without the thread node ID the resolveReviewThread mutation in Step 7 cannot be populated, silently failing the core new feature.
• Pagination limitation silently removed: The old Known Limitations note about REST API pagination being unhandled was deleted, but the gh api commands in Step 3 still have no --paginate flag or ?per_page=100 parameter. On large PRs the agent will triage only the first ~30 comments with no warning to the user.

Confidence Score: 2/5

• The PR introduces a new thread-resolution feature that cannot work as written because the required thread node IDs are never fetched.
• The triage restructuring is well-conceived and the bot-comment fix is sound, but the headline new capability (resolving review threads via GraphQL) is broken by a data-collection gap: no thread ID is captured in the REST API step, and no GraphQL fallback is provided. Additionally, removing the pagination limitation note without fixing pagination can cause silent data loss on large PRs. Both are correctness issues in a command that will be run autonomously.
• .claude/commands/address-review.md — specifically Step 3 (jq filter missing node_id / no GraphQL thread query) and the Known Limitations section (pagination note removed without fix)

Important Files Changed

Sequence Diagram

sequenceDiagram
    participant U as User
    participant A as Agent
    participant GH as GitHub REST API
    participant GQL as GitHub GraphQL API

    U->>A: /address-review <PR_NUMBER>
    A->>GH: GET /repos/{repo}/pulls/{PR}/comments
    GH-->>A: comments (id, path, body, line, user, in_reply_to_id)
    Note over A: ⚠️ node_id / thread_id NOT fetched

    A->>A: Filter replies (in_reply_to_id set)
    A->>A: Deduplicate bot comments
    A->>A: Triage → MUST-FIX / DISCUSS / SKIPPED
    A->>A: TodoWrite (MUST-FIX items only)
    A-->>U: Present triage summary

    U->>A: "address item 1"
    A->>A: Apply code / doc fix
    A->>GH: POST /pulls/{PR}/comments/{id}/replies
    GH-->>A: reply created

    A->>GQL: resolveReviewThread(threadId: ???)
    Note over A,GQL: ⚠️ threadId unavailable — mutation will fail
    GQL-->>A: thread resolved (if threadId known)

    A-->>U: Item addressed & thread resolved

_{Last reviewed commit: bdb4381}