devpilot-resolving-review-threadslisted

# Resolving Review Threads ## Overview After pushing fixes for a code review, every inline thread falls into one of three buckets. This skill is the decision matrix and the exact API calls for each bucket on GitHub and GitLab. **Core principle:** Resolve only what you can prove is fixed at HEAD. **Every thread gets a reply before it is resolved — no silent resolves, ever.** Reply with technical reasoning, never with gratitude or hedging. Never resolve a thread you pushed back on — the reviewer does that. **The Reply-Before-Resolve Rule:** A resolve with no reply leaves the reviewer guessing whether you read the comment, agreed with it, or fixed something else. The reply is the receipt. Even for a one-character typo fix, post the commit SHA. No exceptions. **REQUIRED BACKGROUND:** superpowers:receiving-code-review — the no-gratitude and technical-rigor rules apply here verbatim. ## The Three Buckets ``` FOR each open review thread: Did I change code to address it? ├── YES → Does HEAD contain the change? (verify with git/grep, not memory) │ ├── YES → BUCKET A: resolve (+ optional one-line reply) │ └── NO → STOP. Push the missing change first. └── NO → Is the reviewer technically wrong, misreading, or asking for out-of-scope work? ├── YES → BUCKET B: reply with reasoning, LEAVE OPEN └── NO/UNSURE → BUCKET C: reply asking for clarification, LEAVE OPEN ``` **Never resolve buckets B or C.** Resolving a thread closes the c