Patch many#
The patch_many tool applies several patch-style changes in one call and
commits them atomically: if any hunk fails validation, no file is written. It is
meant for cross-cutting edits (“rename this symbol”, “add a parameter and update
its callers”) that would otherwise take one patch call per file.
Patches are validated in-memory before anything lands, so a failed hunk validation leaves files unchanged. If a file write fails, rollback is best-effort and a partial refactor may remain on disk.
Gives the LLM agent the ability to patch multiple files atomically in one tool call.
Intended for cross-cutting changes (“rename this class”, “add a param and update callers”) where the model would otherwise issue N separate patch calls, one per file.
Instructions
Apply patches to multiple files atomically.
Patches are validated in-memory: if ANY fails, NO files are written.
Simple (one hunk per file), paths in the fence header:
```patch_many path1.py
<<<<<<< ORIGINAL
old content
=======
new content
>>>>>>> UPDATED
```
Multi-hunk (any number of hunks per file), using `=== PATH: ... ===` headers:
```patch_many
=== PATH: path1.py ===
<<<<<<< ORIGINAL
first hunk original
=======
first hunk updated
>>>>>>> UPDATED
<<<<<<< ORIGINAL
second hunk original
=======
second hunk updated
>>>>>>> UPDATED
```
Tool-call: `patches` is a JSON array of {"path": "...", "patch": "..."} entries.
Each patch string may hold multiple ORIGINAL/UPDATED blocks, so one entry lands
several hunks.
Repeated paths apply in order, each hunk seeing the previous result. Prefer one
entry per path with multiple blocks; repeat a path only when a later hunk depends
on an earlier one landing.