majiayu000 PR Operations Skill
Core Rule
CRITICAL: Use ONLY
erk execCommands for PR Thread Operations
- ❌ DO NOT use raw
gh apicalls for thread operations- ❌ DO NOT use
gh prcommands directly for thread resolution- ✅ ONLY use
erk execcommands listed belowThe
erk execcommands handle thread resolution correctly. Raw API calls only reply without resolving.
Quick Reference
| Command | Purpose | Key Point |
|---|---|---|
get-pr-review-comments |
Fetch unresolved review threads | Returns threads with line info |
get-pr-discussion-comments |
Fetch PR discussion comments | Returns top-level comments |
resolve-review-thread |
Reply AND resolve a thread | Does both in one operation |
reply-to-discussion-comment |
Reply to discussion comment | For non-code feedback |
post-pr-inline-comment |
Post new inline comment | Creates new review thread |
When to Use Each Command
Fetching Comments
# Get all unresolved review threads (code comments)
erk exec get-pr-review-comments
# Get all discussion comments (top-level PR comments)
erk exec get-pr-discussion-comments
# Include resolved threads (for reference)
erk exec get-pr-review-comments --all
Resolving Review Threads
# Always use this to resolve review threads - it replies AND resolves
erk exec resolve-review-thread --thread-id "PRRT_abc123" --comment "Fixed in commit abc1234"
Replying to Discussion Comments
# For PR discussion comments (not code review threads)
erk exec reply-to-discussion-comment --comment-id 12345 --reply "**Action taken:** Updated the docs as requested."
Common Mistakes
| Mistake | Why It's Wrong | Correct Approach |
|---|---|---|
Using gh api repos/.../comments/{id}/replies |
Only replies, doesn't resolve | Use erk exec resolve-review-thread |
Using gh pr comment |
Doesn't resolve threads | Use erk exec resolve-review-thread |
| Skipping resolution for outdated threads | Threads stay open in PR | Always resolve, even if already fixed |
| Generic replies like "Noted" | Not useful for PR history | Include investigation findings |
Replying vs Resolving
IMPORTANT: Replying ≠ Resolving
- Replying (via raw
gh api .../replies): Adds a comment but thread stays OPEN- Resolving (via
erk exec resolve-review-thread): Adds a comment AND marks thread as RESOLVEDAlways use
erk exec resolve-review-thread- it does both in one operation.
Comment Classification Model
When analyzing PR feedback, classify comments by complexity and group into batches.
Complexity Categories
- Local fix: Single comment → single location change (e.g., "Fix typo", "Add type annotation")
- Multi-location: Single comment → changes in multiple spots in one file
- Cross-cutting: Single comment → changes across multiple files
- Related: Multiple comments that inform a single unified change
Batch Ordering
Process batches from simplest to most complex:
| Batch | Complexity | Description | Example |
|---|---|---|---|
| 1 | Local fixes | One file, one location per comment | "Use LBYL pattern at line 42" |
| 2 | Single-file multi-location | One file, multiple locations | "Rename this variable everywhere in this file" |
| 3 | Cross-cutting | Multiple files affected | "Update all callers of this function" |
| 4 | Complex/Related | Multiple comments inform one change | "Fold validate into prepare" + "Use union types for this" |
Note: Discussion comments requiring doc updates go in Batch 3 (cross-cutting).
Batch Confirmation Flow
- Batch 1-2 (simple): Auto-proceed without confirmation
- Batch 3-4 (complex): Show plan and wait for user approval
Detailed Documentation
For complete command documentation including JSON output formats, options, and examples:
@references/commands.md