Security patch workflow
[COLM'26] SkillLearnBench is the first benchmark for evaluating continual learning methods that automatically generate agent skills.
npx -y skills add cxcscmu/SkillLearnBench --skill security-patch-workflowAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
What its author says it does
Copied from the file, not written here
How to create, apply, and verify security patches for git repositories. Use this skill when creating patches from code changes, applying patches to source code, or validating that patches correctly address vulnerabilities.
SKILL.md
4.3 KB, ~1.0k tokens by cl100k_base, as published. Nobody here has run it
Security Patch Workflow
Overview
Security patches are created as unified diff files that can be transported and applied to source code repositories. This workflow covers creating patches from changes and applying them to Druid or other git repositories.
Creating Patches
Method 1: Creating Patch from Uncommitted Changes
If you've edited files directly:
cd /root/druid
git diff > /root/patches/fix-vulnerability.patch
Method 2: Creating Patch from Committed Changes
If changes are already committed:
cd /root/druid
git format-patch -1 HEAD -o /root/patches/
This creates a patch file named like 0001-fix-vulnerability.patch
Method 3: Creating Patch from Multiple Commits
cd /root/druid
git format-patch HEAD~3..HEAD -o /root/patches/
Creates patches for the last 3 commits.
Understanding Patch File Format
A unified diff patch file contains:
- File paths with
a/andb/prefixes - Hunk headers showing line numbers
- Lines prefixed with
-(removed),+(added), or(context)
Example:
--- a/src/main/java/org/apache/druid/query/filter/JavaScriptFilter.java
+++ b/src/main/java/org/apache/druid/query/filter/JavaScriptFilter.java
@@ -45,6 +45,12 @@
public void init() {
// initialization code
+ // Add validation for filter specification
+ if (filterSpec.containsKey("")) {
+ throw new IllegalArgumentException(
+ "Invalid filter specification: contains empty keys");
+ }
}
Applying Patches
Method 1: Using git apply
Non-interactive application, good for automation:
cd /root/druid
git apply /root/patches/fix-vulnerability.patch
Method 2: Using git am (Recommended for Commits)
If the patch was created with git format-patch:
cd /root/druid
git am /root/patches/0001-fix-vulnerability.patch
Method 3: Using patch Command
Direct application with the patch utility:
cd /root/druid
patch -p1 < /root/patches/fix-vulnerability.patch
Verifying Patch Application
After applying a patch, verify:
1. Check Git Status
cd /root/druid
git status
You should see modified files (if using git apply) or new commits (if using git am).
2. Review Changed Files
cd /root/druid
git diff HEAD~1..HEAD # if patch was committed
# or
git diff # if patch was applied but not committed
3. Verify Specific Fixes
Look for:
- Expected files were modified
- Validation logic was added
- Security checks are in place
- No unintended changes
Handling Patch Conflicts
If a patch doesn't apply cleanly:
cd /root/druid
git apply --reject /root/patches/fix-vulnerability.patch
This creates .rej files showing conflicts. Manually merge them:
# View the .rej files
find . -name "*.rej" -exec cat {} \;
# Manually fix the conflicts in the source files
# Then remove the .rej files
find . -name "*.rej" -delete
# Apply remaining patches
git add .
git commit -m "Apply security patch (manual resolution)"
Patch Best Practices
- Minimal changes: Patches should contain only the necessary fixes
- Clear context: Include sufficient context lines for reliable application
- No unrelated changes: Don't mix security fixes with refactoring
- Test before patching: Verify the original code builds and runs
- Test after patching: Verify the patched code builds and runs correctly
- Document the patch: Include a description of the vulnerability and fix
Creating a Patch Series
For multiple related patches:
# Create numbered patches
git format-patch -3 -o /root/patches/
# List them
ls /root/patches/*.patch
# Apply all in order
cd /root/druid
git am /root/patches/*.patch
Validating Patch Content
Before applying, review the patch to ensure it's legitimate:
cat /root/patches/fix-vulnerability.patch | head -50
Check for:
- Appropriate file modifications
- No suspicious code patterns
- Clear change descriptions
- Expected syntax and structure
Gives 0 of the 12 instructions most automation workflows skills give in ~1.0k tokens
Counted across 745 of the 1,008 authors here whose files we hold, read 2026-08-06
- write conventional commit messagesin 36 of 745, across 35 files
- delete branches after mergein 30 of 745, across 21 files
- make atomic commitsin 25 of 745, across 15 files
- write minimal code to pass testsin 22 of 745, across 10 files
- run tests before committingin 21 of 745, across 13 files
- re-snapshot after navigation or DOM changesin 21 of 745, across 13 files
- use try-catch for error handlingin 20 of 745, across 6 files
- write tests before implementationin 20 of 745, across 8 files
- configure branch protection rulesin 19 of 745, across 5 files
- explain the why in commit messagesin 19 of 745, across 9 files
- refactor code while tests remain greenin 19 of 745, across 6 files
- Interact with elements using refsin 19 of 745, across 11 files
Said here and by no other author read
- create patches from uncommitted changes using git diff
- create patches from committed changes using git format-patch
- use git apply to apply patches non-interactively
- use git am to apply formatted patch commits
- check git status after applying a patch
- review changed files after applying a patch
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.