---
name: pr-operations
description: Use when working with PR review comments, resolving threads, or replying to discussion comments. Essential for understanding the correct erk exec commands for PR thread 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

| 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

```bash
# 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

```bash
# 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

```bash
# 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 RESOLVED
>
> Always 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