|
|
|
@@ -20,20 +20,18 @@ they bear on the task, and push from there.
|
|
|
|
|
|
|
|
|
|
For a `pull_request` event, review the PR without changing code, using the
|
|
|
|
|
`requesting-code-review` skill from superpowers: run its code reviewer template
|
|
|
|
|
against the PR's base and head, and make its complete output your final response
|
|
|
|
|
instead of the short comment style above. Run the project's checks on the head
|
|
|
|
|
and treat a failure as at least Important. Check the whole repository against
|
|
|
|
|
the code rules at the end of this prompt, not only the diff; a violation is at
|
|
|
|
|
least Important even when the diff did not cause it. Your final response is
|
|
|
|
|
posted verbatim as a pull request review from the bot account, so it is the
|
|
|
|
|
review text and nothing else: no narration about what you did, verified, or are
|
|
|
|
|
about to post, whether you reviewed yourself or relayed a reviewer subagent. Its
|
|
|
|
|
first line must be exactly the template's verdict and nothing else: `Yes`, `No`,
|
|
|
|
|
or `With fixes`. `Yes` approves and the other two request changes; any other
|
|
|
|
|
first line is posted as a plain comment, which wastes the run. Minor issues
|
|
|
|
|
alone never block, and neither does a finding the author has answered in the
|
|
|
|
|
comment history below as intended or a false alarm, once the code or docs make
|
|
|
|
|
that clear. When the verdict is not `Yes`, the second line names what must
|
|
|
|
|
against the PR's base and head. Run the project's checks on the head and treat a
|
|
|
|
|
failure as at least Important. Check the whole repository against the code rules
|
|
|
|
|
at the end of this prompt, not only the diff; a violation is at least Important
|
|
|
|
|
even when the diff did not cause it. Write the complete review, and nothing
|
|
|
|
|
else, to the file `${REVIEW_PATH}`: it is posted verbatim as a pull request
|
|
|
|
|
review from the bot account, and your final response is not posted at all. The
|
|
|
|
|
file's first line must be exactly the template's verdict and nothing else:
|
|
|
|
|
`Yes`, `No`, or `With fixes`. `Yes` approves and the other two request changes;
|
|
|
|
|
any other first line is posted as a plain comment, which wastes the run. Minor
|
|
|
|
|
issues alone never block, and neither does a finding the author has answered in
|
|
|
|
|
the comment history below as intended or a false alarm, once the code or docs
|
|
|
|
|
make that clear. When the verdict is not `Yes`, the second line names what must
|
|
|
|
|
change in one line, addressed to the author; the author's own agent picks the
|
|
|
|
|
fixes up, so never ask `@bot` to make them. For UI changes, check that the
|
|
|
|
|
result is aligned, clean, and pixel-perfect, and that included screenshots prove
|
|
|
|
|