fix(skill): warn about code fence collisions in suggestion blocks

[worktrunk-bot]

Summary

• Adds guidance to the review-pr skill about code fence marker collisions in GitHub suggestion blocks
• When a suggestion's target range includes a ``` line, the suggestion's own delimiters collide with it, causing the fence marker to be eaten if applied

Evidence

Run 22790184425 posted a suggestion on PR #1322 anchored at lines 289–291, where line 291 was the closing ``` of a code fence. max-sixty caught this: applying the suggestion would have removed the closing backticks and broken the markdown.

Closes #1326

Test plan

• Verify the new guidance reads clearly in the skill file
• No code changes — skill guidance only

🤖 Generated with Claude Code

[max-sixty]

can you explain exactly what request was sent to gh in the motivating case, and how the ``` was confused?

[worktrunk-bot]

The bot posted a review comment on PR #1322 via gh api with a suggestion block. The comment targeted lines 289–291 (start_line: 289, line: 291). At that commit, those lines were:

289: gh api "repos/$REPO/pulls/<number>/reviews" \
290:   --jq "[.[] | select(.user.login == \"$BOT_LOGIN\")] | last | .submitted_at // empty"
291: ```

Line 291 is the closing ``` of a bash code fence in the markdown file.

The suggestion body in the API request was:

```suggestion
gh api "repos/$REPO/pulls/<number>/reviews" \
  --jq "[.[] | select(.user.login == \"$BOT_LOGIN\" and .commit_id == \"$HEAD_SHA\")] | last | .submitted_at // empty"
```

GitHub suggestions replace every line in [start_line, line] with the suggestion body content. So clicking "Apply suggestion" would replace all 3 lines (289–291) with just the 2 code lines — deleting the closing ``` fence marker on line 291 since it wasn't reproduced inside the suggestion body.

The fix was straightforward: either narrow the range to start_line: 289, line: 290 (excluding the fence marker), or include the ``` as a third line inside the suggestion body. The bot applied the commit_id change directly in a follow-up commit instead of through the suggestion.

That said — this guidance is pretty niche and may not be worth the added complexity in the skill file. Happy to close this if you'd rather not carry it.

[max-sixty]

how did the bot post the review comment? what exact command did it run?

[worktrunk-bot]

I don't have the exact command from that run's logs — Claude Code's tool calls aren't captured in GitHub Actions output. But based on the review-pr skill instructions and the actual comment metadata, the command would have been:

gh api "repos/$REPO/pulls/1322/reviews" \
  --method POST \
  -f event=COMMENT \
  -f body="..." \
  -f 'comments[0][path]=.claude/skills/review-pr/SKILL.md' \
  -f 'comments[0][start_line]=289' \
  -f 'comments[0][line]=291' \
  -f 'comments[0][body]=```suggestion
gh api "repos/$REPO/pulls/<number>/reviews" \\
  --jq "[.[] | select(.user.login == \"$BOT_LOGIN\" and .commit_id == \"$HEAD_SHA\")] | last | .submitted_at // empty"
```'

The range start_line=289, line=291 covered lines 289–291. Line 291 was the closing ``` of a bash code fence. The suggestion body contained its own ``` delimiters (```suggestion and ```) but did not reproduce the closing fence marker from line 291. So applying the suggestion would have replaced all three lines with just the two code lines, deleting the fence marker.

That said — I agree with what I noted in my earlier comment: this is pretty niche. Happy to close this if the added skill complexity isn't worth it.

[max-sixty]

I see. Can you think of the generality of what went wrong? Or is it really so specific as this?

[worktrunk-bot]

The more general issue is: suggestions silently delete any line in the range that isn't reproduced in the suggestion body. The fence collision is one symptom, but the root cause is anchoring the suggestion to a wider range than the lines actually being changed.

That general principle is already stated in the bullet just above this new one: "verify that every line in [start_line, line] is either removed or rewritten in the suggestion body." So the fence-specific guidance is arguably redundant — it's just one way to violate a rule that's already there.

The fence case is slightly special because the rendered suggestion looks correct (GitHub's markdown rendering hides the collision), so it's harder to catch by visual inspection. But I don't think that's enough to justify its own bullet point.

Happy to close this — the existing guidance covers the general case well enough.