レビュー指摘への回答
コードレビューの指摘に対して、ソースコードの該当箇所に説明コメントを挿入することで解決します。これにより、将来のレビューアが同じ疑問を提起することを防ぎます。
入力
両方の入力は会話のコンテキストから推測します。不明瞭な場合のみ質問します。
入力1 — 指摘。
レビューアの発見事項：通常は場所（ファイル:行）と懸念の説明を含むテーブル行です。
このテーブルは通常、dakubo-display-pr-remarks または dakubo-review-commit-range スキルから取得されます。会話にテーブルがなく、これらのスキルが利用可能な場合は、それを使用してテーブルを作成します。そうでない場合は、ユーザーに指摘を尋ねます。
入力2 — 説明。 開発者の応答：コードがそのままで正しい理由、背後にある設計判断、受け入れたトレードオフ、またはレビューアが見逃していた大局的なコンテキスト。これは指摘に直接反論する必要はなく、レビューアの視点を変えるだけの場合もあります。
プロセス
- 入力1の場所にあるファイルを読み取ります。
- 指摘が対象としている正確な構造（メソッド、ブロック、フィールド、行）を特定します。
- 次の条件を満たすコメントを作成します：
- 入力2（根拠/判断/コンテキスト）の本質を捉えている。
- 簡潔である — 最大1〜4行。
- レビューア、PR、または指摘番号に言及しない（コメントはレビューを超えて存続します）。
- コードが既に言っていることを繰り返さない — 読んでも明らかでないWHYだけを追加する。
- 説明をより明確にする場合に限り、指摘の懸念に対処することもできますが、これはオプションです。
- 対象の構造の直上、または末尾コメントが自然に収まる場合はインラインに配置します。
- 編集を適用します。
出力
コメントが追加されたファイルと行を確認します。一文で十分です。
やってはいけないこと
- ユーザーが明示的に要求しない限り、コードを書き換えないでください。
- コードが何をするかを単に言い換えるだけのコメントを書かないでください。
- コメント内で「レビューアが言った…」や「PR #N」を参照しないでください。
- 約4行を超えるコメントを追加しないでください。説明がさらに必要な場合は、設計ドキュメントやコミットメッセージに属するものであり、インラインコメントには適しません。