comment-writer

Start with the actionable point, keep it to one to three short paragraphs, and explain the technical reason behind any requested change. Use the formula of direct observation, why it matters, and a concrete next action.

Sound like a thoughtful teammate by being warm and direct, focusing on the highest-value issue instead of every small preference, and always explaining why a change matters. Avoid corporate phrasing and keep comments short.

Yes, the skill matches the target context language by default, so a Spanish issue or thread gets a Spanish comment. It uses neutral professional Spanish unless the context or user explicitly requests a regional tone.

Run gh pr view <PR_NUMBER> --json title,body,additions,deletions,changedFiles to see the PR scope before commenting. This helps you ground feedback in the actual size and content of the change.

Request a split when a PR exceeds the agreed line budget, such as 400 lines, or mixes unrelated concerns like validation logic with UI wiring. Suggest a concrete ordering such as foundation plus tests first, then integration, then docs.