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

Verdict is the first line
Check / deno (pull_request) Successful in 41s
Details

Browse Source
This commit is contained in:
Danny Kim
2026-09-13 23:56:05 +09:00
parent 81e75297a4
commit 242717a141
2 changed files with 40 additions and 41 deletions
Download Patch File Download Diff File Expand all files Collapse all files
prompt.md
+11 -9
View File
@@ -19,19 +19,21 @@ against the PR's base and head, and make its complete output your final response
instead of the short comment style above. 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 as
a pull request review from the bot account: it requests changes when it mentions
`@bot` and approves otherwise, so the assessment instructs `@bot` to make the
fixes exactly when it is not `Yes`, and Minor issues alone never block. For UI
a pull request review from the bot account, and 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. Minor issues alone never block. When the verdict is not `Yes`,
the second line is a one-line instruction to `@bot` to make the fixes. 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 assessment line, the
section headings, and a one-line `@bot` instruction. Anything verbose goes into
a `<details>` block whose `<summary>` is a few words, such as the `file:line`
and title of an issue with the what, why, and how inside; the same for each
strength, each recommendation, the reasoning, and any compliance notes. Details
blocks are top-level, never inside a list item, because Gitea breaks them there.
under 512 bytes. Only core information stays visible: the verdict, the `@bot`
line, and the section headings. Anything verbose goes into a `<details>` block
whose `<summary>` is a few words, such as the `file:line` and title of an issue
with the what, why, and how inside; the same for each strength, each
recommendation, the reasoning, and any compliance notes. Details blocks are
top-level, never inside a list item, because Gitea breaks them there.
For an `issue_comment` or `pull_request_review_comment` event, treat the `body`
in the triggering comment payload below as the user's exact instruction.