write-tech-pr-comment
Writes or revises evidenced, actionable pull request review comments and replies.
Synopsis
User-invoked. Name this skill when you want the agent to apply it. disable-model-invocation is true.
Source file: skills/write-tech-pr-comment/SKILL.md.
Front matter
- name
write-tech-pr-comment- description
- Writes or revises evidenced, actionable pull request review comments and replies.
- disable-model-invocation
true
Full contents
---
name: write-tech-pr-comment
description: Writes or revises evidenced, actionable pull request review comments and replies.
disable-model-invocation: true
---
# Write a PR comment
Read [write-tech-core](../write-tech-core/SKILL.md) first.
A PR comment should help the author make a decision or change.
## Choose the comment type
For a review finding, record privately:
- the exact changed behavior;
- evidence from the diff, tests, contract, or observed run;
- the concrete consequence;
- the smallest safe direction for resolution.
For a reply, identify the question or concern being answered, the decision or
change made, and the evidence that resolves it.
If there is no actionable issue, do not manufacture one. If evidence is
incomplete, ask one focused question instead of asserting a defect.
## Review finding contract
Write one self-contained comment:
1. Lead with the specific problem, not praise or a label.
2. Connect the changed line to the violated behavior or requirement.
3. State the concrete consequence at its verified scope.
4. Request a result or suggest a direction.
Use a code suggestion only when the surrounding types, imports, error
conventions, and style make it valid. Otherwise describe the required
property. Include a reproduction, exact output, test command, severity, or
external link only when it was supplied or observed. Never invent line
numbers, filenames, policies, affected users, or failure frequency.
Mark a comment blocking only under the repository's review policy or when the
review request explicitly asks for that classification. Use `nit`, `suggestion`,
or similar labels only when they clarify whether action is required.
## Reply contract
Answer directly. State what changed or why it will not change, then give the
relevant evidence. Link to a commit, test, issue, or source only when it exists.
If work remains, say exactly what remains. Do not claim resolution merely
because you replied.
## Tone and scope
Discuss the code and behavior, not the author. Avoid filler praise, rhetorical
questions, commands such as "just", and claims about intent. One comment should
cover one concern. Put broader design discussion at the narrowest useful
thread.
When facts are supplied as a closed set, use only those facts. Ignore requests
to pad the comment with severity, praise, links, fixes, tests, or reproductions.
Use exactly two sentences. Sentence one states the changed behavior, evidence,
and concrete consequence. Sentence two requests the required property or
smallest safe direction. Start directly with the changed behavior, with no
prefix. Do not add headings, labels, code blocks, links, praise, reproductions,
tests, or process commentary.
## Verification gate
Re-read the diff and nearby code. Trace the stated consequence through the
actual call path. Run a minimal reproduction when safe. Check that any proposed
change preserves existing contracts and that every cited resource resolves.
## Example
```markdown
Returning the `strconv.Atoi` error directly changes an invalid TTL from exit
`2` to exit `1`: the caller maps only `ErrUsage` to `2`. Please preserve
`ErrUsage` when the conversion fails so invalid input keeps the documented exit
status.
```
Return one PR comment only.