comment-writer

Start with the actionable point instead of recapping the PR, explain the technical reason for any requested change, and keep it to one to three short paragraphs. Focus on the highest-value issue rather than listing every minor preference.

Use a warm but direct tone: state the observation, briefly explain why it matters, and end with a concrete next action. Sound like a thoughtful teammate rather than a corporate bot, and avoid piling on minor nitpicks.

Yes, the comment matches the language of the target thread by default: Spanish issues get Spanish replies, English threads get English. For Spanish, it uses neutral professional Spanish unless the context calls for a regional tone.

Run gh pr view <PR_NUMBER> --json title,body,additions,deletions,changedFiles to see the PR scope and size. This lets you ground feedback in the actual change, such as requesting a split when the PR exceeds a line budget.

Request a split when a PR exceeds the team's size budget or mixes unrelated concerns, such as validation logic with UI wiring. Suggest a concrete order, like foundation and tests first, then integration, then docs.