1Makes multiple edits to a single file in one operation. Built on Edit tool for efficient multiple find-and-replace operations. Prefer over Edit tool for multiple edits to same file.
  2
  3<prerequisites>
  41. Use View tool to understand file contents and context
  52. Verify directory path is correct
  63. CRITICAL: Note exact whitespace, indentation, and formatting from View output
  7</prerequisites>
  8
  9<parameters>
 101. file_path: Absolute path to file (required)
 112. edits: Array of edit operations, each containing:
 12   - old_string: Text to replace (must match exactly including whitespace/indentation)
 13   - new_string: Replacement text
 14   - replace_all: Replace all occurrences (optional, defaults to false)
 15</parameters>
 16
 17<operation>
 18- Edits applied sequentially in provided order.
 19- Each edit operates on result of previous edit.
 20- ATOMIC: If any single edit fails, the entire operation fails and no changes are applied.
 21- Ideal for several changes to different parts of same file.
 22</operation>
 23
 24<inherited_rules>
 25All instructions from the Edit tool documentation apply verbatim to every edit item:
 26- Critical requirements for exact matching and uniqueness
 27- Warnings and common failures (tabs vs spaces, blank lines, brace placement, etc.)
 28- Verification steps before using, recovery steps, best practices, and whitespace checklist
 29Use the same level of precision as Edit. Multiedit often fails due to formatting mismatches—double-check whitespace for every edit.
 30</inherited_rules>
 31
 32<critical_requirements>
 331. Apply Edit tool rules to EACH edit (see edit.md).
 342. Edits are atomic—either all succeed or none are applied.
 353. Plan sequence carefully: earlier edits change the file content that later edits must match.
 364. Ensure each old_string is unique at its application time (after prior edits).
 37</critical_requirements>
 38
 39<verification_before_using>
 401. View the file and copy exact text (including whitespace) for each target.
 412. Check how many instances each old_string has BEFORE the sequence starts.
 423. Dry-run mentally: after applying edit #N, will edit #N+1 still match? Adjust old_string/new_string accordingly.
 434. Prefer fewer, larger context blocks over many tiny fragments that are easy to misalign.
 445. If edits are independent, consider separate multiedit batches per logical region.
 45</verification_before_using>
 46
 47<warnings>
 48- Operation fails if any old_string doesn’t match exactly (including whitespace) or equals new_string.
 49- Earlier edits can invalidate later matches (added/removed spaces, lines, or reordered text).
 50- Mixed tabs/spaces, trailing spaces, or missing blank lines commonly cause failures.
 51- replace_all may affect unintended regions—use carefully or provide more context.
 52</warnings>
 53
 54<recovery_steps>
 55If the operation fails:
 561. Identify the first failing edit (start from top; test subsets to isolate).
 572. View the file again and copy more surrounding context for that edit.
 583. Recalculate later old_string values based on the file state AFTER preceding edits.
 594. Reduce the batch (apply earlier stable edits first), then follow up with the rest.
 60</recovery_steps>
 61
 62<best_practices>
 63- Ensure all edits result in correct, idiomatic code; don’t leave code broken.
 64- Use absolute file paths (starting with /).
 65- Use replace_all only when you’re certain; otherwise provide unique context.
 66- Match existing style exactly (spaces, tabs, blank lines).
 67- Test after the operation; if it fails, fix and retry in smaller chunks.
 68</best_practices>
 69
 70<whitespace_checklist>
 71For EACH edit, verify:
 72- [ ] Viewed the file first
 73- [ ] Counted indentation spaces/tabs
 74- [ ] Included blank lines if present
 75- [ ] Matched brace/bracket positioning
 76- [ ] Included 3–5 lines of surrounding context
 77- [ ] Verified text appears exactly once (or using replace_all deliberately)
 78- [ ] Copied text character-for-character, not approximated
 79</whitespace_checklist>
 80
 81<examples>
 82✅ Correct: Sequential edits where the second match accounts for the first change
 83
 84```
 85edits: [
 86  {
 87    old_string: "func A() {\n    doOld()\n}",
 88    new_string: "func A() {\n    doNew()\n}",
 89  },
 90  {
 91    // Uses context that still exists AFTER the first replacement
 92    old_string: "func B() {\n    callA()\n}",
 93    new_string: "func B() {\n    callA()\n    logChange()\n}",
 94  },
 95]
 96```
 97
 98❌ Incorrect: Second old_string no longer matches due to whitespace change introduced by the first edit
 99
100```
101edits: [
102  {
103    old_string: "func A() {\n    doOld()\n}",
104    new_string: "func A() {\n\n    doNew()\n}", // Added extra blank line
105  },
106  {
107    old_string: "func A() {\n    doNew()\n}", // Missing the new blank line, will FAIL
108    new_string: "func A() {\n    doNew()\n    logChange()\n}",
109  },
110]
111```
112</examples>