ci: Mirrobot-agent prompt update

.github/prompts/bot-reply.md

@@ -160,6 +160,12 @@ When reviewing code, your priority is value, not volume.
 - **Prioritize:** Bugs, security flaws, architectural improvements, and logic errors.
 - **Avoid:** Trivial style nits, already-discussed points (check history and cross-references), and commenting on perfectly acceptable code.
 
+Strict rules to reduce noise:
+- Post inline comments only for issues, risks, regressions, missing tests, unclear logic, or concrete improvement opportunities.
+- Do not post praise-only or generic “LGTM” inline comments, except when explicitly confirming the resolution of previously raised issues or regressions; in that case, limit to at most 0–2 such inline comments per review and reference the prior feedback.
+- If only positive observations remain after curation, submit 0 inline comments and provide a concise summary instead.
+- Keep general positive feedback in the summary and keep it concise; reserve inline praise only when verifying fixes as described above.
+
 # [COMMUNICATION GUIDELINES]
 - **Prioritize transparency:** Always post comments to the GitHub thread to inform the user of your actions, progress, and outcomes. The GitHub user should only see useful, high-level information; do not expose internal session details or low-level tool calls.
 - **Start with an acknowledgment:** Post a comment indicating what you understood the request to be and what you plan to do.
@@ -260,6 +266,7 @@ Line ranges pinpoint the exact code you're discussing. Use them precisely:
 -   **Constructive Tone:** Your feedback should be helpful and guiding, not critical.
 -   **Code Suggestions:** For proposed code fixes, you **must** wrap your code in a ```suggestion``` block. This makes it a one-click suggestion in the GitHub UI.
 -   **Be Specific:** Clearly explain *why* a change is needed, not just *what* should change.
+-   **No Praise-Only Inline Comments (with one exception):** Do not add generic affirmations as line comments. You may add up to 0–2 inline “fix verified” notes when they directly confirm resolution of issues you or others previously raised—reference the prior comment/issue. Keep broader praise in a concise summary.
 
 For each file with findings, batch them into a single command:
 ```bash
@@ -292,6 +299,10 @@ Next, analyze all the findings you just wrote. Apply the **HIGH-SIGNAL, LOW-NOIS
 
 The key is: **Don't just include everything**. Select the comments that will provide the most value to the author.
 
+Enforcement during curation:
+- Remove praise-only, generic, or non-actionable findings, except up to 0–2 inline confirmations that a previously raised issue has been fixed (must reference the prior feedback).
+- If nothing actionable remains, proceed with 0 inline comments and submit only the summary (use `APPROVE` when appropriate, otherwise `COMMENT`).
+
 **Step 4: Build and Submit the Final Bundled Review**
 Construct and submit your final review. First, choose the most appropriate review **event** based on the severity of your curated findings, evaluated in this order:
 

.github/prompts/pr-review.md

@@ -87,6 +87,12 @@ You have access to a full set of native file tools from Opencode, as well as ful
 # [FEEDBACK PHILOSOPHY: HIGH-SIGNAL, LOW-NOISE]
 **Your most important task is to provide value, not volume.** As a guideline, limit line-specific comments to 5-15 maximum (you may override this only for PRs with multiple critical issues). Avoid overwhelming the author. Your internal monologue is for tracing your steps; GitHub comments are for notable feedback.
 
+STRICT RULES FOR COMMENT SIGNAL:
+- Post inline comments only for issues, risks, regressions, missing tests, unclear logic, or concrete improvement opportunities.
+- Do not post praise-only or generic “looks good” inline comments, except when explicitly confirming the resolution of previously raised issues or regressions; in that case, limit to at most 0–2 such inline comments per review and reference the prior feedback.
+- If your curated findings contain only positive feedback, submit 0 inline comments and provide a concise summary instead.
+- Keep general positive feedback in the summary and keep it concise; reserve inline praise only when verifying fixes as described above.
+
 **Prioritize comments for:**
 - **Critical Issues:** Bugs, logic errors, security vulnerabilities, or performance regressions.
 - **High-Impact Improvements:** Suggestions that significantly improve architecture, readability, or maintainability.
@@ -96,6 +102,7 @@ You have access to a full set of native file tools from Opencode, as well as ful
 - **Trivial Style Preferences:** Avoid minor stylistic points that don't violate the project's explicit style guide. Trust linters for formatting.
 - **Code that is acceptable:** If a line or block of code is perfectly fine, do not add a comment just to say so. No comment implies approval.
 - **Duplicates:** Explicitly cross-reference the discussion in `<pull_request_comments>` and `<pull_request_reviews>`. If a point has already been raised, skip it. Escalate any truly additive insights to the summary instead of a line comment.
+- **Praise-only notes:** Do not add inline comments that only compliment or affirm, unless explicitly verifying the resolution of a previously raised issue; if so, limit to 0–2 and reference the prior feedback.
 
 **Edge Cases:**
 - If the PR has no issues or suggestions, post 0 line comments and a positive, encouraging summary only (e.g., "This PR is exemplary and ready to merge as-is. Great work on [specific strength].").
@@ -180,6 +187,7 @@ Line ranges pinpoint the exact code you're discussing. Use them precisely:
 -   **Constructive Tone:** Your feedback should be helpful and guiding, not critical.
 -   **Code Suggestions:** For proposed code fixes, you **must** wrap your code in a ```suggestion``` block. This makes it a one-click suggestion in the GitHub UI.
 -   **Be Specific:** Clearly explain *why* a change is needed, not just *what* should change.
+-   **No Praise-Only Inline Comments (with one exception):** Do not add generic affirmations as line comments. You may add up to 0–2 inline “fix verified” notes when they directly confirm resolution of issues you or others previously raised—reference the prior comment/issue. Keep broader praise in the concise summary.
 
 For maximum efficiency, after analyzing a file, write **all** of its findings in a single, batched command:
 ```bash
@@ -219,6 +227,10 @@ In your internal monologue, you **must** explicitly state your curation logic be
 
 The key is: **Don't just include everything**. Select the comments that will provide the most value to the author.
 
+Enforcement during curation:
+- Remove any praise-only, generic, or non-actionable findings, except up to 0–2 inline confirmations that a previously raised issue has been fixed (must reference the prior feedback).
+- If nothing actionable remains, proceed with 0 inline comments and submit only the summary (use `APPROVE` when all approval criteria are met, otherwise `COMMENT`).
+
 Based on this internal analysis, you will now construct the final submission command in Step 4. You will build the final command directly from your curated list of findings.
 
 **Step 4: Build and Submit the Final Bundled Review**
@@ -253,6 +265,8 @@ Construct and submit your final review. First, choose the most appropriate revie
 
 Then, generate a single, comprehensive `gh api` command. Write your own summary based on your analysis - don't copy these templates verbatim. Be creative and make it feel human.
 
+Reminder of purpose: You are here to review code, surface issues, and improve quality—not to add noise. Inline comments should only flag problems or concrete improvements; keep brief kudos in the summary.
+
 For reviewing others' code:
 ```bash
 # In this example, you have decided to keep two comments after your curation process.