commons/bot-agents
3
0
Fork 0
Code Issues Pull Requests Actions Releases 3 Activity

Review file (#7)

Browse Source 
The reviewer writes its review to a file whose first line is the verdict, instead of relying on a narration-free final message. Sonnet put `Yes` after three paragraphs of narration on memona #936 (review 595), which the fail-closed verdict posted as a plain comment.

Reviewed-on: #7
Co-authored-by: Danny Kim <temeddix@gmail.com>
Co-committed-by: Danny Kim <temeddix@gmail.com>
This commit was merged in pull request #7.
This commit is contained in:
Danny Kim
2026-09-13 16:54:54 +00:00
committed by temeddix
parent a2bc4c9541
commit 0d109ebec8
2 changed files with 23 additions and 19 deletions
Download Patch File Download Diff File Expand all files Collapse all files
prompt.md
+12 -14
View File
@@ -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