Sigrid Auto-fix Agents MCP

An auto-fix agent uses the available Sigrid skills and MCP tools to fix and improve existing issues. It gives AI agents a prioritized list of refactoring targets from Sigrid, works through the list, fixes what it can, and marks each finding as resolved.

For installation instructions, see the MCP overview page.

Beta: Auto-fix agents are in early access. The current tools cover core refactoring workflows. We’re actively adding more.

Before you start

You need:

• A Sigrid account with at least one system
• The Sigrid MCP server connected to your AI coding agent (see installation)
• A local checkout of the system’s repository
• Your Sigrid customer and system identifiers, visible in the Sigrid URL: sigrid-says.com/<customer>/<system>

Pass them in your prompt or add them to your agent’s context file (e.g. CLAUDE.md, .cursor/rules/).

Skills

The Sigrid Claude Code Plugin ships a set of skills that run the workflows below for you. They come with the plugin, so installing it makes them available. Run /sigrid:setup once afterwards to record your Sigrid system and team conventions; see plugin configuration for what it stores.

If you use a different AI agent, browse the skill definitions in the sigrid-ai-toolkit repository and adapt them to your own workflow.

Guides

For end-to-end walkthroughs, see:

• Preventing architecture drift with an AI coding agent: check a diff against the architecture graph before it reaches production, built on architecture-drift
• Reducing technical debt with auto-fix agents: maintainability, built on sigrid-diagnose and sigrid-improve
• Triaging security and reliability findings: assess in context, triage with a rationale

Workflows

A few patterns for running an auto-fix agent on your codebase. Adapt the prompts, combine them, or do something different entirely.

Autonomous fixing

Give the agent a target property and your decision criteria, and let it work through findings in a loop. It needs to know when to fix and when to accept before it starts, and it should update statuses as it goes. Here that means telling it what a legitimate reason for coupling looks like in your codebase:

Get module coupling findings for [customer]/[system]. For each module, check whether it follows single responsibility. If it doesn't, split it into focused files. If it already has a clear single purpose and is small, mark as accepted. Update finding statuses to reflect your decisions.

The agent investigated eight coupling findings, concluded the high fan-in was deliberate, and marked all eight as accepted:

The sigrid-improve skill runs this loop with Guardrails verification after each change, and reducing technical debt walks through a full session.

Discovery and prioritization

The agent fetches findings, reads the surrounding code, and reports back without changing anything. Useful when you want an overview, or a shortlist to turn into tickets:

Get maintainability findings for [customer]/[system]. What patterns do you see? Suggest a refactoring strategy before making changes.

Prompted this way the agent will rank by severity, which is not the order that moves your rating. sigrid-diagnose weights candidates by the amount of rated code they cover; reducing technical debt explains why that changes the answer.

Architecture exploration

Before touching code, let the agent map how the system fits together: which components call which, and what a change would ripple out to. The three architecture:* tools are read-only, so they inform a plan without changing anything. Giving the agent this context up front helps it respect the existing structure instead of introducing architecture drift. To check whether a change already did, run the architecture-drift skill against the diff instead; preventing architecture drift walks through a session.

We would reach for them in this order:

1. architecture:get_worst_directories to find where restructuring pays off, since the ranking is volume-weighted and a low rating on a large component outranks the same rating on a small one.
2. architecture:get_internal to see how a directory hangs together. Call it without a path first for the system’s top-level components, then drill into the one you care about.
3. architecture:get_external_dependencies on whatever you plan to change, for its blast radius. It returns one hop per call, so follow a returned path with another call to go deeper.

See the tools reference for their parameters.

Map a component:

Before I refactor the Analyses component in [customer]/[system], map its internal structure and tell me which sub-parts are most tightly coupled.

Assess blast radius:

I want to change [file] in [customer]/[system]. What depends on it, and what does it depend on? Treat anything with a high call count as higher risk and call it out.

Security and reliability triage

The agent fetches security or reliability findings, investigates each one in the code, and either fixes it or triages it with a rationale. Give it a severity floor, say whether it may change code, and state your risk tolerance:

Find high severity security findings in the codebase for [customer]/[system]. Assess each one: is it exploitable given the context? Fix what you can, mark false positives with a justification.

Reliability findings use the same loop with a different question, because what you want to know is what happens at runtime when the code fails:

Get reliability findings for [customer]/[system] with severity HIGH or above. Focus on error handling and concurrency issues. Fix straightforward ones and flag complex ones for manual review.

A prompt like this gets you a first batch. What decides whether the verdicts are worth anything is context the agent cannot read from the code, such as which services are reachable from outside, plus a rule that every verdict cites a line. Both are in triaging security and reliability findings.

Open source health

The agent queries your open source dependencies for risks. Unlike security and reliability findings, open source health results are informational: there is no status to update, so the workflow is discover, prioritize, and report.

Component risk overview:

List open source components with high risk for [customer]/[system]. Which risk dimensions are causing the most concern? Group by dimension and suggest priorities.

Vulnerability triage:

Get critical and high severity vulnerabilities in our dependencies for [customer]/[system]. Which ones are in components we actively use? Suggest upgrade paths or alternatives.

Triage and execute

Split the work into two steps: triage findings first (mark as will-fix or accepted), then pick up the will-fix items and fix them. Both steps can happen in one session, or you triage now and execute later.

Triage first:

Get the top 100 duplication findings for [customer]/[system]. We accept duplication in boilerplate configuration between microservices, so mark those as accepted. Mark the rest as will-fix.

Execute after triage:

Get duplication findings for [customer]/[system]. Fix the ones I've previously marked as will-fix and update their status.

Splitting the two is worth it whenever the accept-or-fix call needs something only your team knows. If you can state that call up front, autonomous fixing does both in one pass. Triaging security and reliability findings applies the same split to findings where each decision has to carry a written rationale.

Tools reference

Ten MCP tools drive the workflows above. Every tool takes customer and system; the parameters below are the ones that shape the result.

Valid statuses for update_finding_status: