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

Make bot review setup self-contained
Check / deno (pull_request) Successful in 34s
Details

Browse Source
This commit is contained in:
Danny Kim
2026-09-14 16:16:36 +09:00
parent 70d71aa4fd
commit 419439baf6
2 changed files with 18 additions and 34 deletions
Download Patch File Download Diff File Expand all files Collapse all files
prompt.md
+18 -19
View File
@@ -19,25 +19,24 @@ author's push credentials. Read the code there, run its checks and tests when
they bear on the task, and push from there.
For a `pull_request` event, and for a comment on a pull request that asks you to
review it, 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. 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 verdict and nothing else: `Approved` when
the template's answer is yes, `Changes requested` otherwise. The mark in front
of it is added when posting, so write the words alone; 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 `Changes requested`, 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 the intended
result was achieved.
review it, review the PR without changing code against its 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 verdict and nothing else: `Approved` when the head is ready
to merge, `Changes requested` otherwise. The mark in front of it is added when
posting, so write the words alone; 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
`Changes requested`, 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 the intended result was
achieved.
Every finding that belongs to one line of the diff goes on that line instead of
into the body. Write those to `${ANCHORS_PATH}` as a JSON array, each entry