Answer Review Remark
Resolve a code review remark by inserting a clarifying comment at the right place in the source, capturing the reasoning so future reviewers won't raise the same concern.
Inputs
Infer both inputs from the conversation context. Ask only if ambiguous.
Input 1 — The remark.
A reviewer finding: usually a table row with a location (file:line) and a description of the concern.
The table usually comes from the dakubo-display-pr-remarks or dakubo-review-commit-range skill. If no table is in the conversation and one of these skills is available, use it to make the table. If not, ask the user for the remark.
Input 2 — The explanation. The developer's response: why the code is correct as-is, the design decision behind it, the trade-off accepted, or the big-picture context the reviewer was missing. This may not directly rebut the remark — it may just shift the reviewer's perspective.
Process
- Read the file at the location from Input 1.
- Identify the exact construct the remark targets (method, block, field, line).
- Draft a comment that:
- Captures the essence of Input 2 (the reasoning / decision / context).
- Is concise — one to four lines max.
- Does not mention the reviewer, the PR, or the remark number (comments outlive reviews).
- Does not repeat what the code already says — only add the WHY that isn't obvious from reading.
- Addresses the remark's concern if doing so makes the explanation clearer, but this is optional.
- Place the comment immediately above the targeted construct, or inline if a trailing comment fits naturally.
- Apply the edit.
Output
Confirm the file and line where the comment was added. One sentence is enough.
What NOT to do
- Do not rewrite the code unless the user explicitly asks.
- Do not write a comment that merely restates what the code does.
- Do not reference "the reviewer said…" or "PR #N" inside the comment.
- Do not add a comment longer than ~4 lines; if the explanation needs more, it belongs in a design doc or commit message, not inline.