pr-annotatelisted

# pr-annotate (inline rationale comments on a new PR) ## When this runs Immediately after opening a PR. The PR body already says *what* changed; these comments say *why* — the reasoning a reviewer can't get from the diff alone (why this file was touched, why one duplicate was kept over another, why a helper was promoted vs. left local). Skip files where the "why" is already obvious from the change itself (a one-line typo fix, a version bump) — annotate only where the rationale adds information the diff doesn't already carry. ## Rules for every comment 1. **No attribution footer in the body you write.** Do not append `_Generated by [Claude Code](...)_` or any `---` divider to the comment text yourself. Known platform limitation: the GitHub integration server-appends this footer to every post regardless of body content — confirmed on inline review comments even when the footer was omitted from the call. There is currently no tool-level way to suppress it, so don't spend time working around it; just never add it yourself so nothing doubles up if that ever changes. 2. **Concise and succinct.** One tight paragraph or a short bullet list. No preamble ("This change does X because..."), no restating the diff, no hedging. 3. **2-3 bullet points max per comment.** If a file's rationale doesn't fit in 2-3 bullets, the file should probably be two comments (or the PR should probably be two PRs) — don't write a wall of text in one comment to avoid t