comment-writer

适用场景

每当你要撰写供其他人阅读的评论时，都加载此技能。

适用于：

• GitHub PR 或 issue 评论。
• 评审反馈和修改请求。
• 维护者回复。
• Slack、Discord 或异步项目动态。

语气规则

规则	要求
快速提供价值	从可执行的要点开始。不要在给出反馈前复述整个 PR。
亲切直接	像一位体贴的队友，而不是企业机器人。
简明扼要	尽量控制在 1 到 3 段短文内，或使用精炼的项目符号列表。
解释原因	请求修改时，说明技术原因。
避免面面俱到	聚焦最有价值的问题，而不是每个细枝末节的偏好。
匹配目标上下文的语言	默认使用目标上下文的语言：西班牙语 issue／讨论串使用西班牙语评论，英语 issue／讨论串使用英语评论，混合上下文则使用目标消息的语言。如果用户明确指定语言或语气，请遵循其要求。对于西班牙语评论，默认使用中性、专业的西班牙语，除非用户或目标上下文明显要求使用地区化语气。
不使用长破折号	使用逗号、句号或括号。

评论模板

<Direct observation or request>

<Why it matters, only if needed>

<Concrete next action>

示例

请求修改

Good approach overall. I'd split this into a separate commit because it mixes validation logic with UI wiring.

That keeps the reviewer's focus narrower and makes rollback cleaner if the integration fails.

批准并附上备注

Approved. The scope is clear and the change is well-contained.

For the next PR, add links to the previous and following PRs so the chain stays navigable.

请求拆分

This PR exceeds the 400-line budget, so we need to split it or justify `size:exception`.

Suggested order: foundation + tests first, then integration, then docs. That gives each review a clear start and end.

命令

# Inspect a PR before writing review feedback
gh pr view <PR_NUMBER> --json title,body,additions,deletions,changedFiles