Develocity Failure Handler

The Develocity Failure Handler is an agent skill that diagnoses a single build failure, including a flaky test, using Develocity’s cross-build data, reporting a root cause and a reproduction recipe, and, when you direct it, handles the failure.

 The Develocity Failure Handler is in Beta. See Feature Availability.

The skill answers questions a working tree cannot: whether a failure is flaky, pre-existing, or caused by your own change. It reads Build Scan data and cross-build history through the Develocity MCP Server, classifies the failure, and states what it found. When you direct it to deal with the failure, it opens a pull request with the fix, routes an operational cause to the owning team, or records what it found. The skill holds no fixing expertise of its own: your AI agent writes any fix, within the constraints the diagnosis sets.

When to Use It

Reach for the Failure Handler when you hold a failure and need its cause before you act on it. Common cases:

  • A failure on a build you did not run: A CI job fails on another branch and you have the log but not the workspace. The skill resolves the Build Scan and diagnoses the failure from Develocity data alone. Fixing it needs the checkout, so here you get the diagnosis to act on.

  • A failure you cannot yet attribute: You do not know whether your own change caused it. The skill weighs the failure against builds beyond your own, separating a pre-existing or systemic failure from one you introduced.

  • A flaky test: You need to know why a test flakes, not only whether it does. The skill measures the flake across builds, identifies the conditions it flakes under, and grades its confidence in the cause.

  • A failure blocking a pull request, merge, or release: You need a citable diagnosis to decide whether the failure is yours to fix or belongs elsewhere.

The Failure Handler is built to be reached mid-task, the moment a failure surfaces. You need no Build Scan ID: finding it is where the run starts.

How It Works

The skill takes one failure at a time and progresses through five phases:

  1. Resolve Scan: Finds the Build Scan for the failing build, from the build output, your prompt, or a lookup.

  2. Triage: Runs a fixed set of queries against Develocity cross-build data to establish the failure signature and how often it recurs in builds beyond your own.

  3. Diagnose: Traces the failure to a root cause and classifies it two ways: whether a repository change can fix it (code-fixable or operational), and how widely it occurs (local, systemic, or undetermined). For a flaky test, it derives the regression window and a confidence grade for its claim.

  4. Respond: States the diagnosis, with the classification, the root cause, the supporting evidence, and a reproduction recipe.

  5. Handle: When you direct the skill to deal with the failure, it takes one of three routes. For a code-fixable cause with a checkout to commit from, it opens a pull request with the fix. For an operational cause, it files an issue and notifies the owning team. When it can do neither, such as with no checkout to fix from, it records what it found.

The Failure Handler diagnoses. When the run reaches the Handle phase, your AI agent writes the fix under two constraints the skill enforces: suppressing a test is never a fix, and a fix stays within the failure’s blast radius.

Prerequisites

The Failure Handler reads Develocity data through the Develocity MCP Server, so confirm the following before you run it:

  • A running Develocity instance with the Develocity MCP Server enabled, connected with an access key whose user has the Access build data via the API and MCP permission. The skill reads Build Scan data and cross-build history through the server. See the MCP Server installation manual and Permissions.

  • The Develocity skills installed in your AI agent. See Getting Started.

  • A published Build Scan for the failing build. The skill starts by resolving that scan and declines when the build published none.

Beyond the key the MCP Server authenticates with, the skill can read an access key from the DEVELOCITY_ACCESS_KEY environment variable or your build tool’s Develocity keys file, and use it to run faster scripted scans directly over the Develocity API. This is optional: without it the skill runs the same scans through the MCP Server, at a higher token cost. See the Develocity API user manual.

The diagnosis draws on two more Develocity capabilities. Their absence caps what the skill can conclude rather than stopping the run, and the diagnosis states when it was capped:

  • Cross-build failure grouping supplies the occurrence counts that separate a recurring failure from a one-off. See the Failure Classification Guide.

  • The Git branch custom value, recorded by the Common Custom User Data plugins, scopes a flaky test’s history and the search for a later passing build. Without it, the skill cannot tell a failure limited to one branch from one that is everywhere.

