Your First Review

After installing SlopBuster, here's what to expect when it reviews your first pull request.

What Happens Automatically

Once installed, SlopBuster reviews every new pull request automatically. No commands needed, just open a PR and the review appears as inline comments within seconds.

A review runs when a PR is opened and again each time it is updated. SlopBuster reads the diff in the context of your full repository and ties each review to the commit it analyzed, so findings always match the code you pushed.

Example: A First Review, Step by Step

Here is how a typical first review plays out, using the framework reinvention example from the Pattern Library.

1. Open the pull request
A developer opens a PR that adds a 67-line custom retry function. SlopBuster starts reviewing as soon as the PR is opened.
2. Read the inline finding
SlopBuster flags framework reinvention: RetryableOperation already exists in commons/utils.ts with exponential backoff, jitter, circuit breaker support, and telemetry hooks, features the new code is missing. Framework reinvention that adds maintenance burden is a high severity finding.
3. Ask for context
The developer replies @slopbuster why to see the reasoning, or @slopbuster show example to see how the existing utility is used elsewhere in the codebase.
4. Fix and push
The developer replaces the custom function with RetryableOperation and pushes. The update triggers a new review tied to the new commit.
5. Close the finding
The developer replies @slopbuster resolve. If the team decides the custom code is intentional, @slopbuster dismiss --reason "..." records why, and SlopBuster learns from it.

Understanding Findings

Each finding includes:

Severity Level

Every finding carries one of four severities, from blocker to style. See the reference below.

Contextual Explanation

Every finding explains why it matters, referencing your actual codebase, not generic rules.

Suggested Fix

Actionable recommendations with code examples showing how to resolve the issue.

Severity Reference

Severity	What it covers
Blocker	Critical issues that must be fixed before merge: security vulnerabilities, data exposure, authentication bypasses.
High	Significant issues: performance problems, missing error handling, framework reinventions that increase maintenance burden.
Medium	Improvements worth addressing: code duplication, missing types, inconsistent patterns.
Style	Suggestions for readability and consistency: naming, formatting, documentation.

Lower-severity findings can be cleared in bulk: @slopbuster dismiss --severity style dismisses all style findings, and @slopbuster dismiss --severity med dismisses medium and below. See Batch Operations.

Interacting with Findings

You can respond to any finding directly in the PR:

PR comment examples

@slopbuster why - Ask why this was flagged

@slopbuster how - Get a suggested fix

@slopbuster show example - See the correct pattern from your codebase

@slopbuster dismiss - Dismiss the finding

@slopbuster resolve - Mark as resolved

The Summary

At the end of each review, SlopBuster posts a summary comment with an overall quality score based on the Quality Radar, the number of findings by severity, praise for well-written code, technical debt notes for follow-up, and a merge recommendation: block, allow, or schedule follow-ups.

95 to 100: Excellent, production-ready code
85 to 94: Good, minor improvements recommended
70 to 84: Needs attention, significant issues found
Below 70: Critical, blocking issues must be addressed

Tips for Your First Review

SlopBuster shows 1 to 3 findings at a time, prioritized by impact, to avoid overwhelming you. Adjust the cap with max_findings_per_review in your configuration.
Use @slopbuster why to start a Teaching Chat conversation about any finding
Dismissed findings teach SlopBuster about your team's preferences
No configuration is needed, SlopBuster works out of the box