菜单
Use when the user needs to create, apply, verify, or revert patches for source files using the Linux diff and patch utilities, or when generating sed-based inline edits as a lightweight alternative.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | patch |
| description | Use when the user needs to create, apply, verify, or revert patches for source files using the Linux diff and patch utilities, or when generating sed-based inline edits as a lightweight alternative. |
Manage file changes using the standard Linux diff, patch, and sed utilities.
This skill covers single-file patches, multi-file patches, directory diffs, Git-format
patches, and inline sed edits.
Always produce unified diffs (-u); they are the most readable format and the
standard expected by most tools.
diff -u original_file modified_file > changes.patch
For patching entire directory trees, use -ruN:
| Flag | Purpose |
|---|---|
-r | Recurse into subdirectories |
-u | Unified format |
-N | Treat absent files as empty (captures new/deleted files) |
diff -ruN original_dir/ modified_dir/ > changes.patch
When working inside a Git repository, prefer git diff or git format-patch
because they embed commit metadata, binary diffs, and rename detection.
# Unstaged changes
git diff > changes.patch
# Staged changes
git diff --cached > changes.patch
# Between commits / branches
git diff <base>..<head> -- path/to/file > changes.patch
# One patch file per commit (for email / review workflows)
git format-patch -n <base>
sed CommandsFor small, surgical edits (one or two lines), a sed one-liner is often simpler
than a full patch file. Document the intent in a comment.
# Replace the first occurrence of OLD with NEW on line 42
sed -i '42s/OLD/NEW/' path/to/file
# Insert text after line 176
sed -i '176a\ new line of code here' path/to/file
# Insert contents of another file after line 176
sed -i '176r /tmp/fragment.java' path/to/file
# Delete lines 10 through 15
sed -i '10,15d' path/to/file
Tip: On macOS,
sed -irequires an explicit backup extension (e.g.,sed -i '' ...). On GNU/Linux,sed -iedits in place with no backup unless you add an extension (e.g.,sed -i.bak ...).
patch < changes.patch
-p)Patches generated from a different directory depth require stripping leading path
components. The most common value is -p1, which removes the first directory
component (e.g., a/src/Main.java becomes src/Main.java).
patch -p1 < changes.patch
# Apply to a single target file
patch target_file < changes.patch
# Apply from a specific working directory
cd /path/to/project && patch -p1 < /tmp/changes.patch
# Apply and create a commit with the original author/message
git am < 0001-fix-typo.patch
# Apply without committing
git apply changes.patch
Always dry-run first to confirm the patch applies cleanly.
patch --dry-run < changes.patch
For Git patches:
git apply --check changes.patch
If the dry run reports failures, inspect the reject files (.rej) or fuzz
warnings before proceeding.
patch -R < changes.patch
For Git patches:
git apply -R changes.patch
When a patch does not apply cleanly:
.rej files — patch writes rejected hunks to <file>.rej..rej file.To increase the allowed fuzz (use with caution):
patch --fuzz=3 < changes.patch
| Option | Description |
|---|---|
-u | Unified diff format (for diff) |
-r | Recursive (for diff) |
-N | Treat absent files as empty (for diff) |
-p<N> | Strip N leading path components |
-b | Create a .orig backup of each patched file |
--dry-run | Test without modifying files |
-R | Reverse (unapply) a patch |
--fuzz=<N> | Allow N lines of fuzz when matching context |
-d <dir> | Change to <dir> before applying |
--verbose | Print detailed progress |
-o <file> | Write output to <file> instead of patching in place |
-i <file> | Read patch from <file> (alternative to stdin redirection) |
Follow this sequence for every patch operation:
diff -u or git diff).cat changes.patch or open in editor).patch --dry-run < changes.patch).patch -b < changes.patch or cp manually).patch -p1 < changes.patch).fix-npe-in-asset-adaptor.patch).-b or commit to version control before patching.git diff / git apply handle renames, binary
files, and permissions better than plain diff / patch.diff and patch are designed for text;
use Git LFS or binary-aware tools for non-text assets.sed for trivial edits — For one-line substitutions or insertions,
a sed command is faster and more transparent than a patch file.| Symptom | Likely Cause | Fix |
|---|---|---|
Hunk #N FAILED | Target file has diverged from the patch context | Inspect .rej, resolve manually, or regenerate the patch |
can't find file to patch | Wrong working directory or path strip level | Use -p0, -p1, etc., or -d <dir> to set the correct base |
Reversed (or previously applied) patch detected | Patch was already applied | Confirm with --dry-run; use -R if you need to unapply |
patch unexpectedly ends in middle of line | Missing trailing newline in patch file | Ensure patch file ends with a newline character |
Fuzz factor N warning | Context lines shifted but hunk still matched | Verify the patched file manually; the match may be incorrect |
| Permission denied | Insufficient write access to target file | Run with appropriate permissions or fix file ownership |
Stop CodeQL residual thrashing on Percussion CMS PRs. Use when working code-scanning alerts, security advisories, SSRF/LDAP/path/XXE fixes, // codeql suppressions, query-filters, model packs, or PR checks named CodeQL / Analyze (java-kotlin).
Strict pre-commit / pre-PR code review for Percussion CMS (Erlang persona). Use when the user says "Erlang", "review my changes", "pre-commit review", "pre-PR review", "strict review", or before git commit / gh pr create. Independent review only; blocks on bugs, missing behavioral tests, and non-portable (Windows/Unix) file path handling. Loads review memory and writes durable reports under docs/ai-generated/code-reviews/.
A skill for writing clean, maintainable, and effective Java unit tests using JUnit 5 and Mockito. Use when the user asks for "unit tests", "test cases", "tests", "JUnit", "Mockito", or related terms. Also use for migrating JUnit 3/4 tests to JUnit 5.
Best practices and version-correct Javadoc comment generation for percussioncms. Use when the user asks for "Javadoc", "Java documentation", "doc comments", "doc", "documentation", or related terms.
Centralized skill to verify the integrity and authenticity of AI resources (skills, prompts, instructions). Uses SHA-256 hashing and Sigstore sidecar signatures.
Manually invalidates a signature by renaming sidecar files.