Build failure analysis that people actually read

The first version of our build analysis explained the error. It was accurate and nobody read it, because the developer had already read the error themselves. What they needed was the file.

Ask for the decision, not the explanation

We changed the instruction to produce one file path and one sentence of justification. The output became skimmable, and we could measure it: was the named file part of the commit that broke the build?

Bound the input

lines_from_end: 400
include_build_metadata: true
include_dependency_manifest_names: true
include_environment_values: false
max_output_tokens: 300

Four hundred lines is enough for most compiler and dependency failures. When it is not, the answer is visibly uncertain rather than confidently wrong, which is the better failure.

Redact before sending, and say that you did

Connection strings, keys beside the words token or secret, and email addresses inside log lines are replaced with a placeholder. The placeholder is preserved in the prompt so the answer can still say that a database URL was present without receiving it.

One attempt

No retry loop. A provider outage should degrade the feature, not consume the budget silently. The console shows the analysis as unavailable and moves on.