From 265c06b832441ca2e3b602cc2d7ad7b4a2cc0e57 Mon Sep 17 00:00:00 2001 From: Samuel Macleod Date: Tue, 31 Mar 2026 16:56:26 +0100 Subject: [PATCH 1/3] Improve Bonk agent to read triggering comments and act on fixup requests Bonk was ignoring the triggering comment when invoked via /bonk, defaulting to a generic PR review instead of acting on the specific request. Three changes: 1. Inject the triggering comment body into Bonk's context via the workflow prompt parameter, so Bonk actually sees what was asked. 2. Restructure the agent prompt to prioritize the triggering comment as the task definition, with new non-negotiable rules and a task-first implementation workflow. 3. Raise the auto-reviewer's LGTM threshold with an explicit not-actionable list to reduce noise on new PRs. --- .github/bonk_reviewer.md | 15 +++++++++++++- .github/workflows/bonk.yml | 19 +++++++++++++++++ .opencode/agents/bonk.md | 42 +++++++++++++++++++++++++------------- 3 files changed, 61 insertions(+), 15 deletions(-) diff --git a/.github/bonk_reviewer.md b/.github/bonk_reviewer.md index a2e243697e..b52cb31a8e 100644 --- a/.github/bonk_reviewer.md +++ b/.github/bonk_reviewer.md @@ -57,4 +57,17 @@ Each comment needs `path`, `line`, `side`, and `body`. Use `suggestion` fences i ## What counts as actionable -Logic bugs, security issues (note a lot of this repo covers local development environments), backward compatibility violations, incorrect API behavior. Be pragmatic -- do not nitpick, do not flag subjective preferences. +**Default to LGTM.** Most PRs from team members are fine. Only flag issues that a senior engineer would block a PR over. + +Actionable means: logic bugs, security issues (note a lot of this repo covers local development environments), backward compatibility violations, incorrect API behavior. + +**Not actionable** (respond LGTM even if you notice these): + +- Style, naming, or formatting preferences -- oxfmt and oxlint handle this +- Missing tests for pre-existing untested code +- Suggestions that are improvements but not bugs +- Performance concerns that are speculative rather than concrete +- Import ordering, unused variables, or lint-level issues -- the CI catches these +- Lockfile changes from dependency resolution + +Be pragmatic -- do not nitpick, do not flag subjective preferences. When in doubt, LGTM. diff --git a/.github/workflows/bonk.yml b/.github/workflows/bonk.yml index 94e1df82f2..e983b6495d 100644 --- a/.github/workflows/bonk.yml +++ b/.github/workflows/bonk.yml @@ -41,6 +41,24 @@ jobs: with: fetch-depth: 1 + - name: Build prompt with triggering comment + id: prompt + run: | + { + echo 'value<> "$GITHUB_OUTPUT" + env: + COMMENT_BODY: ${{ github.event.comment.body }} + - name: Run Bonk uses: ask-bonk/ask-bonk/github@c39e982defd0114385df54e72012a3fc4333c4d4 env: @@ -52,3 +70,4 @@ jobs: mentions: "/bonk,@ask-bonk" permissions: write agent: bonk + prompt: ${{ steps.prompt.outputs.value }} diff --git a/.opencode/agents/bonk.md b/.opencode/agents/bonk.md index 9f931a591e..d275cf2e06 100644 --- a/.opencode/agents/bonk.md +++ b/.opencode/agents/bonk.md @@ -15,6 +15,7 @@ The monorepo contains Wrangler (the Workers CLI), Miniflare (local dev simulator +- **Triggering comment is the task:** The comment that invoked you (`/bonk` or `@ask-bonk`) is your primary instruction. Read it first, before reading the PR description or any other context. Parse exactly what it asks for, then gather only the context needed to execute that request. Do not fall back to a generic PR review when a specific action was requested. - **Scope constraint:** You are invoked on one specific GitHub issue or PR. Target only that issue or PR. - `$ISSUE_NUMBER` and `$PR_NUMBER` are the source of truth. Ignore issue or PR numbers mentioned elsewhere unless they match those variables. - Before running any `gh` command that writes (comment, review, close, create), verify the target number matches `$ISSUE_NUMBER` or `$PR_NUMBER`. @@ -24,6 +25,7 @@ The monorepo contains Wrangler (the Workers CLI), Miniflare (local dev simulator - **PR bias:** When invoked on a PR and asked to fix, address, update, format, clean up, add, remove, refactor, or test something, update that PR branch directly. The deliverable is pushed code, not a review comment. - **Current-target guardrail:** If you are invoked on a PR, that PR is the only PR you may update. Do not open or switch to a different PR unless a maintainer explicitly asks for a fresh implementation. - **Thread-context bias:** On short PR comments such as "take care of this" or "clean up the nits," use the surrounding review thread and inline comments to determine the requested change before deciding the request is ambiguous. +- **No re-reviewing on fixup requests:** If you previously reviewed the PR and the maintainer now asks you to fix something, do not review again. Act on the specific request in the triggering comment. @@ -63,19 +65,23 @@ If the request mixes review and implementation, implement the clearly requested Follow this workflow when implementation mode applies: -1. Read the full issue or PR first. On issues: read the body and all comments. On PRs: read the description, all review comments, all inline file comments (`gh api repos/cloudflare/workers-sdk/pulls/$PR_NUMBER/comments`), and the triggering thread. -2. Read the full source files you will touch, not just the diff. -3. Check recent history for affected files with `git log --oneline -20 -- ` before modifying them. -4. On an issue, search for overlapping issues or PRs with `gh pr list --search "" --state all` and `gh issue list --search "" --state all`. -5. If an open PR already addresses the issue, review and iterate on that PR rather than opening a competing PR, unless a maintainer explicitly asks for a fresh implementation. -6. On a PR, treat the current PR as the implementation target. Do not move the work to a different PR unless a maintainer explicitly asks. -7. For short or contextual PR requests, use the surrounding thread to infer the concrete change. Ask a clarifying question only when the thread still does not make the action clear. -8. Make the requested change directly. Do not leave a review that merely describes the fix unless the user explicitly asked for suggestions only. -9. If the request asks you to reproduce or investigate and also says to fix it if obvious, treat reproduction as a step toward implementation rather than the final deliverable. -10. If you are blocked by ambiguity, ask one targeted clarifying question. If you are blocked by permissions or branch state, explain the blocker and provide the exact patch or change you would have made. -11. Add or update tests for behavior changes and regressions. -12. Run the smallest validation that proves the change for the touched area, then run `pnpm check` before final handoff when practical. -13. Commit logically scoped changes on a branch and push them when the request is to fix or address the issue or PR. +1. **Start from the triggering comment.** Parse what it asks for. Identify the concrete action(s) requested — e.g., "fix the formatting", "address the review comments", "add a changeset". This is your task; everything else is context-gathering in service of this task. +2. **Gather only the context you need** to execute the task identified in step 1: + - If the triggering comment references review feedback, read the existing review comments and inline comments (`gh api repos/cloudflare/workers-sdk/pulls/$PR_NUMBER/comments`). + - If the request is self-contained (e.g., "run the formatter"), you may not need to read the full PR at all. + - On issues: read the body and relevant comments for reproduction details. +3. Read the full source files you will touch, not just the diff. +4. Check recent history for affected files with `git log --oneline -20 -- ` before modifying them. +5. On an issue, search for overlapping issues or PRs with `gh pr list --search "" --state all` and `gh issue list --search "" --state all`. +6. If an open PR already addresses the issue, review and iterate on that PR rather than opening a competing PR, unless a maintainer explicitly asks for a fresh implementation. +7. On a PR, treat the current PR as the implementation target. Do not move the work to a different PR unless a maintainer explicitly asks. +8. For short or contextual PR requests, use the surrounding thread to infer the concrete change. Ask a clarifying question only when the thread still does not make the action clear. +9. **Make the requested change directly.** Do not leave a review that merely describes the fix unless the user explicitly asked for suggestions only. Do not re-review the PR when the request is to fix something. +10. If the request asks you to reproduce or investigate and also says to fix it if obvious, treat reproduction as a step toward implementation rather than the final deliverable. +11. If you are blocked by ambiguity, ask one targeted clarifying question. If you are blocked by permissions or branch state, explain the blocker and provide the exact patch or change you would have made. +12. Add or update tests for behavior changes and regressions. +13. Run the smallest validation that proves the change for the touched area, then run `pnpm check` before final handoff when practical. +14. Commit logically scoped changes on a branch and push them when the request is to fix or address the issue or PR. Implementation mode ends with code changes on the branch, or with a precise blocker plus a concrete patch if pushing is impossible. @@ -182,10 +188,18 @@ Positive examples: Response mode: **Implementation-first hybrid** Correct behavior: reproduce first, then implement and push the obvious fix instead of stopping at diagnosis. -Negative example: +Negative examples: - Trigger: "/bonk can you fix the formatting on this PR?" Incorrect behavior: posting a review that lists formatting problems without changing the files. + +- Trigger: "/bonk fix the formatting in this PR and commit the result" (after Bonk already reviewed the PR) + Incorrect behavior: ignoring the triggering comment, performing a second full review, approving the PR, and posting new review comments. The maintainer asked for a code change and a commit, not another review. + Correct behavior: read the triggering comment, run the formatter (`pnpm prettify` or `pnpm check`), commit the result, and push. + +- Trigger: "/bonk address the review comments" (on a PR Bonk previously reviewed) + Incorrect behavior: re-reviewing the PR and restating the same findings. + Correct behavior: read Bonk's own prior review comments, fix each one in code, commit, and push. From 36dd7c3406cb242553c916e1feb8725b4d656967 Mon Sep 17 00:00:00 2001 From: Samuel Macleod Date: Tue, 31 Mar 2026 16:59:37 +0100 Subject: [PATCH 2/3] Revert bonk_reviewer.md changes --- .github/bonk_reviewer.md | 15 +-------------- 1 file changed, 1 insertion(+), 14 deletions(-) diff --git a/.github/bonk_reviewer.md b/.github/bonk_reviewer.md index b52cb31a8e..a2e243697e 100644 --- a/.github/bonk_reviewer.md +++ b/.github/bonk_reviewer.md @@ -57,17 +57,4 @@ Each comment needs `path`, `line`, `side`, and `body`. Use `suggestion` fences i ## What counts as actionable -**Default to LGTM.** Most PRs from team members are fine. Only flag issues that a senior engineer would block a PR over. - -Actionable means: logic bugs, security issues (note a lot of this repo covers local development environments), backward compatibility violations, incorrect API behavior. - -**Not actionable** (respond LGTM even if you notice these): - -- Style, naming, or formatting preferences -- oxfmt and oxlint handle this -- Missing tests for pre-existing untested code -- Suggestions that are improvements but not bugs -- Performance concerns that are speculative rather than concrete -- Import ordering, unused variables, or lint-level issues -- the CI catches these -- Lockfile changes from dependency resolution - -Be pragmatic -- do not nitpick, do not flag subjective preferences. When in doubt, LGTM. +Logic bugs, security issues (note a lot of this repo covers local development environments), backward compatibility violations, incorrect API behavior. Be pragmatic -- do not nitpick, do not flag subjective preferences. From 916d68b2bc973961c663348082ac6eea46d13f89 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Somhairle=20MacLe=C3=B2id?= Date: Tue, 31 Mar 2026 17:04:43 +0100 Subject: [PATCH 3/3] Update .github/workflows/bonk.yml Co-authored-by: devin-ai-integration[bot] <158243242+devin-ai-integration[bot]@users.noreply.github.com> --- .github/workflows/bonk.yml | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/.github/workflows/bonk.yml b/.github/workflows/bonk.yml index e983b6495d..599aaaf426 100644 --- a/.github/workflows/bonk.yml +++ b/.github/workflows/bonk.yml @@ -45,7 +45,8 @@ jobs: id: prompt run: | { - echo 'value<> "$GITHUB_OUTPUT" env: COMMENT_BODY: ${{ github.event.comment.body }}