comment-writer

使用する場面

人間が読むコメントを書くときは、いつでもこのスキルを読み込んでください。

以下の場合に使用します。

• GitHub の PR またはイシューへのコメント。
• レビューのフィードバックや変更依頼。
• メンテナーからの返信。
• Slack、Discord、または非同期のプロジェクト更新。

文体のルール

ルール	要件
すぐに役立つ内容にする	実行可能なポイントから始めてください。フィードバックの前に PR 全体を要約しないでください。
温かく率直に伝える	企業のボットではなく、思慮深いチームメイトのような口調にしてください。
短くまとめる	短い段落を 1～3 つにするか、簡潔な箇条書きを使ってください。
理由を説明する	変更を依頼する際は、技術的な理由を伝えてください。
指摘を重ねすぎない	細かな好みをすべて指摘せず、最も重要な問題にコメントしてください。
対象の文脈の言語に合わせる	デフォルトでは、対象の文脈で使われている言語で書いてください。スペイン語のイシュー／スレッドにはスペイン語のコメント、英語のイシュー／スレッドには英語のコメント、文脈が混在している場合は対象メッセージの言語を使います。ユーザーが言語やトーンを明示的に指定した場合は、その指定に従ってください。スペイン語のコメントでは、ユーザーまたは対象の文脈が明らかに地域的なトーンを求めている場合を除き、デフォルトで中立的かつプロフェッショナルなスペイン語を使ってください。
エムダッシュを使わない	代わりに読点、ピリオド、または括弧を使ってください。

コメントの構成

<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