For a flaky test, the skill also reads Test Analytics history.

Run the Skill

You can invoke the Failure Handler by name, or let your AI agent start it when your request matches, such as asking why a test flakes or whether a failure is yours. Point it at the failure in plain language:

/develocity-failure-handler Why is this test failing on CI? https://ci.example.com/build/1234

How the run ends depends on what you asked it to do:

  • When the failure interrupts other work and you only need the answer, the skill diagnoses the failure and hands back. It changes nothing, and you carry on with what you were doing.

  • When dealing with the failure is the task, the skill diagnoses it and then goes on to handle it: a fix in a pull request, an issue for an operational cause, or a written record.

A fix prompt pasted from the Develocity Failure Report is the second case: the report’s ask is itself the direction to deal with the failure, so the run goes on to handle it.

To keep the skill at the diagnosis even when you asked it to fix the failure, tell it so:

/develocity-failure-handler Diagnose only: is this failure related to my change? https://develocity.example.com/s/abc123

The skill diagnoses one failure per run. When a build carries several failures, it selects one, names the others, and leaves them for their own runs.

Run Behind a Proxy

On a network that reaches Develocity only through an HTTP or HTTPS proxy, the skill routes its own Develocity API scans through it. Name the proxy in your prompt:

/develocity-failure-handler Diagnose this failure using the proxy http://proxy.example.com:8080. https://develocity.example.com/s/abc123

Or set the standard HTTP_PROXY, HTTPS_PROXY, and NO_PROXY environment variables before you start your AI agent. This suits unattended and CI runs:

export HTTPS_PROXY=http://proxy.example.com:8080
export NO_PROXY=localhost,127.0.0.1

The skill takes a proxy only from your prompt or these environment variables, never from another tool’s configuration, and masks any credentials in the proxy URL in its output. The Develocity MCP Server reaches Develocity over its own connection, which you configure with the server rather than through the skill.

Results

The Failure Handler always responds, and several of its outcomes are correct results rather than failed runs. Do not treat one as an error:

  • A root cause analysis names the cause, its classification, and the evidence behind it.

  • A flaky report or flaky diagnosis reports that a test is flaky. Flakiness is a property of the test across builds, so this is the right answer even when the failure looked like it came from your change.

  • A fast hint points you at the Develocity data that answers the question when a full diagnosis would add nothing.

  • A decline is the answer when the cross-build data adds nothing beyond the build in front of you, most often a failure your own change just caused, which you can fix without a diagnosis. The skill says so and points you at the relevant data.

Each response states its decision and the signals behind it. A decline or a flaky report has done its job: it has told you the failure is not what a cross-build diagnosis is for.

Scope

The skill diagnoses one failure and, when directed, coordinates handling it. It does not:

  • write the fix from its own expertise. Your AI agent authors the fix, and the skill supplies the diagnosis and the constraints the fix has to keep,

  • suppress a test to make a failure go away. Disabling, ignoring, or deleting a test removes the signal, not the defect, and the skill reports that as not a fix, or

  • diagnose more than one failure per run.

When the cause is operational, such as an infrastructure incident or an expired credential, no repository change resolves it. The skill routes the finding to the team that owns it instead of proposing a fix.

Considerations

  • Diagnosis needs only Develocity data, so the skill runs against a failure on a build you did not run. Fixing a code-fixable failure is different: opening a pull request needs a checkout the skill can commit from, so run it where the affected project is checked out. Without one, the skill records the diagnosis instead.

  • A flaky diagnosis carries a confidence grade backed by the per-execution failure detail Develocity captures for Gradle and Maven builds. When that detail is absent, the grade is capped rather than the run blocked.

  • The skill uses your AI agent’s model, so each run consumes model tokens. Set budget and turn limits in your agent to bound a run.

  • Develocity is required throughout. The skill diagnoses from Develocity data and has no offline mode.