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

Verdict words (#8)

Browse Source 
The review file starts with `Approved` or `Changes requested` instead of `Yes`/`No`/`With fixes`. The match is still the whole trimmed first line; `run.ts` prepends ✅, 🛑, or 💬 when posting, so the mark never takes part in the match.

Verified: `deno fmt`, `deno lint`, `deno check` pass; a scratch run of the matcher maps `Approved` → APPROVED, `Changes requested` → REQUEST_CHANGES, and `Approved, mostly`, `✅ Approved`, `Yes` → COMMENT.
Reviewed-on: #8
Co-authored-by: Danny Kim <temeddix@gmail.com>
Co-committed-by: Danny Kim <temeddix@gmail.com>
This commit was merged in pull request #8.
This commit is contained in:
Danny Kim
2026-09-13 17:21:34 +00:00
committed by temeddix
parent 0d109ebec8
commit 4ed8b48b7a
2 changed files with 20 additions and 18 deletions
Download Patch File Download Diff File Expand all files Collapse all files
prompt.md
+11 -10
View File
@@ -26,16 +26,17 @@ 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
the intended result was achieved.
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.
The review must read at a glance: everything outside `<details>` blocks totals
under 512 bytes. Only core information stays visible: the verdict, the summary