@@ -1,125 +1 @@
1−Apply multiple find-and-replace edits to a single file in one operation; edits run sequentially. Prefer over edit for multiple changes to the same file. Same exact-match rules as edit apply.
1+Apply multiple find-and-replace edits to a single file in one operation; edits run sequentially. Prefer over edit for multiple changes to the same file. Same exact-match rules as edit apply.
4−1. Use View tool to understand file contents and context
5−2. Verify directory path is correct
6−3. CRITICAL: Note exact whitespace, indentation, and formatting from View output
10−1. file_path: Absolute path to file (required)
11−2. 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)
18−- Edits applied sequentially in provided order.
19−- Each edit operates on result of previous edit.
20−- PARTIAL SUCCESS: If some edits fail, successful edits are still applied. Failed edits are returned in the response.
21−- File is modified if at least one edit succeeds.
22−- Ideal for several changes to different parts of same file.
26−All instructions from the Edit tool documentation apply verbatim to every edit item:
27−- Critical requirements for exact matching and uniqueness
28−- Warnings and common failures (tabs vs spaces, blank lines, brace placement, etc.)
29−- Verification steps before using, recovery steps, best practices, and whitespace checklist
30−Use the same level of precision as Edit. Multiedit often fails due to formatting mismatches—double-check whitespace for every edit.
33−<critical_requirements>
34−1. Apply Edit tool rules to EACH edit (see edit.md).
35−2. Edits are applied in order; successful edits are kept even if later edits fail.
36−3. Plan sequence carefully: earlier edits change the file content that later edits must match.
37−4. Ensure each old_string is unique at its application time (after prior edits).
38−5. Check the response for failed edits and retry them if needed.
39−</critical_requirements>
41−<verification_before_using>
42−1. View the file and copy exact text (including whitespace) for each target.
43−2. Check how many instances each old_string has BEFORE the sequence starts.
44−3. Dry-run mentally: after applying edit #N, will edit #N+1 still match? Adjust old_string/new_string accordingly.
45−4. Prefer fewer, larger context blocks over many tiny fragments that are easy to misalign.
46−5. If edits are independent, consider separate multiedit batches per logical region.
47−</verification_before_using>
50−- Operation continues even if some edits fail; check response for failed edits.
51−- Earlier edits can invalidate later matches (added/removed spaces, lines, or reordered text).
52−- Mixed tabs/spaces, trailing spaces, or missing blank lines commonly cause failures.
53−- replace_all may affect unintended regions—use carefully or provide more context.
58−1. Check the response metadata for the list of failed edits with their error messages.
59−2. View the file again to see the current state after successful edits.
60−3. Adjust the failed edits based on the new file content.
61−4. Retry the failed edits with corrected old_string values.
62−5. Consider breaking complex batches into smaller, independent operations.
66−- Ensure all edits result in correct, idiomatic code; don't leave code broken.
67−- Use absolute file paths (starting with /).
68−- Use replace_all only when you're certain; otherwise provide unique context.
69−- Match existing style exactly (spaces, tabs, blank lines).
70−- Review failed edits in the response and retry with corrections.
73−<whitespace_checklist>
74−For EACH edit, verify:
75−- [ ] Viewed the file first
76−- [ ] Counted indentation spaces/tabs
77−- [ ] Included blank lines if present
78−- [ ] Matched brace/bracket positioning
79−- [ ] Included 3–5 lines of surrounding context
80−- [ ] Verified text appears exactly once (or using replace_all deliberately)
81−- [ ] Copied text character-for-character, not approximated
82−</whitespace_checklist>
85−✅ Correct: Sequential edits where the second match accounts for the first change
90− old_string: "func A() {\n doOld()\n}",
91− new_string: "func A() {\n doNew()\n}",
94− // Uses context that still exists AFTER the first replacement
95− old_string: "func B() {\n callA()\n}",
96− new_string: "func B() {\n callA()\n logChange()\n}",
101−❌ Incorrect: Second old_string no longer matches due to whitespace change introduced by the first edit
106− old_string: "func A() {\n doOld()\n}",
107− new_string: "func A() {\n\n doNew()\n}", // Added extra blank line
110− old_string: "func A() {\n doNew()\n}", // Missing the new blank line, will FAIL
111− new_string: "func A() {\n doNew()\n logChange()\n}",
116−✅ Correct: Handling partial success
119−// If edit 2 fails, edit 1 is still applied
120−// Response will indicate:
121−// - edits_applied: 1
122−// - edits_failed: [{index: 2, error: "...", edit: {...}}]
123−// You can then retry edit 2 with corrected context