メニュー
Apply multi-file or tricky edits atomically with git apply instead of many fragile edit_file calls. Use when changing several files at once or when edit_file fails to match.
Four-layer skill composition, skill marketplaces, the self-learning loop
四层技能合成、技能市场、自学习闭环
Use when the user asks for a summary, TL;DR, or condensed version of any content.
Search a codebase efficiently with ripgrep regular expressions, file globs, and git history search. Use to locate symbols, usages, and definitions instead of reading whole files.
Use git as a safety net - create a checkpoint commit before risky or large changes and roll back cleanly if a change makes things worse. Use before multi-file refactors.
Verify code changes by running the project's typecheck, build, lint, and targeted tests, then fix and re-run until clean. Use after editing any source file.
| name | apply-patch |
| description | Apply multi-file or tricky edits atomically with git apply instead of many fragile edit_file calls. Use when changing several files at once or when edit_file fails to match. |
The built-in edit_file does an exact string match on a single file and has no fuzzy
tolerance. For multi-file changes, or when edit_file keeps failing to find the string,
construct a unified diff and apply it atomically with git.
Write the unified diff to a file in the sandbox (use write_file or a heredoc via execute):
diff --git a/path/to/file b/path/to/file
--- a/path/to/file
+++ b/path/to/file
@@ -10,7 +10,7 @@ context line
-old line
+new line
Validate before applying: git apply --check changes.patch
Apply: git apply changes.patch (use -p0 if paths are not a/...b/...).
If git apply rejects the hunk, the surrounding context is stale — read_file the exact
lines again, regenerate the diff with correct context, and retry.
edit_file exact-match struggles.git diff).Always run the verify-changes skill afterwards.