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

Inline comments (#10)

Browse Source 
A finding about one line now lands on that line of the diff: the agent writes anchors as JSON, and the review posts them with the body in one call. Bad entries fail the run, and an anchor Gitea refuses falls back to posting the body alone.

Verified with deno fmt, lint and check.

Reviewed-on: #10
Co-authored-by: bot <temeddix@gmail.com>
Co-committed-by: bot <temeddix@gmail.com>
This commit was merged in pull request #10.
This commit is contained in:
bot
2026-09-14 00:11:35 +00:00
committed by temeddix
parent 2b51793c92
commit 70d71aa4fd
2 changed files with 77 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files
prompt.md
+18 -7
View File
@@ -39,13 +39,24 @@ 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
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.
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
`{"path": "<path from the repository root>", "line": <number>, "side": "new" |
"old", "body": "<the finding>"}`.
`side` is `new` for a line in the head file and `old` for one only in the base
file; `line` is that file's own line number, and it must be a line the diff
touches, or Gitea refuses the anchor. Write the file only when there is
something to anchor, and keep each body to the what, the why, and the how, with
no `file:line` prefix; the line carries that.
The review body must read at a glance: everything outside `<details>` blocks
totals under 512 bytes. Only core information stays visible: the verdict, the
summary line, and the section headings. Anything verbose goes into a `<details>`
block whose `<summary>` is a few words, such as the title of an issue with the
what, why, and how inside; the same for each strength, each recommendation, the
reasoning, and any compliance notes. A finding you anchored belongs there only
as its title, since its detail is on the line. 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.