TL;DR: A 422 on an inline comment means the commit SHA or hunk position you posted against is stale - someone pushed since you computed it. Re-fetch the PR's head SHA, recompute the comment's position against the fresh diff, and repost. If the exact line moved, locate it in the new diff and adjust; if it is gone, fall back to a file-level comment.

```text
inline comment failed when agent attempted to post on an outdated diff hunk
```

1. Confirm the staleness. Compare the commit SHA your comment references with the PR's current head SHA.
   Expected: the SHAs differ, proving a push happened between analysis and posting.
2. Re-fetch the file's current diff at the new head SHA and find the code your comment was about. Match by surrounding context lines, not by old line numbers.
   Expected: the target line located in the fresh diff, with its new position.
3. Recompute the comment position (path, line, and side) against the new head and repost the comment referencing the new SHA.
   Expected: the API accepts the comment with a 201 instead of the 422.
4. If the line no longer exists in the new diff (code deleted or heavily rewritten), post the comment at file level instead, quoting the removed snippet.
   Expected: the feedback still lands, attached to the file rather than a dead line.
5. Shrink the race window for next time: compute positions and post comments in one tight step per file, instead of analyzing the whole PR and posting everything at the end.
   Expected: fewer pushes land between position computation and posting.
6. Re-run the comment flow on an active PR and push a commit mid-run as a test.
   Expected: the retried comments land on the new head with no 422s.

## Use this when
- Inline comments fail with 422 after new commits are pushed
- The comment's commit SHA no longer matches the PR head
- Line comments land on code that has moved
- You need a retry path for stale hunk positions

## Not for this skill when
- The 422 comes with "must contain only one review comment" (that is a batching problem, not staleness)
- The submit fails with 403 (permissions) or 404 (wrong PR or repo)
- The PR merged before posting (check PR state - nothing can be posted)
- Comments fail on a fresh PR with no new pushes (suspect a position-computation bug instead)

## Variant phrasings
- "422 Unprocessable Entity from review comments API on outdated diff hunk"
- "inline comment rejected, diff hunk outdated"
- "review comment position stale after push"
- "repost line comment on new commit SHA"

## Why it happens
GitHub pins every inline comment to a specific commit and a diff position. The moment a new push changes the head SHA, positions computed against the old diff become invalid and the API rejects them with 422. Agents that analyze first and post in a batch at the end maximize the window in which a push can invalidate everything.

## Edge cases
- Context matching can misfire when the same code pattern appears twice. Prefer the hunk closest to the original position when there are duplicates.
- If several pushes land during a long analysis, you may need more than one retry round. Cap retries (two or three) and then fall back to file-level comments.
- Multiline comments pin a start and end line; both must be recomputed, not just the start.
- Side matters: a comment on the LEFT (old) side of a hunk versus RIGHT (new) side resolves differently after a rebase. Recompute the side from the fresh diff, do not carry it over.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_oyHE3VZBRWAvzDrx08fI4A