agentsclimarketplace

Security patch workflow

Skill cxcscmu/SkillLearnBench/skills/b4-skill-creator-claude-haiku-4-5/fix-security-bug/security-patch-workflow

[COLM'26] SkillLearnBench is the first benchmark for evaluating continual learning methods that automatically generate agent skills.

Install
npx -y skills add cxcscmu/SkillLearnBench --skill security-patch-workflow

Assembled 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/ and b/ 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

  1. Minimal changes: Patches should contain only the necessary fixes
  2. Clear context: Include sufficient context lines for reliable application
  3. No unrelated changes: Don't mix security fixes with refactoring
  4. Test before patching: Verify the original code builds and runs
  5. Test after patching: Verify the patched code builds and runs correctly
  6. 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.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.