Reporting Findings to Train Scrubby

scrubby_report_findings is the tool that turns your AI editor’s review output into training signal for Scrubby’s connection graph. Most agents will call it automatically when prompted to “review and report” — this guide is about getting that loop reliable.

Why this matters

Scrubby’s network of domain connections is learned, not configured. The connections that produce useful findings get reinforced; the ones that don’t get weakened. After a few weeks of consistent use, the graph reflects how your codebase actually behaves — if the loop is being fed.

If your team uses the MCP tools but never reports findings, you’re getting half the value: codebase context on the way in, but no learning on the way out. Connections stay at their initial weights instead of converging on what matters for your repo.

For the full mechanics see Findings & the Learning Loop.

Getting your agent to report consistently

The reliable pattern is: have your agent end every review with a scrubby_report_findings call. Three ways to make that habitual:

1. System prompt or rules file

Most AI editors have a place for persistent instructions:

• Claude Code: CLAUDE.md in the repo root.
• Cursor: .cursorrules or .cursor/rules/.
• Windsurf: .windsurfrules.
• VS Code (Copilot): copilot instructions file.
• Zed: .rules.

Add something like:

After reviewing or changing code, call scrubby_report_findings with
any issues you found, even if the array is empty. Attribute each
finding to the domain that surfaced it.

A persistent rule of this form is the most reliable way to get an agent to feed the loop.

2. Per-session prompting

If you don’t want a global rule, prompt explicitly when you want the agent to report:

"Review this file with scrubby_review, then post your findings via scrubby_report_findings."

3. Workflow command

If your editor supports custom commands or slash actions, wire one up that combines scrubby_review → analysis → scrubby_report_findings. This makes reporting a single keypress.

What to put in findings

Each finding needs at minimum a severity and a message. To make the report useful for learning, also include:

• domain — the domain that produced the finding. Without this, weights can’t be attributed correctly.
• line — if the finding is line-scoped.

Example:

{
  "file_path": "app/services/billing/charge_processor.rb",
  "findings": [
    {
      "severity": "warning",
      "message": "Direct call to UserMailer skips the queueing convention used elsewhere in this segment.",
      "domain": "Email & Notifications",
      "line": 42
    }
  ]
}

Quiet reviews matter too

Calibrating severity

A few rules of thumb:

• error — the change will break something or violate a strong, high-confidence convention.
• warning — the change diverges from a convention that’s mostly consistent. Worth a second look.
• info — observation, not a complaint. Useful context but doesn’t require action.

Severity affects how findings render on PRs and how aggressively the dashboard surfaces them. It doesn’t currently change weight magnitudes — all reported findings move the network the same amount.

Don’t fake reports

If your agent calls scrubby_report_findings with fabricated findings to game the network, the result is a worse Scrubby. The system is small enough that bad reports do disproportionate damage. Don’t.

Verifying it’s working

Run scrubby_get_network before and after a few weeks of consistent reporting. Connection weights should shift — some up, some down — reflecting the cross-domain interactions your team actually has. If weights are static, the loop isn’t being fed.