Pr Operations

PR Operations Skill

Core Rule

CRITICAL: Use ONLY `erk exec` Commands for PR Thread Operations

>

- ❌ DO NOT use raw gh api calls for thread operations

- ❌ DO NOT use gh pr commands directly for thread resolution

- ✅ ONLY use erk exec commands listed below

>

The erk exec commands handle thread resolution correctly. Raw API calls only reply without resolving.

Quick Reference

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

# Resolve a single thread
erk exec resolve-review-thread --thread-id "PRRT_abc123" --comment "Fixed in commit abc1234"

# Batch resolve multiple threads (preferred for pr-address batches)
echo '[{"thread_id": "PRRT_abc", "comment": "Fixed"}, {"thread_id": "PRRT_def", "comment": "Applied"}]' | erk exec resolve-review-threads

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

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 RESOLVED

>

Always use erk exec resolve-review-thread (single) or erk exec resolve-review-threads (batch) - they do 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:

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

Inline Comment Deduplication

When posting inline review comments, always deduplicate to prevent re-posting existing comments:

1. Build dedup key: (file_path, line_number, body_prefix) where prefix is first 80 characters of comment body 2. Check proximity: Match within 2-line tolerance (line 42 matches existing comments at lines 40–44) 3. Skip duplicates: If a matching key exists, do not post the comment

This prevents the same feedback from appearing multiple times across review iterations. See Inline Comment Deduplication for full algorithm details.

Detailed Documentation

For complete command documentation including JSON output formats, options, and examples:

@references/commands.md

PR Operations Command Reference

Complete documentation for all erk exec commands related to PR thread operations.

get-pr-review-comments

Fetches unresolved review threads from the current branch's PR.

Usage

erk exec get-pr-review-comments          # Unresolved threads only
erk exec get-pr-review-comments --all    # Include resolved threads
erk exec get-pr-review-comments --pr 123 # Specific PR number

Options

JSON Output Format

{
  "success": true,
  "pr_number": 123,
  "pr_url": "https://github.com/owner/repo/pull/123",
  "pr_title": "Feature: Add new capability",
  "threads": [
    {
      "id": "PRRT_abc123",
      "path": "src/foo.py",
      "line": 42,
      "is_outdated": false,
      "comments": [
        {
          "author": "reviewer",
          "body": "This should use LBYL pattern instead of try/except",
          "created_at": "2024-01-01T10:00:00Z"
        }
      ]
    }
  ]
}

Field Notes

• id: Thread ID starting with PRRT_ - use this with resolve-review-thread
• path: File path relative to repository root
• line: Line number in the file, or null if thread is outdated
• is_outdated: true if the code has changed since the comment was made
• comments: Array of all comments in the thread (chronological order)

Handling Outdated Threads

When is_outdated: true:

1. The line field will be null 2. Read the file at path and search for relevant code mentioned in the comment 3. Check if the issue is already fixed in current code 4. Still resolve the thread via erk exec resolve-review-thread

---

get-pr-discussion-comments

Fetches PR discussion comments (top-level comments, not code review threads).

Usage

erk exec get-pr-discussion-comments          # Current branch's PR
erk exec get-pr-discussion-comments --pr 123 # Specific PR number

Options

JSON Output Format

{
  "success": true,
  "pr_number": 123,
  "pr_url": "https://github.com/owner/repo/pull/123",
  "pr_title": "Feature: Add new capability",
  "comments": [
    {
      "id": 12345,
      "author": "reviewer",
      "body": "Please also update the docs",
      "url": "https://github.com/owner/repo/pull/123#issuecomment-12345"
    }
  ]
}

Field Notes

• id: Numeric comment ID - use this with reply-to-discussion-comment
• body: The full comment text
• url: Direct link to the comment on GitHub

---

resolve-review-thread

Replies to a review thread AND marks it as resolved in one operation.

Usage

erk exec resolve-review-thread --thread-id "PRRT_abc123" --comment "Fixed in commit abc1234"

Options

Examples

Standard resolution:

erk exec resolve-review-thread --thread-id "PRRT_abc123" \
  --comment "Resolved via /erk:pr-address at $(date '+%Y-%m-%d %I:%M %p %Z')"

Already-fixed outdated thread:

erk exec resolve-review-thread --thread-id "PRRT_abc123" \
  --comment "Already addressed in current code - this outdated thread can be resolved."

False positive from automated reviewer:

erk exec resolve-review-thread --thread-id "PRRT_abc123" \
  --comment "False positive: The LBYL check already exists on line 344 where we check .exists() before the operation. No code change needed."

Replying vs Resolving

IMPORTANT: This command does BOTH reply AND resolve.

>

- Raw gh api .../replies: Only adds comment, thread stays OPEN

- erk exec resolve-review-thread: Adds comment AND marks RESOLVED

---

reply-to-discussion-comment

Posts a reply to a PR discussion comment.

Usage

erk exec reply-to-discussion-comment --comment-id 12345 --reply "**Action taken:** Updated the docs."

Options

Writing Substantive Replies

The reply becomes a permanent record in the PR. Make it useful for future readers.

Bad (too generic):

--reply "**Action taken:** Noted for future consideration."
--reply "**Action taken:** Added to backlog."

Good (includes investigation findings):

--reply "**Action taken:** Investigated the gateway pattern suggestion. The current implementation uses direct function calls rather than a gateway ABC pattern. This is intentional - artifact operations are file-based and don't require the testability benefits of gateway injection that external APIs need. Filed as backlog consideration for if we add remote artifact fetching."

Good (explains why no code change):

--reply "**Action taken:** Reviewed the suggestion to add caching here. After checking the call sites, this function is only called once per CLI invocation (in main.py:45), so caching wouldn't provide measurable benefit. The perceived slowness is actually from the subprocess call inside, not repeated invocations."

---

post-pr-inline-comment

Posts a new inline comment on a specific line of code in a PR.

Usage

erk exec post-pr-inline-comment --path "src/foo.py" --line 42 --body "Consider using LBYL here"
erk exec post-pr-inline-comment --pr-number 123 --path "src/foo.py" --line 42 --body "Consider using LBYL here"

Options

Examples

Simple comment:

erk exec post-pr-inline-comment --path "src/foo.py" --line 42 \
  --body "This should use LBYL pattern instead of try/except"

Comment on removed line (left side of diff):

erk exec post-pr-inline-comment --path "src/foo.py" --line 42 --side LEFT \
  --body "Why was this removed? It handled the edge case."

Post with markdown formatting:

erk exec post-pr-inline-comment --pr-number 123 --path "src/bar.py" --line 15 \
  --body "This could be simplified:\n\`\`\`python\nresult = x if x else default\n\`\`\`"

Notes

• The line number must be in the PR diff (not the original file)
• The command automatically fetches the PR head commit SHA