PostToolUse build gate

Without a build gate, an agent can produce ten consecutive edits that compile individually but break the solution as a set. The PostToolUse build gate runs after any multi-file edit and feeds the build output back into the agent’s context — turning compilation and test failures into immediate, plan-step-local feedback rather than end-of-session surprises.

The registration is a PostToolUse matcher; the multi-file logic lives in the script:

{
  "hooks": {
    "PostToolUse": [{
      "matcher": "Edit|Write",
      "hooks": [{ "type": "command", "command": ".claude/hooks/build-gate.ps1" }]
    }]
  }
}

The script keeps a small state file of files touched since the last green build. One edited file → skip, let the agent finish the unit of work. A second distinct file — or any edit to a .csproj or migration — triggers dotnet build, then dotnet test --filter scoped to the projects covering the touched files. On failure, the hook feeds back a trimmed report rather than the raw MSBuild wall of text: the first error per file with its line, the failing test names, and the touched-file list. Enough for the agent to localize the break without burning context on 400 lines of restore output.

When to use

• Any .NET solution where the build is fast enough to run between agent steps without significantly slowing the loop.
• Large refactors where the agent’s confidence in correctness needs to come from the compiler, not from its own reasoning.

Compare with

A pre-merge CI build catches the same failures, but only after the agent has produced the full PR. The PostToolUse build gate catches them per-step, which means the agent can recover before the failure compounds across subsequent edits.