Make slop gate the verdict, not just carry a label - #461
Conversation
Slop was blocking in name only: the panel-wide rule said it does not gate merge, so a BLOCKING finding could still land under an APPROVE. - Carve slop out of the panel's advisory stance. An unresolved Slopinator BLOCKING rules out APPROVE on its own. - Add an arbiter bias against softening slop, so it is not filtered as noise or downgraded because the rest of the change is good. - Report every Part A instance. Residue is binary, so the clustering rule that governs prose tells does not apply to it; one review-history comment is enough to block.
|
Warning Review limit reached
Next review available in: 30 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (5)
📒 Files selected for processing (2)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Meh, the current version is fine. |
PR Summary by QodoMake Slopinator BLOCKING gate the panel verdict
AI Description
Diagram
High-Level Assessment
Files changed (7)
|
Code Review by Qodo
Context used✅ Compliance rules (platform):
140 rules✅ Skills:
|
| - Do not soften slop. A Slopinator `BLOCKING` finding is not a style nit to be | ||
| filtered as noise in Step 3, and it is not downgraded because the rest of the | ||
| change is good. |
There was a problem hiding this comment.
1. Wrong step number 🐞 Bug ≡ Correctness
The arbiter bias says slop findings must not be “filtered as noise in Step 3”, but Step 3 is dispatching specialists; the noise-filtering step is in Step 5 during arbiter synthesis. This incorrect reference reduces instruction clarity and can misdirect where the slop exception is enforced.
Agent Prompt
## Issue description
The slop exception guidance incorrectly references “Step 3” as the noise-filtering step, but Step 3 is the specialist dispatch step. Noise filtering is performed in Step 5 during arbiter synthesis, so the step reference should be corrected (or rewritten to avoid step-number coupling).
## Issue Context
This text is mirrored across the `.agents/`, `.apm/`, and `.claude/` copies of `skillsaw-review-panel/SKILL.md`, so the correction should be applied consistently in all three.
## Fix Focus Areas
- .agents/skills/skillsaw-review-panel/SKILL.md[217-226]
- .apm/skills/skillsaw-review-panel/SKILL.md[217-226]
- .claude/skills/skillsaw-review-panel/SKILL.md[217-226]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #461 +/- ##
=======================================
Coverage 93.54% 93.54%
=======================================
Files 145 145
Lines 11418 11418
=======================================
Hits 10681 10681
Misses 737 737 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 2d52e788bf
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| This is the disposition for unresolved slop, which is always in scope and | ||
| always fixable: the finding quotes the replacement text. |
There was a problem hiding this comment.
Preserve rejection precedence when slop is also present
When a PR has both unresolved slop and an Ecosystem or out-of-domain rejection, this new unconditional REQUEST_CHANGES rule conflicts with the following REJECT — REDIRECT TO PLUGIN and REJECT criteria. The arbiter may therefore hide a terminal rejection behind a request to fix prose, requiring another review cycle before reporting the actual disposition. Define the precedence explicitly so rejection outcomes win, while slop still rules out APPROVE in all other cases.
Useful? React with 👍 / 👎.
| `REQUEST_CHANGES` until they are fixed. What keeps that from being tyranny is | ||
| accuracy, not timidity: "What NOT to flag" below draws the line, and inside it | ||
| there is nothing to soften. |
There was a problem hiding this comment.
Replace the passage that triggers its own slop blocker
Under this reference's newly strengthened Part B rubric, the sentence beginning “What keeps that from being tyranny” clusters manufactured antithesis and dramatic metaphors in shipped skill prose, so a compliant Slopinator must classify this commit itself as BLOCKING. Replace it with the direct wording Read "What NOT to flag" before filing anything; its precision guardrails still apply.
Useful? React with 👍 / 👎.
Follow-up to #460. This commit was pushed about a minute after #460 was
squash-merged, so it missed the merge.
The gap
#460 gave the Slopinator a
BLOCKINGseverity, but blocking in name only.Three things on
maintoday let a slop finding ship anyway:SKILL.mdstill says "Keep the panel advisory. It does not gate merge."with no exception for slop.
APPROVEis "Set when no unresolved BLOCKING findings remain" — nothingprevents the arbiter from resolving a slop finding by filtering it as a
style nit in the noise-filter step.
isolated hits"), so a single review-history comment can read as below the
reporting threshold.
Changes
everything else; review-history residue and generated prose must not merge.
An unresolved Slopinator
BLOCKINGrules outAPPROVEon its own and holdsthe verdict at
REQUEST_CHANGES.nit in Step 3, and not downgraded because the rest of the change is good.
describes the shipped code or the conversation that produced it — so the
clustering rule now explicitly governs Part B prose only. One review-history
comment is enough.
added sentence had pushed past the 500-token
content-section-lengthlimit.The precision guardrails are unchanged: "What NOT to flag" still protects long
"why" comments, house style, domain vocabulary, version-scoped documents, and
comments a reviewer explicitly asked for.
Scope note
The panel posts its verdict with
gh pr comment, soREQUEST_CHANGESis adisposition in a comment rather than a GitHub review state — this makes slop
gate the verdict, not the merge button. A hard gate would mean posting a real
review via
gh pr review --request-changesplus branch protection, which is alarger change to Step 6 and is deliberately not in this PR.
Verification
make test— 2965 passed, unchanged frommainmake lint— clean.venv/bin/skillsaw lint .— 0 errors, 0 warnings, grade A+, 6 info-levelviolations (the
mainbaseline; the regenerated report card shows no drift)🤖 Generated with Claude Code